Re: kcsan -Wmaybe-uninitialized warning in ntfs3

[Marco Elver]

On Tue, 21 Apr 2026 at 12:21, Arnd Bergmann <arnd@xxxxxxxx> wrote:
>
> On Tue, Apr 21, 2026, at 11:33, Marco Elver wrote:
> > On Tue, 21 Apr 2026 at 09:54, Arnd Bergmann <arnd@xxxxxxxx> wrote:
> >> What happens here is that copy_from_user() is used in a very
> >> normal way to copy a user space structure into a previously
> >> uninitialized on-stack buffer. With KCSAN enabled, this passes
> >> the pointer to that buffer into __kcsan_check_access(), which
> >> takes a 'const volatile void *' pointer. Gcc correctly notices
> >> that there is no way to access the data behind this pointer
> >> when it hasn't been initialized yet, as both read and write
> >> would cause undefined behavior.
> >>
> >> I'm not sure what a good solution would be to avoid this,
> >> but I assume this should be fixed in the kcsan instrumentation.
> >> I tried changing that code to pass non-const pointers for
> >> any instrument_write variant, which does avoid the warning,
> >> but also adds a bit of complexity, see below.
> >>
> >> Any other ideas?
> >
> > Indeed, the below is rather complex, and seems unnecessary to me just
> > to suppress this warning which not even the whole kernel enables.
> >
> > How can I reproduce this? GCC version? .config? I can't seem to with
> > an x86 defconfig + CONFIG_NTFS3_FS + KCSAN config + GCC on linux-next
> > (20260420).
>
> I ran into this during randconfig testing, I have attached a
> reproducer .config here, but have not tried to narrow down the
> configuration options that are required for triggering it.
>
> The compiler I used is a recent gcc-16.0.1 snapshot, but
> the same config produces the warning using earlier compilers
> as well, I see this with gcc-12.5 but not with gcc-11.5 or
> earlier.
>
> > There's likely a simpler option (attribute or warning suppression
> > around these functions) I want to try.
>
> I tried the 'unused' and 'uninitialized' attributes on the
> argument without success.
>
> I'm a bit worried that just using __diag_ignore() around the
> call would still leave the problem that gcc warns about, in case
> the compiler decides that this is undefined behavior and do
> something we don't want.

The warning is "maybe-uninitialized". GCC cannot prove what the called
function does with the argument; if it were to miscompile based on
wild assumptions around what a function does with a const-pointer,
that's a compiler bug.

I think diag_ignore() is the right thing here.

> Changing the type of the 'ptr' argument in the internal
> __kcsan_check_access() call to 'unsigned long' or perhaps
> a non-const pointer should avoid the warning.

non-const doesn't work for read (const) accesses.

I still cannot reproduce it - I've tried various permutations and
compiler versions.