From: Peter Zijlstra <peterz@infradead.org>
To: Petr Mladek <pmladek@suse.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
LKML <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: [PATCH] printk/tracing: Do not trace printk_nmi_enter()
Date: Fri, 7 Sep 2018 11:30:55 +0200 [thread overview]
Message-ID: <20180907093055.GL24082@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20180907082834.vjycyvt6nddpb4la@pathway.suse.cz>
On Fri, Sep 07, 2018 at 10:28:34AM +0200, Petr Mladek wrote:
> On Fri 2018-09-07 09:45:31, Peter Zijlstra wrote:
> > On Thu, Sep 06, 2018 at 11:31:51AM +0900, Sergey Senozhatsky wrote:
> > > An alternative option, thus, could be re-instating back the rule that
> > > lockdep_off/on should be the first and the last thing we do in
> > > nmi_enter/nmi_exit. E.g.
> > >
> > > nmi_enter()
> > > lockdep_off();
> > > printk_nmi_enter();
> > >
> > > nmi_exit()
> > > printk_nmi_exit();
> > > lockdep_on();
> >
> > Yes that. Also, those should probably be inline functions.
> >
> > ---
> > Subject: locking/lockdep: Fix NMI handling
> >
> > Someone put code in the NMI handler before lockdep_off(). Since lockdep
> > is not NMI safe, this wrecks stuff.
>
> My view is that nmi_enter() has to switch several features into
> NMI-safe mode. The code must not trigger the other features when
> they are still in the unsafe mode.
>
> It is a chicken&egg problem. And it is hard to completely prevent
> regressions caused by future changes.
Sure, not bothered too much about the regression, that happens.
> I though that printk_nmi_enter() should never need any lockdep-related
> code. On the other hand, people might want to printk debug messages
> when lockdep_off() is called. This is why I put it in the current order.
Nah, that'd be broken. Or rather, if you want to debug NMI stuff, you
had better know wth you're doing. Printk, as per mainline, is utterly
useless for that -- I still carry those force_early_printk patches
locally.
Because even if the core printk code were to be NMI safe (possible I
think, all we need is a lockless ring-buffer), then none of the console
drivers are :/
(I really hate this current printk-nmi mess)
> That said, I am not against this change. Especially the inlining
> is a good move. Note that lockdep_off()/lockdep_on() must not
> be traced as well.
Hard to trace an inline funcion; we could make it __always_inline to
feel better.
next prev parent reply other threads:[~2018-09-07 9:31 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-06 1:33 [PATCH] printk/tracing: Do not trace printk_nmi_enter() Steven Rostedt
2018-09-06 2:31 ` Sergey Senozhatsky
2018-09-06 9:04 ` Petr Mladek
2018-09-06 15:22 ` Steven Rostedt
2018-09-07 7:45 ` Peter Zijlstra
2018-09-07 8:28 ` Petr Mladek
2018-09-07 8:35 ` Sergey Senozhatsky
2018-09-07 13:47 ` Steven Rostedt
2018-09-07 9:30 ` Peter Zijlstra [this message]
2018-09-07 13:53 ` Steven Rostedt
2018-09-10 5:32 ` locking/lockdep: Fix NMI handling kbuild test robot
2018-09-07 7:34 ` [PATCH] printk/tracing: Do not trace printk_nmi_enter() Peter Zijlstra
2018-09-07 13:41 ` Steven Rostedt
2018-09-07 13:45 ` Peter Zijlstra
2018-09-07 13:55 ` Steven Rostedt
2018-09-07 14:01 ` Steven Rostedt
2018-09-07 14:03 ` Peter Zijlstra
2018-09-07 14:52 ` Sergey Senozhatsky
2018-09-07 14:02 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180907093055.GL24082@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=sergey.senozhatsky@gmail.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox