linux-kernel - Re: [PATCH] rcu: ftrace: avoid tracing a few functions executed in multi_cpu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 21 Apr 2022 08:50:47 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     patrick wang <patrick.wang.shcn@...il.com>
Cc:     paulmck@...nel.org, frederic@...nel.org, quic_neeraju@...cinc.com,
        josh@...htriplett.org, mathieu.desnoyers@...icios.com,
        jiangshanlai@...il.com, joel@...lfernandes.org,
        rcu@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rcu: ftrace: avoid tracing a few functions executed in
 multi_cpu_stop()

On Thu, 21 Apr 2022 19:36:06 +0800
patrick wang <patrick.wang.shcn@...il.com> wrote:

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

Are you saying that the RISC-V stop machine implementation has code being
called on the other CPUs while they wait?

-- Steve