Re: [RFC PATCH 3/5] printk/nmi: Try hard to print Oops message in NMI context

[Petr Mladek]

On Tue 2015-07-14 10:20:11, Peter Zijlstra wrote:
> On Mon, Jul 13, 2015 at 04:14:19PM -0700, Andrew Morton wrote:
> > On Thu, 9 Jul 2015 18:21:54 +0200 Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> > 
> > > On Thu, Jul 09, 2015 at 03:36:20PM +0200, Petr Mladek wrote:
> > > > +	/*
> > > > +	 * Messages are passed from NMI context using an extra buffer.
> > > > +	 * The only exception is when Oops is in progress. In this case
> > > > +	 * we try hard to get them out directly.
> > > > +	 */
> > > > +	if (unlikely(oops_in_progress && in_nmi()))
> > > > +		zap_locks();
> > > 
> > > zap_locks() is broken and horrible and is another thing we should take
> > > out back.
> > > 
> > > Imagine a ticket lock that's held, you zap it, it gets released and now
> > > its tail is ahead of its head and you're forever stuck.
> > > 
> > > I've actually had that happen several times.
> > 
> > Is that really a problem?  The thinking is that the system is already
> > hosed.  The role of zap_locks is to increase the chances of getting the
> > why-it-died messages emitted.  After that, nothing matters?
> 
> I've had zap_locks eat my msgs.. doesn't happen often, but it did happen
> a few times and got me upset.

Hmm, zapping locks might cause problems if the old owner of the lock
is still active. But the alternative solution where Peter suggested to
write messages directly on safe consoles might open another can of
problems either.

If the main concern with zap_locks() is the potential deadlock with
ticket locks. I wonder if the following patch might make it more
acceptable. I hope that my thinking is correct.