From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932762AbcA1HP3 (ORCPT ); Thu, 28 Jan 2016 02:15:29 -0500 Received: from LGEAMRELO11.lge.com ([156.147.23.51]:40047 "EHLO lgeamrelo11.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751138AbcA1HP1 (ORCPT ); Thu, 28 Jan 2016 02:15:27 -0500 X-Original-SENDERIP: 156.147.1.121 X-Original-MAILFROM: byungchul.park@lge.com X-Original-SENDERIP: 10.177.222.33 X-Original-MAILFROM: byungchul.park@lge.com Date: Thu, 28 Jan 2016 16:15:02 +0900 From: Byungchul Park To: Peter Hurley Cc: akpm@linux-foundation.org, mingo@kernel.org, linux-kernel@vger.kernel.org, akinobu.mita@gmail.com, jack@suse.cz, torvalds@linux-foundation.org Subject: Re: [PATCH v4] lib/spinlock_debug.c: prevent a recursive cycle in the debug code Message-ID: <20160128071502.GA31266@X58A-UD3R> References: <1453896061-14102-1-git-send-email-byungchul.park@lge.com> <56A9497F.6010206@hurleysoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56A9497F.6010206@hurleysoftware.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 27, 2016 at 02:49:35PM -0800, Peter Hurley wrote: > And we already have lockdep turned off to avoid triggering a recursive > lockdep report (which I think is a mistake). Yes, we already have a way to turn off the lock debug so that we can avoid it. So I used it in v4. thanks, byungchul > > I think we should be working toward properly handling recursion > in printk(). > > Regards, > Peter Hurley > > > > When the debug spinlock code is called from printk(), we should prevent > > calling spin_dump() and the like, calling printk() again in that context. > > > > Signed-off-by: Byungchul Park > > --- > > include/linux/debug_locks.h | 4 ++++ > > kernel/locking/spinlock_debug.c | 14 +++++++++++--- > > 2 files changed, 15 insertions(+), 3 deletions(-) > > > > diff --git a/include/linux/debug_locks.h b/include/linux/debug_locks.h > > index 822c135..b0f977e 100644 > > --- a/include/linux/debug_locks.h > > +++ b/include/linux/debug_locks.h > > @@ -10,6 +10,10 @@ struct task_struct; > > extern int debug_locks; > > extern int debug_locks_silent; > > > > +static inline void __debug_locks_on(void) > > +{ > > + debug_locks = 1; > > +} > > > > static inline int __debug_locks_off(void) > > { > > diff --git a/kernel/locking/spinlock_debug.c b/kernel/locking/spinlock_debug.c > > index 0374a59..65177ba 100644 > > --- a/kernel/locking/spinlock_debug.c > > +++ b/kernel/locking/spinlock_debug.c > > @@ -113,11 +113,19 @@ static void __spin_lock_debug(raw_spinlock_t *lock) > > return; > > __delay(1); > > } > > - /* lockup suspected: */ > > - spin_dump(lock, "lockup suspected"); > > + > > + /* > > + * We should prevent calling printk() further, since it would cause > > + * an infinite recursive cycle if it's called from printk()! > > + */ > > + if (__debug_locks_off()) { > > + /* lockup suspected: */ > > + spin_dump(lock, "lockup suspected"); > > #ifdef CONFIG_SMP > > - trigger_all_cpu_backtrace(); > > + trigger_all_cpu_backtrace(); > > #endif > > + __debug_locks_on(); > > + } > > > > /* > > * The trylock above was causing a livelock. Give the lower level arch > >