Messages in this thread | | | From | Björn Töpel <> | Subject | Re: [PATCH] riscv: kprobe: Optimize kprobe with accurate atomicity | Date | Mon, 30 Jan 2023 17:56:43 +0100 |
| |
Mark Rutland <mark.rutland@arm.com> writes:
>> ...and stop_machine() with !PREEMPTION is broken as well, when you're >> replacing multiple instructions (see Mark's post at [1]). The >> stop_machine() dance might work when you're replacing *one* instruction, >> not multiple as in the RISC-V case. I'll expand on this in a comment in >> the OPTPROBES v6 series. > > Just to clarify, my comments in [1] were assuming that stop_machine() was not > used, in which case there is a problem with or without PREEMPTION. > > I believe that when using stop_machine(), the !PREEMPTION case is fine, since > stop_machine() schedules work rather than running work in IRQ context on the > back of an IPI, so no CPUs should be mid-sequnce during the patching, and it's > not possible for there to be threads which are preempted mid-sequence.
TIL! stop_cpus() highlights that very nicely. Thanks for clearing that out! That's good news; That means that this fix [4] should go in.
> That all said, IIUC optprobes is going to disappear once fprobe is ready > everywhere, so that might be moot.
Yes (However, the stop_machine()/!PREEMPTION issue was with ftrace).
Björn
[4] https://lore.kernel.org/lkml/20230107133549.4192639-2-guoren@kernel.org/
| |