On Mon, Jun 22, 2015 at 11:15 AM, Borislav Petkov <[email protected]> wrote: > 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.
That'll annoy people using regular consoles, though. I think this scenario isn't that likely. If we dereference a NULL pointer, then we really should rcu watching before we actually oops in the page fault code. Similarly, if we take a non-fixed-up GPF, we should have rcu watching in the early part of do_general_protection. I'd be all for skipping the assertion entirely if we're going to OOPS, but we don't know whether we're actually OOPSing when notify_die is called. We could individually instrument everything, or we could just drop this patch entirely, but it has helped me catch some goofs while developing all this code. --Andy > > Am I making more sense now? > > -- > Regards/Gruss, > Boris. > > ECO tip #101: Trim your mails when you reply. > -- -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
