https://bugzilla.kernel.org/show_bug.cgi?id=215851 LinnDa (laraditta691@xxxxxxxxx) changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |laraditta691@xxxxxxxxx --- Comment #3 from LinnDa (laraditta691@xxxxxxxxx) --- (In reply to Dave Chinner from comment #1) > On Mon, Apr 18, 2022 at 08:02:41AM +0000, bugzilla-daemon@xxxxxxxxxx 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: https://myteamz.co.uk/linnworks/ > > Reporter: Erich.Loew@xxxxxxxxxxx > > 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. Does the gcc warns here? -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
