From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752019AbcJKHgf (ORCPT ); Tue, 11 Oct 2016 03:36:35 -0400 Received: from mail-pa0-f68.google.com ([209.85.220.68]:35941 "EHLO mail-pa0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751594AbcJKHgd (ORCPT ); Tue, 11 Oct 2016 03:36:33 -0400 Date: Tue, 11 Oct 2016 16:35:28 +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: <20161011073528.GA18875@swordfish> References: <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> <20161010111729.GJ23809@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161010111729.GJ23809@pathway.suse.cz> User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (10/10/16 13:17), Petr Mladek wrote: [..] > > 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. sorry, what do you mean by 'printk-context handling in lockdep'? wouldn't `lockdep + might_printk() + printk_safe' be enough? am I missing something? -ss