Messages in this thread | | | Date | Sat, 30 Nov 2013 17:51:22 +0100 | From | Oleg Nesterov <> | Subject | Re: [PATCH] Add a text_poke syscall v2 |
| |
Sorry for completely offtopic question, but while we are here...
On 11/30, Jiri Kosina wrote: > > We have moved from using stop_machine() to int3-based patching exactly > because it's much more lightweight.
I don't really understans the barriers in poke_int3_handler() and text_poke_bp(). To the point, I do not really understand why do we actually need bp_patching_in_progress, but lets ignore this.
Lets look at the end of text_poke_bp(), it does
on_each_cpu(do_sync_core, NULL, 1);
bp_patching_in_progress = false; smp_wmb();
First of all, this smp_wmb() is not clear. But what I actually can't understand is why it is safe to clear bp_patching_in_progress.
OK, on_each_cpu() should serialize us with do_int3(), but only if poke_int3_handler() is called with irqs disabled.
However, do_int3() does preempt_conditional_sti() and this looks as if it can be called with irqs enabled? If this is actually possible then text_poke_bp() needs synchronize_sched() to avoid the races with poke_int3_handler(), afaics.
OTOH, int3 is GATE_INTERRUPT, doesn't this mean that that do_int3() can enable irqs unconditionally and on_each_cpu() also acts as a synchronization barrier?
Oleg.
| |