From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751982AbcJJLRz (ORCPT ); Mon, 10 Oct 2016 07:17:55 -0400 Received: from mx2.suse.de ([195.135.220.15]:33973 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751061AbcJJLRv (ORCPT ); Mon, 10 Oct 2016 07:17:51 -0400 Date: Mon, 10 Oct 2016 13:17:29 +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: <20161010111729.GJ23809@pathway.suse.cz> References: <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> <20161005095013.GB23809@pathway.suse.cz> <20161006042248.GA5458@swordfish> <20161006113233.GF23809@pathway.suse.cz> <20161010040957.GC3496@swordfish> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161010040957.GC3496@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 Mon 2016-10-10 13:09:57, Sergey Senozhatsky wrote: > On (10/06/16 13:32), Petr Mladek wrote: > > On Thu 2016-10-06 13:22:48, Sergey Senozhatsky wrote: > > > On (10/05/16 11:50), Petr Mladek wrote: > > > [..] > > > > > 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. > > > > > > 1) some pathces/reports from Byungchul Park > > > 2) a report from Viresh Kumar. > > > 4) sleeping function called from inside logbuf lock > > > 5) ARM specific > > > 6) logbuf_lock corruption > > > > It is great that you have such a list in hands. It might help > > to push this solution. > > > > I actually have one more reason for this approach: > > > > It seems that we will need to keep printk_deferred()/WARN_*DEFERRED(). > > We do not know about a better solution for the deadlocks caused > > by scheduler/timekeeping/console_drivers locks. > > yes, seems so. > > > The pain is that the list of affected locations is hard to maintain. > > It would definitely help if such problems are reported by lockdep > > in advance. But lockdep is disabled because it creates the deadlock > > on its own. > > right. another issue is that those potentially recursive printk/WARN_ON > calls may be coming from error-handling branches, not all of which are > easily reachable for automated solutions. so in order to find out there > is a problem we must hit it [in some cases]. yes > it may look that lockdep *probably* can report the issues via 'safe' printk, > but that's a notably huge behavior breakage -- if lockdep report comes from > an about-to-deadlock irq handler, then we won't see anything from that CPU > unless there is a panic/nmi panic. > > so it probably has to be semi-automatic/semi-manual: > - add might_printk() that would acquire/release console sem; or > logbuf_lock (which is probably even better) > - find all functions that do printk/WARN in kernel/time and kernel/sched > - add might_printk() to those functions (just like might_sleep()) > - run the kernel > - ... > - profit I like the idea with might_printk(). I hope that it will be acceptable for the scheduler/timekeeping people. JFYI, I could work on the printk-context handling in lockdep. I am just working on a lockdep support in NMI and am getting kind of familiar with that code. Best Regards, Petr