[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200316161904.zouwkwup6vwsmxgp@treble>
Date: Mon, 16 Mar 2020 11:19:04 -0500
From: Josh Poimboeuf <jpoimboe@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: tglx@...utronix.de, linux-kernel@...r.kernel.org, x86@...nel.org
Subject: Re: [RFC][PATCH 15/16] objtool: Implement noinstr validation
On Mon, Mar 16, 2020 at 02:24:19PM +0100, Peter Zijlstra wrote:
> > And "read_instr_hints" reads as "read_instruction_hints()".
> >
> > Can we come up with a more readable name? Why not just "notrace"?
> >
> > The trace begin/end annotations could be
> >
> > trace_allow_begin()
> > trace_allow_end()
>
> notrace already exists and we didn't want to confuse things further.
Um, why would it confuse things to call a section of notrace code
".notrace.text"???
> > Also -- what happens when a function belongs in both .notrace.text and
> > in one of the other special-purpose sections like .sched.text,
> > .meminit.text or .entry.text?
>
> Hasn't happened yet, initially we were thinking of using .entry.text for
> this as a whole, but decided against that due to how .entry.text is
> special for PTI (although exposing most of this code really wouldn't
> matter).
>
> The thing with .sched.text is that we really should never call into
> scheduling from these contexts anyway. We've not ran into meminit yet.
> (all this finicky entry code is ran with IRQs disabled).
>
> The one that could potentially interfere is .cpuidle.text.
>
> > Maybe storing pointers to the functions, like NOKPROBE_SYMBOL does,
> > would be better than putting the functions in a separate section.
>
> Thing is, I really _hate_ that annotation style.
I do too, but I get the feeling this "put everything in its own section"
thing is going to bite us.
> > Also, maybe we can just hard-code the fact that vmlinux.o is always
> > noinstr-only. Over time we'll probably need to move more per-.o
> > functionalities to vmlinux.o and I think we should avoid creating a
> > bunch of cmdline options.
>
> but you're ruining things here, see, for a regular x86_64 config, we'd
> run this with:
>
> objtool check -fail vmlinux.o
>
> And I was hoping to get vmlinux.o objtool clean, surprisingly there
> really aren't that many complaints. But the -i thing makes it run
> significantly faster without duplicating all the bits we've already
> checked.
My suggestion is that the "-i" option would be hard-coded (for now). So
nothing extra would get checked.
--
Josh
Powered by blists - more mailing lists