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

[RESEND] everything text-poke: ftrace, modules, static_call and jump_label

[Peter Zijlstra]

Because typing on a Monday is hard, here's a resend with the LKML address
corrected.

---

Hi All,

Here are 4 series that have accumulated in my queue for a while and I
figured I'd 'finish' and send out again.

The first series is rewriting x86/ftrace to use the normal text_poke()
interfaces we have, which rids us of the last major W^X violation and a
whole second implementation of the INT3 breakpoint code patching
infrastructure.

The second series cleans up various module stuff.

The third series is a refresh of the static_call() implementation.  I've
been meaning to use that to get rid of a number of indirect calls in the
x86 pmu implementation (RETPOLINE made them so much more painful), but
also other people have been asking for it. This series has a lot of new
patches since last time, most all a result of me trying to actually use
it.

The fourth series is something that has been languishing in my queue for
a long while and I figure I'd send it out to see if anybody has any
clever ideas on how to proceed with it.

They're all related, and the 3rd and 4rd series depend on the first two.
But instead of sending a giant 30+ patch series, I figured I'd send you 4
smaller series instead ;-)

Enjoy!

[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.

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.

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

[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