linux-kernel - Re: Back to the future.

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200704290103.38409.rjw@sisk.pl>
Date:	Sun, 29 Apr 2007 01:03:37 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Pavel Machek <pavel@....cz>,
	Nigel Cunningham <nigel@...el.suspend2.net>,
	Pekka J Enberg <penberg@...helsinki.fi>,
	LKML <linux-kernel@...r.kernel.org>,
	Oleg Nesterov <oleg@...sign.ru>
Subject: Re: Back to the future.

On Saturday, 28 April 2007 23:25, Linus Torvalds wrote:
> 
> On Sat, 28 Apr 2007, Rafael J. Wysocki wrote:
> > > 
> > > The freezer has *caused* those deadlocks (eg by stopping threads that were 
> > > needed for the suspend writeouts to succeed!), not solved them.
> > 
> > I can't remember anything like this, but I believe you have a specific test
> > case in mind.
> 
> Ehh.. Why do you thik we _have_ that PF_NOFREEZE thing in the first place?

Well, I don't know why exactly it had been originally introduced.  Currently,
it is used by the threads that should be running after the snapshot is done
(they are not only I/O threads).

> Rafael, you really don't know what you're talking about, do you?

I think I know.

> Just _look_ at them. It's the IO threads etc that shouldn't be frozen, 
> exactly *because* they do IO. You claim that kernel threads shouldn't do 
> IO, but that's the point: if you cannot do IO when snapshotting to disk,  
> here's a damn big clue for you: how do you think that snapshot is going to 
> get written?

OK, more precisely: fs-related threads should not try to process their queues,
etc., after the snapshot is done, because that may cause some fs data to be
written at that time and then the fs in question may be corrupted after the
restore.  Not all of the I/O in general, fs data.

Still, that alone probably is not a good enough reason for freezing all kernel
threads.

> I *guarantee* you that we've had a lot more problems with threads that 
> should *not* have been frozen than with those hypothetical threads that 
> you think should have been frozen.

Well, I'm not sure whether or not that still would have been the case if we had
stopped to freeze kernel threads for the hibernation/suspend.  I just see
potential problems that I've mentioned in the previous message and I don't see
any evidence that they cannot occur.

Greetings,
Rafael
-
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/