All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.