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

Re: [XEN PATCH] xen/types: address Rule 10.1 for macro BITS_TO_LONGS


  • To: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 6 Sep 2023 18:02:38 +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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4kUAf5eefgN+wtm6KtzSqpbLfYJJM/3+zBWnQ6BscKg=; b=IswLhB+QVfO+wdTNY3TVT34iWPOT/FlaVUS/JT11wQZ9NTo2mJMARsLVgYr8Q8e6SmDPrRZ9iu4yyfpZSfPxKWLnzXOVulnF0yQ8x4xOsUpidcY0rs7dJvYNEFl/dpbqMoAJCOzJjbSJWDcIFu2+TjusOWbFYuYHgzk1y/hglAl0WN1k3BCi7+7NdZkrtCjK7NF8HmhcBM/y20BeYG74Xw45JIwmK6tGdGPV9yIvezkOuOCQEfURoMWUBtCdLQm4Y8rWUpMrGRuOEggyQqw6DYS4RnWC3RgE2xatlcOi72dLmyRee5GVetSOIiNnKX6RGVNGf+m+mZ3WC3VUv1n/CA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iUurZB2cZ1YYvI+zD0typBMUNKbB7pVilajdsZaCcGEnNMmZWUtj8NOGOfBS5E9V1zdLZqXvvcQ2auHyw1ohxNaxjp8vIxn5+zfEZKMVJmQsnSTYVuhlyBGNxG41AJvb3JzTl/fWeTY+HDdZh3L+tSbXXYAaz2cjGkUYFEUFUPdQncwRvHWe9/LgYc7jOIi3EwGAW1D+eFrsDXxGR/4dek5q2PgT+nNcUfsyX/ZUjt+Lt/BHPoOzOt3o5U8w3pDoLjgcnHUQqynhRVW/6H+c2SGsvata4eNzjV/ds7nCu0lJZklN2e0Kj3jDSzpo8uXUO7HhZXKMWKv1gnpKeILGDA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: sstabellini@xxxxxxxxxx, michal.orzel@xxxxxxx, xenia.ragiadakou@xxxxxxx, ayan.kumar.halder@xxxxxxx, consulting@xxxxxxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 06 Sep 2023 16:02:50 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 06.09.2023 17:57, Nicola Vetrini wrote:
> On 05/09/2023 10:33, Jan Beulich wrote:
>> On 05.09.2023 10:20, Nicola Vetrini wrote:
>>> On 05/09/2023 09:46, Jan Beulich wrote:
>>>> On 05.09.2023 09:31, Nicola Vetrini wrote:
>>>>> Given its use in the declaration
>>>>> 'DECLARE_BITMAP(features, IOMMU_FEAT_count)' the argument
>>>>> 'bits' has essential type 'enum iommu_feature', which is not
>>>>> allowed by the Rule as an operand to the addition operator.
>>>>> Given that its value can be represented by a signed integer,
>>>>> the explicit cast resolves the violation.
>>>>
>>>> Wait - why would this lead to a change to BITS_TO_LONGS()? And if 
>>>> that
>>>> was to be changed, why plain int? I don't think negative input makes
>>>> sense there, and in principle I'd expect values beyond 4 billion to
>>>> also be permissible (even if likely no such use will ever appear in a
>>>> DECLARE_BITMAP(), but elsewhere it may make sense). Even going to
>>>> "unsigned long" may be too limiting ...
>>>>
>>>
>>> You have a point. I can think of doing it like this:
>>> DECLARE_BITMAP(features, (int)IOMMU_FEAT_count)
>>> on the grounds that the enum constant is representable in an int, and 
>>> it
>>> does not seem likely
>>> to get much bigger.
>>> Having an unsigned cast requires making the whole expression
>>> essentially unsigned, otherwise Rule 10.4 is violated because
>>> BITS_PER_LONG is
>>> essentially signed. This can be done, but it depends on how
>>> BITS_TO_LONGS will be/is used.
>>
>> It'll need looking closely, yes, but I expect that actually wants to be 
>> an
>> unsigned constant. I wouldn't be surprised if some use of 
>> DECLARE_BITMAP()
>> appeared (or already existed) where the 2nd argument involves sizeof() 
>> in
>> some way.
>>
> 
> I think there's one with ARRAY_SIZE. In my opinion this can be resolved 
> as follows:
> 
> #define BYTES_PER_LONG (1U << LONG_BYTEORDER) // the essential type gets 
> from signed to unsigned
> 
> #define BITS_TO_LONGS(bits) \
>          (((unsigned long long)(bits)+BITS_PER_LONG-1U)/BITS_PER_LONG) // 
> same here

Except, as said before, I consider any kind of cast on "bits" latently
problematic.

Jan




 


Rackspace

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