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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAGcnep86pd2trfTovU8_z1msOstx7gKCdndm=pHLDGTy+_K7=g@mail.gmail.com>
Date:   Thu, 21 Apr 2022 19:36:06 +0800
From:   patrick wang <patrick.wang.shcn@...il.com>
To:     Steven Rostedt <rostedt@...dmis.org>
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, 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.

> > [*] 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