linux-kernel - Re: [PATCH] panic: release stale console lock to always get the logbuf printed out

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20151008135433.bab13c6f80abdf7c6661df66@linux-foundation.org>
Date:	Thu, 8 Oct 2015 13:54:33 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Vitaly Kuznetsov <vkuznets@...hat.com>
Cc:	HATAYAMA Daisuke <d.hatayama@...fujitsu.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Jiri Kosina <jkosina@...e.cz>, Baoquan He <bhe@...hat.com>,
	Prarit Bhargava <prarit@...hat.com>,
	Xie XiuQi <xiexiuqi@...wei.com>,
	Seth Jennings <sjenning@...hat.com>,
	linux-kernel@...r.kernel.org,
	"K. Y. Srinivasan" <kys@...rosoft.com>, Jan Kara <jack@...e.cz>
Subject: Re: [PATCH] panic: release stale console lock to always get the
 logbuf printed out

On Thu, 08 Oct 2015 11:51:13 +0200 Vitaly Kuznetsov <vkuznets@...hat.com> wrote:

> > On Wed,  7 Oct 2015 19:02:22 +0200 Vitaly Kuznetsov <vkuznets@...hat.com> wrote:
> >
> >> In some cases we may end up killing the CPU holding the console lock
> >> while still having valuable data in logbuf. E.g. I'm observing the
> >> following:
> >> - A crash is happening on one CPU and console_unlock() is being called on
> >>   some other.
> >> - console_unlock() tries to print out the buffer before releasing the lock
> >>   and on slow console it takes time.
> >> - in the meanwhile crashing CPU does lots of printk()-s with valuable data
> >>   (which go to the logbuf) and sends IPIs to all other CPUs.
> >> - console_unlock() finishes printing previous chunk and enables interrupts
> >>   before trying to print out the rest, the CPU catches the IPI and never
> >>   releases console lock.
> >
> > Why doesn't the lock-owning CPU release the console lock?  Because it
> > was stopped by smp_send_stop() in panic()?
> >
> > I don't recall why we stop CPUs in panic(), and of course we didn't
> > document the reason.  I guess it makes sense from the "what else can we
> > do" point of view, but I wonder if we can just do it later on - that
> > would fix this problem?
> 
> We don't know for how long should we wait for the other CPU to finish
> the output and it can take some time. In case we're rebooting after a
> short timeout we can still end up with something in the logbuf.

I don't understand what you're saying here.

If we move panic()'s call to smp_send_stop() so it occurs later in
panic(), won't this result in this CPU's messages being properly
displayed?  The currently-printing CPU will still be running and all
the printks will proceed in the normal fashion?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/