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.
next prev parent 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