From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757240AbcCVHm2 (ORCPT ); Tue, 22 Mar 2016 03:42:28 -0400 Received: from mail-pf0-f194.google.com ([209.85.192.194]:35092 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753978AbcCVHmU (ORCPT ); Tue, 22 Mar 2016 03:42:20 -0400 Date: Tue, 22 Mar 2016 16:43:42 +0900 From: Sergey Senozhatsky To: Byungchul Park Cc: Sergey Senozhatsky , Sergey Senozhatsky , Andrew Morton , Jan Kara , Petr Mladek , Tejun Heo , Tetsuo Handa , linux-kernel@vger.kernel.org, Jan Kara Subject: Re: [RFC][PATCH v5 1/2] printk: Make printk() completely async Message-ID: <20160322074342.GB1759@swordfish> References: <20160321000647.GP5220@X58A-UD3R> <20160321004347.GA563@swordfish> <20160321005608.GQ5220@X58A-UD3R> <20160321073507.GA501@swordfish> <20160321080751.GA2279@X58A-UD3R> <20160321084743.GB2279@X58A-UD3R> <20160321092848.GB504@swordfish> <20160322021343.GC2279@X58A-UD3R> <20160322055243.GA1759@swordfish> <20160322065729.GE2279@X58A-UD3R> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160322065729.GE2279@X58A-UD3R> 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 (03/22/16 15:57), Byungchul Park wrote: > On Tue, Mar 22, 2016 at 02:52:43PM +0900, Sergey Senozhatsky wrote: > > On (03/22/16 11:13), Byungchul Park wrote: > > [..] > > > > what about a "normal" case, when things are not going to explode printk(), > > but we have several lockups on the same lock (which is probably more > > likely than printk recursion)? > > > > suppose: > > - there are 8 CPUs on the system > > - 1 cpus owns the spin_lock for too long > > - 4 cpus are trying to lock the spin_lock w/o any success > > - so all 4 trigger spin_dump. > > > > what we have at the moment, is that all 4 CPUs will report a lockup, > > but with this static pointer only X (between 1 and 4, depending on the > > timing; on how fast spin_dump() will return (logbuf lock can > > be busy for a while); etc.) CPUs will do so. > > Yes, I agree with you. If it's important to warn "lockup suspected" not > only per each lock, but also per each pair (cpu, lock), it should be > modified so that it can distinguish between cpus. well, just my opinion, I'd really prefer to have lockup reports from all of the CPUs that have actually locked up, not on a per-lock basis. this gives better understanding what was going on. trigger_all_cpu_backtrace() is not guaranteed to be NMI-based, so if CPUA has detected a lockup it better report straight ahead. > Anyway I think it's meaningful to make printing "lockup suspected" per a > meaningful unit, e.g. (cpu, lock), once. > > If you agree with it, I will post it in your thread after fixing it. Or I > will do it in another thread. The reason why I ask you is because it can > solve a infinite recursion caused by newly introduced locks in yours. a separate thread I think; this patch set is around different things and does not touch spinlock_debug code, recursive printk is a problem even w/o this patch set. -ss