From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753233AbZBRFFR (ORCPT ); Wed, 18 Feb 2009 00:05:17 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750826AbZBRFFD (ORCPT ); Wed, 18 Feb 2009 00:05:03 -0500 Received: from fg-out-1718.google.com ([72.14.220.158]:6803 "EHLO fg-out-1718.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750720AbZBRFFA (ORCPT ); Wed, 18 Feb 2009 00:05:00 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=e8jxKVkYueXBb9bwdlt9dIpYHuzIZLmXQDVoyr0vuDca0/ab+n1hhM/U7vacPpUf0/ mbTJUHupzTiEwy51spkH61ba3l/ipFAVF3+Wp0Vi8F+cvlgLbmVK7XY79+S6RR+UYCsD /qok2LJimZ8LWKCavw4WNsebNyfihWw3qQPnI= Date: Wed, 18 Feb 2009 08:11:23 +0300 From: Alexey Dobriyan To: Dave Hansen Cc: Ingo Molnar , Andrew Morton , linux-api@vger.kernel.org, containers@lists.linux-foundation.org, hpa@zytor.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, viro@zeniv.linux.org.uk, mpm@selenic.com, tglx@linutronix.de, torvalds@linux-foundation.org, xemul@openvz.org, Nathan Lynch Subject: Re: What can OpenVZ do? Message-ID: <20090218051123.GA9367@x200.localdomain> References: <1234467035.3243.538.camel@calx> <20090212114207.e1c2de82.akpm@linux-foundation.org> <1234475483.30155.194.camel@nimitz> <20090212141014.2cd3d54d.akpm@linux-foundation.org> <20090213105302.GC4608@elte.hu> <1234817490.30155.287.camel@nimitz> <20090217222319.GA10546@elte.hu> <1234909849.4816.9.camel@nimitz> <20090218003217.GB25856@elte.hu> <1234917639.4816.12.camel@nimitz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1234917639.4816.12.camel@nimitz> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 17, 2009 at 04:40:39PM -0800, Dave Hansen wrote: > On Wed, 2009-02-18 at 01:32 +0100, Ingo Molnar wrote: > > > > 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 ... > > > > > > Again, as these patches stand, we don't support checkpointing > > > when non-simple files are opened. Basically, if a > > > open()/lseek() pair won't get you back where you were, we > > > don't deal with them. > > > > > > init does non-checkpointable things. If the flag is a one-way > > > trip, we'll never be able to checkpoint because we'll always > > > inherit init's ! checkpointable flag. > > > > > > To fix this, we could start working on making sure we can > > > checkpoint init, but that's practically worthless. > > > > i mean, it should be per process (per app) one-way flag of > > course. If the app does something unsupported, it gets > > non-checkpointable and that's it. > > OK, we can definitely do that. Do you think it is OK to run through a > set of checks at exec() time to check if the app currently has any > unsupported things going on? If we don't directly inherit the parent's > status, then we need to have *some* time when we check it. Uncheckpointable is not one-way. Imagine remap_file_pages(2) is unsupported. Now app uses remap_file_pages(2), then unmaps interesting VMA. Now app is checkpointable again. As for overloading LSM, I think, it would be horrible. Most hooks are useless, there are config options expanding LSM hooks, and CPT and LSM are just totally orthogonal. Instead, just (no offence) get big enough coverage -- run modern and past distros, run servers packaged with them, and if you can checkpoint all of this, you're mostly fine.