linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [Bug 215851] New: gcc 12.0.1 LATEST: -Wdangling-pointer= triggers
@ 2022-04-18  8:02 bugzilla-daemon
  2022-04-20 23:50 ` Dave Chinner
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: bugzilla-daemon @ 2022-04-18  8:02 UTC (permalink / raw)
  To: linux-xfs

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

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.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Bug 215851] New: gcc 12.0.1 LATEST: -Wdangling-pointer= triggers
  2022-04-18  8:02 [Bug 215851] New: gcc 12.0.1 LATEST: -Wdangling-pointer= triggers bugzilla-daemon
@ 2022-04-20 23:50 ` Dave Chinner
  2022-04-20 23:50 ` [Bug 215851] " bugzilla-daemon
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: Dave Chinner @ 2022-04-20 23:50 UTC (permalink / raw)
  To: bugzilla-daemon; +Cc: linux-xfs

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.
-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug 215851] gcc 12.0.1 LATEST: -Wdangling-pointer= triggers
  2022-04-18  8:02 [Bug 215851] New: gcc 12.0.1 LATEST: -Wdangling-pointer= triggers bugzilla-daemon
  2022-04-20 23:50 ` Dave Chinner
@ 2022-04-20 23:50 ` bugzilla-daemon
  2023-02-15 14:05 ` bugzilla-daemon
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: bugzilla-daemon @ 2022-04-20 23:50 UTC (permalink / raw)
  To: linux-xfs

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

--- Comment #1 from Dave Chinner (david@fromorbit.com) ---
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.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug 215851] gcc 12.0.1 LATEST: -Wdangling-pointer= triggers
  2022-04-18  8:02 [Bug 215851] New: gcc 12.0.1 LATEST: -Wdangling-pointer= triggers bugzilla-daemon
  2022-04-20 23:50 ` Dave Chinner
  2022-04-20 23:50 ` [Bug 215851] " bugzilla-daemon
@ 2023-02-15 14:05 ` bugzilla-daemon
  2024-06-28 12:21 ` bugzilla-daemon
  2024-07-01 14:59 ` bugzilla-daemon
  4 siblings, 0 replies; 6+ messages in thread
From: bugzilla-daemon @ 2023-02-15 14:05 UTC (permalink / raw)
  To: linux-xfs

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

Marek Polacek (polacek@redhat.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |polacek@redhat.com

--- Comment #2 from Marek Polacek (polacek@redhat.com) ---
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.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug 215851] gcc 12.0.1 LATEST: -Wdangling-pointer= triggers
  2022-04-18  8:02 [Bug 215851] New: gcc 12.0.1 LATEST: -Wdangling-pointer= triggers bugzilla-daemon
                   ` (2 preceding siblings ...)
  2023-02-15 14:05 ` bugzilla-daemon
@ 2024-06-28 12:21 ` bugzilla-daemon
  2024-07-01 14:59 ` bugzilla-daemon
  4 siblings, 0 replies; 6+ messages in thread
From: bugzilla-daemon @ 2024-06-28 12:21 UTC (permalink / raw)
  To: linux-xfs

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

LinnDa (laraditta691@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |laraditta691@gmail.com

--- Comment #3 from LinnDa (laraditta691@gmail.com) ---
(In reply to Dave Chinner from comment #1)
> 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: https://myteamz.co.uk/linnworks/
> >           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.

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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug 215851] gcc 12.0.1 LATEST: -Wdangling-pointer= triggers
  2022-04-18  8:02 [Bug 215851] New: gcc 12.0.1 LATEST: -Wdangling-pointer= triggers bugzilla-daemon
                   ` (3 preceding siblings ...)
  2024-06-28 12:21 ` bugzilla-daemon
@ 2024-07-01 14:59 ` bugzilla-daemon
  4 siblings, 0 replies; 6+ messages in thread
From: bugzilla-daemon @ 2024-07-01 14:59 UTC (permalink / raw)
  To: linux-xfs

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

Artem S. Tashkinov (aros@gmx.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2024-07-01 14:59 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-04-18  8:02 [Bug 215851] New: gcc 12.0.1 LATEST: -Wdangling-pointer= triggers bugzilla-daemon
2022-04-20 23:50 ` Dave Chinner
2022-04-20 23:50 ` [Bug 215851] " bugzilla-daemon
2023-02-15 14:05 ` bugzilla-daemon
2024-06-28 12:21 ` bugzilla-daemon
2024-07-01 14:59 ` bugzilla-daemon

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).