mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "linyujun (C)" <linyujun809@huawei.com>
To: Ard Biesheuvel <ardb@kernel.org>, Mark Rutland <mark.rutland@arm.com>
Cc: <catalin.marinas@arm.com>, <will@kernel.org>,
	<broonie@kernel.org>, <kristina.martsenko@arm.com>,
	<james.morse@arm.com>, <maz@kernel.org>,
	<samitolvanen@google.com>, <andreyknvl@gmail.com>,
	<masahiroy@kernel.org>, <joey.gouly@arm.com>,
	<anshuman.khandual@arm.com>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <wanghai38@huawei.com>
Subject: Re: [PATCH -next] arm64: Optimize the comparison of unsigned expressions to avoid compiling error
Date: Wed, 22 Feb 2023 15:08:16 +0800	[thread overview]
Message-ID: <b6f596c9-b246-e1d8-0020-64e9b56c3914@huawei.com> (raw)
In-Reply-To: <CAMj1kXHyv1_56-CdX-egQTxnJn5ob15=TrfSOGmp+s019EfT2w@mail.gmail.com>

Thanks for your advice


在 2023/2/21 23:10, Ard Biesheuvel 写道:
> On Tue, 21 Feb 2023 at 11:37, Mark Rutland <mark.rutland@arm.com> wrote:
>> On Tue, Feb 21, 2023 at 09:27:40AM +0800, Lin Yujun wrote:
>>> while compile arch/arm64/include/asm/cpufeature.h with
>>> -Werror=type-limits enabled, errors shown as below:
>>>
>>> ./arch/arm64/include/asm/cpufeature.h: In function 'system_supports_4kb_granule':
>>> ./arch/arm64/include/asm/cpufeature.h:653:14: error: comparison of unsigned expression >= 0 is always true [-Werror=type-limits]
>>>    return (val >= ID_AA64MMFR0_TGRAN4_SUPPORTED_MIN) &&
>>>                ^~
>>> ./arch/arm64/include/asm/cpufeature.h: In function 'system_supports_64kb_granule':
>>> ./arch/arm64/include/asm/cpufeature.h:666:14: error: comparison of unsigned expression >= 0 is always true [-Werror=type-limits]
>>>    return (val >= ID_AA64MMFR0_TGRAN64_SUPPORTED_MIN) &&
>>>                ^~
> The usefulness of this diagnostic is debatable even when the right
> hand is a literal '0' but warning about symbolic constants like this
> is actively evil.
>
> In general, preprocessor #defined values can depend on Kconfig
> settings or other build configuration switches, and this warning
> encourages us to remove the expression altogether, which could mean
> introducing a bug if the macro may assume values >0 in other
> configurations.
>
> Ergo, we must ignore -Wtype-limits until it is fixed, and can at least
> distinguish literal 0 constants from ones instantiated by a CPP macro.
>
>
>> When is the `-Werror=type-limits` flag enabled by the build system?
>>
>> We have patterns like this all over the kernel, and I don't think this is
>> indicative of a real problem, and I don't think that we need to change code to
>> make this warning disappear.
>>
>>> Modify the return judgment statement, use
>>> "((val - min) < (val - max - 1))" to confirm that returns
>>> true in “min <= val <= max” cases, false in other cases.
>> That expression is far less clear than the existing code, so I do not think
>> that is a good idea.
>>
>>> Fixes: 79d82cbcbb3d ("arm64/kexec: Test page size support with new TGRAN range values")
>> What functional error does this fix?
>>
>> What configuration is broken?
>>
>> Thanks,
>> Mark.
>>
>>> Signed-off-by: Lin Yujun <linyujun809@huawei.com>
>>> ---
>>>   arch/arm64/include/asm/cpufeature.h | 18 ++++++++++++------
>>>   1 file changed, 12 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
>>> index 03d1c9d7af82..0a6bda025141 100644
>>> --- a/arch/arm64/include/asm/cpufeature.h
>>> +++ b/arch/arm64/include/asm/cpufeature.h
>>> @@ -54,6 +54,9 @@ enum ftr_type {
>>>   #define FTR_VISIBLE_IF_IS_ENABLED(config)            \
>>>        (IS_ENABLED(config) ? FTR_VISIBLE : FTR_HIDDEN)
>>>
>>> +#define IN_RANGE_INCLUSIVE(val, min, max)            \
>>> +     (((val) - (min)) < ((val) - (max) - 1))
>>> +
>>>   struct arm64_ftr_bits {
>>>        bool            sign;   /* Value is signed ? */
>>>        bool            visible;
>>> @@ -693,8 +696,9 @@ static inline bool system_supports_4kb_granule(void)
>>>        val = cpuid_feature_extract_unsigned_field(mmfr0,
>>>                                                ID_AA64MMFR0_EL1_TGRAN4_SHIFT);
>>>
>>> -     return (val >= ID_AA64MMFR0_EL1_TGRAN4_SUPPORTED_MIN) &&
>>> -            (val <= ID_AA64MMFR0_EL1_TGRAN4_SUPPORTED_MAX);
>>> +     return IN_RANGE_INCLUSIVE(val,
>>> +             ID_AA64MMFR0_EL1_TGRAN4_SUPPORTED_MIN,
>>> +             ID_AA64MMFR0_EL1_TGRAN4_SUPPORTED_MAX);
>>>   }
>>>
>>>   static inline bool system_supports_64kb_granule(void)
>>> @@ -706,8 +710,9 @@ static inline bool system_supports_64kb_granule(void)
>>>        val = cpuid_feature_extract_unsigned_field(mmfr0,
>>>                                                ID_AA64MMFR0_EL1_TGRAN64_SHIFT);
>>>
>>> -     return (val >= ID_AA64MMFR0_EL1_TGRAN64_SUPPORTED_MIN) &&
>>> -            (val <= ID_AA64MMFR0_EL1_TGRAN64_SUPPORTED_MAX);
>>> +     return IN_RANGE_INCLUSIVE(val,
>>> +             ID_AA64MMFR0_EL1_TGRAN64_SUPPORTED_MIN,
>>> +             ID_AA64MMFR0_EL1_TGRAN64_SUPPORTED_MAX);
>>>   }
>>>
>>>   static inline bool system_supports_16kb_granule(void)
>>> @@ -719,8 +724,9 @@ static inline bool system_supports_16kb_granule(void)
>>>        val = cpuid_feature_extract_unsigned_field(mmfr0,
>>>                                                ID_AA64MMFR0_EL1_TGRAN16_SHIFT);
>>>
>>> -     return (val >= ID_AA64MMFR0_EL1_TGRAN16_SUPPORTED_MIN) &&
>>> -            (val <= ID_AA64MMFR0_EL1_TGRAN16_SUPPORTED_MAX);
>>> +     return IN_RANGE_INCLUSIVE(val,
>>> +             ID_AA64MMFR0_EL1_TGRAN16_SUPPORTED_MIN,
>>> +             ID_AA64MMFR0_EL1_TGRAN16_SUPPORTED_MAX);
>>>   }
>>>
>>>   static inline bool system_supports_mixed_endian_el0(void)
>>> --
>>> 2.34.1
>>>
> .

      reply	other threads:[~2023-02-22  7:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-21  1:27 Lin Yujun
2023-02-21 10:36 ` Mark Rutland
2023-02-21 15:10   ` Ard Biesheuvel
2023-02-22  7:08     ` linyujun (C) [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b6f596c9-b246-e1d8-0020-64e9b56c3914@huawei.com \
    --to=linyujun809@huawei.com \
    --cc=andreyknvl@gmail.com \
    --cc=anshuman.khandual@arm.com \
    --cc=ardb@kernel.org \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=james.morse@arm.com \
    --cc=joey.gouly@arm.com \
    --cc=kristina.martsenko@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=masahiroy@kernel.org \
    --cc=maz@kernel.org \
    --cc=samitolvanen@google.com \
    --cc=wanghai38@huawei.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®