On Thu, Oct 04, 2018 at 05:11:12AM -0400, Bastien Nocera wrote: > > > ----- Original Message ----- > > On Tue, Oct 02, 2018 at 12:16:02PM -0400, Bastien Nocera wrote: > > > > > > > > > ----- Original Message ----- > > > > On Di, 02.10.18 10:16, Bastien Nocera (bnocera@xxxxxxxxxx) wrote: > > > > > > > > > Until the kernel can use a dedicated partition for hibernation, which > > > > > would fix the majority of problems users can encounter, we're just > > > > > offering more sharp edges with which to cut themselves. > > > > > > > > As I understand the problems have more to do with hardware > > > > combinations, and driver code not getting things right, the actual > > > > serialization of stuff is fine and unproblematic... > > > > This is mixing two things — userspace configuration and autodetection, > > and kernel driver issues. The first is an easy problem (relatively), the > > second is much harder. > > > > Specifically: > > > > > There's problems with: > > > - not having enough swap space available at a particular instant > > as you know, systemd looks at the current memory usage, and does not > > advertise hibernation when not enough memory. So users might be > > unhappy that hibernation sometimes stops being available, but otherwise > > this is not a problem. > > > > There's some heuristics here. I haven't seen reports where hibernation > > would fail because systemd misdetected the amount of memory, but if you > > see this, please report, and we'll try to adjust. > > Simple. Boot machine, swap is empty. You'd setup hibernation because at that > moment in time, your swap is empty, and you have enough room to dump your whole > RAM. Then work on something, and fill up the swap. And hibernation now fails > because the swap is full up. Well, "hibernation is possible" is a dynamic state. Hibernation does not "fail", it just stops being advertised. I was explicitly talking about the case where it is *advertised* as available, it starts, but then actually fails mid-way. > > > - swap being encrypted and not allowing restore because the keys aren't > > > there anymore > > This particular case is not detected, but we certainly should do this. > > I'll put it on the todo list. > > > > > - swap not being encrypted, which could leak information down the line > > But that case also affect normal usage: if I have physical access to the > > machine, I can just press reset, and after reboot extract anything from > > swap. Hibernation doesn't change much here. > > There's bits of data that will never be swapped to disk under normal > operations, such as passwords, under normal circumstances. Those would end > up on disk, in the swap, when hibernating. True, that is valid point. If applications use mlock(2), they can protect some pages against being swapped out. gnome-keyring-daemon, goa-daemon, some WebKit stuff is doing that on F29. But it seems many applications don't actually do that. E.g. firefox ($ for i in $(pidof firefox); do grep VmLck /proc/$i/status;done|uniq -c 5 VmLck: 0 kB) One simply has to assume that all applications cannot get it right all of the time, so if one does not trust physical security of the machine, the only reliable way to protect against such attacks is to encrypt swap. > > > - resume= not being there in the default parameters, so dracut needing > > > to rewrite the initrd before hibernation is considered done (?) > > This is also solvable. Pull request [1] is upstream to check for resume= > > presence, and I plan to backport this to F29. > > > > [1] https://github.com/systemd/systemd/pull/10262 > > We'll still need to fix the installer to take that into account. The installer has already been fixed to add resume=, but that is irrelevant. What is discussed here is the opposite: other parts of userspace detecting if the setup is correct. > > > If the drivers being broken were the only problem, then reporting bugs > > > upstream > > > for those drivers would help, just in the same way it helped for suspend > > > 10 years ago. > > > > > > In my experience, the problem isn't so much with specific drivers, and > > > more with the whole infrastructure, whether in the kernel, user-space, > > > or a combination of both. > > Yes, hibernation gets a lot of flak for non-kernel issues, like those > > listed above. But those we can actually fix relatively easy. > > But we still need to get away from using swap for saving that data, and until > we do, hibernation will be flaky. Yes, it seems we really want to do this. It'd be so nice if kernel could allow memory.swap.current to be set on the root cgroup. We could set it to something like ~10% RAM but still have a bigger swap to support hibernation. (The kernel does not allow limits on the root cgroup with the justification that those limits are already settable in other places. But this one isn't.) > (I can't hibernate on any of my machines as I never set up big enough > swap partitions, because I know that my machine will be unusable if the swap > is actually used as swap). Zbyszek _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx
