From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756343AbcCUObt (ORCPT ); Mon, 21 Mar 2016 10:31:49 -0400 Received: from mx2.suse.de ([195.135.220.15]:58390 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755941AbcCUObr (ORCPT ); Mon, 21 Mar 2016 10:31:47 -0400 Date: Mon, 21 Mar 2016 15:32:12 +0100 From: Jan Kara To: Sergey Senozhatsky Cc: Byungchul Park , 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: <20160321143212.GK30819@quack.suse.cz> 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> <20160321092848.GB504@swordfish> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160321092848.GB504@swordfish> 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 Mon 21-03-16 18:28:48, Sergey Senozhatsky wrote: > 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. Actually, this is not true. These locks are already in vprintk_emit() via the up(&console_sem) call from console_unlock() since up() can call wake_up() which needs the same locks as wake_up_process(). And by calling wake_up_process() under logbuf_lock, you actually introduce recursion issues for printk_deferred() messages which are supposed to be working from under rq->lock and similar. So I think you have to keep this section outside of logbuf_lock. Honza -- Jan Kara SUSE Labs, CR