From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754830AbeAOIvU (ORCPT + 1 other); Mon, 15 Jan 2018 03:51:20 -0500 Received: from mx2.suse.de ([195.135.220.15]:40463 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753842AbeAOIvT (ORCPT ); Mon, 15 Jan 2018 03:51:19 -0500 Date: Mon, 15 Jan 2018 09:51:15 +0100 From: Petr Mladek To: Sergey Senozhatsky Cc: Steven Rostedt , Sergey Senozhatsky , Tejun Heo , akpm@linux-foundation.org, linux-mm@kvack.org, Cong Wang , Dave Hansen , Johannes Weiner , Mel Gorman , Michal Hocko , Vlastimil Babka , Peter Zijlstra , Linus Torvalds , Jan Kara , Mathieu Desnoyers , Tetsuo Handa , rostedt@home.goodmis.org, Byungchul Park , Pavel Machek , linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup Message-ID: <20180115085115.h73vimlyuuj56be7@pathway.suse.cz> References: <20180111045817.GA494@jagdpanzerIV> <20180111093435.GA24497@linux.suse> <20180111103845.GB477@jagdpanzerIV> <20180111112908.50de440a@vmware.local.home> <20180112025612.GB6419@jagdpanzerIV> <20180111222140.7fd89d52@gandalf.local.home> <20180112100544.GA441@jagdpanzerIV> <20180112072123.33bb567d@gandalf.local.home> <20180112125536.GC24497@linux.suse> <20180113073100.GB1701@tigerII.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180113073100.GB1701@tigerII.localdomain> User-Agent: NeoMutt/20170421 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Sat 2018-01-13 16:31:00, Sergey Senozhatsky wrote: > On (01/12/18 13:55), Petr Mladek wrote: > [..] > > > I'm not fixing console_unlock(), I'm fixing printk(). BTW, all my > > > kernels are CONFIG_PREEMPT (I'm a RT guy), my mind thinks more about > > > PREEMPT kernels than !PREEMPT ones. > > > > I would say that the patch improves also console_unlock() but only in > > non-preemttive context. > > > > By other words, it makes console_unlock() finite in preemptible context > > (limited by buffer size). It might still be unlimited in > > non-preemtible context. > > could you elaborate a bit? Ah, I am sorry, I swapped the conditions. I meant that console_unlock() is finite in non-preemptible context. There are two possibilities if console_unlock() is in atomic context and never sleeps. First, if there are new printk() callers, they could take over the job. Second. if they are no more callers, the current owner will release the lock after processing the existing messages. In both situations, the current owner will not handle more than the entire buffer. Therefore it is limited. We might argue if it is enough. But the point is that it is limited which is a step forward. And I think that you already agreed that this was a step forward. The chance of taking over the lock is lower when console_unlock() owner could sleep. But then there is not a danger of a softlockup. In each case, this patch did not make it worse. Could we agree on this, please? All in all, this patch improved one scenario and did not make worse another one. We know that it does not fix everything. But it is a step forward. Could we agree on this, please? Best Regards, Petr