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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/