Re: kcsan -Wmaybe-uninitialized warning in ntfs3

[Marco Elver]

On Wed, 22 Apr 2026 at 22:57, Arnd Bergmann <arnd@xxxxxxxx> wrote:
>
> On Wed, Apr 22, 2026, at 10:23, Marco Elver wrote:
> > On Wed, 22 Apr 2026 at 10:00, Arnd Bergmann <arnd@xxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx/
> >> >
> >> > 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.

Thanks for confirming - this is rather unfortunate. I wish a suitable
attribute would exist to suppress this, but I guess that's not yet the
case.

Which means the simplest fix is probably the absolute_pointer() one.

Thanks,
-- Marco