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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20200420174031.GM20730@hirez.programming.kicks-ass.net>
Date:   Mon, 20 Apr 2020 19:40:31 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Ingo Molnar <mingo@...nel.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        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>
Subject: Re: [GIT pull] perf/urgent for 5.7-rc2

On Mon, Apr 20, 2020 at 09:51:55AM -0700, Linus Torvalds wrote:
> On Mon, Apr 20, 2020 at 12:48 AM Ingo Molnar <mingo@...nel.org> wrote:
> >
> > Fortunately, much of what objtool does against vmlinux.o can be
> > parallelized in a rather straightforward fashion I believe, if we build
> > with -ffunction-sections.
> 
> Well, I was actually thinking about a simpler model.
> 
> By "link time" I didn't mean "after final link". Yes, there may be
> reasons to do it at that point too (to do any whole-program checks),
> but that wasn't what I meant.
> 
> I meant literally doing it in the $(LD) and $(AR) phases, when you
> still have lots of independent object files that you are just about to
> link (or archive - do we even do that any more?) into one.
> 
> Then you'd parallelize exactly the same way we do now: one object file
> at a time, and with no real change of semantics.
> 
> IOW, what I was thinking that instead of doing it as part of a final
> step after the CC/AS, we'd do it as a preparatory step before the
> LD/AR. Same exact operation, same exact target *.o files, just shifted
> in time.

So my pet peeve is that when objtool errors, or crashes, the .o file
gets deleted and it becomes really hard to debug the situation. I'm
thinking that your suggestion would actually help with that too.

I just don't have enough Kbuild foo to even attempt this :/