Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1431631 > unrolled thread

Re: [PATCH] Disable non-ABI-compliant optimisations for live patching

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] Disable non-ABI-compliant optimisations for live patching Pavel Machek <pavel@ucw.cz> - 2016-06-27 00:40 +0200
    Re: [PATCH] Disable non-ABI-compliant optimisations for live  patching Jiri Kosina <jikos@kernel.org> - 2016-06-27 10:20 +0200
      Re: [PATCH] Disable non-ABI-compliant optimisations for live  patching Jiri Kosina <jikos@kernel.org> - 2016-06-27 10:30 +0200
        Re: [PATCH] Disable non-ABI-compliant optimisations for live patching Pavel Machek <pavel@ucw.cz> - 2016-06-27 10:40 +0200
          Re: [PATCH] Disable non-ABI-compliant optimisations for live  patching Jiri Kosina <jikos@kernel.org> - 2016-06-27 13:40 +0200
      Re: [PATCH] Disable non-ABI-compliant optimisations for live patching Pavel Machek <pavel@ucw.cz> - 2016-06-27 10:30 +0200

#1431631 — Re: [PATCH] Disable non-ABI-compliant optimisations for live patching

On Wed 2016-06-22 16:24:41, Torsten Duwe wrote:
> Live patching, as we use it, deliberately disrupts the fabric of
> compile units; thus all assumptions a compiler can make about the
> control flow may be invalid. As an example, it could analyse that a
> callee does not touch a caller-saved register at all, so why waste
> memory bandwidth saving it? The register allocations for the live
> patch replacement function may however be quite different.
> 
> Starting with this example, disable all compiler optimisations that
> do not strictly comply with the established calling conventions.

I thought that in such case, person creating the live patch should
notice and adjust patch appropriately, at assembly level if
neccessary..?

If this is not true, and we want gcc to help us, what other
optimalizations do we need to disable? Even changes inside one
compiler unit can be "interesting"...

								Pavel

> Signed-off-by: Torsten Duwe <duwe@suse.de>
> ---
> 
> Working on the arm64 ftrace-with-regs/livepatch, it struck me that
> this is a general problem: with live patching, certain optimisations
> must be switched off for all architectures, the new(?) IPA register
> allocator in gcc6 is only one example. We should tackle this
> well before it bites us.
> 
> 	Torsten
> 
> ---
>  Makefile | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/Makefile b/Makefile
> index b409076..424d2e6 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -743,6 +743,13 @@ KBUILD_CFLAGS 	+= $(call cc-option, -femit-struct-debug-baseonly) \
>  		   $(call cc-option,-fno-var-tracking)
>  endif
>  
> +ifdef CONFIG_LIVEPATCH
> +# The compiler might generate ABI "shortcuts" to speed up the code,
> +# making assumptions which are no longer valid when live patching
> +# is enabled. Disable all of them.
> +KBUILD_CFLAGS	+= $(call cc-option,-fno-ipa-ra)
> +endif
> +
>  ifdef CONFIG_FUNCTION_TRACER
>  ifndef CC_FLAGS_FTRACE
>  CC_FLAGS_FTRACE := -pg

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [next] | [standalone]

#1431800 — Re: [PATCH] Disable non-ABI-compliant optimisations for live patching

On Mon, 27 Jun 2016, Pavel Machek wrote:

> > Live patching, as we use it, deliberately disrupts the fabric of
> > compile units; thus all assumptions a compiler can make about the
> > control flow may be invalid. As an example, it could analyse that a
> > callee does not touch a caller-saved register at all, so why waste
> > memory bandwidth saving it? The register allocations for the live
> > patch replacement function may however be quite different.
> > 
> > Starting with this example, disable all compiler optimisations that
> > do not strictly comply with the established calling conventions.
> 
> I thought that in such case, person creating the live patch should
> notice and adjust patch appropriately, at assembly level if
> neccessary..?

Yes, that still holds; a lot of things could be automated though, and 
creating the automation tools is one of the big TODO items.

> If this is not true, and we want gcc to help us, what other 
> optimalizations do we need to disable? Even changes inside one compiler 
> unit can be "interesting"...

