From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753825AbdDJOia (ORCPT ); Mon, 10 Apr 2017 10:38:30 -0400 Received: from mail-pf0-f196.google.com ([209.85.192.196]:36459 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751396AbdDJOi2 (ORCPT ); Mon, 10 Apr 2017 10:38:28 -0400 Date: Mon, 10 Apr 2017 23:38:17 +0900 From: Sergey Senozhatsky To: Andreas Mohr , Petr Mladek 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: <20170410143817.GA457@tigerII.localdomain> References: <20170329092511.3958-1-sergey.senozhatsky@gmail.com> <20170329092511.3958-5-sergey.senozhatsky@gmail.com> <20170406172051.GC10363@amd> <20170409105918.GA32358@rhlx01.hs-esslingen.de> <20170410122043.GW3452@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170410122043.GW3452@pathway.suse.cz> 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 (04/10/17 14:20), Petr Mladek wrote: [..] > > 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. good idea indeed. wish we also had kexec and sysrq notifiers :) there is a `panic_notifier_list', but that's not exactly what we need. [..] > > 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. yep. I wonder if some of those can be moved to printk pm notifiers. but that's out of the scope of this patch set. -ss