linux-kernel - Re: [PATCH V3 1/2] uapi: Define GENMASK

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <8b780eda-bb64-4baf-8e24-501baf8ed8db@app.fastmail.com>
Date: Tue, 20 Aug 2024 08:35:37 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Anshuman Khandual" <anshuman.khandual@....com>,
 linux-kernel@...r.kernel.org
Cc: "Ard Biesheuvel" <ardb@...nel.org>,
 "Andrew Morton" <akpm@...ux-foundation.org>,
 "Yury Norov" <yury.norov@...il.com>,
 "Rasmus Villemoes" <linux@...musvillemoes.dk>,
 Linux-Arch <linux-arch@...r.kernel.org>
Subject: Re: [PATCH V3 1/2] uapi: Define GENMASK_U128

On Tue, Aug 20, 2024, at 03:25, Anshuman Khandual wrote:
> On 8/19/24 12:43, Arnd Bergmann wrote:
>
> Should not the second shift operation warn about the possible
> overflow scenario ? But actually it does not. Or the compiler
> is too smart in detecting what's happening next in the overall
> equation and do the needful while creating the mask below the
> highest bit.

Not sure about the reasoning behind the compiler warning for
one but not the other, but I know that we rely on similar
behavior in places like:

#define upper_32_bits(n) ((u32)(((n) >> 16) >> 16))

which is intended to return a zero without a compiler
warning when passing an 'unsigned long' input on 32-bit
architectures.

      Arnd