On Thu 2022-06-09 12:02:04, Peter Zijlstra wrote:
On Thu, Jun 09, 2022 at 11:16:46AM +0200, Petr Mladek wrote:
On Wed 2022-06-08 16:27:47, Peter Zijlstra wrote:
The problem, per commit fc98c3c8c9dc ("printk: use rcuidle console
tracepoint"), was printk usage from the cpuidle path where RCU was
already disabled.
Does this "prevent" calling printk() a safe way in code with
RCU disabled?
On x86_64, yes. Other architectures, less so.
Specifically, the objtool noinstr validation pass will warn at build
time (DEBUG_ENTRY=y) if any noinstr/cpuidle code does a call to
non-vetted code like printk().
At the same time; there's a few hacks that allow WARN to work, but
mostly if you hit WARN in entry/noinstr you get to keep the pieces in
any case.
On other architecture we'll need to rely on runtime coverage with
PROVE_RCU. That is, if a splat like in the above mentioned commit
happens again, we'll need to fix it by adjusting the callchain, not by
mucking about with RCU state.
Makes sense. Feel free to use for this patch:
Acked-by: Petr Mladek <pmladek@xxxxxxxx>
Therefore if this patch allows to remove some tricky tracing
code then it might be worth it. But if trace_console_rcuidle()
variant is still going to be available then I would keep using it.
My ultimate goal is to delete trace_.*_rcuidle() and RCU_NONIDLE()
entirely. We're close, but not quite there yet.
I keep my fingers crossed.
Best Regards,
Petr
