Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751866AbbBXH1Z (ORCPT ); Tue, 24 Feb 2015 02:27:25 -0500 Received: from mail-we0-f171.google.com ([74.125.82.171]:46249 "EHLO mail-we0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750776AbbBXH1Y (ORCPT ); Tue, 24 Feb 2015 02:27:24 -0500 Date: Tue, 24 Feb 2015 08:27:19 +0100 From: Ingo Molnar To: Anton Blanchard Cc: Andrew Morton , Steven Rostedt , Michael Ellerman , Paul Mackerras , Benjamin Herrenschmidt , sam.bobroff@au1.ibm.com, Thomas Gleixner , Ingo Molnar , hpa@zytor.com, Russell King , peterz@infradead.org, Don Zickus , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org, Linus Torvalds , Arjan van de Ven , Peter Zijlstra Subject: Re: [PATCH 1/7] Add die_spin_lock_{irqsave,irqrestore} Message-ID: <20150224072719.GB15894@gmail.com> References: <1424748634-9153-1-git-send-email-anton@samba.org> <1424748634-9153-2-git-send-email-anton@samba.org> <20150224064107.GB15387@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150224064107.GB15387@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1552 Lines: 51 * Ingo Molnar wrote: > > * Anton Blanchard wrote: > > > +static arch_spinlock_t die_lock = __ARCH_SPIN_LOCK_UNLOCKED; > > +static int die_owner = -1; > > +static unsigned int die_nest_count; > > + > > +unsigned long __die_spin_lock_irqsave(void) > > +{ > > + unsigned long flags; > > + int cpu; > > + > > + /* racy, but better than risking deadlock. */ > > + raw_local_irq_save(flags); > > + > > + cpu = smp_processor_id(); > > + if (!arch_spin_trylock(&die_lock)) { > > + if (cpu != die_owner) > > + arch_spin_lock(&die_lock); > > So why not trylock and time out here after a few seconds, > instead of indefinitely supressing some potentially vital > output due to some other CPU crashing/locking with the lock > held? [...] > If we fix the deadlock potential, and get a true global > ordering of various oopses/warnings as they triggered (or > at least timestamping them), [...] If we had a global 'trouble counter' we could use that to refine the spin-looping timeout: instead of using a pure timeout of a few seconds, we could say 'a timeout of a few seconds while the counter does not increase'. I.e. only override the locking/ordering if the owner CPU does not seem to be able to make progress with printing the oops/warning. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/