Re: [RFC] x86/alternatives: Merge first and second step in text_poke_bp_batch

[Jiri Olsa]

On Tue, Jan 14, 2025 at 10:36:04AM -0500, Steven Rostedt wrote:
> On Tue, 14 Jan 2025 15:31:14 +0100
> Jiri Olsa <olsajiri@xxxxxxxxx> wrote:
> 
> > > IIRC this is the magic recipe blessed by both Intel and AMD, and
> > > if we're going to be changing this I would want both vendors to sign off
> > > on that.  
> > 
> > ok
> 
> Right. In fact Intel wouldn't sign off on this recipe for a few years. We
> actually added to the kernel before they gave their full blessing. I got a
> "wink, it should work" from them but they wouldn't officially say so ;-)
> 
> But a lot of it has to do with all the magic of the CPU. They have always
> allowed writing the one byte int3. I figured, if I could write that one
> byte int3 then run a sync on all CPUs where all CPUs see that change, then
> nothing should ever care about the other 4 bytes after that int3 (a sync
> was already done). Then change the 4 bytes and sync again.
> 
> I doubt the int3 plus the 4 byte change would work, as was mentioned if the
> other 4 bytes were on another cache line, another CPU could read the first
> set of bytes without the int3 and the second set of bytes with the update
> and go boom!
> 
> This dance was to make sure everything sees everything properly. I gave a
> talk about this at Kernel-Recipes in 2019:
> 
>   https://www.slideshare.net/slideshow/kernel-recipes-2019-ftrace-where-modifying-a-running-kernel-all-started/177509633#44

nice! thanks for all the details,
jirka