From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936478AbcLOOev (ORCPT ); Thu, 15 Dec 2016 09:34:51 -0500 Received: from mx2.suse.de ([195.135.220.15]:47821 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752673AbcLOOes (ORCPT ); Thu, 15 Dec 2016 09:34:48 -0500 Date: Thu, 15 Dec 2016 15:34:43 +0100 From: Petr Mladek To: Steven Rostedt Cc: Andrew Morton , Linus Torvalds , Peter Zijlstra , Sergey Senozhatsky , linux-kernel@vger.kernel.org Subject: Re: [PATCH] MAINTAINERS: Add printk maintainers Message-ID: <20161215143443.GA1053@pathway.suse.cz> References: <1481798878-31898-1-git-send-email-pmladek@suse.com> <20161215084815.4d479755@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161215084815.4d479755@gandalf.local.home> 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 Thu 2016-12-15 08:48:15, Steven Rostedt wrote: > On Thu, 15 Dec 2016 11:47:58 +0100 > Petr Mladek wrote: > > > I and Sergey would like to volunteer as printk code maintainers. > > It is a code that everyone is using, various people fix bugs or > > even add features but there is nobody really interested into > > maintaining it. > > > > I and Sergey have put a lot of effort into understanding the code > > and related problems. We are working on solutions for some long > > term problems. There is a nice summary from the Kernel Summit > > presentation, see https://lwn.net/Articles/705938/ > > > > We have already started to use the gained knowledge and comment > > on other printk-related patches. The official role should help > > us to do it more effectively. > > > > Our priorities are: > > > > + prevent deadlocks (printk_safe patchset, console locks) > > + prevent softlocks (async printk, console_sem and flushing) > > + handle other bugs/fixes/features as they come > > > > with this in mind: > > > > + printk is used in different context > > + need special care in some modes, e.g. oops, panic, suspend > > + do best effort to store/show messages > > Output immediately when they happen too. Perhaps we need a way to > differentiate, "Show now" messages vs "This is info only, delay if > needed". We have to find the right balance. For example, we do not show messages immediately in NMI context because there is a risk of a deadlock. We have to somehow limit it in IRQ context to avoid a softlock. In fact, we must avoid "infinite" output even in normal context to avoid a livelock. It must be decently configurable because a more risky handling might help to debug some corner-case bugs. The async printk patchset is important here. It will allow to do output in a safe context using a dedicated kthread. I am sure that it will need some tuning. We could discuss it more once Sergey sends new version, ... > > + the code is already pretty complicated and twisted; > > support clean ups; always think hard if a feature/fix > > is worth any complication > > > > Of course, it still will be much appreciated if other people review > > printk patches. > > I don't have a problem with you maintaining this, but put me down as a > reviewer: > > R: Steven Rostedt Definitely. This is great news! > > > > Regarding the workflow. It will be highly appreciated if the patches > > might still go via Andrew's -mm tree at least for 4.10. In the long > > term, we would like to make Andrew's life easier and handle printk > > patches in an own git tree. But we first need to set it up and get > > familiar with the processes. > > Maybe Andrew should be a reviewer too. But I'll let him speak for > himself. It would be much appreciated as well. > But anyway... > > Acked-by: Steven Rostedt Thanks a lot for your input. Best Regards, Petr