From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752224AbdDIK71 (ORCPT ); Sun, 9 Apr 2017 06:59:27 -0400 Received: from rhlx01.hs-esslingen.de ([129.143.116.10]:44802 "EHLO rhlx01.hs-esslingen.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752062AbdDIK7T (ORCPT ); Sun, 9 Apr 2017 06:59:19 -0400 Date: Sun, 9 Apr 2017 12:59:18 +0200 From: Andreas Mohr To: Pavel Machek Cc: Sergey Senozhatsky , Steven Rostedt , Petr Mladek , Jan Kara , Andrew Morton , Linus Torvalds , Peter Zijlstra , "Rafael J . Wysocki" , Eric Biederman , Greg Kroah-Hartman , Jiri Slaby , Len Brown , linux-kernel@vger.kernel.org, Sergey Senozhatsky Subject: Re: [RFC][PATCHv2 4/8] pm: switch to printk.emergency mode in unsafe places Message-ID: <20170409105918.GA32358@rhlx01.hs-esslingen.de> References: <20170329092511.3958-1-sergey.senozhatsky@gmail.com> <20170329092511.3958-5-sergey.senozhatsky@gmail.com> <20170406172051.GC10363@amd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170406172051.GC10363@amd> X-Priority: none User-Agent: Mutt/1.8.0 (2017-02-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 06, 2017 at 07:20:52PM +0200, Pavel Machek wrote: > On Wed 2017-03-29 18:25:07, Sergey Senozhatsky wrote: > > It's not always possible/safe to wake_up() printk kernel > > thread. For example, late suspend/early resume may printk() > > while timekeeping is not initialized yet, so calling into the > > scheduler may result in recursive warnings. > > > > Another thing to notice is the fact PM at some point > > freezes user space and kernel threads: freeze_processes() > > and freeze_kernel_threads(), correspondingly. Thus we need > > printk() to operate in old mode there and attempt to > > immediately flush pending kernel message to the console. > > > > This patch adds printk_emergency_begin/on sections. > > > > Signed-off-by: Sergey Senozhatsky > > I don't like this. It is symptom of printk getting much more fragile > now. Sergey has mentioned it already: "at some point freezes user space and kernel threads". Well, this is the action which is *itself* causing thoroughly disrupting consequences, which I'd think thus ought to be responsible to ensure *itself* that all resulting consequences actually can be dealt with properly, rather than having weird *completely-unrelated-dependency* crap ("there happens to be some functionality called printk, and we need to bend it, since we need to bend it, since otherwise it would not be bent" - ahem...) leak into ("layer violation" keyword) pm handling implementation specifics. IOW, I would think that for any relevant kthread use in API user code, such code ought to be able to register kthread-API-provided callbacks (observer pattern, or whatever) where the (back to current case:) printk kthread would then be able to *implicitly*/*invisibly* switch the entire printk operation interface (e.g. via a global interface struct) to the "dumb"/"safe" fallback variant. Potential interface: kthread_notify(callback_func, kthread_notification_type); That way it could (hopefully) be ensured that people could use a consistent "printk" *interface* universally regardless of which "special" conditions happen to be in place at the moment. (IOW, keep interface behaviour which is required/expected at user code definitely isolated from awkward "implementation aspects" necessity which is currently poisoning user code implementation). Put differently, handling preferrably ought to get consistently adapted (i.e., switched) *centrally*, rather than requiring weird helpers (printk_emergency_X()) at all user code sites. ...or so goes the theory. (quite possibly such thoughts may hit roadblocks e.g. due to locking/atomicity issues) HTH, Andreas Mohr -- GNU/Linux. It's not the software that's free, it's you.