From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752111AbcA2GPl (ORCPT ); Fri, 29 Jan 2016 01:15:41 -0500 Received: from mail-pf0-f194.google.com ([209.85.192.194]:35017 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751352AbcA2GPk (ORCPT ); Fri, 29 Jan 2016 01:15:40 -0500 Date: Fri, 29 Jan 2016 15:16:53 +0900 From: Sergey Senozhatsky To: Peter Hurley Cc: Sergey Senozhatsky , Sergey Senozhatsky , Byungchul Park , 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: <20160129061653.GE4820@swordfish> References: <20160128060530.GC1834@swordfish> <20160128081313.GB31266@X58A-UD3R> <20160128104137.GA610@swordfish> <20160128105342.GB610@swordfish> <20160128154257.GA564@swordfish> <56AA9F63.9070600@hurleysoftware.com> <20160129002703.GA4820@swordfish> <56AAEB50.8050801@hurleysoftware.com> <20160129052838.GD4820@swordfish> <56AAFD41.5020005@hurleysoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56AAFD41.5020005@hurleysoftware.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/28/16 21:48), Peter Hurley wrote: [..] > > yes, I proposed to add a ->reset callback to struct console > > a while ago, and to do a console reset loop in zap_locks() > > What was the patch series title? I'd like to review that. Thanks. it was deep in the thread where Jan Kara proposed v1 of his printk offloading support "Re: [PATCH 1/7] printk: Hand over printing to console if printing too long" http://marc.info/?l=linux-kernel&m=144976121529901 I never ended up sending this out as a separate patch. my bad. the panic()->zap_locks() was here (well, not even a patch set): http://marc.info/?l=linux-kernel&m=145260677129044 > That would solve the recursive deadlock from console driver as well > (at least with CONFIG_DEBUG_SPINLOCK) because the printk() recursion > would zap the locks including the console driver's lock and > at least get the last output so that we'd know there was a recursion, > and fix it. yes, if printk() has a chance to detect a recursion and invoke zap_locks() (which is based on logbuf_cpu check). in my other email there is a scenario when printk() has no such a chance -- because 'logbuf_cpu' is set to UINT_MAX right before raw_spin_unlock(&logbuf_lock). and if debug_spin_unlock() detects a coding error (not even a corruption) (->owner != current, or ->owner_cpu != raw_smp_processor_id()) then things are turning bad quickly. mail: http://marc.info/?l=linux-kernel&m=145404023915268 -ss