[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150714223250.GD13950@treble.redhat.com>
Date: Tue, 14 Jul 2015 17:32:50 -0500
From: Josh Poimboeuf <jpoimboe@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>, Michal Marek <mmarek@...e.cz>,
Andy Lutomirski <luto@...nel.org>,
Borislav Petkov <bp@...en8.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andi Kleen <andi@...stfloor.org>,
Pedro Alves <palves@...hat.com>, x86@...nel.org,
live-patching@...r.kernel.org, linux-kernel@...r.kernel.org,
Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH v7 2/4] x86/stackvalidate: Compile-time stack validation
On Tue, Jul 14, 2015 at 11:56:49PM +0200, Peter Zijlstra wrote:
> On Tue, Jul 14, 2015 at 04:30:34PM -0500, Josh Poimboeuf wrote:
> > the past few years for newer versions of gcc, stackvalidate silently
> > ignores __fentry__ calls and assumes that ftrace indeed knows wtf it's
> > doing. I don't see a problem there as long as the ftrace handler
> > doesn't sleep.
>
> They should not indeed, however it would be very nice if backtraces
> would still be 'good'.
Agreed, though I don't know if it's possible for stackvalidate to
reasonably understand what ftrace is doing. I tend to doubt it, since
ftrace does some code modification at runtime.
It does spit out some warnings for mcount_64.S. I'll need to look at
that code in more detail to figure out if the warnings should be
whitelisted as false positives, or if there's some way to annotate the
code to help stackvalidate understand it and validate it.
--
Josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists