[lkml]   [2019]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v3 0/6] Static calls
On Fri, Jan 11, 2019 at 12:31 PM Josh Poimboeuf <> wrote:
> I was referring to the fact that a single static call key update will
> usually result in patching multiple call sites. But you're right, it's
> only 1-2 trampolines per text_poke_bp() invocation. Though eventually
> we may want to batch all the writes like what Daniel has proposed for
> jump labels, to reduce IPIs.

Yeah, my suggestion doesn't allow for batching, since it would
basically generate one trampoline for every rewritten instruction.

> Regardless, the trampoline management seems more complex to me. But
> it's easier to argue about actual code, so maybe I'll code it up to make
> it easier to compare solutions.

I do agree hat the stack games are likely "simpler" in one sense. I
just abhor playing those kinds of games with the entry code and entry

A small bit of extra complexity in the code that actually does the
rewriting would be much more palatable to me than the complexity in
the entry code. I prefer seeing the onus of complexity being on the
code that introduces the problem, not on a innocent bystander.

I'd like to say that our entry code actually looks fairly sane these
days. I'd _like_ to say that, but I'd be lying through my teeth if I
did. The macros we use make any normal persons head spin.

The workaround for the stack corruption was fairly simple, but the
subtlety behind the *reason* for it was what made my hackles rise
about that code.

The x86 entry code is some of the nastiest in the kernel, I feel, with
all the subtle interactions about odd stack switches, odd CPU bugs
causing odd TLB switches, NMI interactions etc etc.

So I am fully cognizant that the workaround to shift the stack in the
entry code was just a couple of lines, and not very complicated.

And I agree that I may be a bit oversensitive about that area, but it
really is one of those places where I go "damn, I think I know some
low-level x86 stuff better than most, but that code scares *me*".

Which is why I'd accept a rather bigger complexity hit just about
anywhere else in the code...


 \ /
  Last update: 2019-01-11 21:47    [W:0.141 / U:1.608 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site