[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 2/5] libxencall: osdep_hypercall() should return long


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 18 Jun 2021 15:42:25 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=t4noPiWMcK0oPSOckF4kf0ES74lzeH7J4YEp4oJnJ8k=; b=P4+avrM5BXOuYPP4nb+1eogrUfksbl7tYnlpNE1g4yrAoiBz+fhuaAZ8clG5FxiFoOQ/0Vv8MxKLD7beU9VSMchqgNJI+ehR+91GPcc6k7JNSG8t3W7UZJTsmf8W07GCT6gos76URluLIwnskXeq/H9flZrB54ob6v+drXizbgIDAYatyBMiVP9kZ+eG0S30KGncyrted5xl2bQ8U41SAiDVU1aSTSN+8/udcGQDzkW7Ndbd2cd7BDB7U9kP6zH5DCzDr9j9YGPXByf3SQtvf+BWVr9d3tkDAm5iFsqtJpe7g3gmDWEfDHrdSYCt7C+ODb/G17uq1lcuUrUqYOzeZQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SHoGsd1vr0EjB873neCu6XzwjhqQlihpydz/4/rImwXjWUAYToPFFspPQEgvNzyBPmbqVuCp292Y1QyAumMZwtp8GfBHmzEXxzsKAxjwvZ9OpZvcyDGir61kMInoVKuzQ7H8Id+Ce0u2Wfpp+lkk5sJHaCHR9ctP+B9CCw/PiHp4Jxq+I2DbTXKLlZr0t5XLMJfcEkYFhAtsoS1z4mGdVOQ4w4lDkT2wxFf16/pyNWVPo+FLnpwpgGAyIeKIlCQLL+o7JnRafuO8tKHprGuWj+x2vuiHv4/CyZ38dKo5aHRhxxM3umSBYuZpObsP0da9V90QnQK/a/VkY9p9vH6ukQ==
  • Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com;
  • Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 18 Jun 2021 13:42:43 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 18.06.2021 15:26, Andrew Cooper wrote:
> On 18/06/2021 11:23, Jan Beulich wrote:
>> Some hypercalls, memory-op in particular, can return values requiring
>> more than 31 bits to represent. Hence the underlying layers need to make
>> sure they won't truncate such values. (Note that for Solaris the
>> function also gets renamed, to match the other OSes.)
> 
> Spot the environment which obviously hasn't been compiled since the
> 4.5(?) timeframe...
> 
> Also, I'm fairly sure the comment in the NetBSD version is false when it
> says it is copying the Linux way of doing things - I'm pretty sure it
> means copying the FreeBSD way.

It doesn't say "copy", but "mimic", and I think what it means is the
effect for its callers. Therefore I think the comment makes sense in
its current shape. And I don't think I should change it right here
anyway.

>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> I think the commit message needs to state that this doesn't fix
> truncation in the Linux or Solaris, nor the truncation in the
> xencall{0..5}() public APIs.  It only fixes truncation issues for
> FreeBSD, MiniOS and NetBSD.

I've added

"Due to them merely propagating ioctl()'s return value, this change is
 benign on Linux and Solaris. IOW there's an actual effect here only for
 the BSDs and MiniOS, but even then further adjustments are needed at the
 xencall<N>() level."

> With a suitable adjustment, and ideally a fix to the NetBSD comment,
> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

Thanks.

Jan




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.