From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755715AbbJHKDd (ORCPT ); Thu, 8 Oct 2015 06:03:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56303 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751770AbbJHKDa (ORCPT ); Thu, 8 Oct 2015 06:03:30 -0400 From: Vitaly Kuznetsov To: Jan Kara Cc: Andrew Morton , HATAYAMA Daisuke , Masami Hiramatsu , Jiri Kosina , Baoquan He , Prarit Bhargava , Xie XiuQi , Seth Jennings , linux-kernel@vger.kernel.org, "K. Y. Srinivasan" Subject: Re: [PATCH] panic: release stale console lock to always get the logbuf printed out References: <1444237342-13282-1-git-send-email-vkuznets@redhat.com> <20151007153408.5c66b7468dee3b2dac16930b@linux-foundation.org> <20151008090153.GB13232@quack.suse.cz> Date: Thu, 08 Oct 2015 12:03:25 +0200 In-Reply-To: <20151008090153.GB13232@quack.suse.cz> (Jan Kara's message of "Thu, 8 Oct 2015 11:01:53 +0200") Message-ID: <87612hfziq.fsf@vitty.brq.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Jan Kara writes: >> --- a/kernel/panic.c~panic-release-stale-console-lock-to-always-get-the-logbuf-printed-out-fix >> +++ a/kernel/panic.c >> @@ -149,10 +149,10 @@ void panic(const char *fmt, ...) >> bust_spinlocks(0); >> >> /* >> - * We may have ended up killing the CPU holding the lock and still have >> - * some valuable data in console buffer. Try to acquire the lock and >> - * release it regardless of the result. The release will also print the >> - * buffers out. >> + * We may have ended up stopping the CPU holding the lock (in >> + * smp_send_stop()) while still having some valuable data in the console >> + * buffer. Try to acquire the lock then release it regardless of the >> + * result. The release will also print the buffers out. >> */ >> console_trylock(); >> console_unlock(); >> _ >> >> >> Does the console_trylock() guarantee that the console lock is now held? >> If the console_lock-holding CPU is still running then there's a window >> where the above code could enter console_unlock() when nobody's holding >> console_lock. If smp_send_stop() always works (synchronously) then >> that won't happen. > > We have this mechanism using zap_locks() in kernel/printk/printk.c when > crash happens on the CPU holding console_sem. Can't we use the same > mechanism for this case? Something like adding: > > zap_locks(); > console_lock(); > console_unlock(); > > to panic? I thought it doesn't really matter who holds the lock at this point -- all other cpus were already stopped with IPIs/NMIs. > If we picked up patch "kernel: Avoid softlockups in > stop_machine() during heavy printing" from my series (it's completely > independent, I've attached the latest version), the result would look less > hacky to me (attached). Thoughts? Haven't tested it but should also work... Thanks, -- Vitaly