Re: [PATCH] panic.c: export panic_on_oops

[Linus Torvalds <torvalds@linux-foundation.org>]

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