[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231012213038.pnq6eds53dbqxstj@treble>
Date: Thu, 12 Oct 2023 14:30:38 -0700
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Ingo Molnar <mingo@...nel.org>
Cc: "H. Peter Anvin" <hpa@...or.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Uros Bizjak <ubizjak@...il.com>, x86@...nel.org,
linux-kernel@...r.kernel.org, Nadav Amit <namit@...are.com>,
Andy Lutomirski <luto@...nel.org>,
Brian Gerst <brgerst@...il.com>,
Denys Vlasenko <dvlasenk@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Josh Poimboeuf <jpoimboe@...hat.com>
Subject: Re: [PATCH v2 -tip] x86/percpu: Use C for arch_raw_cpu_ptr()
On Thu, Oct 12, 2023 at 07:59:43PM +0200, Ingo Molnar wrote:
>
> * Josh Poimboeuf <jpoimboe@...nel.org> wrote:
>
> > On Thu, Oct 12, 2023 at 08:19:14AM +0200, Ingo Molnar wrote:
> > >
> > > * Josh Poimboeuf <jpoimboe@...nel.org> wrote:
> > >
> > > > Though, another problem is that .text has a crazy amount of padding
> > > > which makes it always the same size, due to the SRSO alias mitigation
> > > > alignment linker magic. We should fix that somehow.
> > >
> > > We could emit a non-aligned end-of-text symbol (we might have it already),
> > > and have a script or small .c program in scripts/ or tools/ that looks
> > > at vmlinux and displays a user-friendly and accurate list of text and
> > > data sizes in the kernel?
> > >
> > > And since objtool is technically an 'object files tool', and it already
> > > looks at sections & symbols, it could also grow a:
> > >
> > > objtool size <objfile>
> > >
> > > command that does the sane thing ... I'd definitely start using that, instead of 'size'.
> > >
> > > /me runs :-)
> >
> > Yeah, that's actually not a bad idea.
> >
> > I had been thinking a "simple" script would be fine, but I'm realizing
> > the scope of this thing could grow over time. In which case a script is
> > less than ideal. And objtool already has the ability to do this pretty
> > easily.
>
> Yeah, and speed actually matters here: I have scripts that generate object
> comparisons between commits, and every second of runtime counts - and a
> script would be slower and more fragile for something like allmodconfig
> builds or larger disto configs.
Ah, good to know.
> BTW., maybe the right objtool subcommand would be 'objtool sections', with
> an 'objtool sections size' sub-sub-command. Because I think this discussion
> shows that it would be good to have a bit of visibility into the sanity of
> our sections setup, with 'objtool sections check' for example doing a
> sanity check on whether there's anything extra in the text section that
> shouldn't be there? Or so ...
What would be an example of something "extra"? A sanity check might fit
better alongside the other checks already being done by the main objtool
"subcommand" which gets run by the kernel build.
BTW, I actually removed subcommands a while ago when I overhauled
objtool's interface to make it easier to combine options. That said,
I'm not opposed to re-adding them if we can find a sane way to do so.
Here's the current interface:
Usage: objtool <actions> [<options>] file.o
Actions:
-h, --hacks[=<jump_label,noinstr,skylake>]
patch toolchain bugs/limitations
-i, --ibt validate and annotate IBT
-l, --sls validate straight-line-speculation mitigations
-m, --mcount annotate mcount/fentry calls for ftrace
-n, --noinstr validate noinstr rules
-o, --orc generate ORC metadata
-r, --retpoline validate and annotate retpoline usage
-s, --stackval validate frame pointer rules
-t, --static-call annotate static calls
-u, --uaccess validate uaccess rules for SMAP
--cfi annotate kernel control flow integrity (kCFI) function preambles
--dump[=<orc>] dump metadata
--prefix <n> generate prefix symbols
--rethunk validate and annotate rethunk usage
--unret validate entry unret placement
Options:
-v, --verbose verbose warnings
--backtrace unwind on error
--backup create .orig files before modification
--dry-run don't write modifications
--link object is a linked object
--mnop nop out mcount call sites
--module object is part of a kernel module
--no-unreachable skip 'unreachable instruction' warnings
--sec-address print section addresses in warnings
--stats print statistics
Note how all the actions can be easily combined in a single execution
instance.
If we re-added subcommands, most of the existing functionality would be
part of a single subcommand. It used to be called "check", but it's no
longer a read-only operation so that's misleading. I'll call it "run"
for now.
Right now my preference would be to leave the existing interface as-is,
and then graft optional subcommands on top. If no subcommand is
specified then it would default to the "run" subcommand. It's a little
funky, but it would work well for the common case, where ~99% of the
functionality lives. And it doesn't break existing setups and
backports.
For example:
# current interface (no changes)
objtool --mcount --orc --retpoline --uaccess vmlinux.o
# same, with optional explicit "run" subcommand
objtool run --mcount --orc --retpoline --uaccess vmlinux.o
# new "size" subcommand
obtool size [options] vmlinux.o.before vmlinux.o.after
--
Josh
Powered by blists - more mailing lists