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. Per the patches earlier in this series, this is no longer the case.My understanding is that this series reduces a lot the amount of code called with RCU disabled. As a result the particular printk() call mentioned by commit fc98c3c8c9dc ("printk: use rcuidle console tracepoint") is called with RCU enabled now. Hence this particular problem is fixed better way now. But is this true in general? 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.
I am not sure if anyone cares. printk() is the best effort functionality because of the consoles code anyway. Also I wonder if anyone uses this trace_console().
This is the tracepoint used to spool all of printk into ftrace, I suspect there's users, but I haven't used it myself.
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.
