From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754799AbcJEJuR (ORCPT ); Wed, 5 Oct 2016 05:50:17 -0400 Received: from mx2.suse.de ([195.135.220.15]:50350 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752258AbcJEJuQ (ORCPT ); Wed, 5 Oct 2016 05:50:16 -0400 Date: Wed, 5 Oct 2016 11:50:13 +0200 From: Petr Mladek To: Sergey Senozhatsky Cc: Sergey Senozhatsky , Jan Kara , Andrew Morton , Tejun Heo , Calvin Owens , linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCH 6/7] printk: use alternative printk buffers Message-ID: <20161005095013.GB23809@pathway.suse.cz> References: <20160927142237.5539-1-sergey.senozhatsky@gmail.com> <20160927142237.5539-7-sergey.senozhatsky@gmail.com> <20160929130000.GE26796@pathway.suse.cz> <20160930011544.GC547@swordfish> <20160930111546.GI26796@pathway.suse.cz> <20161004145221.GF13369@pathway.suse.cz> <20161005012714.GA9539@swordfish> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161005012714.GA9539@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 Wed 2016-10-05 10:27:14, Sergey Senozhatsky wrote: > On (10/04/16 16:52), Petr Mladek wrote: > > > > > > Or is there any other catch that I do not see at the moment? > > > > And there is :-( The above logic looked at the problem only from > > one side. It was about errors starting from the printk() > > code itself, for example: > > yes, like I said - printk recursion and printk deadlock are different > things. and recursion cases are a subset of deadlock cases. I see. > > The only thing that might help here is to call > > alt_printk_enter()/exit() in wake_up_process() itself. Otherwise, > > we still would need to keep the printk_deferred() stuff. > > yes. > or > - combine alt_printk and DEFERRED_WARN/etc. The question is if alt_printk brings any win after all, see below. > or > - rewrite printk() to be lock-less by default (for all invocations). We already have it and it is called trace_printk(). But it is very tricky and have some limitations. For example, it does not support random parallel readers. Also printing the trace log is noticeably slow. > > By other words, we might need to put alt_printk_enter()/exit() > > into the scheduler and timekeeping code. In theory it might > > be easier to maintain than the separated printk_deferred() calls. > > But there might be some catches because we need to disable > > the interrupts, ... > > right. and I have some doubts that people will be willing to put > alt_printk_enter/exit into those hot paths. I have the same doubts. > > Sigh, this 2nd scenario is much more likely than the 1st one. > > I guess that warnings in the scheduler/timekeeping code > > will be triggered outside printk() most of the time. > > hm. may be. but the reports we received so far starts from printk() > and end up in printk() - IOW, recursion. My statement might have been too strong. Well, my thinking was the following: I am not aware of any real life bug reports caused by recursion inside locbuf_lock garded section. I guess that it is because the most sensitive one is guarded by that logbuf_cpu check. I am not aware of any generic recursions inside the console code. In fact, it is not easily possible because we console_trylock(). It means that we do not call console if it is already being handled. We are basically down to the recursion/deadlock caused by the wake_up_process() call. And there are much more such calls outside printk(). In fact, I am aware only about one report. It was related to the async printk patchset, the added wake_up_process(), and used RT scheduler. This one started from printk() almost by definition. > > It means that this approach might be much harder to sell > > after all :-( > > well, it solves a number of problems that the existing implementation > cannot handle. Please, provide a summary. I wonder if these are real life problems. Note that we need to put aside all problems that are solvable with printk_deferred(). It seems that printk_deferred() will need to stay because it avoids the deadlock caused by scheduler/timekeeping code locks. By other words, if there is a missing printk_deferred() we need to put it there anyway because the same code might get first called outside printk(). Or do I miss something? Best Regards, Petr