From: JANAK DESAI <janak@us.ibm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: viro@ftp.linux.org.uk, chrisw@osdl.org, dwmw2@infradead.org,
jamie@shareable.org, serue@us.ibm.com, mingo@elte.hu,
linuxram@us.ibm.com, jmorris@namei.org, sds@tycho.nsa.gov,
akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH -mm 1/9] unshare system call: system call handler function
Date: Thu, 15 Dec 2005 15:38:13 -0500 [thread overview]
Message-ID: <43A1D435.5060602@us.ibm.com> (raw)
In-Reply-To: <m1k6e687e2.fsf@ebiederm.dsl.xmission.com>
Eric W. Biederman wrote:
>JANAK DESAI <janak@us.ibm.com> writes:
>
>
>
>>[PATCH -mm 1/9] unshare system call: system call handler function
>>
>>sys_unshare system call handler function accepts the same flags as
>>clone system call, checks constraints on each of the flags and invokes
>>corresponding unshare functions to disassociate respective process
>>context if it was being shared with another task.
>>
>>Changes since the first submission of this patch on 12/12/05:
>> - Moved cleaning up of old shared structures outside of the
>> block that holds task_lock (12/13/05)
>>
>>Signed-off-by: Janak Desai <janak@us.ibm.com>
>>
>>---
>>
>> fork.c | 232 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 files changed, 232 insertions(+)
>>
>>diff -Naurp 2.6.15-rc5-mm2/kernel/fork.c 2.6.15-rc5-mm2+patch/kernel/fork.c
>>--- 2.6.15-rc5-mm2/kernel/fork.c 2005-12-12 03:05:59.000000000 +0000
>>+++ 2.6.15-rc5-mm2+patch/kernel/fork.c 2005-12-13 18:38:26.000000000 +0000
>>@@ -1330,3 +1330,235 @@ void __init proc_caches_init(void)
>> sizeof(struct mm_struct), 0,
>> SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL, NULL);
>> }
>>+
>>+
>>+/*
>>+ * Check constraints on flags passed to the unshare system call and
>>+ * force unsharing of additional process context as appropriate.
>>+ */
>>
>>
>
>If it isn't legal how about we deny the unshare call.
>Then we can share this code with clone.
>
>Eric
>
>
>
>
unshare is doing the reverse of what clone does. So if you are unsharing
namespace
you want to make sure that you are not sharing fs. That's why the
CLONE_FS flag
is forced (meaning you are also going to unshare fs). Since namespace is
shared
by default and fs is not, if clone is called with CLONE_NEWNS, the
intent is to
create a new namespace, which means you cannot share fs. clone checks to
makes sure that CLONE_NEWNS and CLONE_FS are not specified together, while
unshare will force CLONE_FS if CLONE_NEWNS is spefcified. Basically you
can have a shared namespace and non shared fs, but not the other way
around and
since clone and unshare are doing opposite things, sharing code between
them that
checks constraints on the flags can get convoluted.
-Janak
next prev parent reply other threads:[~2005-12-15 20:38 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-13 22:54 [PATCH -mm 1/9] unshare system call: system call handler function JANAK DESAI
2005-12-15 19:52 ` Eric W. Biederman
2005-12-15 20:38 ` JANAK DESAI [this message]
2005-12-15 21:13 ` Eric W. Biederman
2005-12-15 21:32 ` Jamie Lokier
2005-12-15 22:34 ` Eric W. Biederman
2005-12-16 4:36 ` JANAK DESAI
2005-12-16 4:32 ` JANAK DESAI
2005-12-16 10:50 ` Jamie Lokier
2005-12-16 12:46 ` Eric W. Biederman
2005-12-16 17:00 ` Jamie Lokier
2005-12-17 2:23 ` Eric W. Biederman
2005-12-16 14:32 ` Serge E. Hallyn
2005-12-16 12:39 ` Eric W. Biederman
2005-12-15 21:28 ` Jamie Lokier
2005-12-16 4:35 ` JANAK DESAI
-- strict thread matches above, loose matches on Subject: below --
2005-12-13 13:42 [PATCH -mm 1/9] unshare system call : " JANAK DESAI
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=43A1D435.5060602@us.ibm.com \
--to=janak@us.ibm.com \
--cc=akpm@osdl.org \
--cc=chrisw@osdl.org \
--cc=dwmw2@infradead.org \
--cc=ebiederm@xmission.com \
--cc=jamie@shareable.org \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxram@us.ibm.com \
--cc=mingo@elte.hu \
--cc=sds@tycho.nsa.gov \
--cc=serue@us.ibm.com \
--cc=viro@ftp.linux.org.uk \
/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