From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933682AbcBACaB (ORCPT ); Sun, 31 Jan 2016 21:30:01 -0500 Received: from mail-pa0-f68.google.com ([209.85.220.68]:35598 "EHLO mail-pa0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933594AbcBACaA (ORCPT ); Sun, 31 Jan 2016 21:30:00 -0500 Date: Mon, 1 Feb 2016 11:31:12 +0900 From: Sergey Senozhatsky To: Byungchul Park Cc: akpm@linux-foundation.org, mingo@kernel.org, linux-kernel@vger.kernel.org, akinobu.mita@gmail.com, jack@suse.cz, sergey.senozhatsky.work@gmail.com, peter@hurleysoftware.com, torvalds@linux-foundation.org Subject: Re: [PATCH v5] lib/spinlock_debug.c: prevent a recursive cycle in the debug code Message-ID: <20160201023112.GC1033@swordfish> References: <1454071417-20685-1-git-send-email-byungchul.park@lge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1454071417-20685-1-git-send-email-byungchul.park@lge.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (01/29/16 21:43), Byungchul Park wrote: [..] > +extern int is_console_lock(raw_spinlock_t *lock); > + > static void __spin_lock_debug(raw_spinlock_t *lock) > { > u64 i; > @@ -113,11 +115,19 @@ static void __spin_lock_debug(raw_spinlock_t *lock) > return; > __delay(1); > } > - /* lockup suspected: */ > - spin_dump(lock, "lockup suspected"); > + > + /* > + * If this function is called from printk(), then we should > + * not call printk() more. Or it will cause an infinite > + * recursive cycle! > + */ > + if (likely(!is_console_lock(lock))) { > + /* lockup suspected: */ > + spin_dump(lock, "lockup suspected"); > #ifdef CONFIG_SMP > - trigger_all_cpu_backtrace(); > + trigger_all_cpu_backtrace(); > #endif > + } /* speaking in a context of printk locks only */ ... may be for a recoverable "lockup suspected" spin_dump() we can switch to deferred printk of the messages, which is a bit better than nothing. but for unrecoverable "lockup suspected" spin_dump() -- an actual bug (spin lock owner is not going to release the lock any more) -- we need something else, I think. the bug will neither be reported nor fixed. -ss > /* > * The trylock above was causing a livelock. Give the lower level arch > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c > index 2ce8826..568ab11 100644 > --- a/kernel/printk/printk.c > +++ b/kernel/printk/printk.c > @@ -1981,6 +1981,11 @@ asmlinkage __visible void early_printk(const char *fmt, ...) > } > #endif > > +int is_console_lock(raw_spinlock_t *lock) > +{ > + return lock == &console_sem.lock; > +} > + > static int __add_preferred_console(char *name, int idx, char *options, > char *brl_options) > { > -- > 1.9.1 >