Re: kcsan -Wmaybe-uninitialized warning in ntfs3

["Arnd Bergmann" <arnd@arndb.de>]

On Wed, Apr 22, 2026, at 10:23, Marco Elver wrote:
> On Wed, 22 Apr 2026 at 10:00, Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> On Tue, Apr 21, 2026, at 21:12, Arnd Bergmann wrote:
>> > On Tue, Apr 21, 2026, at 21:06, Marco Elver wrote:
>> >> On Tue, 21 Apr 2026 at 17:26, Marco Elver <elver@google.com> wrote:
>> >> [...]
>> >>> > To me, 2 makes more sense. The attribute requires gcc-11 or higher,
>> >>> > so you need to wrap that in a compiler version specific macro,
>> >>> > but since I only saw the warning with gcc-12 and higher, that
>> >>> > should be fine.
>> >>
>> >> Kindly test if you can:
>> >> https://lore.kernel.org/all/20260421190351.1976329-1-elver@google.com/
>> >
>> > Applied to my randconfig tree and verified that this fixes the
>> > known warning (only one out of about 200 random configs). I'll
>> > let you know if something comes up by tomorrow.
>>
>> Unfortunately, there are new warnings after your patches using
>> gcc-11. In 500 randconfig builds with that compiler, I saw 7
>> configurations failing with one of these four messages:
>
> Looks like a compiler bug to me; can you check gcc-12+ ? Maybe we need
> to allow the __access attribute only for later GCC versions.

All gcc versions I tried that support kcsan run into some of
the warnings, but the exact set is not always the same.

The stringop-overread warnings are (like -Wmaybe-uninitialized)
a bit unpredictable and depend on the exact optimizations taken
by the compiler, to see exactly which object is passed into
a string operation and what its size is.

I'm guessing that by annotating a function argument as being
not accessed, gcc starts assuming that the object has zero
valid bytes if it cannot deduce the actual length in any
other way.

     Arnd