[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150622181528.GE20244@pd.tnic>
Date: Mon, 22 Jun 2015 20:15:28 +0200
From: Borislav Petkov <bp@...en8.de>
To: Andy Lutomirski <luto@...capital.net>
Cc: Kees Cook <keescook@...omium.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Oleg Nesterov <oleg@...hat.com>,
Denys Vlasenko <vda.linux@...glemail.com>,
Brian Gerst <brgerst@...il.com>,
Frédéric Weisbecker <fweisbec@...il.com>,
X86 ML <x86@...nel.org>, Rik van Riel <riel@...hat.com>
Subject: Re: [PATCH v2 03/14] notifiers: Assert that RCU is watching in
notify_die
On Mon, Jun 22, 2015 at 10:37:39AM -0700, Andy Lutomirski wrote:
> But if we OOPS, we'll OOPS after the lockdep splat and the lockdep
> splat will scroll off the screen, right? Am I missing something here?
No, you're not.
> notify_die is called before the actual OOPS code is invoked in traps.c.
Yes, and with this assertion, you get to potentially print two
dump_stack()'s back-to-back instead of the one from traps.c.
And if the machine is about to be wedged solid soon anyway, we want to
dump as less (not-so-important) blurb to serial/console as possible. And
in this case, my suspicion is not that the lockdep splat will scroll
off the screen but that we might freeze before we even issue the whole
thing.
That's why I think we should be conservative and make the lockdep splat
come out second, if possible.
Am I making more sense now?
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists