|| ||Ingo Molnar <mingo-AT-elte.hu>|
|| ||Dave Hansen <dave-AT-linux.vnet.ibm.com>|
|| ||Re: What can OpenVZ do?|
|| ||Tue, 17 Feb 2009 23:23:19 +0100|
|| ||Andrew Morton <akpm-AT-linux-foundation.org>, linux-api-AT-vger.kernel.org,
viro-AT-zeniv.linux.org.uk, mpm-AT-selenic.com, tglx-AT-linutronix.de,
Nathan Lynch <nathanl-AT-austin.ibm.com>|
|| ||Article, Thread
* Dave Hansen <email@example.com> wrote:
> On Fri, 2009-02-13 at 11:53 +0100, Ingo Molnar wrote:
> > In any case, by designing checkpointing to reuse the existing LSM
> > callbacks, we'd hit multiple birds with the same stone. (One of
> > which is the constant complaints about the runtime costs of the LSM
> > callbacks - with checkpointing we get an independent, non-security
> > user of the facility which is a nice touch.)
> There's a fundamental problem with using LSM that I'm seeing
> now that I look at using it for file descriptors. The LSM
> hooks are there to say, "No, you can't do this" and abort
> whatever kernel operation was going on. That's good for
> detecting when we do something that's "bad" for checkpointing.
> *But* it completely falls on its face when we want to find out
> when we are doing things that are *good*. For instance, let's
> say that we open a network socket. The LSM hook sees it and
> marks us as uncheckpointable. What about when we close it?
> We've become checkpointable again. But, there's no LSM hook
> for the close side because we don't currently have a need for
Uncheckpointable should be a one-way flag anyway. We want this
to become usable, so uncheckpointable functionality should be as
painful as possible, to make sure it's getting fixed ...
> We have a couple of options:
> We can let uncheckpointable actions behave like security
> violations and just abort the kernel calls. The problem with
> this is that it makes it difficult to do *anything* unless
> your application is 100% supported. Pretty inconvenient,
> especially at first. Might be useful later on though.
It still beats "no checkpointing support at all in the upstream
kernel", by a wide merging. If an app fails, the more reasons to
bring checkpointing support up to production quality? We dont
want to make the 'interim' state _too_ convenient, because it
will quickly turn into the status quo.
Really, the LSM approach seems to be the right approach here. It
keeps maintenance costs very low - there's no widespread
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to firstname.lastname@example.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"email@example.com"> firstname.lastname@example.org </a>
to post comments)