From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754325AbcCVG5k (ORCPT ); Tue, 22 Mar 2016 02:57:40 -0400 Received: from LGEAMRELO12.lge.com ([156.147.23.52]:49797 "EHLO lgeamrelo12.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751264AbcCVG5e (ORCPT ); Tue, 22 Mar 2016 02:57:34 -0400 X-Original-SENDERIP: 156.147.1.127 X-Original-MAILFROM: byungchul.park@lge.com X-Original-SENDERIP: 10.177.222.33 X-Original-MAILFROM: byungchul.park@lge.com Date: Tue, 22 Mar 2016 15:57:29 +0900 From: Byungchul Park To: Sergey Senozhatsky Cc: 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: <20160322065729.GE2279@X58A-UD3R> References: <1458483191-3596-2-git-send-email-sergey.senozhatsky@gmail.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160322055243.GA1759@swordfish> 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 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. 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. Thank you for informing it, Byungchul > > -ss