On Thu, Apr 21, 2022 at 8:50 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>
> On Thu, 21 Apr 2022 19:36:06 +0800
> patrick wang <patrick.wang.shcn@xxxxxxxxx> wrote:
>
> > On Thu, Apr 21, 2022 at 12:26 AM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> > >
> > > On Wed, 20 Apr 2022 11:44:54 -0400
> > > Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> > >
> > >
> > > Interesting. On x86 when we used stop machine[*] it was not an issue to
> > > modify the code that is being executed in stop machine. I'm curious to
> > > exactly what the issue is if something does get traced in the stop machine
> > > processing. Why does it crash?
> >
> > I looked up the commit history. When x86 turned to breakpoints, stop
> > machine's state machine loop had no calls during waiting. So there
> > was no function being called during modifying code. Which means
> > there were no other cpus would load those instructions to be updated
> > in this period. While the stop machine currently will call other functions
> > and the call chain is fairly deep. So it may not quite be suitable for ftrace
> > now because it can not make sure the instructions within its own call
> > chain are updated atomically.
>
> Are you saying that the RISC-V stop machine implementation has code being
> called on the other CPUs while they wait?
>
Yes, and not just RISC-V. It's arch-independent. It's the internal change of
stop machine implementation.
----------------------------------------------------------------
Former stop machine wait loop:
do {
cpu_relax(); => macro
...
} while (curstate != STOPMACHINE_EXIT);
-----------------------------------------------------------------
Current stop machine wait loop:
do {
stop_machine_yield(cpumask); => function (notraced)
...
touch_nmi_watchdog(); => function (notraced, inside calls also notraced)
...
rcu_momentary_dyntick_idle(); => function (notraced, inside calls traced)
} while (curstate != MULTI_STOP_EXIT);
------------------------------------------------------------------
Thanks,
Patrick
