public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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