Message ID | cover.1676908729.git.dsterba@suse.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [GIT,PULL] Btrfs updates for 6.3 | expand |
On Mon, Feb 20, 2023 at 11:26 AM David Sterba <dsterba@suse.com> wrote: > > Other: > > - locally enable -Wmaybe-uninitialized after fixing all warnings I've pulled this, but I strongly suspect this change will get reverted. I bet neither you nor linux-next is testing even _remotely_ a big chunk of the different compiler versions that are out there, and the reason flags like '-Wmaybe-uninitialized' get undone is because some random compiler version on some random config and target archiecture gives completely nonsensical warnings for odd reasons. But hey, maybe the btrfs code is special. Linus
The pull request you sent on Mon, 20 Feb 2023 20:20:08 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-6.3-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/885ce48739189fac6645ff42d736ee0de0b5917d
Thank you!
On 2/21/23 4:02 AM, Linus Torvalds wrote: > On Mon, Feb 20, 2023 at 11:26 AM David Sterba <dsterba@suse.com> wrote: >> Other: >> >> - locally enable -Wmaybe-uninitialized after fixing all warnings > > I've pulled this, but I strongly suspect this change will get reverted. > > I bet neither you nor linux-next is testing even _remotely_ a big > chunk of the different compiler versions that are out there, and the > reason flags like '-Wmaybe-uninitialized' get undone is because some > random compiler version on some random config and target archiecture > gives completely nonsensical warnings for odd reasons. > > But hey, maybe the btrfs code is special. Maybe it's too late for 6.3. So please fix this in 6.4 and backport it to 6.3 stable. If someone fixes it, kindly add: Reported-by: Memet <zxce3@gnuweeb.org> Compiling with GCC 9.4: gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0 Copyright (C) 2019 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Linux version 6.3-rc7: CC [M] fs/btrfs/volumes.o fs/btrfs/volumes.c: In function ‘btrfs_init_new_device’: fs/btrfs/volumes.c:2524:2: error: ‘seed_devices’ may be used uninitialized in this function [-Werror=maybe-uninitialized] 2524 | list_add(&seed_devices->seed_list, &fs_devices->seed_list); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ fs/btrfs/volumes.c:2621:27: note: ‘seed_devices’ was declared here 2621 | struct btrfs_fs_devices *seed_devices; | ^~~~~~~~~~~~ cc1: all warnings being treated as errors make[7]: *** [scripts/Makefile.build:252: fs/btrfs/volumes.o] Error 1 make[6]: *** [scripts/Makefile.build:494: fs/btrfs] Error 2 make[5]: *** [scripts/Makefile.build:494: fs] Error 2 make[4]: *** [Makefile:2025: .] Error 2 make[3]: *** [Makefile:357: __build_one_by_one] Error 2 make[2]: *** [debian/rules:8: build-arch] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 make[1]: *** [scripts/Makefile.package:120: bindeb-pkg] Error 2 make: *** [Makefile:1656: bindeb-pkg] Error 2 fs/btrfs/send.c: In function ‘get_cur_inode_state’: fs/btrfs/send.c:1909:13: error: ‘right_gen’ may be used uninitialized in this function [-Werror=maybe-uninitialized] 1909 | } else if (right_gen == gen) { | ^
On Sun, Apr 23, 2023 at 09:27:30AM +0700, Ammar Faizi wrote: > On 2/21/23 4:02 AM, Linus Torvalds wrote: > > On Mon, Feb 20, 2023 at 11:26 AM David Sterba <dsterba@suse.com> wrote: > >> Other: > >> > >> - locally enable -Wmaybe-uninitialized after fixing all warnings > > > > I've pulled this, but I strongly suspect this change will get reverted. > > > > I bet neither you nor linux-next is testing even _remotely_ a big > > chunk of the different compiler versions that are out there, and the > > reason flags like '-Wmaybe-uninitialized' get undone is because some > > random compiler version on some random config and target archiecture > > gives completely nonsensical warnings for odd reasons. > > > > But hey, maybe the btrfs code is special. > > Maybe it's too late for 6.3. So please fix this in 6.4 and backport it to > 6.3 stable. If someone fixes it, kindly add: Fix for this warning is in 6.4 pull request, there's no CC:stable tag but we can ask to add it once the code lands in master.
On Tue, Apr 25, 2023 at 04:54:12PM +0200, David Sterba wrote: > On Sun, Apr 23, 2023 at 09:27:30AM +0700, Ammar Faizi wrote: > > On 2/21/23 4:02 AM, Linus Torvalds wrote: > > > On Mon, Feb 20, 2023 at 11:26 AM David Sterba <dsterba@suse.com> wrote: > > >> Other: > > >> > > >> - locally enable -Wmaybe-uninitialized after fixing all warnings > > > > > > I've pulled this, but I strongly suspect this change will get reverted. > > > > > > I bet neither you nor linux-next is testing even _remotely_ a big > > > chunk of the different compiler versions that are out there, and the > > > reason flags like '-Wmaybe-uninitialized' get undone is because some > > > random compiler version on some random config and target archiecture > > > gives completely nonsensical warnings for odd reasons. > > > > > > But hey, maybe the btrfs code is special. > > > > Maybe it's too late for 6.3. So please fix this in 6.4 and backport it to > > 6.3 stable. > > Fix for this warning is in 6.4 pull request, there's no CC:stable tag > but we can ask to add it once the code lands in master. It landed in master. [ Adding stable team to the Cc list ] Hi Greg and stable team, could you please backport: commit 8ba7d5f5ba931be68a94b8c91bcced1622934e7a upstream ("btrfs: fix uninitialized variable warnings") to v6.3 to fix gcc (10, 9, 7) build error? The fs/btrfs/volumes.c hunk won't apply cleanly, but it can auto-merge: $ git cherry-pick 8ba7d5f5ba931be68a94b8c91bcced1622934e7a Auto-merging fs/btrfs/volumes.c [detached HEAD 572410288a1070c1] btrfs: fix uninitialized variable warnings Author: Genjian Zhang <zhanggenjian@kylinos.cn> Date: Fri Mar 24 10:08:38 2023 +0800 2 files changed, 2 insertions(+), 2 deletions(-) Thanks,
On Fri, Apr 28, 2023 at 10:14:58AM +0700, Ammar Faizi wrote: > On Tue, Apr 25, 2023 at 04:54:12PM +0200, David Sterba wrote: > > On Sun, Apr 23, 2023 at 09:27:30AM +0700, Ammar Faizi wrote: > > > On 2/21/23 4:02 AM, Linus Torvalds wrote: > > > > On Mon, Feb 20, 2023 at 11:26 AM David Sterba <dsterba@suse.com> wrote: > > > >> Other: > > > >> > > > >> - locally enable -Wmaybe-uninitialized after fixing all warnings > > > > > > > > I've pulled this, but I strongly suspect this change will get reverted. > > > > > > > > I bet neither you nor linux-next is testing even _remotely_ a big > > > > chunk of the different compiler versions that are out there, and the > > > > reason flags like '-Wmaybe-uninitialized' get undone is because some > > > > random compiler version on some random config and target archiecture > > > > gives completely nonsensical warnings for odd reasons. > > > > > > > > But hey, maybe the btrfs code is special. > > > > > > Maybe it's too late for 6.3. So please fix this in 6.4 and backport it to > > > 6.3 stable. > > > > Fix for this warning is in 6.4 pull request, there's no CC:stable tag > > but we can ask to add it once the code lands in master. > > It landed in master. > > [ Adding stable team to the Cc list ] > > Hi Greg and stable team, could you please backport: > > commit 8ba7d5f5ba931be68a94b8c91bcced1622934e7a upstream > ("btrfs: fix uninitialized variable warnings") > > to v6.3 to fix gcc (10, 9, 7) build error? > > The fs/btrfs/volumes.c hunk won't apply cleanly, but it can auto-merge: > > $ git cherry-pick 8ba7d5f5ba931be68a94b8c91bcced1622934e7a > Auto-merging fs/btrfs/volumes.c > [detached HEAD 572410288a1070c1] btrfs: fix uninitialized variable warnings > Author: Genjian Zhang <zhanggenjian@kylinos.cn> > Date: Fri Mar 24 10:08:38 2023 +0800 > 2 files changed, 2 insertions(+), 2 deletions(-) Now queued up, thanks. greg k-h