Messages in this thread |  | | Date | Sun, 9 Apr 2017 12:59:18 +0200 | From | Andreas Mohr <> | Subject | Re: [RFC][PATCHv2 4/8] pm: switch to printk.emergency mode in unsafe places |
| |
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 <sergey.senozhatsky@gmail.com> > > 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.
|  |