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: <alpine.LFD.0.98.0705241507050.26602@woody.linux-foundation.org>
Date:	Thu, 24 May 2007 15:10:29 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Pavel Machek <pavel@....cz>
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



On Fri, 25 May 2007, Pavel Machek wrote:
> > 
> > Equally arguably, we should just have a "resume_late()" call that can be 
> > used to do this after everything is up and running.
> 
> Yes, we can do that. But userland will see devices "not there" for a
> few seconds after boot.

No they won't.

Why the HELL cannot you realize that kernel threads are different?

The right thing to do is AND HAS ALWAYS BEEN, to stop and start user 
threads only around the whole thing.

Don't touch those kernel threads. Stop freezing them.

Then, what you do is:
 - stop user space
 - suspend
 - resume
 - start user space

and at no point do you touch any kernel threads.

And yes, that "resume" part is multi-phase. We already have 
"resume_early()" to do bus-level setup, and then "resume()" to do the 
"make devices work". I was suggesting adding a "resume_late()" phase to 
let the devices do things that require other devices to work, like doing 
firmware loading.

But stopping kernel threads is STUPID. As long as we continue to do that, 
it will never _ever_ work.

Yeah, we could re-start the kernel thread before "resume_late()", but the 
fact is, they shouldn't have been stopped in the first place.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