Re: [PATCH v3] fs: fix undefined behavior in bit shift for SB_NOUSER

[Al Viro <viro@zeniv.linux.org.uk>]

On Mon, Oct 31, 2022 at 10:26:21PM +0800, Gaosheng Cui wrote:
> Shifting signed 32-bit value by 31 bits is undefined, so changing most
> significant bit to unsigned, and mark all of the flags as unsigned so
> that we don't mix types. The UBSAN warning calltrace like below:

... is completely irrelevant.  If you want to credit UBSAN for finding
that - sure, no problem, but who cares about the call chain leading to
use of SB_NOUSER?  If nothing else, report would be just as valid if
the only use had been in initializer for static variable...

I've no problem with the change itself, but I'd go with something along
the lines of

----
SB_... flags are masks for struct super_block ->s_flags, which is an
unsigned long.  In particular, SB_NOUSER lives in bit 31.  1 << 31
is not the right way to spell that - it's not just that it is an
undefined behaviour; it's not the right value when used to initialize
an unsigned long variable.  Nasal demons aside, on 64bit architecture
	unsigned long v = 1 << 31;
is *not* going to have v equal to 0x80000000 - it'll be 0xffffffff80000000.

Make the entire bunch explicitly unsigned - 1U << constant.  Note that
it doesn't make sense to go for 1UL - the flags are arch-independent
and that limits us to 32 bits anyway.

Spotted by UBSAN.
----

for commit message.  Not sure about "Fixes:", to be honest...