[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <nycvar.YFH.7.76.2001290404240.31058@cbobk.fhfr.pm>
Date: Wed, 29 Jan 2020 04:14:36 +0100 (CET)
From: Jiri Kosina <jikos@...nel.org>
To: Josh Poimboeuf <jpoimboe@...hat.com>
cc: Petr Mladek <pmladek@...e.com>, Miroslav Benes <mbenes@...e.cz>,
Peter Zijlstra <peterz@...radead.org>,
Steven Rostedt <rostedt@...dmis.org>,
Joe Lawrence <joe.lawrence@...hat.com>,
Jessica Yu <jeyu@...nel.org>, x86@...nel.org,
linux-kernel@...r.kernel.org, mhiramat@...nel.org,
bristot@...hat.com, jbaron@...mai.com,
torvalds@...ux-foundation.org, tglx@...utronix.de,
mingo@...nel.org, namit@...are.com, hpa@...or.com, luto@...nel.org,
ard.biesheuvel@...aro.org, live-patching@...r.kernel.org,
Randy Dunlap <rdunlap@...radead.org>
Subject: Re: [PATCH v3 5/6] x86/ftrace: Use text_poke()
On Tue, 28 Jan 2020, Josh Poimboeuf wrote:
> > For the cases I've seen so far, it has always been gcc deciding under
> > certain circumstances not to propagate __attribute__((__noreturn__)) from
> > callee to caller even in the cases when caller unconditionally called
> > callee.
> >
> > AFAIU, the behavior is (and always will) be dependent on the state of gcc
> > optimizations, and therefore I don't see any other way than adding
> > __noreturn anotation transitively everywhere in order to silence objtool.
> >
> > So those cases have to be fixed anyway.
> >
> > What are the other cases please? Either I have completely missed those, or
> > they haven't been mentioned in this thread.
>
> For example, see:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git/commit/?h=objtool-fixes&id=6265238af90b395a1e5e5032a41f012a552d8a9e
>
> Many of those callees are static noreturns, for which we've *never*
> needed annotations. Disabling -fipa-pure-const has apparently changed
> that.
For some reason I thought you were talking about static inlines, sorry for
the noise.
Yeah, so I agree with you -- whether we need those anotations depends on
compiler implementation of optimizations, and most importantly on (the
current state of) internal implementation of specific optimizations in
gcc.
Leaving live patching completely aside for the sake of this discussion for
now -- I believe we either fully rely on gcc to propagate the 'noreturn'
propery throughout the callstack upward, or we don't.
If we don't, then we do need the anotations (both the global and static
ones), and problem solved.
If we do, well, where is the 'this is *the* behavior of any current/future
clang^Wcompiler' invariant guarantee?
Thanks,
--
Jiri Kosina
SUSE Labs
Powered by blists - more mailing lists