Bug 2165898

Summary: gcc reports false warnings in kernel compile (Wdangling-pointer=)
Product: Red Hat Enterprise Linux 9 Reporter: Prarit Bhargava <prarit>
Component: gccAssignee: Marek Polacek <mpolacek>
gcc sub component: gcc-toolset-11 QA Contact: qe-baseos-tools-bugs
Status: CLOSED UPSTREAM Docs Contact:
Severity: unspecified    
Priority: unspecified CC: ahajkova, esandeen, fweimer, jakub, ohudlick, sipoyare
Version: 9.3Keywords: Bugfix, Triaged
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-02-15 14:14:11 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Prarit Bhargava 2023-01-31 12:37:50 UTC
Description of problem: Enabling -Werror on the centos-stream-9/RHEL9 kernel compile results in false "-Werror=dangling-pointer" errors


Version-Release number of selected component (if applicable): centos-stream-9/RHEL9 latest



How reproducible: 100%


Steps to Reproduce:
1. Compile centos-stream-9/RHEL kernel with -Werror (see MR link below)

Actual results:  

See build artifacts from: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/1955

For example, on aarch64:

00:00:17 + perl -p -i -e 's/^CONFIG_BUILD_SALT.*/CONFIG_BUILD_SALT="5.14.0-247.1955_761091570.el9.aarch64"/' .config
00:00:17 + /usr/bin/make CROSS_COMPILE=aarch64-linux-gnu- -s HOSTCFLAGS= HOSTLDFLAGS= ARCH=arm64 'KCFLAGS= ' WITH_GCOV=0 -j24 Image.gz
00:04:23 + '[' 1 -eq 1 ']'
00:04:23 + /usr/bin/make CROSS_COMPILE=aarch64-linux-gnu- -s HOSTCFLAGS= HOSTLDFLAGS= ARCH=arm64 'KCFLAGS= ' WITH_GCOV=0 -j24 modules
00:05:59 fs/xfs/libxfs/xfs_attr_remote.c: In function ‘__xfs_attr3_rmt_read_verify’:
00:05:59 fs/xfs/libxfs/xfs_attr_remote.c:140:35: error: storing the address of local variable ‘__here’ in ‘*failaddr’ [-Werror=dangling-pointer=]
00:05:59   140 |                         *failaddr = __this_address;
00:05:59 In file included from ./fs/xfs/xfs.h:22,
00:05:59                  from fs/xfs/libxfs/xfs_attr_remote.c:7:
00:05:59 ./fs/xfs/xfs_linux.h:132:46: note: ‘__here’ declared here
00:05:59   132 | #define __this_address  ({ __label__ __here; __here: barrier(); &&__here; })
--
00:05:59       |                                              ^~~~~~
00:05:59 fs/xfs/libxfs/xfs_attr_remote.c:140:37: note: in expansion of macro ‘__this_address’
00:05:59   140 |                         *failaddr = __this_address;
00:05:59       |                                     ^~~~~~~~~~~~~~



Expected results: No warnings


Additional info: After a discussion with esandeen, the xfs maintainer, these warnings are false.  This is a gcc bug and not an issue with the kernel:

https://bugzilla.kernel.org/show_bug.cgi?id=215851

Comment 1 Marek Polacek 2023-01-31 14:49:54 UTC
Could we get a preprocessed source file?  You can obtain that by adding -save-temps to the compile flags line, it should produce xfs_attr_remote.i.

It could be one of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=Wdangling-pointer

So this is the system RHEL9 gcc11?  Does it only happen on aarch64?

Comment 2 Prarit Bhargava 2023-02-14 13:46:55 UTC
Hey Marek, sorry for the late reply.

(In reply to Marek Polacek from comment #1)
> Could we get a preprocessed source file?  You can obtain that by adding
> -save-temps to the compile flags line, it should produce xfs_attr_remote.i.

I will add this file as the next comment to this BZ.

> 
> It could be one of
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=Wdangling-pointer
> 

Yes, that's what I thought, however after staring at the code it doesn't look like the code is wrong, and that is confirmed by sandeen the maintainer of XFS.  Additionally there isn't an upstream resolution for this either.  I came across a commit (which I frustratingly cannot find) in which someone disabled the dangling pointer check in their driver so it seems others may have hit this issue as well.

> So this is the system RHEL9 gcc11?  Does it only happen on aarch64?

It seems to happen on aarch64 and 

https://s3.amazonaws.com/arr-cki-prod-trusted-artifacts/trusted-artifacts/762903479/build%20aarch64/3689672654/artifacts/build.log

and s390x

https://s3.amazonaws.com/arr-cki-prod-trusted-artifacts/trusted-artifacts/762903479/build%20s390x/3689672668/artifacts/build.log

P.

Comment 4 Marek Polacek 2023-02-14 16:06:03 UTC
Thanks for the .i file.  Unfortunately this seems to be reproducible with trunk as well.
aarch64 cross:

$ ./cc1 -quiet xfs_attr_remote.i -Iinclude -O2 -Wdangling-pointer
fs/xfs/libxfs/xfs_attr_remote.c: In function ‘__xfs_attr3_rmt_read_verify’:
fs/xfs/libxfs/xfs_attr_remote.c:140:14: warning: storing the address of local variable ‘__here’ in ‘*failaddr’ [-Wdangling-pointer=]
fs/xfs/libxfs/xfs_attr_remote.c:140:37: note: ‘__here’ declared here
fs/xfs/libxfs/xfs_attr_remote.c:140:37: note: ‘failaddr’ declared here

so I think I'll have to open an upstream PR and close this BZ, because I have nothing to backport.

Comment 5 Marek Polacek 2023-02-15 14:14:11 UTC
This is upstream PR106080 which I just fixed for GCC 13 [1], and plan to backport to GCC 12.
However: I don't plan any further DTS/GTS 12 updates (they would need exception+), and
GCC 11 doesn't have -Wdangling-pointer at all.  So I'm confused; you must have used GCC
12 rather than the system RHEL9 GCC 11.

[1] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=d482b20fd346482635a770281a164a09d608b058