Re: [GIT PULL for v7.1] vfs fixes

[Nathan Chancellor]

On Mon, May 18, 2026 at 10:05:00PM +0100, David Howells wrote:
> Nathan Chancellor <nathan@xxxxxxxxxx> wrote:
> 
> > > David Howells (22):
> > >       netfs: Fix potential for tearing in ->remote_i_size and ->zero_point
> > ...
> > >  fs/smb/client/cifsfs.c       |  38 ++++--
> > 
> > The changes in this file from that patch breaks the build with clang:
> > 
> >   fs/smb/client/cifsfs.c:1390:29: error: variable 'old_size' is uninitialized when used here [-Werror,-Wuninitialized]
> >    1390 |                 if (rc == 0 && new_size > old_size) {
> >         |                                           ^~~~~~~~
> >   fs/smb/client/cifsfs.c:1307:37: note: initialize the variable 'old_size' to silence this warning
> >    1307 |         unsigned long long i_size, old_size, new_size, zero_point;
> >         |                                            ^
> >         |                                             = 0
> >   fs/smb/client/cifsfs.c:1375:13: error: variable 'zero_point' is uninitialized when used here [-Werror,-Wuninitialized]
> >    1375 |         if (fend > zero_point)
> >         |                    ^~~~~~~~~~
> >   fs/smb/client/cifsfs.c:1307:59: note: initialize the variable 'zero_point' to silence this warning
> >    1307 |         unsigned long long i_size, old_size, new_size, zero_point;
> >         |                                                                  ^
> >         |                                                                   = 0
> >   2 errors generated.
> 
> For some reason, make W=1 with gcc doesn't seem to generate uninitialised
> variable warnings (though maybe clang does?).  Is that specifically
> suppressed?
> 
> 	ifdef CONFIG_CC_IS_GCC
> 	KBUILD_CFLAGS += -Wno-maybe-uninitialized
> 	endif

Yeah, clang's -Wuninitialized and -Wsometimes-uninitialized are on by
default (not just at W=1) for the kernel, whereas GCC's
-Wmaybe-uninitialized has been under W=2 since 78a5255ffb6a ("Stop the
ad-hoc games with -Wno-maybe-initialized") back in 5.7.

I consider this an unfortunate difference between GCC and clang with
regards to -Wuninitialized. If there is any control flow that would
avoid the block that uses the variable uninitialized, GCC "downgrades"
it to -Wmaybe-uninitialized, whereas clang keeps it as -Wuninitialized
with a note of "when used here" to make it clear that the variable will
be used uninitialized if the block is reached:

  https://godbolt.org/z/6eb5zK76T

> I guess.  Can we remove that?

It would be nice for my sanity if it could be but then we are back into
the same situation of false positives, as GCC's warnings are influenced
by optimizations, whereas clang's warnings happen purely in the frontend
before optimizations happen. clang's versions do not flag as many
instances of potentially uninitialized variables (as it cannot do
interprocedural analysis to see across function boundaries) but that
results in much fewer false positives in my experience.

> > There were no -next updates last week, so it seems like the majority of
> > this pull request saw zero -next testing time. I see two kbuild test
> > robot build reports but I guess they were ignored.
> > 
> >   https://lore.kernel.org/202605031459.eX5UbO3K-lkp@xxxxxxxxx/
> >   https://lore.kernel.org/202605021450.ca5QGqLH-lkp@xxxxxxxxx/
> 
> Gmail labelled them as spam :-(

Bummer :/

> I think this should be fixed as below, but Steve needs to look it over.

Thanks, I will give it a build test but it seems obvious that it will
fix it.

-- 
Cheers,
Nathan