Re: What can OpenVZ do?

* Dave Hansen [off-list ref] wrote:

On Fri, 2009-02-13 at 11:53 +0100, Ingo Molnar wrote:

quoted

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 
it.

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 
BKL-style flaggery.

	Ingo

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>