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

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

[Nathan Chancellor]

On Mon, May 18, 2026 at 09:35:59AM +0200, Christian Brauner 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.

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@intel.com/
  https://lore.kernel.org/202605021450.ca5QGqLH-lkp@intel.com/

-- 
Cheers,
Nathan

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

[David Howells]

Nathan Chancellor <nathan@kernel.org> 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

I guess.  Can we remove that?

> 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@intel.com/
>   https://lore.kernel.org/202605021450.ca5QGqLH-lkp@intel.com/

Gmail labelled them as spam :-(

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

David
---
commit dd962b95985a8b5bc564c5c4f6c48edbc2cbc02d
Author: David Howells <dhowells@redhat.com>
Date:   Mon May 18 21:45:45 2026 +0100

    cifs: Fix undefined variables
    
    Fix a couple of undefined variables introduced by the patch to fix tearing
    on ->remote_i_size and ->zero_point.  For some reason, make W=1 with gcc
    doesn't give undefined variable warnings (but clang does).
    
    Fixes: 2c8f4742bb76 ("netfs: Fix potential for tearing in ->remote_i_size and ->zero_point")
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202605031459.eX5UbO3K-lkp@intel.com/
    Closes: https://lore.kernel.org/oe-kbuild-all/202605021450.ca5QGqLH-lkp@intel.com/
    cc: Steve French <sfrench@samba.org>
    cc: Paulo Alcantara <pc@manguebit.org>
    cc: Matthew Wilcox <willy@infradead.org>
    cc: Christian Brauner <brauner@kernel.org>
    cc: linux-cifs@vger.kernel.org
    cc: netfs@lists.linux.dev
    cc: linux-fsdevel@vger.kernel.org

diff --git a/fs/smb/client/cifsfs.c b/fs/smb/client/cifsfs.c
index feac491c5070..f557eb7875c7 100644
--- a/fs/smb/client/cifsfs.c
+++ b/fs/smb/client/cifsfs.c
@@ -1304,7 +1304,7 @@ static loff_t cifs_remap_file_range(struct file *src_file, loff_t off,
 	struct cifsFileInfo *smb_file_src = src_file->private_data;
 	struct cifsFileInfo *smb_file_target = dst_file->private_data;
 	struct cifs_tcon *target_tcon, *src_tcon;
-	unsigned long long i_size, old_size, new_size, zero_point;
+	unsigned long long i_size, new_size;
 	unsigned long long destend, fstart, fend;
 	unsigned int xid;
 	int rc;
@@ -1372,7 +1372,7 @@ static loff_t cifs_remap_file_range(struct file *src_file, loff_t off,
 		goto unlock;
 
 	spin_lock(&target_inode->i_lock);
-	if (fend > zero_point)
+	if (fend > target_cifsi->netfs._zero_point)
 		netfs_write_zero_point(target_inode, fend + 1);
 	i_size = target_inode->i_size;
 	spin_unlock(&target_inode->i_lock);
@@ -1387,7 +1387,7 @@ static loff_t cifs_remap_file_range(struct file *src_file, loff_t off,
 	if (target_tcon->ses->server->ops->duplicate_extents) {
 		rc = target_tcon->ses->server->ops->duplicate_extents(xid,
 			smb_file_src, smb_file_target, off, len, destoff);
-		if (rc == 0 && new_size > old_size) {
+		if (rc == 0 && new_size > i_size) {
 			truncate_setsize(target_inode, new_size);
 			fscache_resize_cookie(cifs_inode_cookie(target_inode),
 					      new_size);

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@kernel.org> 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@intel.com/
> >   https://lore.kernel.org/202605021450.ca5QGqLH-lkp@intel.com/
> 
> 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