console: use might_sleep in console_lock
Instead of BUG_ON(in_interrupt()), since that doesn't check for all the newfangled stuff like preempt. Note that this is valid since the console_sem is essentially used like a real mutex with only two twists: - we allow trylock from hardirq context - across suspend/resume we lock the logical console_lock, but drop the semaphore protecting the locking state. Now that doesn't guarantee that no one is playing tricks in single-thread atomic contexts at suspend/resume/boot time, but - I couldn't find anything suspicious with some grepping, - might_sleep shouldn't die, - and I think the upside of catching more potential issues is worth the risk of getting a might_sleep backtrace that would have been save (and then dealing with that fallout). Cc: Dave Airlie <airlied@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This commit is contained in:
parent
ecbbfd44a0
commit
6b898c07cb
1 changed files with 2 additions and 1 deletions
|
@ -1914,7 +1914,8 @@ static int __cpuinit console_cpu_notify(struct notifier_block *self,
|
|||
*/
|
||||
void console_lock(void)
|
||||
{
|
||||
BUG_ON(in_interrupt());
|
||||
might_sleep();
|
||||
|
||||
down(&console_sem);
|
||||
if (console_suspended)
|
||||
return;
|
||||
|
|
Loading…
Reference in a new issue