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

Groups > linux.kernel > #1431632 > 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:50 +0200
    Re: [PATCH] Disable non-ABI-compliant optimisations for live patching Torsten Duwe <duwe@lst.de> - 2016-06-27 09:10 +0200

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

On Thu 2016-06-23 14:47:03, Jiri Kosina wrote:
> On Thu, 23 Jun 2016, Jiri Kosina wrote:
> 
> > > I haven't looked at the fentry solution, but the code I'm involved in saves
> > > the registers so that ftrace, live patch and friends can work freely. But
> > > then it restores all regs and _then_ calls the replacement, so ftrace
> > > saving all regs is no gain at all.
> > 
> > You're right, thanks for bringing this up.
> > 
> > In principle we should be able to modify the trampoline so that it 
> > performs its own register saving (in ftrace_regs_caller) and restoring 
> > (*), completely shielding the new function from any optimization gcc might 
> > have done on registers, shouldn't we?
> > 
> > (*) we'll have to piggy-back on ftrace_epilogue on that, i.e. making the 
> >     return to the original code go through trampoline as well (the same 
> >     way graph tracer works)
> 
> Okay, after looking more about how ftrace implements the return 
> trampolines for graph caller, it'd be rather difficult to implement in a 
> way that we neither interfere with ftrace graph tracer (the 
> ftrace_ret_stack in task_struct) nor introduce a serious performance 
> overhead or stack usage pressure.
> 
> I am pretty sure the overhead we'd be adding would be much worse than just 
> really simply turning the IPA-RA off in CONFIG_LIVEPATCH-enabled kernels 
> is the easiest way to go.
> 
> After talking to Jan Hubicka, I'd actually suggest turning off most/all 
> the IPA optimizations; they are supposed to be of questionable benefit for 
> kernel anyway, and they might be causing serious issues for us.

Lets compile kernel with -O0, and sacrifice few lambs....?

Would it be possible to document which kind of guarantees live
patching needs from compiler?

I always assumed that whoever is preparing the patch does manual
investigation to see what needs to be changed and how, but apparantly
that's not the case, so documentation would be good.

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

[toc] | [next] | [standalone]

#1431763

On Mon, Jun 27, 2016 at 12:39:56AM +0200, Pavel Machek wrote:

> Would it be possible to document which kind of guarantees live
> patching needs from compiler?

Sure, here you go, all required guarantees:

Stick to the ABI.

> I always assumed that whoever is preparing the patch does manual
> investigation to see what needs to be changed and how, but apparantly
> that's not the case, so documentation would be good.

See above for the documentation. Imagine each architecture had a whole
hand-optimised assembler kernel. That would give some performance
improvement, right? Same issue here, only much smaller. It's ultimate
performance vs. maintainability.

HTH,
	Torsten

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web