linux-kernel - Re: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation

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: <Pine.LNX.4.44L0.0707131402001.2684-100000@iolanthe.rowland.org>
Date:	Fri, 13 Jul 2007 14:15:46 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Jeremy Maitin-Shepard <jbms@....edu>, <david@...g.hm>,
	"Huang, Ying" <ying.huang@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Pavel Machek <pavel@....cz>, <nigel@...el.suspend2.net>,
	<linux-kernel@...r.kernel.org>,
	<linux-pm@...ts.linux-foundation.org>
Subject: Re: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation

On Fri, 13 Jul 2007, Eric W. Biederman wrote:

> > I doubt that re-probing devices will work.  The probe routine won't 
> > expect there to be any registered children, so it will try to 
> > re-register them.
> 
> So really unregister the children.  All we really need to do is disassociate
> the drivers from the devices (to reuse the existing code) we don't
> need to rescan for the devices.  The associating the device drivers
> with devices takes human measurable amount of time.  The only thing
> that takes time is waiting on hardware.  Maybe things will suck
> and associating the drivers with the device tree with take a whole
> second on a bad day, I don't think that is enough time to add
> complicated new code paths for the drivers to maintain.

This would be even worse!

Suppose you unbind (or unregister, either way) a disk driver.  It's 
unbind method will unregister the gendisk structure, thereby deleting 
all the partitions and block devices associated with the disk.  This 
will leave any and all memory mappings dangling in the breeze.  When 
the kernel resumes from hibernation, nothing will work.

> > On the other hand, post_restore methods could be written to expect 
> > something like this.
> 
> Please Please Plaese do not start with the existing software suspend
> to disk code and thinking.

Ha!  Gotcha.  You evidently haven't been reading the linux-pm mailing 
list for the last few months.  :-)

     1. post_restore isn't "existing software suspend to disk code"
	(you're supposed to call it "hibernation" now, BTW).

     2. post_restore isn't new.  It has already been proposed and
	generally accepted.  It is part of the movement to untangle
	and separate the suspend and hibernate code paths.

     3. post_restore hasn't been implemented yet.  It's barely past
	the proposal stage.

     4. Maybe _you_ like to discuss complicated issues such as this
	one without thinking, but the rest of us prefer a little 
	cerebration.

>  We are not implementing suspend to ram
> here or anything like it.

One of the topics in this discussion has been "suspend-to-both", which
includes suspend-to-RAM.  

But anyway, so what?  I wasn't talking about suspend-to-RAM; I was
talking about hibernation.

>  We already have proven code paths that
> know how to quiesce hardware.  We already have proven code paths
> that know how to take quite hardware and make it run.  Please let's
> just use them.  At least until we can see that they are insufficient
> to the task.

Was this request directed at me or at Rafael?  It's hard to tell.

Alan Stern

-
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/