Messages in this thread | | | Date | Thu, 25 Oct 2018 18:05:39 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [RFC][PATCHv2 1/4] panic: avoid deadlocks in re-entrant console drivers |
| |
On (10/25/18 10:29), Petr Mladek wrote: > > Yes, klogd is not a big deal. I just think that the bust_spinlocks() > ping-pong would just confuse the code.
I agree; that's why I put some comments there.
> It might be better to keep the spinlocks busted and make sure that we do > not cause regressions by not calling bust_spinlocks(0).
Sure, I understand. One reason to keep bust_spinlocks(0) there was "invoke arch-specific bust_spinlocks(0), which might do something that common bust_spinlocks() wouldn't do". Without going into details if any arch actually does anything "special" in bust_spinlocks(0). Another reason was - this patch looks like a -stable material to me; especially given that we have panic() deadlock reports now. So I wanted to have a one liner which will not change things for arch-s that re-define bust_spinlocks() and, at the same time, fix the deadlock. Other than that I'm all for keeping spinlocks busted all the time and just doing:
--- #ifdef CONFIG_VT unblank_screen(); #endif console_unblank(); ---
in panic().
BTW, speaking of s390 bust_spinlocks(). It seems that starting from 4.21 all arch-s will use common bust_spinlocks() [1].
[..] > > Hmm, I don't think I've seen any reports because of this. From printk/console > > POV the locks which are not taken under oops_in_progress are not released. > > Fair enough. Let's keep debug_locks_off() in panic().
Agreed.
[1] lkml.kernel.org/r/20181025081108.GB26561@osiris
-ss
| |