lkml.org 
[lkml]   [2009]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] panic.c: export panic_on_oops


On Mon, 12 Oct 2009, Artem Bityutskiy wrote:
>
> But mtdoops tries to solves the following problem. What if we are
> oopsing in an interrupt, which interrupted the mtd driver, so we have
> all the locks held, and the mtd driver is in a unexpected stage ATM? Or
> what if we are oopsing in the mtd driver, or in something which was
> called by the MTD driver.?

Well, quite frankly, if you have an oops while holding a spinlock, then
the machine is dead _anyway_.

So what I would suggest is to just ignore the above problem. No amount of
workqueue logic will help it - if the oops happened while an interrupt
held a critical mtd lock, that lock will _never_ be released, so exactly
what would be helped?

Now, I realize that _if_ you treat mtdoops as a 'console' layer, then you
need to do that crazy thing, because you still want the oops to print out
to the other consoles, and you're only getting data one line at a time.
But since that was the wrong thing to do for a lot of other reasons
anyway, that's not a very good argument.

Once you do the final flush in a controlled place _after_ you've printed
out all the oops information, you simply don't care about locks any more.
Because if you were holding critical locks, you're done anyway.

Sure, maybe you want to do a "trylock()" and skip the oops flush entirely
in the mtd layer if you can't do it, but it's the "let's use a workqueue"
or something that doesn't seem to make a lot of sense to me.

Linus


\
 
 \ /
  Last update: 2009-10-18 23:28    [W:0.178 / U:0.444 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site