Messages in this thread | | | Date | Tue, 12 Jul 2022 06:49:16 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH -printk] printk, tracing: fix console tracepoint |
| |
On Tue, Jul 12, 2022 at 09:39:40AM -0400, Steven Rostedt wrote: > On Tue, 12 Jul 2022 04:49:54 -0700 > "Paul E. McKenney" <paulmck@kernel.org> wrote: > > > > But a quick fix that stopped the bleeding and allowed printk() to > > > progress would be useful in the short term, regardless of whether or > > > not in the longer term it makes sense to make srcu_read_lock_trace() > > > and srcu_read_unlock_trace() NMI-safe. > > > > Except that doesn't rcuidle && in_nmi() imply a misplaced trace event? > > > > Isn't it still the case that you are not supposed to have trace events > > in NMI handlers before RCU is watching or after it is no longer watching, > > just as for entry/exit code in general? Once in the body of the handler, > > rcuidle should be false and all should be well. > > > > Or am I missing something here? > > I guess the question is, can we have printk() in such a place? Because this > tracepoint is attached to printk and where ever printk is done so is this > tracepoint.
As I understand it, code in such a place should be labeled noinstr. Then the call to printk() would be complained about as an illegal noinstr-to-non-noinstr call.
But where exactly is that printk()?
Thanx, Paul
| |