
Avoiding Retpolines with Static Calls - rwmj
https://lwn.net/SubscriberLink/815908/8fe01199eee0f77f/
======
saagarjha
> Changing the target of a static call requires patching the code of the
> running kernel, which is an expensive operation.

Am I misunderstanding, or is this literally patching code pages at runtime?
This sounds like it could be dangerous…

~~~
asveikau
Seems like it could be done safely...

Remove X bit and add write bit.

Patch.

Remove write bit and add X bit.

Tricky part: If you get a protection fault trying to jump there, spin until
the X bit is re-added.

So yeah. That is going to be a hefty performance cost to write.

~~~
barrkel
Seems safer to me to park CPUs in known safe spots where they can spin until
modification is complete. CPUs could check if there's a pending patch when
they attempt to reschedule, and when all CPUs apart from the patching CPU are
safe, then the patch can go ahead.

Trying to retry an operation (so it's transparent from the user's perspective)
or reset state to the way it was at the time of the protection fault sounds
harder to my mind.

PS: I looked at the ftrace doc linked above, and it's architecture dependent
of course, but for ftrace's purposes, they use generally use breakpoints on
the place being modified.

