[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161012042825.48b2618a@grimm.local.home>
Date: Wed, 12 Oct 2016 04:28:25 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Ingo Molnar <mingo@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [GIT pull] locking fix for 4.9
On Mon, 10 Oct 2016 10:29:27 -0700
Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> On Sat, Oct 8, 2016 at 5:47 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
> >
> > A single fix which prevents newer GCCs from spamming the build output with
> > overly eager warnings about __builtin_return_address() uses which are
> > correct.
>
> Ugh. This feels over-engineered to me.
>
> We already disable that warning unconditionally for the trace
> subdirectory, and for mm/usercopy.c.
>
> I feel that the simpler solution is to just disable the warning
> globally, and not worry about "when this config option is enabled we
> need to disable it".
>
> Basically, we disable the warning every time we ever use
> __builtin_return_address(), so maybe we should just disable it once
> and for all.
The only advantage of doing this is to make it a pain to use
__builtin_return_address(n) with n > 0, so that we don't accidentally
use it without knowing what we are doing.
>
> It's not like the __builtin_return_address() warning is so incredibly
> useful anyway.
>
But I agree. We have lived a long time without the need for this
warning. I'm not strongly advocating keeping the warning around and
just disabling it totally. But it all comes down to how much we
trust those that inherit this after we are gone ;-)
/me is feeling his age.
-- Steve
Powered by blists - more mailing lists