From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752616AbcCUJ3i (ORCPT ); Mon, 21 Mar 2016 05:29:38 -0400 Received: from mail-pf0-f195.google.com ([209.85.192.195]:33186 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751842AbcCUJ3c (ORCPT ); Mon, 21 Mar 2016 05:29:32 -0400 Date: Mon, 21 Mar 2016 18:28:48 +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: <20160321092848.GB504@swordfish> References: <1458483191-3596-1-git-send-email-sergey.senozhatsky@gmail.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160321084743.GB2279@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/21/16 17:47), Byungchul Park wrote: [..] > > Is there any reason why you don't put the wake_up_process() out of the > > critical section with my suggestion, even though it can solve the infinite > > recuresion you worried about? > > Just to be sure, whether you take my suggestion or not is not important. > I just suggested it in this thread since it can solve what you worried > about. That's all. I can post it in another thread though. Why don't you > consider it so that yours don't miss any printk message? Do you think there > are any problems in my suggestion? we have 2 spin locks in vprintk_emit() -- logbuf_lock and sem->lock. and N CPUs can concurrently lockup on those two locks, which already makes a single static pointer in spiun_dump() questionable. logbug_lock *theoretically* can detect and handle recursive printk()s, there is no way to catch sem->lock spin_dump() at the moment (but that's not the point). there are 2 new spin locks in vprintk_emit() -- p->pi_lock and rq->lock. what I want is to put those locks inside the "we can detect recursion 100%" region. so these two locks will not add any new possibilities of recursive printks, they are covered by the existing recursion detection code thanks to logbuf lock and static logbuf_cpu. so we still can say that we have 5 places where printk recursion can happen -- lock + unlock logbuf_lock printk() recursion detection code can't help here -- inside of logbuf_lock critical section printk() recursion detection code works here -- lock + unlock sem->lock printk() recursion detection code can't help here note how "inside of logbuf_lock critical section" takes care of nested 'lock + unlock p->pi_lock' and 'lock + unlock rq->lock'. moreover, printk() will switch to synchronous mode in recursion handler and two misbehaving spin locks (4 places where recursion can happen) will not be executed anymore. what you want to have -- 4 independent spin locks and 9 places where recursion can happen, only 1 of which is covered by printk recursion code. -- lock + unlock logbuf_lock printk() recursion detection code can't help here -- inside of logbuf_lock critical section printk() recursion detection code works here -- lock + unlock p->pi_lock printk() recursion detection code can't help here -- lock + unlock rq->lock printk() recursion detection code can't help here -- lock + unlock sem->lock printk() recursion detection code can't help here and there is a static pointer to fix everything up? what if 2 CPUs will simultaneously printk-recurse in 2 different places? why this is better? -ss