Re: [RFC][PATCH 0/9] Variable size jump_label support

Re: [RFC][PATCH 0/9] Variable size jump_label support

[Ingo Molnar]

[ Sorry, fixed the Cc:lkml line. ]

* Peter Zijlstra <peterz@infradead.org> wrote:

> These here patches are something I've been poking at for a while, 
> enabling jump_label to use 2 byte jumps/nops.
> 
> It _almost_ works :-/
> 
> That is, you can build some kernels with it (x86_64-defconfig for 
> example works just fine).
> 
> The problem comes when GCC generates a branch into another section, 
> mostly .text.unlikely. At that point GAS just gives up and throws a fit 
> (more details in the last patch).
> 
> Aside from anyone coming up with a really clever GAS trick, I don't see 
> how we can do this other than:

>  - use 'jmp' and get objtool to rewrite the text. Steven has earlier proposed
>    something like that (using recordmcount) and Linus hated that.

As long as GCC+GAS correctly generates a 2-byte or 5-byte JMP depending 
on the target distance, the objtool solution should work fine, shouldn't 
it?

I can see the recordmcount solution sucking, it would depend on early 
kernel patchery. But build time patchery is something we already depend 
on, so assuming some objtool catastrophy it's a more robust solution, 
isn't it?

Thanks,

	Ingo

Re: [RFC][PATCH 0/9] Variable size jump_label support

[Steven Rostedt]

On Mon, 7 Oct 2019 13:26:06 +0200
Ingo Molnar <mingo@kernel.org> wrote:

> [ Sorry, fixed the Cc:lkml line. ]

/me joining the fun.

> 
> * Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > These here patches are something I've been poking at for a while, 
> > enabling jump_label to use 2 byte jumps/nops.
> > 
> > It _almost_ works :-/
> > 
> > That is, you can build some kernels with it (x86_64-defconfig for 
> > example works just fine).
> > 
> > The problem comes when GCC generates a branch into another section, 
> > mostly .text.unlikely. At that point GAS just gives up and throws a fit 
> > (more details in the last patch).
> > 
> > Aside from anyone coming up with a really clever GAS trick, I don't see 
> > how we can do this other than:  
> 
> >  - use 'jmp' and get objtool to rewrite the text. Steven has earlier proposed
> >    something like that (using recordmcount) and Linus hated that.  
> 
> As long as GCC+GAS correctly generates a 2-byte or 5-byte JMP depending 
> on the target distance, the objtool solution should work fine, shouldn't 
> it?
> 
> I can see the recordmcount solution sucking, it would depend on early 
> kernel patchery. But build time patchery is something we already depend 
> on, so assuming some objtool catastrophy it's a more robust solution, 
> isn't it?
> 

Actually, even back then I said that it would be best to merge all the
tools into one (I just didn't have the time to implement it), and then
we could pull this off. I have one of my developers working to merge
record-mcount into objtool now (there's been some patches floating
around).

Then with a single tool, it shouldn't be controversial.

-- Steve

Re: [RFC][PATCH 0/9] Variable size jump_label support

[Peter Zijlstra]

On Mon, Oct 07, 2019 at 11:17:42AM -0400, Steven Rostedt wrote:
> Actually, even back then I said that it would be best to merge all the
> tools into one (I just didn't have the time to implement it), and then
> we could pull this off. I have one of my developers working to merge
> record-mcount into objtool now (there's been some patches floating
> around).

Right, but while working on this I discovered GCC's -mrecord-mcount (and
the kernel using this), so how much do we really still need the
record-mcount tool?

Do we really only need the tool for the little hole between gcc-4.6
(minimal supported GCC version) and gcc-5 (when -mrecord-mcount was
introduced) ?

Re: [RFC][PATCH 0/9] Variable size jump_label support

[Steven Rostedt]

On Mon, 7 Oct 2019 18:13:02 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Mon, Oct 07, 2019 at 11:17:42AM -0400, Steven Rostedt wrote:
> > Actually, even back then I said that it would be best to merge all the
> > tools into one (I just didn't have the time to implement it), and then
> > we could pull this off. I have one of my developers working to merge
> > record-mcount into objtool now (there's been some patches floating
> > around).  
> 
> Right, but while working on this I discovered GCC's -mrecord-mcount (and
> the kernel using this), so how much do we really still need the
> record-mcount tool?

That only works for some archs, not all of them. At least not yet that
I'm aware of.

> 
> Do we really only need the tool for the little hole between gcc-4.6
> (minimal supported GCC version) and gcc-5 (when -mrecord-mcount was
> introduced) ?

Again, it's for more than just x86 ;-)

-- Steve

Re: [RFC][PATCH 0/9] Variable size jump_label support

[Steven Rostedt]

On Mon, 7 Oct 2019 14:55:19 +0200
Ingo Molnar <mingo@kernel.org> wrote:

> * Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > IIRC the recordmcount variant from Steve was also rewriting JMP8 to NOP2
> > at build time.
> >
> > I dug this here link out of my IRC logs:
> > 
> >   https://lore.kernel.org/lkml/1318007374.4729.58.camel@gandalf.stny.rr.com/  
> 
> Ancient indeed ...
> 
> > Looking at that, part of the reason might've been running yet another 
> > tool, instead of having one tool do everything.  
> 
> Yeah - that too wouldn't be a problem with objtool, as we are running it 
> anyway, right?
> 
> So I can see about 2 valid technical reasons why Linus would have 
> objected to that old approach from Steve while finding the objtool 
> approach more acceptable.
> 
> Basically the main assumption is that we better never run out of 
> competent objtool experts... :-)

