[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170627144513.GM1538@pathway.suse.cz>
Date: Tue, 27 Jun 2017 16:45:13 +0200
From: Petr Mladek <pmladek@...e.com>
To: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Steven Rostedt <rostedt@...dmis.org>, Jan Kara <jack@...e.cz>,
Andrew Morton <akpm@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>,
"Rafael J . Wysocki" <rjw@...ysocki.net>,
Eric Biederman <ebiederm@...ssion.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Slaby <jslaby@...e.com>, Pavel Machek <pavel@....cz>,
Andreas Mohr <andi@...as.de>,
Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCHv3 5/5] printk: register PM notifier
On Wed 2017-05-31 15:42:24, Sergey Senozhatsky wrote:
> On (05/30/17 11:55), Petr Mladek wrote:
> > BTW: Do you know about some locations that would need to be
> > patched explicitly, for example, kexec?
>
> a tricky question and I need to think more. I'm a bit overloaded
> with some other stuff now, sorry for long replies.
Same here.
> in case of kexec_image->preserve_context my assumption was that
> PM would send out PM notifications. but it seems that I need to have
> a second look. quite possible we will have to register yet another
> PM notifier - add syscore_ops to syscore_ops_list via
> register_syscore_ops() - the one that would be called from
> syscore_suspend().
syscore_suspend() is called also in many other locations. Also it
might be too late. For example, in the chain:
hybernate()
power_down()
hibernation_platform_enter()
syscore_suspend()
PM_HIBERNATION_PREPARE notifiers are called much earlier
in hybernate().
> the other branch invokes kernel_restart_prepare(), which updates
> `system_statem' variable and we test it in console_offload_printing().
Sounds promissing.
> some other cases also update `system_statem'. the exception is maybe
> sysrq emergency restart. but I'm a bit uncertain here. on one hand the
> expected emergency restart behavior is "just reboot the system, OK?",
> on the other hand there are people who expect kernel log messages to
> be flushed before that "just reboot the system" thing.
>
> > Some old versions of this patch touched console_suspend().
> > This brought me to snapshot_ioctl(). It looks like an
> > API that allows to create snapshots from user space.
> > I wonder if we should switch to the emergency mode
> > there are well, probably in the SNAPSHOT_FREEZE
> > stage.
>
> my assumption was that PM ioctl sends out PM notifications.
> see snapshot_open()/snapshot_release().
Great catch! I have missed this. It seems that the open()
funtion really has to be called before any ioctl() stuff
and we are on the safe side.
Best Regards,
Petr
Powered by blists - more mailing lists