From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753353AbdDJMUs (ORCPT ); Mon, 10 Apr 2017 08:20:48 -0400 Received: from mx2.suse.de ([195.135.220.15]:42006 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752343AbdDJMUr (ORCPT ); Mon, 10 Apr 2017 08:20:47 -0400 Date: Mon, 10 Apr 2017 14:20:43 +0200 From: Petr Mladek To: Andreas Mohr Cc: Pavel Machek , Sergey Senozhatsky , Steven Rostedt , 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: <20170410122043.GW3452@pathway.suse.cz> References: <20170329092511.3958-1-sergey.senozhatsky@gmail.com> <20170329092511.3958-5-sergey.senozhatsky@gmail.com> <20170406172051.GC10363@amd> <20170409105918.GA32358@rhlx01.hs-esslingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170409105918.GA32358@rhlx01.hs-esslingen.de> 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 Sun 2017-04-09 12:59:18, Andreas Mohr wrote: > 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. > > > > 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); Interesting idea. The power management area probably can be solved by the existing notifiers framework, see register_pm_notifier(). I haven't checked it but if the notifiers are called on right locations, it would be cleaner than adding the calls into the pm code. > 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. Note that there already all many printk/console related "hacks" in sensitive code paths. For example, see the use of pm_prepare_console(), suspend_console(), console_level. Best Regards, Petr