From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751421AbcA1XzQ (ORCPT ); Thu, 28 Jan 2016 18:55:16 -0500 Received: from LGEAMRELO12.lge.com ([156.147.23.52]:46766 "EHLO lgeamrelo12.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750832AbcA1XzM (ORCPT ); Thu, 28 Jan 2016 18:55:12 -0500 X-Original-SENDERIP: 156.147.1.151 X-Original-MAILFROM: byungchul.park@lge.com X-Original-SENDERIP: 10.177.222.33 X-Original-MAILFROM: byungchul.park@lge.com Date: Fri, 29 Jan 2016 08:54:48 +0900 From: Byungchul Park To: Peter Hurley Cc: Sergey Senozhatsky , akpm@linux-foundation.org, mingo@kernel.org, linux-kernel@vger.kernel.org, akinobu.mita@gmail.com, jack@suse.cz, torvalds@linux-foundation.org, Sergey Senozhatsky Subject: Re: [PATCH v4] lib/spinlock_debug.c: prevent a recursive cycle in the debug code Message-ID: <20160128235448.GC31266@X58A-UD3R> References: <1453896061-14102-1-git-send-email-byungchul.park@lge.com> <20160128014253.GC1538@X58A-UD3R> <20160128023750.GB1834@swordfish> <000301d15985$7f416690$7dc433b0$@lge.com> <20160128060530.GC1834@swordfish> <20160128081313.GB31266@X58A-UD3R> <20160128104137.GA610@swordfish> <20160128105342.GB610@swordfish> <20160128154257.GA564@swordfish> <56AA9F63.9070600@hurleysoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56AA9F63.9070600@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 Thu, Jan 28, 2016 at 03:08:19PM -0800, Peter Hurley wrote: > The problem is you have postulated a very shallow recursion. > This looks much worse if this happens 1000 times, and > probably won't recover to output anything. > > Additionally, what if the console_sem is simply corrupted? > A livelock with no output ever is not very helpful. > > As I wrote earlier, I don't think this is the way to fix > recursion problems with printk() [by eliding output]. I think you are currently misunderstading about this patch. Or I'm misunderstanding you.. The patch was changed in v4 so that it can print a debug message even in the recursive cycle case, at the first time. I also thought printing nothing in the case was not helpful at all which I did in v1,2,3. But it's changed in v4, that is, this patch. thanks, byungchul > > Rather, a way to effectively determine a recursion is in progress, > and _at a minimum_ guaranteeing that the recursive output will > eventually be output should be the goal. > > Including dumb recursion like a console driver printing > an error :/ > > Then, lockdep could remain enabled while calling console drivers. > > Regards, > Peter Hurley > > > sem->count-- > > spin_unlock() << unlock, return > > arch_spin_lock() << got the lock, return > > sem->count-- > > spin_unlock() << unlock, return > > arch_spin_lock() << got the lock, return > > sem->count-- > > spin_unlock() << unlock, return > > > > > > ...um > > > > > >> But I found there's a possiblity in the debug code *itself* to cause a > >> lockup. > > > > please explain. > > > > -ss > >