From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754928AbcA0Wtk (ORCPT ); Wed, 27 Jan 2016 17:49:40 -0500 Received: from mail-pf0-f171.google.com ([209.85.192.171]:36024 "EHLO mail-pf0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754824AbcA0Wti (ORCPT ); Wed, 27 Jan 2016 17:49:38 -0500 Subject: Re: [PATCH v4] lib/spinlock_debug.c: prevent a recursive cycle in the debug code To: Byungchul Park , akpm@linux-foundation.org References: <1453896061-14102-1-git-send-email-byungchul.park@lge.com> Cc: mingo@kernel.org, linux-kernel@vger.kernel.org, akinobu.mita@gmail.com, jack@suse.cz, torvalds@linux-foundation.org From: Peter Hurley Message-ID: <56A9497F.6010206@hurleysoftware.com> Date: Wed, 27 Jan 2016 14:49:35 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <1453896061-14102-1-git-send-email-byungchul.park@lge.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/27/2016 04:01 AM, Byungchul Park wrote: > changes form v3 to v4 > - reuse a existing code as much as possible for preventing an infinite > recursive cycle. > > changes from v2 to v3 > - avoid printk() only in case of lockup suspected, not real lockup in > which case it does not help at all. > - consider not only console_sem.lock but also logbuf_lock which is used > by printk(). > > changes from v1 to v2 > - only change comment and commit message esp. replacing "deadlock" with > "infinite recursive cycle", since it is not an actual deadlock. > > thanks, > byungchul > > -----8<----- > From 7b0c6e48625632fa1732b619083dc550b5d924c6 Mon Sep 17 00:00:00 2001 > From: Byungchul Park > Date: Wed, 27 Jan 2016 18:11:55 +0900 > Subject: [PATCH v4] lib/spinlock_debug.c: prevent a recursive cycle in the > debug code > > It causes an infinite recursive cycle when using CONFIG_DEBUG_SPINLOCK, > in the spin_dump(). Backtrace prints printk() -> console_trylock() -> > do_raw_spin_lock() -> spin_dump() -> printk()... infinitely. printk() is potentially recursive in many situations. What about spinlocks used by console drivers? And we already have lockdep turned off to avoid triggering a recursive lockdep report (which I think is a mistake). 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 >