linux-kernel - Re: Hibernation Redesign

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: <200707120854.46873.nigel@nigel.suspend2.net>
Date:	Thu, 12 Jul 2007 08:54:45 +1000
From:	Nigel Cunningham <nigel@...el.suspend2.net>
To:	david@...g.hm
Cc:	Miklos Szeredi <miklos@...redi.hu>, rjw@...k.pl, a1426z@...ab.com,
	jeremy@...p.org, jbms@....edu, pavel@....cz,
	nickpiggin@...oo.com.au, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org
Subject: Re: Hibernation Redesign

Hi.

On Thursday 12 July 2007 03:55:40 david@...g.hm wrote:
> On Wed, 11 Jul 2007, Nigel Cunningham wrote:
> 
> > Hi.
> >
> > On Wednesday 11 July 2007 21:11:34 Miklos Szeredi wrote:
> >>> Anyway, to implement the kexec approach we must separate the
> >>> hibernation from the suspend at the drivers level, which I'm still
> >>> going to do, but I need to take part in endless discussions
> >>
> >> Discussions are good.  We understand the problem better.  Now I still
> >> think we don't understand every aspect completely, so continuing the
> >> discussion makes sense.
> >>
> >>> regarding the freezer, how it is bad and how we should drop it,
> >>> because it breaks things (which NB is not true, because it doesn't).
> >>
> >> This thread started out from a bug, that seemed to be caused by the
> >> freezer (we still don't exactly know what it was caused by), and the
> >> discussion uncovered various problems _with_ the freezer, that up to
> >> now no other _proper_ solutions have been propsed than to remove the
> >> freezer.
> >
> > No other _proper_ solutions have been proposed. Everyone who suggests 
removing
> > the freezer also suggests implementing it all over again. It might be 
sending
> > SIGSTOP to everything. It might be shifting the desk chairs around and
> > creating a completely new kernel context, but they always have the same
> > goal - stopping the existing activity, and they all come with their own
> > issues (even if they're not obvious yet because the alternatives are
> > currently vapourware to one extent or another).
> 
> I think the big problem with the existing freezer is that you want to stop 
> everything, except X, except Y, except Z.....
> 
> the advantage of the new approaches being proposed is that they don't 
> require _anything_ from the origional system continue to run so you avoid 
> all the exceptions.
> 
> freezing everything is easy, figuring out what you don't want to freeze is 
> where everyone is seeing problems.
> 
> > IMHO, the real solution is to go back to the original issue and fix it
> > properly. Make fuse filesystems play nicely with the existing freezer. 
I've
> > just gone back and looked at the point where you started talking
> > about "malicious filesystems". You talk about fuse imposing certain 
ordering
> > in the userspace tasks being frozen. Please, say more. What ordering 
issues?
> > Why? How can such ordering be determined programmatically?
> 
> I think most people just see this as a symptom of the problem, not the 
> core problem itself.

Sure, but before we go out and buy a new car, let's figure out properly what 
the problems with the old one are. It might just be that the horrendous sound 
that's making us want a new car isn't as bad as we initially think. Even if 
we do decide we want a new version, we can at least learn something from the 
old one.

Regards,

Nigel
-- 
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.

Content of type "application/pgp-signature" skipped