Actually, even back then I said that it would be best to merge all the
tools into one (I just didn't have the time to implement it), and then
we could pull this off. I have one of my developers working to merge
record-mcount into objtool now (there's been some patches floating
around).

Then with a single tool, it shouldn't be controversial.

-- Steve

Re: [RFC][PATCH 0/9] Variable size jump_label support

[Ingo Molnar]

* Peter Zijlstra <peterz@infradead.org> wrote:

> IIRC the recordmcount variant from Steve was also rewriting JMP8 to NOP2
> at build time.
>
> I dug this here link out of my IRC logs:
> 
>   https://lore.kernel.org/lkml/1318007374.4729.58.camel@gandalf.stny.rr.com/

Ancient indeed ...

> Looking at that, part of the reason might've been running yet another 
> tool, instead of having one tool do everything.

Yeah - that too wouldn't be a problem with objtool, as we are running it 
anyway, right?

So I can see about 2 valid technical reasons why Linus would have 
objected to that old approach from Steve while finding the objtool 
approach more acceptable.

Basically the main assumption is that we better never run out of 
competent objtool experts... :-)

Thanks,

	Ingo

Re: [RFC][PATCH 0/9] Variable size jump_label support

[Peter Zijlstra]

In the failed thread Ingo posted:

>On Mon, Oct 07, 2019 at 01:26:06PM +0200, Ingo Molnar wrote:
> * Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > These here patches are something I've been poking at for a while, 
> > enabling jump_label to use 2 byte jumps/nops.
> > 
> > It _almost_ works :-/
> > 
> > That is, you can build some kernels with it (x86_64-defconfig for 
> > example works just fine).
> > 
> > The problem comes when GCC generates a branch into another section, 
> > mostly .text.unlikely. At that point GAS just gives up and throws a fit 
> > (more details in the last patch).
> > 
> > Aside from anyone coming up with a really clever GAS trick, I don't see 
> > how we can do this other than:
> 
> >  - use 'jmp' and get objtool to rewrite the text. Steven has earlier proposed
> >    something like that (using recordmcount) and Linus hated that.
> 
> As long as GCC+GAS correctly generates a 2-byte or 5-byte JMP depending 
> on the target distance, the objtool solution should work fine, shouldn't 
> it?
> 
> I can see the recordmcount solution sucking, it would depend on early 
> kernel patchery. But build time patchery is something we already depend 
> on, so assuming some objtool catastrophy it's a more robust solution, 
> isn't it?

IIRC the recordmcount variant from Steve was also rewriting JMP8 to NOP2
at build time.

I dug this here link out of my IRC logs:

  https://lore.kernel.org/lkml/1318007374.4729.58.camel@gandalf.stny.rr.com/

Looking at that, part of the reason might've been running yet another
tool, instead of having one tool do everything.

[RFC][PATCH 0/9] Variable size jump_label support

[Peter Zijlstra]

These here patches are something I've been poking at for a while, enabling
jump_label to use 2 byte jumps/nops.

It _almost_ works :-/

That is, you can build some kernels with it (x86_64-defconfig for example works
just fine).

The problem comes when GCC generates a branch into another section, mostly
.text.unlikely. At that point GAS just gives up and throws a fit (more details
in the last patch).

Aside from anyone coming up with a really clever GAS trick, I don't see how we
can do this other than:

 - get binutils/gas 'fixed', for this there's two possible approaches:

  * add some extra operators such that something like:

      .set disp %[l_yes] ~ 1b ? (%[l_yes] - (1b + 2)) : 128

    works, where the new '~' infix operator would indicate left and right hand
    operands are from the same section, and the ?: conditional operator would be
    added to make it all work.

  * add a 'fake' mnemonic for x86 that directly generates the right NOP:

      nojmp{.d8,d32} %target

    which would completely mirror how the existing 'jmp{.d8,d32} %target'
    works, except it would emit single instruction NOP2/NOP5.

 - use 'jmp' and get objtool to rewrite the text. Steven has earlier proposed
   something like that (using recordmcount) and Linus hated that.