linux-kernel - Re: [PATCH]: In kernel hibernation, suspend to both

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4FB048A0.9000601@linux.vnet.ibm.com>
Date:	Mon, 14 May 2012 05:19:52 +0530
From:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
To:	Bojan Smojver <bojan@...ursive.com>
CC:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux PM list <linux-pm@...r.kernel.org>,
	linux-kernel@...r.kernel.org, bp@...en8.de
Subject: Re: [PATCH]: In kernel hibernation, suspend to both

On 05/14/2012 04:48 AM, Bojan Smojver wrote:

> On Sun, 2012-05-13 at 15:10 +0200, Rafael J. Wysocki wrote:
>>> So, a suspend after the image write will be just one long "failure",
>> after
>>> which hibernation code has to unwind again. No?
>>
>> Hmm.  Good question.  It should be like this I think, although there
>> may be some corner cases lurking.
> 
> AFAICT, the user space suspend to both works this way.
> 

But does it carry out suspend-to-ram in full, or does it skip the
PM_SUSPEND_PREPARE notifications?

> If I understand thing correctly, at the point of suspend to memory, we
> are not really running a full system any more. All the processes have
> been frozen and they've been told that hibernation is in progress. Ditto
> devices, minus the ones we use to write to swap. So, when hibernation
> code unwinds post resume from memory, it would be doing the correct
> thing.
> 
> Srivatsa, does that make sense to you?
> 

See my concerns about the preparation stage for suspend, in my other
mail as well. I would have been less worried if we did things in full:
1. prepare for hibernation
2. create image
3. prepare for suspend
4. do suspend
5. do resume
6. unwind from hibernation code (like a failed hibernation).

Still no guarantees, but somewhat better.
(consider what will happen if some code expects completion of an operation,
successful or otherwise, before starting another.. and hence is unprepared
for something like:
hibernation prepare -> suspend prepare -> post suspend -> post hibernation)

If we don't rework this thing carefully via a special notification for
save-image-and-suspend like what Rafael suggested, and instead try to go
with existing stuff as it is, I would definitely suggest putting this feature
under something like CONFIG_EXPERIMENTAL ;-)

Regards,
Srivatsa S. Bhat

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/