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: <Pine.LNX.4.63.0704271521230.10565@qynat.qvtvafvgr.pbz>
Date:	Fri, 27 Apr 2007 15:26:04 -0700 (PDT)
From:	David Lang <david.lang@...italinsight.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Pekka J Enberg <penberg@...helsinki.fi>,
	Nigel Cunningham <nigel@...el.suspend2.net>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Back to the future.

On Sat, 28 Apr 2007, Rafael J. Wysocki wrote:

>>> We're freezing many of them just fine. ;-)
>>
>> And can you name a _single_ advantage of doing so?
>
> Yes.  We have a lot less interdependencies to worry about during the whole
> operation.
>
>> It so happens, that most people wouldn't notice or care that kmirrord got
>> frozen (kernel thread picked at random - it might be one of the threads
>> that has gotten special-cased to not do that), but I have yet to hear a
>> single coherent explanation for why it's actually a good idea in the first
>> place.
>
> Well, I don't know if that's a 'coherent' explanation from your point of view
> (probably not), but I'll try nevertheless:
> 1) if the kernel threads are frozen, we know that they don't hold any locks
> that could interfere with the freezing of device drivers,

does teh process of freezing really wait until all locks have been released?

> 2) if they are frozen, we know, for example, that they won't call user mode
> helpers or do similar things,

this won't matter unless the user mode helpers are going to do I/O or other 
permanent changes

> 3) if they are frozen, we know that they won't submit I/O to disks and
> potentially damage filesystems (suspend2 has much more problems with that
> than swsusp, but still.  And yes, there have been bug reports related to it,
> so it's not just my fantasy).

if you have the filesystems checkpointed then I/O after the freeze won't matter 
as you just revert to the checkpoint (and since this is going to be thrown away 
it can stay in ram)

if we are willing to make a break with the past to implement the new snapshot 
capability, we should be able to use the LVM snapshot code to handle the 
filesystem

David Lang

> Probably some other people can say more about it.
>
>> And it has added totally idiotic code to every single kernel thread main
>> loop. For _no_ reason, except that the concept was broken, and needed more
>> breakage to just make it work.
>
> It is actually useful for some things other than the hibernation/suspend, the
> code is not idiotic (it's one line of code in the majority of cases) and you
> should take that "I hate everything even remotely related to hibernation" hat
> off, really.
>
> 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/
>
-
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/