Do we use runtime patching of function calls somewhere?

Do we use runtime patching of function calls somewhere?

[Sam Ravnborg]

Do we have any archs that does runtime patching of function calls?

On sparc32 we have infrastructure to do so but this
requires an additional step after the final link
that I like to get rid of.

Basically what is required is to locate all
call-sites that for example call:

     cache_flush_all();

and replace this with a

    srmmu_cache_flush_all();

sparc32 has ~30 calls that is eligble for runtime patching.
sparc-next has seen some nice cleanup in this area,
so your regular kernel has much more.

We know early on the what to patch with as the only
paramters involved are platform and MMU type.

I could try to come up with something myself - but if we already
have it somewhere maybe there is something to be inspired by.

	Sam

Re: Do we use runtime patching of function calls somewhere?

[Matthew Wilcox]

On Sun, May 13, 2012 at 02:16:00PM +0200, Sam Ravnborg wrote:
> Do we have any archs that does runtime patching of function calls?

Isn't this a slightly easier version of the x86 altinstructions mechanism?

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: Do we use runtime patching of function calls somewhere?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 462 bytes --]

On Sunday 13 May 2012 08:16:00 Sam Ravnborg wrote:
> Do we have any archs that does runtime patching of function calls?

Matthew already mentioned the x86 altinstruction support (which helps with 
building smp kernels which run well on UP setups), but in case it helps, 
there's the ftrace stuff that runtime patches calls to mcount.  there's 
HAVE_FTRACE_MCOUNT_RECORD and HAVE_DYNAMIC_FTRACE which 
Documentation/trace/ftrace-design.txt covers.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Do we use runtime patching of function calls somewhere?

[David Miller]

From: Matthew Wilcox <matthew@wil.cx>
Date: Sun, 13 May 2012 08:29:35 -0600

> On Sun, May 13, 2012 at 02:16:00PM +0200, Sam Ravnborg wrote:
>> Do we have any archs that does runtime patching of function calls?
> 
> Isn't this a slightly easier version of the x86 altinstructions mechanism?

Nope, altinstructions patches the implementation.

Sparc wants to patch the call sites.

Basically, run time linking of function calls.

Re: Do we use runtime patching of function calls somewhere?

[David Miller]

From: Sam Ravnborg <sam@ravnborg.org>
Date: Sun, 13 May 2012 14:16:00 +0200

> I could try to come up with something myself - but if we already
> have it somewhere maybe there is something to be inspired by.

You could relocatable link, record all the R_SPARC_WDISP30 relocations
into a special data file (which you'd link into vmlinux), then provide
a stub version of all the routines.

At run time you walk through the relocations and resolve them just as
the linker or the module loader would.

But I wouldn't do this, it's hairy with modules etc.

Instead, I'd do for these routines what sparc64 does, which is patch
the actual code.

You have a base implementation which is at least as large as the
largest implementation which exists.  Then you simply copy the
instructions over from the implementation you want to use.  All
branches must be relative and be to destination only within the
routine itself, otherwise you'd have to fixup their offsets since the
necessary branch displacement changes once you move the instruction
from one place to another.

See arch/sparc/mm/ultra.S

Re: Do we use runtime patching of function calls somewhere?

[Sam Ravnborg]

On Sun, May 13, 2012 at 02:32:29PM -0400, David Miller wrote:
> From: Sam Ravnborg <sam@ravnborg.org>
> Date: Sun, 13 May 2012 14:16:00 +0200
> 
> > I could try to come up with something myself - but if we already
> > have it somewhere maybe there is something to be inspired by.
> 
> You could relocatable link, record all the R_SPARC_WDISP30 relocations
> into a special data file (which you'd link into vmlinux), then provide
> a stub version of all the routines.
> 
> At run time you walk through the relocations and resolve them just as
> the linker or the module loader would.
> 
> But I wouldn't do this, it's hairy with modules etc.
> 
> Instead, I'd do for these routines what sparc64 does, which is patch
> the actual code.
> 
> You have a base implementation which is at least as large as the
> largest implementation which exists.  Then you simply copy the
> instructions over from the implementation you want to use.  All
> branches must be relative and be to destination only within the
> routine itself, otherwise you'd have to fixup their offsets since the
> necessary branch displacement changes once you move the instruction
> from one place to another.

That makes sense - then we do not need to search for the callers etc.
And we can use the base implemntation as the default case.

But I need to brush up my sparc assembler skills a bit first,
I'm afraid.
I will put this on my todo list as this would be good to
have, but I will postpone the idea for now.

	Sam

Re: Do we use runtime patching of function calls somewhere?

[David Miller]

From: Sam Ravnborg <sam@ravnborg.org>
Date: Sun, 13 May 2012 20:45:38 +0200

> On Sun, May 13, 2012 at 02:32:29PM -0400, David Miller wrote:
>> Instead, I'd do for these routines what sparc64 does, which is patch
>> the actual code.
>> 
>> You have a base implementation which is at least as large as the
>> largest implementation which exists.  Then you simply copy the
>> instructions over from the implementation you want to use.  All
>> branches must be relative and be to destination only within the
>> routine itself, otherwise you'd have to fixup their offsets since the
>> necessary branch displacement changes once you move the instruction
>> from one place to another.
> 
> That makes sense - then we do not need to search for the callers etc.
> And we can use the base implemntation as the default case.
> 
> But I need to brush up my sparc assembler skills a bit first, I'm
> afraid.  I will put this on my todo list as this would be good to
> have, but I will postpone the idea for now.

BTW, I just wanted to make a note that the R_SPARC_WDISP30 thing I
mentioned is essentially what btfixup is doing by hand.  If you look
at arch/sparc/boot/btfix.S that gets generated, it has the table of
relocations (call sites to fix up) and then the NOP function stubs so
that vmlinux can link.

Re: Do we use runtime patching of function calls somewhere?

[Sam Ravnborg]

On Sun, May 13, 2012 at 02:16:00PM +0200, Sam Ravnborg wrote:
> Do we have any archs that does runtime patching of function calls?
> 
> On sparc32 we have infrastructure to do so but this
> requires an additional step after the final link
> that I like to get rid of.
> 
> Basically what is required is to locate all
> call-sites that for example call:
> 
>      cache_flush_all();
> 
> and replace this with a
> 
>     srmmu_cache_flush_all();
> 
> sparc32 has ~30 calls that is eligble for runtime patching.
> sparc-next has seen some nice cleanup in this area,
> so your regular kernel has much more.
> 
> We know early on the what to patch with as the only
> paramters involved are platform and MMU type.
> 
> I could try to come up with something myself - but if we already
> have it somewhere maybe there is something to be inspired by.

Just a follow-up to all.
We decided to go for _ops structures for sparc32.

In one case we do runtime patching where we replace the
implementation depending on the platform.

It it 2 times 3 instructions - so nothing big and fancy.

Thanks for the feedback anyway!

	Sam