Messages in this thread | | | Date | Tue, 12 Jul 2022 09:39:40 -0400 | From | Steven Rostedt <> | Subject | Re: [PATCH -printk] printk, tracing: fix console tracepoint |
| |
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.
-- Steve
| |