public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Cedric Le Goater <clg@fr.ibm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Kirill Korotaev <dev@openvz.org>, Andrew Morton <akpm@osdl.org>,
	devel@openvz.org, xemul@openvz.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	herbert@13thfloor.at, saw@sw.ru, serue@us.ibm.com,
	sfrench@us.ibm.com, sam@vilain.net, haveblue@us.ibm.com
Subject: Re: [PATCH 2/6] IPC namespace - utils
Date: Mon, 12 Jun 2006 23:05:34 +0200	[thread overview]
Message-ID: <448DD71E.1020209@fr.ibm.com> (raw)
In-Reply-To: <m1bqsy6ynn.fsf@ebiederm.dsl.xmission.com>

Eric W. Biederman wrote:
> Cedric Le Goater <clg@fr.ibm.com> writes:
> 
>> I've used the ipc namespace patchset in rc6-mm2. Thanks for putting this
>> together, it works pretty well ! A few questions when we clone :
>>
>> * We should do something close to what exit_sem() already does to clear the
>> sem_undo list from the task doing the clone() or unshare().
> 
> Possibly which case are you trying to prevent?

task records a list of struct sem_undo each containing a semaphore id. When
we unshare ipc namespace, we break the 'reference' between the semaphore id
and the struct sem_array because the struct sem_array are cleared and freed
in the new namespace. When the task exit, that inconstency could lead to
unexpected results in exit_sem(), task locks, BUG_ON, etc. Nope ?


>> * I don't like the idea of being able to unshare the ipc namespace and keep
>> some shared memory from the previous ipc namespace mapped in the process mm.
>> Should we forbid the unshare ?
> 
> No.  As long as the code handles that case properly we should be fine.

what is the proper way to handle that case ? the current patchset is not
protected : a process can be in one ipc namespace and use a shared segment
from a previous ipc namespace. This situation is not desirable in a
migration scenario. May be asking too much for the moment ... and I agree
this can be fixed by the way namespaces are created.

> As a general principle we should be able to keep things from other namespaces
> open if we get them.  The chroot or equivalent binary is the one that needs
> to ensure these kinds of issues don't exist if we care.
>
> Speaking of we should put together a small test application probably similar
> to chroot so people can access these features at least for testing.

are you thinking about a command unshare()ing each namespace or some kind
of create_nsproxy ?

> Ack.  For the unshare fix below.  Could you resend this one separately with
> patch in the subject so Andrew sees it and picks  up?

done.

thanks,

c.

  reply	other threads:[~2006-06-12 21:06 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-09 14:55 [PATCH] IPC namespace Kirill Korotaev
2006-06-09 15:01 ` [PATCH 1/6] IPC namespace core Kirill Korotaev
2006-06-09 15:20   ` Cedric Le Goater
2006-06-09 15:26   ` James Morris
2006-06-09 18:38   ` Andrew Morton
2006-06-10  0:44   ` Eric W. Biederman
2006-06-10  3:22   ` Andrew Morton
2006-06-09 15:05 ` [PATCH 2/6] IPC namespace - utils Kirill Korotaev
2006-06-12 17:08   ` Cedric Le Goater
2006-06-12 18:01     ` Eric W. Biederman
2006-06-12 21:05       ` Cedric Le Goater [this message]
2006-06-12 21:49         ` Eric W. Biederman
2006-06-13 21:17           ` Cedric Le Goater
2006-06-14 11:14             ` Kirill Korotaev
2006-06-09 15:07 ` [PATCH 3/6] IPC namespace - msg Kirill Korotaev
2006-06-09 15:08 ` [PATCH 4/6] IPC namespace - sem Kirill Korotaev
2006-06-09 15:09 ` [PATCH 5/6] IPC namespace - shm Kirill Korotaev
2006-06-09 15:11 ` [PATCH 6/6] IPC namespace - sysctls Kirill Korotaev
2006-06-12 17:19 ` [PATCH] IPC namespace Dave Hansen
2006-06-13  2:44 ` Eric W. Biederman
2006-06-13 16:41   ` Kirill Korotaev
2006-06-13 17:01     ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=448DD71E.1020209@fr.ibm.com \
    --to=clg@fr.ibm.com \
    --cc=akpm@osdl.org \
    --cc=dev@openvz.org \
    --cc=devel@openvz.org \
    --cc=ebiederm@xmission.com \
    --cc=haveblue@us.ibm.com \
    --cc=herbert@13thfloor.at \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sam@vilain.net \
    --cc=saw@sw.ru \
    --cc=serue@us.ibm.com \
    --cc=sfrench@us.ibm.com \
    --cc=xemul@openvz.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox