linux-kernel - Re: [PATCH 5/9] objtool: Rework rebuild

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]

Date:   Thu, 18 Mar 2021 13:57:03 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     x86@...nel.org, jgross@...e.com, mbenes@...e.cz,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/9] objtool: Rework rebuild_reloc logic

On Wed, Mar 17, 2021 at 07:49:17PM -0500, Josh Poimboeuf wrote:
> On Wed, Mar 17, 2021 at 09:12:15AM +0100, Peter Zijlstra wrote:
> > On Tue, Mar 16, 2021 at 10:34:17PM -0500, Josh Poimboeuf wrote:
> > > On Fri, Mar 12, 2021 at 06:16:18PM +0100, Peter Zijlstra wrote:
> > > > --- a/tools/objtool/elf.c
> > > > +++ b/tools/objtool/elf.c
> > > > @@ -479,6 +479,8 @@ void elf_add_reloc(struct elf *elf, stru
> > > >  
> > > >  	list_add_tail(&reloc->list, &sec->reloc_list);
> > > >  	elf_hash_add(elf->reloc_hash, &reloc->hash, reloc_hash(reloc));
> > > > +
> > > > +	sec->rereloc = true;
> > > >  }
> > > 
> > > Can we just reuse sec->changed for this?  Something like this on top
> > > (untested of course):
> > 
> > I think my worry was that we'd dirty too much and slow down the write,
> > but I haven't done any actual performance measurements on this.
> 
> Really?  I thought my proposal was purely aesthetic, no functional
> change, but my brain is toasty this week due to other distractions so
> who knows.

I was thinking you could get a section changed without touching
relocations, but while that is theoretically possible, it is exceedingly
unlikely (and objtool doesn't do that).

Because if entries have relocations, then adding an entry will also add
relocations etc..

pre: 79.269 +- 0.104 seconds time elapsed  ( +-  0.13% )
post: 79.0604 +- 0.0441 seconds time elapsed  ( +-  0.06% )
fini: 79.2995 +- 0.0448 seconds time elapsed  ( +-  0.06% )

is what I get for kbuild x86_64-defconfig-ish build times with the
various patches applied. Which is all noise afaict. I'll fold your
thing. Less is more etc..