What would actually be helpful is gcc providing us with a list of 
functions where it performed this ABI-violating optimization (similarly, 
we're already obtaining list of "what got inlined where"). Unfortunately, 
-fdump-ipa-ra is currently missing; I'm talking to gcc guys now to have it 
implemented.

-- 
Jiri Kosina
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1431808 — Re: [PATCH] Disable non-ABI-compliant optimisations for live patching

On Mon, 27 Jun 2016, Pavel Machek wrote:

> > > I thought that in such case, person creating the live patch should
> > > notice and adjust patch appropriately, at assembly level if
> > > neccessary..?
> > 
> > Yes, that still holds; a lot of things could be automated though, and 
> > creating the automation tools is one of the big TODO items.
> 
> So the patch is not a bugfix, it is just something that slows down
> kernel to make stuff easier for the person doing the live patching...?

Well, up to the last week noone realized the implications IPA-RA has for 
live patches. Now that we know about this, we have to deal with it 
somehow; as currently gcc doesn't provide easy way for us to obtain the 
information (non-existing -fdump-ipa-ra), disabling the optimization on 
CONFIG_LIVEPATCH-enabled kernels is a sensible workaround before we're 
able to get the information from gcc.

> What you actually want is "whenever source of function A influenced code 
> in function B, I want to be notified", right?
> 
> If gcc can eliminate an if() brach in function B, because it can tell 
> reading function A it can not happen, you need to know. Maybe that's 
> limited to ABI today, but...

Yeah; dead code elimination is also a thing to watch for.

-- 
Jiri Kosina
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1431816

On Mon 2016-06-27 10:26:58, Jiri Kosina wrote:
> On Mon, 27 Jun 2016, Pavel Machek wrote:
> 
> > > > I thought that in such case, person creating the live patch should
> > > > notice and adjust patch appropriately, at assembly level if
> > > > neccessary..?
> > > 
> > > Yes, that still holds; a lot of things could be automated though, and 
> > > creating the automation tools is one of the big TODO items.
> > 
> > So the patch is not a bugfix, it is just something that slows down
> > kernel to make stuff easier for the person doing the live patching...?
> 
> Well, up to the last week noone realized the implications IPA-RA has for 
> live patches. Now that we know about this, we have to deal with it 
> somehow; as currently gcc doesn't provide easy way for us to obtain the 
> information (non-existing -fdump-ipa-ra), disabling the optimization on 
> CONFIG_LIVEPATCH-enabled kernels is a sensible workaround before we're 
> able to get the information from gcc.

You can still build the whole kernel with the patch applied, and look
for code differences in all the functions, then analyzing them... no?

> > What you actually want is "whenever source of function A influenced code 
> > in function B, I want to be notified", right?
> > 
> > If gcc can eliminate an if() brach in function B, because it can tell 
> > reading function A it can not happen, you need to know. Maybe that's 
> > limited to ABI today, but...
> 
> Yeah; dead code elimination is also a thing to watch for.

That was supposed to be just an example.

I believe you want "whenever source of function A influenced code in
function B, I want to be notified", and I believe it should be
documented as such.

gcc might produce new and interesting optimalizations in future. I
believe you want --dont-let-function-influence-function switch to gcc,
not growing list of --no-optimalization-A, --no-optimalization-B...

Thanks,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1431966 — Re: [PATCH] Disable non-ABI-compliant optimisations for live patching

On Mon, 27 Jun 2016, Pavel Machek wrote:

> I believe you want "whenever source of function A influenced code in 
> function B, I want to be notified", and I believe it should be 
> documented as such.

Well, exactly. IPA is a group of optimizations that are, by definition, 
intra-prodcedural.

-- 
Jiri Kosina
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1431809

On Mon 2016-06-27 10:13:28, Jiri Kosina wrote:
> On Mon, 27 Jun 2016, Pavel Machek wrote:
> 
> > > Live patching, as we use it, deliberately disrupts the fabric of
> > > compile units; thus all assumptions a compiler can make about the
> > > control flow may be invalid. As an example, it could analyse that a
> > > callee does not touch a caller-saved register at all, so why waste
> > > memory bandwidth saving it? The register allocations for the live
> > > patch replacement function may however be quite different.
> > > 
> > > Starting with this example, disable all compiler optimisations that
> > > do not strictly comply with the established calling conventions.
> > 
> > I thought that in such case, person creating the live patch should
> > notice and adjust patch appropriately, at assembly level if
> > neccessary..?
> 
> Yes, that still holds; a lot of things could be automated though, and 
> creating the automation tools is one of the big TODO items.

So the patch is not a bugfix, it is just something that slows down
kernel to make stuff easier for the person doing the live patching...?

> > If this is not true, and we want gcc to help us, what other 
> > optimalizations do we need to disable? Even changes inside one compiler 
> > unit can be "interesting"...
> 
> What would actually be helpful is gcc providing us with a list of 
> functions where it performed this ABI-violating optimization (similarly, 
> we're already obtaining list of "what got inlined where"). Unfortunately, 
> -fdump-ipa-ra is currently missing; I'm talking to gcc guys now to have it 
> implemented.

What you actually want is "whenever source of function A influenced
code in function B, I want to be notified", right?

If gcc can eliminate an if() brach in function B, because it can tell
reading function A it can not happen, you need to know. Maybe that's
limited to ABI today, but...

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web