linux-kernel - Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

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: <1180058123.3997.91.camel@nigel.suspend2.net>
Date:	Fri, 25 May 2007 11:55:22 +1000
From:	Nigel Cunningham <nigel@...el.suspend2.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Pavel Machek <pavel@....cz>,
	Romano Giannetti <romanol@...omillas.es>,
	Chris Wright <chrisw@...s-sol.org>,
	Chuck Ebbert <cebbert@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	stable@...nel.org, Justin Forbes <jmforbes@...uxtx.org>,
	Zwane Mwaikambo <zwane@....linux.org.uk>,
	Theodore Ts'o <tytso@....edu>,
	Randy Dunlap <rdunlap@...otime.net>,
	Dave Jones <davej@...hat.com>,
	Chuck Wolber <chuckw@...ntumlinux.com>,
	Chris Wedgwood <reviews@...cw.f00f.org>,
	Michael Krufky <mkrufky@...uxtv.org>,
	akpm@...ux-foundation.org, alan@...rguk.ukuu.org.uk,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

Hi Linus.

On Thu, 2007-05-24 at 17:37 -0700, Linus Torvalds wrote:
> 
> On Fri, 25 May 2007, Pavel Machek wrote:
> > 
> > 2) we need to preload firmware during _suspend_. I AM TELLING THAT TO
> > PEOPLE FOR FIVE YEARS NOW.
> 
> And people aren't listening. Have you thought about _why_?
> 
> The thing is, it should just work. Even without pre-loading.
> 
> > Imageine we killed freezer. Also imagine Romano has IDE card his
> > PCMCIA slot. Kaboom, we solved nothing.
> 
> Don't be silly. We solved it. The firmware has to be loadable from 
> somewhere else, since otherwise his IDE card wouldn't have been accessible 
> in the first place! 
> 
> So all your arguments are just bogus crap.

Let me see if I can help. I'll probably fail miserably, but I can only
try :)

First, let me agree with you that for the atomic copy itself, the
freezer is unnecessary. Disabling irqs and so on is enough to ensure the
atomic copy is atomic. I don't think any of us are arguing with you
there.

Where we see the problem is with what happens after the atomic copy is
made. The problem is that the atomic copy includes struct inodes, dnodes
and such like - an in memory representation of the state of mounted
filesystems. Imagine that, post atomic copy, we don't have the freezer.
Processes can then make on-disk changes to these mounted filesystems in
the time before we complete saving the image and powering down. If, at
resume time, we then restore the atomic copy, we have a mismatch between
what the in-memory data structures say and what the on-disk data says.
This leads to corruption.

How to avoid?

Well, there are only two options as far as I can see. We either stop
those changes occurring in the first place, or we make them undoable.

Freezing processes, and/or filesystems would be the first path,
checkpointing the second.

So, as far as I can see, we're stuck with freezing processes at least
until checkpointing is implemented.

I have to admit though, that even if checkpointing was implemented, I'd
like to see freezing processes remain. The image gets written faster if
we don't have to compete for cpu and i/o. It also allows us to do a
fuller image of memory than is otherwise possible (Yes, I know some
people don't care for full images, but others of us have usage patterns
that make the system far more useable if a full image is kept, or simply
prefer to have our machines as if the power had never gone away).
Without processes freezing, I'd have to work a lot harder to find a way
to do that full image. The simplest way would probably be to carry the
freezer code myself. (Yeah, I'm reconciled to the idea of never getting
Suspend2 merged. I'd like it to happen, but won't hold my breath.
Someone needs to break your suspend-to-ram or battery so you see the use
for hibernation :>).

Hope this helps.

Nigel

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)