Date: 20220415 Kernel: 5.17.3 Compiler gcc.12.0.1 File: linux-5.17.3/fs/xfs/libxfs/xfs_attr_remote.c Line: 141 Issue: Linux kernel compiling enables all warnings, this has consequnces: -Wdangling-pointer= triggers because assignment of an address pointing to something inside of the local stack of a function/method is returned to the caller. Doing such things is tricky but legal, however gcc 12.0.1 complains deeply on this. Mitigation: disabling with pragmas temporarily inlined the compiler triggered advises. Interesting: clang-15.0.0 does not complain. Remark: this occurence is reprsentative; the compiler warns at many places To go pass through the compilation I added "-Wno-stringop-overread -Wno-dangling-pointer -Wno-address -Wno-array-bounds -Wno-stringop-truncatio" to the Makefile root file of the kernel tree. This is not the cleanest approach but it helps for time being.
On Mon, Apr 18, 2022 at 08:02:41AM +0000, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=215851 > > Bug ID: 215851 > Summary: gcc 12.0.1 LATEST: -Wdangling-pointer= triggers > Product: File System > Version: 2.5 > Kernel Version: 5.17.3 > Hardware: All > OS: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: XFS > Assignee: filesystem_xfs@kernel-bugs.kernel.org > Reporter: Erich.Loew@outlook.com > Regression: No > > Date: 20220415 > Kernel: 5.17.3 > Compiler gcc.12.0.1 > File: linux-5.17.3/fs/xfs/libxfs/xfs_attr_remote.c > Line: 141 > Issue: Linux kernel compiling enables all warnings, this has consequnces: > -Wdangling-pointer= triggers because assignment of an address > pointing > to something inside of the local stack > of a function/method is returned to the caller. > Doing such things is tricky but legal, however gcc 12.0.1 complains > deeply on this. > Mitigation: disabling with pragmas temporarily inlined the compiler > triggered advises. > Interesting: clang-15.0.0 does not complain. > Remark: this occurence is reprsentative; the compiler warns at many places The actual warning message is this: fs/xfs/libxfs/xfs_attr_remote.c: In function ‘__xfs_attr3_rmt_read_verify’: fs/xfs/libxfs/xfs_attr_remote.c:140:35: warning: storing the address of local variable ‘__here’ in ‘*failaddr’ [-Wdangling-pointer=] 140 | *failaddr = __this_address; In file included from ./fs/xfs/xfs.h:22, from fs/xfs/libxfs/xfs_attr_remote.c:7: ./fs/xfs/xfs_linux.h:133:46: note: ‘__here’ declared here 133 | #define __this_address ({ __label__ __here; __here: barrier(); &&__here; }) | ^~~~~~ fs/xfs/libxfs/xfs_attr_remote.c:140:37: note: in expansion of macro ‘__this_address’ 140 | *failaddr = __this_address; | ^~~~~~~~~~~~~~ ./fs/xfs/xfs_linux.h:133:46: note: ‘failaddr’ declared here 133 | #define __this_address ({ __label__ __here; __here: barrier(); &&__here; }) | ^~~~~~ fs/xfs/libxfs/xfs_attr_remote.c:140:37: note: in expansion of macro ‘__this_address’ 140 | *failaddr = __this_address; | ^~~~~~~~~~~~~~ I think this is a compiler bug. __here is declared as a *label*, not a local variable: #define __this_address ({ __label__ __here; __here: barrier(); &&__here; }) and it is valid to return the address of a label in the code as the address must be a constant instruction address and not a local stack variable. If the compiler is putting *executable code* on the stack, we've got bigger problems... We use __this_address extensively in XFS (indeed, there are 8 separate uses in __xfs_attr3_rmt_read_verify() and xfs_attr3_rmt_verify() alone) and it is the same as _THIS_IP_ used across the rest of the kernel for the same purpose. The above is the only warning that gets generated for any of (the hundreds of) sites that use either _THIS_IP_ or __this_address is the only warning that gets generated like this, it points to the problem being compiler related, not an XFS problem. Cheers, Dave.
I agree that gcc shouldn't warn here. I just pushed a patch to suppress that warning: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=d482b20fd346482635a770281a164a09d608b058 and I plan to backport it to gcc 12 as well. gcc 11 doesn't have -Wdangling-pointer. So I think you should be able to re-enable -Wdangling-pointer soon.