[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170323120152.GH4008@pathway.suse.cz>
Date: Thu, 23 Mar 2017 13:01:52 +0100
From: Petr Mladek <pmladek@...e.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"Rafael J . Wysocki" <rjw@...ysocki.net>,
linux-kernel@...r.kernel.org,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Subject: Re: [RFC][PATCH 0/4] printk: introduce printing kernel thread
On Wed 2017-03-22 18:59:20, Peter Zijlstra wrote:
> On Mon, Mar 06, 2017 at 09:45:50PM +0900, Sergey Senozhatsky wrote:
> > sysrq is potentially even trickier. can we always wake_up() kernel
> > thread from sysrq? there probably might be cases when we can't rely
> > on the scheduler.
>
> sysrq runs from interrupt context, right? Should be able to do wakeups.
It would make sense to actually switch to the old mode when
handling sysrq. At least for some requests that are used
for debugging when the system is not responsible.
It is pity that it is the irq context that is prone to
softlocks. But this might be the only way to actually
see the messages.
Tetsuo already suggested to use the old mode for SysRq-t, see
https://lkml.kernel.org/r/201612261954.FJE69201.OFLVtFJSQFOHMO@I-love.SAKURA.ne.jp
Best Regards,
Petr
Powered by blists - more mailing lists