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: <20070524231852.GG9604@elf.ucw.cz>
Date:	Fri, 25 May 2007 01:18:52 +0200
From:	Pavel Machek <pavel@....cz>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	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!

> > > Why the HELL cannot you realize that kernel threads are different?
> > 
> > Ugh? We are talking about request_firmware() here, right? That's
> > calling userland helper to load the firmware...? Looks like USER
> > thread to me.
> 
> Right. And if we had had the nice old /sbin/hotplug thing, it would all 
> have worked fine - because it would just have done an execve(), and things 
> would be happy.
> 
> But people screwed that up too, and now udevd is an undebuggable user 
> thread. Shit happens. See my other email about why even user threads can 
> probably not be frozen, and the whole freezer thing is misdesigned.

I'm not ready to redesign udevd :-(.

Your other mail proves that either

1) we can stop freezing udevd, and pray udevd does not become confused
by "half hardware not available" while system is being suspended

_or_

2) we need to preload firmware during _suspend_. I AM TELLING THAT TO
PEOPLE FOR FIVE YEARS NOW.

> And I repeat: PowerPC had working and stable suspend five _years_ ago, 
> without any of that freezing crud. We should rip it out.

Imageine we killed freezer. Also imagine Romano has IDE card his
PCMCIA slot. Kaboom, we solved nothing. We'll either deadlock or do
something very nasty to the filesystem on the IDE card ... because
we'll have udevd running, but fs on IDE card not available.

That does not work. "Not freezing udevd" only makes problems hard to
trigger, see?

Now... "should we rip freezer out of suspend" is a different story. It
does not help _here_. We still need to load the firmware during
_suspend_.

[Can you ack this point and we can have nice flamewar about ripping
out freezer?]

But I'd actually like to get rid of freezer for suspend (I believe
it is needed for hibernation) -- we'll need to do similar that for
runtime suspending of devices, anyway. But "just rip it out" will
cause some hard to debug breakage, we need to somehow audit the
drivers, or ask driver writers to audit them or something. ... and
yes, ripping freezer out _will_ make drivers more complex. Your video
capture card will now have to deal with

"ouch, I was already told to suspend, and now someone is calling my
ioctls() ?!".

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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/