linux-kernel - Re: On trace_*_rcuidle functions in modules

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: <CALAqxLV1A6sOC1GWpFYXeBoDff0+AJgoOYK7NktcTdvX3kvAeg@mail.gmail.com>
Date:   Wed, 15 Apr 2020 12:56:52 -0700
From:   John Stultz <john.stultz@...aro.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     paulmck@...nel.org, Josh Triplett <josh@...htriplett.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Saravana Kannan <saravanak@...gle.com>,
        Todd Kjos <tkjos@...gle.com>, Stephen Boyd <sboyd@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: On trace_*_rcuidle functions in modules

On Wed, Apr 15, 2020 at 5:53 AM Steven Rostedt <rostedt@...dmis.org> wrote:
>
> [ +Peter +Thomas ]
>
> On Tue, 14 Apr 2020 19:20:01 -0700
> John Stultz <john.stultz@...aro.org> wrote:
>
> > Hey folks,
> >   So recently I was looking at converting some drivers to be loadable
> > modules instead of built-in only, and one of my patches just landed in
> > -next and started getting build error reports.
> >
> > It ends up, recently in the merge window, the driver I was converting
> > to module switched a trace_*() function to trace_*_rcuidle() to fix a
> > bug.  Now when building as a module, if tracing is configured on, it
> > can't seem to find the trace_*_rcuidle() symbol.
>
> Which modules need this.

Hey Steven!

I'm trying to enable the qcom rpmh driver
(drivers/soc/qcom/rpmh-rsc.c) to be a module.  As I mentioned to Paul,
it registers a cpu_pm notifier callback, which calls its
__tcs_buffer_write() function. The trace in the __tcs_buffer_write()
function was just converted to using rcuidle to address bugs seen when
it was being called from idle.

> Currently, Thomas and Peter are working on removing trace events from
> places that don't have RCU enabled, or at least cleaning up the context
> switches from user to kernel to interrupt.

So does that mean folks would most likely lean to trying to remove the
tracepoint rather than reevaluating allowing the rcuidle call to be
made from the module?

thanks
-john