linux-kernel - Re: [GIT pull] perf/urgent for 5.7-rc2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200419200758.3xry3vn2a5caxapx@treble>
Date:   Sun, 19 Apr 2020 15:07:58 -0500
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [GIT pull] perf/urgent for 5.7-rc2

On Sun, Apr 19, 2020 at 11:56:51AM -0700, Linus Torvalds wrote:
> On Sun, Apr 19, 2020 at 6:57 AM Thomas Gleixner <tglx@...utronix.de> wrote:
> >
> > please pull the latest perf/urgent branch from:
> >
> >    git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf-urgent-2020-04-19
> 
> So this one took me by surprise, because it only touched the 'tools'
> subdirectory for the perf tool, and then when I did what I thought
> would be a trivial test build, it re-built the whole kernel.
> 
> And that made me go "Whaa?!?"
> 
> After looking at it for a while (longer than I really want to admit),
> I realized that it's because the headers are also shared with objtool,
> and it all kind of made sense.
> 
> I say "kind of" because I would have wished that objtool wouldn't
> necessarily rebuild everything.

Objtool is run against every .o file, and it's considered part of the
toolchain, because of ORC generation and other reasons.  If anything in
the toolchain changes, everything gets rebuilt.  It *is* kind of crude,
because GCC shouldn't really need to run again.  I don't know if there's
a more refined way to handle that dependency.  ccache helps :-)

> So I'm wondering if there any way that objtool could be run at
> link-time (and archive time) rather than force a re-build of all the
> object files from source?

We've actually been making progress in that direction.  Peter added
partial vmlinux.o support, for Thomas' noinstr validation.  The problem
is, linking is single-threaded so it ends up making the kernel build
slower overall.

So right now, we still do most things per compilation unit, and only do
the noinstr validation at vmlinux.o link time.  Eventually, especially
with LTO, we'll probably end up moving everything over to link time.

-- 
Josh