Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
MIME-Version: 1.0
References: <20220418043735.11441-1-patrick.wang.shcn@gmail.com>
 <20220418143404.55c8fcab@gandalf.local.home> <CAGcnep8bH4Nncbt3t+VRLff35ZyD8JyzHcEgkq-u6TEq47jqzQ@mail.gmail.com>
 <CAGcnep_Gx+3KiUvDVronYKn_divU3OM-RQEOPZakv7MRYh4EJw@mail.gmail.com>
 <20220420114454.69ab108c@gandalf.local.home> <20220420122633.55d4ff6b@gandalf.local.home>
In-Reply-To: <20220420122633.55d4ff6b@gandalf.local.home>
From:   patrick wang <patrick.wang.shcn@gmail.com>
Date:   Thu, 21 Apr 2022 19:36:06 +0800
Message-ID: <CAGcnep86pd2trfTovU8_z1msOstx7gKCdndm=pHLDGTy+_K7=g@mail.gmail.com>
Subject: Re: [PATCH] rcu: ftrace: avoid tracing a few functions executed in multi_cpu_stop()
To:     Steven Rostedt <rostedt@goodmis.org>
Cc:     paulmck@kernel.org, frederic@kernel.org, quic_neeraju@quicinc.com,
        josh@joshtriplett.org, mathieu.desnoyers@efficios.com,
        jiangshanlai@gmail.com, joel@joelfernandes.org,
        rcu@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Apr 21, 2022 at 12:26 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Wed, 20 Apr 2022 11:44:54 -0400
> Steven Rostedt <rostedt@goodmis.org> 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.

> > [*] You really should come up with a better way than stop machine, because
> > the stop machine method is really disruptive, can you not use the break
> > point method for updates?
>
> Talk about dejavu!
>
>   https://lore.kernel.org/all/mhng-62c2ef00-fb64-48c3-a2bb-43b2799161bf@palmer-ri-x1c9/
>

Right, breakpoint should be better.

This stall happens on my qemu machine too, maybe it's qemu related.

Thanks,
Patrick