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: 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.0704261021160.9964@woody.linux-foundation.org>
Date:	Thu, 26 Apr 2007 10:34:16 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Xavier Bestel <xavier.bestel@...e.fr>
cc:	Nigel Cunningham <nigel@...el.suspend2.net>,
	Pekka Enberg <penberg@...helsinki.fi>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Back to the future.

On Thu, 26 Apr 2007, Xavier Bestel wrote:
> 
> Won't there be problems if e.g. X tries to write something to its
> logfile after snapshot ?

Sure. But that's a user-level issue.

You do have to allow writing after snapshotting, since at a minimum, you'd 
want the snapshot itself to be written. So the kernel has to be fully 
running, and support full user space. No "degraded mode" like now.

So when I said "fully running user mode", I really meant it from the 
perspective of the kernel - not necessarily from the perspective of the 
"user". You do want to limit _what_ user mode does, but you must not limit 
it by making the kernel less capable.

Remounting mounted filesystems read-only sounds like a good idea, for 
example. We can do that. We have the technology. But we shouldn't limit 
user space from doing other things (for example, it might want to actually 
*mount* a new filesystem for writing the snapshot image).

For example, right now we try to "fix" that with the whole process freezer 
thing. And that code has *caused* more problems than it fixed, since it 
tries to freeze all the kernel threads etc, and you simply don't have a 
truly *working*system*.

I think it's fine to freeze processes if that is what you want to do (for 
example, send them SIGSTOP), but we freeze them *too*much* right now, and 
the suspend stuff has taken over policy way too much. We don't actually 
leave the system in a runnable state. I can almost guarantee that you'd be 
*better* off having the snapshot taking thing do a

	kill(-1, SIGSTOP);

in user space than our current broken process freezer. At least that 
wouldn't have screwed up those kernel threads as badly as swsusp did.

And no, I'm not saying that my suggestion is the only way to do it. Go 
wild. But the *current* situation is just broken. Three different things, 
none of which people can agree on. I'd *much* rather see a conceptually 
simpler approach that then required, but even more important is that right 
now people aren't even discussing alternatives, they're just pushing one 
of the three existing things, and that's simply not viable. Because I'm 
not merging another one.

In fact, I personally feel that I shouldn't even have merged 
userspace-swsusp, but if Andrew thinks it needs to be merged, my personal 
feelings simply don't matter that much. I have to trust people. But yes, 
as far as *I* am personally concerned, I think it was a mistake to merge 
it.

			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/