From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754399AbcJEB1T (ORCPT ); Tue, 4 Oct 2016 21:27:19 -0400 Received: from mail-pf0-f194.google.com ([209.85.192.194]:32809 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752985AbcJEB1S (ORCPT ); Tue, 4 Oct 2016 21:27:18 -0400 Date: Wed, 5 Oct 2016 10:27:14 +0900 From: Sergey Senozhatsky To: Petr Mladek Cc: Sergey Senozhatsky , 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: <20161005012714.GA9539@swordfish> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161004145221.GF13369@pathway.suse.cz> User-Agent: Mutt/1.7.0 (2016-08-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > 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. or - rewrite printk() to be lock-less by default (for all invocations). > 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. > 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. > 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. would have been nice to cover all of the cases, but that's a bit hard. -ss