On Thursday, December 5, 2019 6:17:16 PM MST Chris Murphy wrote:
On Thu, Dec 5, 2019 at 4:49 PM John M. Harris Jr
<johnmh(a)splentity.com>
wrote:
>
>
> On Thursday, December 5, 2019 1:40:02 PM MST Chris Murphy wrote:
>
> > Hibernation is out of scope to rely on, let alone make a default, for
> > at least the following reasons:
> > a. It's not sufficiently well supported upstream for regressions that
> > may appear in new kernels, and not supported by the Fedora kernel
> > team.
>
>
>
> I'm not sure who told you this, but that's not the case. Hibernation is
> supported in Fedora.
No it isn't. But as I've asked you for your definition of "support"
and you still haven't, and I've offered my own and you haven't
disputed it, I win. That's the short version because you have a track
record of not reading provided references. For the long version:
There's nothing to "win". This isn't a competition. We're all on the
same side
here.
My definition of "supported in Fedora" is.. supported in Fedora. You can do it
in Fedora. Without modifying anything. In my DE, for example, I'd do that by
pressing Alt + F1, the Super key, or click the KDE icon in the left of my
primary screen's Panel, Leave -> Hibernate.
> > b. It's disabled by kernel lockdown on UEFI Secure Boot
systems.
>
>
>
> How so? What "kernel lockdown" are you referring to?
[ 1.097121] Lockdown: swapper/0: Hibernation is restricted; see man
kernel_lockdown.7
And also the above kernel list email thread mentions it also. I'm
surprised you haven't heard of it, it's been around for quite a long
time as it's an obvious attack vector that obviates the point of
Secure Boot.
I don't have a personal system that uses UEFI, much less "Secure Boot", so I
things that affect those systems in Fedora, but not the versions of RHEL I
work with, I have no reason to follow normally. I'll take a look, however.
"Secure Boot" is a misnomer, by the way, and hibernation is not a security
issue. Suspension is, but not hibernation.
> What are you talking about? You should have at least 1x RAM for
swap
> whether you use hibernation or not. If you're having issues, you can
> adjust the swappiness as needed. There is no "effective loss of the
> system" involved.
...snip...
In the case where swap is used heavily, rather than incidentally,
the
UX is atrocious. The resulting swap thrashing is ai bad the system is
functionally lost and it's completely reasonable for a user to force
power off.
What are you suggesting the UX is atrocious for? Modifying the swappiness
value? I have come across situations where a system without swap OOMs, and
effectively freezes up as a result, causing the user to hard-boot the system,
but I have never seen that with a system where swap was at least 1x the amount
of RAM.
> > d. There's no release criterion. Therefore the project
wouldn't block
> > release on any discovered bugs. Serious bugs would likely lead to
> > reverting any use of hibernation by default, and so it's not at all
> > likely it'll become supported by default.
>
>
>
> Blockers are dynamic. We can make new blockers if we need them.
There's actual background study and work to be done before a release
criterion is accepted. Saying things doesn't make them true. The
criterion itself needs to be written, test cases produced and sanity
checked, and perhaps most importantly: who will be fixing the blocker
bugs? You need willing people to be available from multiple teams,
each having enough resources to ensure it gets highly escalated fixes.
It doesn't really make any sense to dismiss this. If it's deemed necessary for
there to be a blocker, we can make a new blocker. That's a non-issue.
--
John M. Harris, Jr.
Splentity