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]

Message-ID: <CAGcnep9Ez-S962vukR_a=otzcSxDRo5HUW2vG_YCBanCfURGXw@mail.gmail.com>
Date:   Fri, 22 Apr 2022 18:45:46 +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 8:50 PM Steven Rostedt <rostedt@...dmis.org> wrote:
>
> 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?
>

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