From: Cedric Le Goater <legoater-GANU6spQydw@public.gmane.org>
To: Linux Kernel Mailing List
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Cc: Linux Containers
<containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org>,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
Pavel Emelianov <xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
Subject: [PATCH 2/2] extend clone_flags using parent_tidptr argument
Date: Mon, 04 Feb 2008 18:27:09 +0100 [thread overview]
Message-ID: <47A74AED.1080806@free.fr> (raw)
From: Cedric Le Goater <clg-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
We have at least 2 patchsets requiring each a new clone flag and
there it is, we've reached the limit, none are left.
This patch uses the CLONE_DETACHED flag (unused) as a marker to
extend the clone flags through the parent_tidptr argument.
Initially, we thought on using the last bit but it has recently
been taken by CLONE_IO.
Obviously, this hack doesn't work for unshare() for which I don't
see any other solution than to add a new syscall :
long sys_unshare64(unsigned long clone_flags_high,
unsigned long clone_flags_low);
Is this the right path to extend the clone flags ? should we add a
clone64() rather than hack the extending clone() ?
Thanks for any comments !
C.
Signed-off-by: Cedric Le Goater <clg-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
---
include/linux/sched.h | 1 +
kernel/fork.c | 14 +++++++++++++-
2 files changed, 14 insertions(+), 1 deletion(-)
Index: 2.6.24-mm1/include/linux/sched.h
===================================================================
--- 2.6.24-mm1.orig/include/linux/sched.h
+++ 2.6.24-mm1/include/linux/sched.h
@@ -28,6 +28,7 @@
#define CLONE_NEWPID 0x20000000 /* New pid namespace */
#define CLONE_NEWNET 0x40000000 /* New network namespace */
#define CLONE_IO 0x80000000 /* Clone io context */
+#define CLONE_EXTFLAGS CLONE_DETACHED /* use parent_tidptr as an extended set of flags */
/*
* Scheduling policies
Index: 2.6.24-mm1/kernel/fork.c
===================================================================
--- 2.6.24-mm1.orig/kernel/fork.c
+++ 2.6.24-mm1/kernel/fork.c
@@ -1012,6 +1012,14 @@ static struct task_struct *copy_process(
struct task_struct *p;
int cgroup_callbacks_done = 0;
+ /*
+ * It is not permitted to specify both CLONE_EXTFLAGS and
+ * CLONE_PARENT_SETTID
+ */
+ if ((clone_flags & (CLONE_EXTFLAGS|CLONE_PARENT_SETTID)) ==
+ (CLONE_EXTFLAGS|CLONE_PARENT_SETTID))
+ return ERR_PTR(-EINVAL);
+
if ((clone_flags & (CLONE_NEWNS|CLONE_FS)) == (CLONE_NEWNS|CLONE_FS))
return ERR_PTR(-EINVAL);
@@ -1455,6 +1463,7 @@ long do_fork(unsigned long clone_flags,
struct task_struct *p;
int trace = 0;
long nr;
+ u64 clone_flags64 = clone_flags;
/*
* We hope to recycle these flags after 2.6.26
@@ -1479,7 +1488,10 @@ long do_fork(unsigned long clone_flags,
clone_flags |= CLONE_PTRACE;
}
- p = copy_process(clone_flags, stack_start, regs, stack_size,
+ if (clone_flags & CLONE_EXTFLAGS)
+ clone_flags64 = ((u64) (uintptr_t) parent_tidptr << 32) | clone_flags;
+
+ p = copy_process(clone_flags64, stack_start, regs, stack_size,
child_tidptr, NULL);
/*
* Do this prior waking up the new thread - the thread pointer
WARNING: multiple messages have this Message-ID (diff)
From: Cedric Le Goater <legoater@free.fr>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Pavel Emelianov <xemul@openvz.org>,
Linux Containers <containers@lists.osdl.org>
Subject: [PATCH 2/2] extend clone_flags using parent_tidptr argument
Date: Mon, 04 Feb 2008 18:27:09 +0100 [thread overview]
Message-ID: <47A74AED.1080806@free.fr> (raw)
From: Cedric Le Goater <clg@fr.ibm.com>
We have at least 2 patchsets requiring each a new clone flag and
there it is, we've reached the limit, none are left.
This patch uses the CLONE_DETACHED flag (unused) as a marker to
extend the clone flags through the parent_tidptr argument.
Initially, we thought on using the last bit but it has recently
been taken by CLONE_IO.
Obviously, this hack doesn't work for unshare() for which I don't
see any other solution than to add a new syscall :
long sys_unshare64(unsigned long clone_flags_high,
unsigned long clone_flags_low);
Is this the right path to extend the clone flags ? should we add a
clone64() rather than hack the extending clone() ?
Thanks for any comments !
C.
Signed-off-by: Cedric Le Goater <clg@fr.ibm.com>
---
include/linux/sched.h | 1 +
kernel/fork.c | 14 +++++++++++++-
2 files changed, 14 insertions(+), 1 deletion(-)
Index: 2.6.24-mm1/include/linux/sched.h
===================================================================
--- 2.6.24-mm1.orig/include/linux/sched.h
+++ 2.6.24-mm1/include/linux/sched.h
@@ -28,6 +28,7 @@
#define CLONE_NEWPID 0x20000000 /* New pid namespace */
#define CLONE_NEWNET 0x40000000 /* New network namespace */
#define CLONE_IO 0x80000000 /* Clone io context */
+#define CLONE_EXTFLAGS CLONE_DETACHED /* use parent_tidptr as an extended set of flags */
/*
* Scheduling policies
Index: 2.6.24-mm1/kernel/fork.c
===================================================================
--- 2.6.24-mm1.orig/kernel/fork.c
+++ 2.6.24-mm1/kernel/fork.c
@@ -1012,6 +1012,14 @@ static struct task_struct *copy_process(
struct task_struct *p;
int cgroup_callbacks_done = 0;
+ /*
+ * It is not permitted to specify both CLONE_EXTFLAGS and
+ * CLONE_PARENT_SETTID
+ */
+ if ((clone_flags & (CLONE_EXTFLAGS|CLONE_PARENT_SETTID)) ==
+ (CLONE_EXTFLAGS|CLONE_PARENT_SETTID))
+ return ERR_PTR(-EINVAL);
+
if ((clone_flags & (CLONE_NEWNS|CLONE_FS)) == (CLONE_NEWNS|CLONE_FS))
return ERR_PTR(-EINVAL);
@@ -1455,6 +1463,7 @@ long do_fork(unsigned long clone_flags,
struct task_struct *p;
int trace = 0;
long nr;
+ u64 clone_flags64 = clone_flags;
/*
* We hope to recycle these flags after 2.6.26
@@ -1479,7 +1488,10 @@ long do_fork(unsigned long clone_flags,
clone_flags |= CLONE_PTRACE;
}
- p = copy_process(clone_flags, stack_start, regs, stack_size,
+ if (clone_flags & CLONE_EXTFLAGS)
+ clone_flags64 = ((u64) (uintptr_t) parent_tidptr << 32) | clone_flags;
+
+ p = copy_process(clone_flags64, stack_start, regs, stack_size,
child_tidptr, NULL);
/*
* Do this prior waking up the new thread - the thread pointer
next reply other threads:[~2008-02-04 17:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-04 17:27 Cedric Le Goater [this message]
2008-02-04 17:27 ` [PATCH 2/2] extend clone_flags using parent_tidptr argument Cedric Le Goater
2008-02-04 20:24 ` Serge E. Hallyn
2008-02-04 21:38 ` Andrew Morton
2008-02-05 8:20 ` Cedric Le Goater
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=47A74AED.1080806@free.fr \
--to=legoater-ganu6spqydw@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.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.