* Re: [GIT PULL for v7.1] vfs fixes [not found] <20260518-vfs-7.1-rc5.fixes-3eded3a501f4@brauner> @ 2026-05-18 19:46 ` Nathan Chancellor 2026-05-18 21:05 ` David Howells 0 siblings, 1 reply; 3+ messages in thread From: Nathan Chancellor @ 2026-05-18 19:46 UTC (permalink / raw) To: Christian Brauner, David Howells Cc: Linus Torvalds, linux-fsdevel, linux-kernel, Steve French, linux-cifs, Paulo Alcantara 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [GIT PULL for v7.1] vfs fixes 2026-05-18 19:46 ` [GIT PULL for v7.1] vfs fixes Nathan Chancellor @ 2026-05-18 21:05 ` David Howells 2026-05-18 21:32 ` Nathan Chancellor 0 siblings, 1 reply; 3+ messages in thread From: David Howells @ 2026-05-18 21:05 UTC (permalink / raw) To: Nathan Chancellor, Steve French Cc: dhowells, Christian Brauner, Linus Torvalds, linux-fsdevel, linux-kernel, linux-cifs, Paulo Alcantara 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); ^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [GIT PULL for v7.1] vfs fixes 2026-05-18 21:05 ` David Howells @ 2026-05-18 21:32 ` Nathan Chancellor 0 siblings, 0 replies; 3+ messages in thread From: Nathan Chancellor @ 2026-05-18 21:32 UTC (permalink / raw) To: David Howells Cc: Steve French, Christian Brauner, Linus Torvalds, linux-fsdevel, linux-kernel, linux-cifs, Paulo Alcantara 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-05-18 21:32 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20260518-vfs-7.1-rc5.fixes-3eded3a501f4@brauner>
2026-05-18 19:46 ` [GIT PULL for v7.1] vfs fixes Nathan Chancellor
2026-05-18 21:05 ` David Howells
2026-05-18 21:32 ` Nathan Chancellor
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox