* [PATCH 1/3] user namespaces: introduce user_struct->user_namespace relationship
@ 2008-08-02 0:54 Serge E. Hallyn
[not found] ` <20080802005405.GA1269-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
0 siblings, 1 reply; 13+ messages in thread
From: Serge E. Hallyn @ 2008-08-02 0:54 UTC (permalink / raw)
To: Linux Containers
Here's just a repost given some of the feedback from the last round.
Question: do we really want a patch renaming kernel/user_namespace.c,
include/linux/user_namespace.c, and struct user_namespace all to
user_ns? I'm fine with it if we are, but it'll be a pretty big
patch with no other effect.
-serge
From aa31de8d2e62d1903f8dfaa97e71cca7560632ce Mon Sep 17 00:00:00 2001
From: Serge Hallyn <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Date: Tue, 22 Jul 2008 13:31:37 -0500
Subject: [PATCH 1/3] user namespaces: introduce user_struct->user_namespace relationship
When a task does clone(CLONE_NEWNS), the task's user is the 'creator' of the
new user_namespace, and the user_namespace is tacked onto a list of those
created by this user.
Changelog:
Aug 1: renamed user->user_namespace to user_ns, as the next
patch did anyway.
Aug 1: move put_user_ns call in one free_user() definition
to move it outside the lock in free_user. put_user_ns
calls free_user on the user_ns->creator, which in
turn would grab the lock again.
Signed-off-by: Serge Hallyn <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
---
include/linux/sched.h | 1 +
include/linux/user_namespace.h | 1 +
kernel/user.c | 7 +++++++
kernel/user_namespace.c | 20 +++++++++++---------
4 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 5270d44..0149e77 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -600,6 +600,7 @@ struct user_struct {
/* Hash table maintenance information */
struct hlist_node uidhash_node;
uid_t uid;
+ struct user_namespace *user_ns;
#ifdef CONFIG_USER_SCHED
struct task_group *tg;
diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
index b5f41d4..f9477c3 100644
--- a/include/linux/user_namespace.h
+++ b/include/linux/user_namespace.h
@@ -13,6 +13,7 @@ struct user_namespace {
struct kref kref;
struct hlist_head uidhash_table[UIDHASH_SZ];
struct user_struct *root_user;
+ struct user_struct *creator;
};
extern struct user_namespace init_user_ns;
diff --git a/kernel/user.c b/kernel/user.c
index 865ecf5..aedb3a1 100644
--- a/kernel/user.c
+++ b/kernel/user.c
@@ -22,6 +22,7 @@ struct user_namespace init_user_ns = {
.refcount = ATOMIC_INIT(2),
},
.root_user = &root_user,
+ .creator = &root_user,
};
EXPORT_SYMBOL_GPL(init_user_ns);
@@ -53,6 +54,7 @@ struct user_struct root_user = {
.files = ATOMIC_INIT(0),
.sigpending = ATOMIC_INIT(0),
.locked_shm = 0,
+ .user_ns = &init_user_ns,
#ifdef CONFIG_USER_SCHED
.tg = &init_task_group,
#endif
@@ -325,6 +327,7 @@ static inline void free_user(struct user_struct *up, unsigned long flags)
atomic_inc(&up->__count);
spin_unlock_irqrestore(&uidhash_lock, flags);
+ put_user_ns(up->user_ns);
INIT_WORK(&up->work, remove_user_sysfs_dir);
schedule_work(&up->work);
}
@@ -347,6 +350,7 @@ static inline void free_user(struct user_struct *up, unsigned long flags)
sched_destroy_user(up);
key_put(up->uid_keyring);
key_put(up->session_keyring);
+ put_user_ns(up->user_ns);
kmem_cache_free(uid_cachep, up);
}
@@ -409,6 +413,8 @@ struct user_struct *alloc_uid(struct user_namespace *ns, uid_t uid)
if (sched_create_user(new) < 0)
goto out_free_user;
+ new->user_ns = get_user_ns(ns);
+
if (uids_user_create(new))
goto out_destoy_sched;
@@ -441,6 +447,7 @@ struct user_struct *alloc_uid(struct user_namespace *ns, uid_t uid)
out_destoy_sched:
sched_destroy_user(new);
+ put_user_ns(new->user_ns);
out_free_user:
kmem_cache_free(uid_cachep, new);
out_unlock:
diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
index a9ab059..e8db443 100644
--- a/kernel/user_namespace.c
+++ b/kernel/user_namespace.c
@@ -19,7 +19,6 @@
static struct user_namespace *clone_user_ns(struct user_namespace *old_ns)
{
struct user_namespace *ns;
- struct user_struct *new_user;
int n;
ns = kmalloc(sizeof(struct user_namespace), GFP_KERNEL);
@@ -38,15 +37,17 @@ static struct user_namespace *clone_user_ns(struct user_namespace *old_ns)
return ERR_PTR(-ENOMEM);
}
- /* Reset current->user with a new one */
- new_user = alloc_uid(ns, current->uid);
- if (!new_user) {
- free_uid(ns->root_user);
- kfree(ns);
- return ERR_PTR(-ENOMEM);
- }
+ /* pin the creating user */
+ ns->creator = current->user;
+ atomic_inc(&ns->creator->__count);
+
+ /*
+ * The alloc_uid() incremented the userns refcount,
+ * so drop it again
+ */
+ put_user_ns(ns);
- switch_uid(new_user);
+ switch_uid(ns->root_user);
return ns;
}
@@ -72,6 +73,7 @@ void free_user_ns(struct kref *kref)
ns = container_of(kref, struct user_namespace, kref);
release_uids(ns);
+ free_uid(ns->creator);
kfree(ns);
}
EXPORT_SYMBOL(free_user_ns);
--
1.5.4.3
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH 1/3] user namespaces: introduce user_struct->user_namespace relationship
@ 2008-08-26 18:53 Serge E. Hallyn
2008-08-28 0:07 ` Andrew Morton
0 siblings, 1 reply; 13+ messages in thread
From: Serge E. Hallyn @ 2008-08-26 18:53 UTC (permalink / raw)
To: lkml; +Cc: Eric W. Biederman, Andrew Morton
The following 3 patches are a small start to the long task of fleshing
out user namespace support. These three patches just clear up the
relationship of struct user_struct to struct user_namespace (patch 1),
fix up the refcounting (patch 2), and complete the action of switching
users when cloning a new user_namespace (patch 3).
Patch 1:
When a task does clone(CLONE_NEWNS), the task's user is the 'creator' of the
new user_namespace, and the user_namespace is tacked onto a list of those
created by this user.
Changelog:
Aug 25: make free_user not inlined as it's not trivial. (Eric
Biederman suggestion)
Aug 1: renamed user->user_namespace to user_ns, as the next
patch did anyway.
Aug 1: move put_user_ns call in one free_user() definition
to move it outside the lock in free_user. put_user_ns
calls free_user on the user_ns->creator, which in
turn would grab the lock again.
Signed-off-by: Serge Hallyn <serue@us.ibm.com>
---
include/linux/sched.h | 1 +
include/linux/user_namespace.h | 1 +
kernel/user.c | 11 +++++++++--
kernel/user_namespace.c | 20 +++++++++++---------
4 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index cfb0d87..9bebf95 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -601,6 +601,7 @@ struct user_struct {
/* Hash table maintenance information */
struct hlist_node uidhash_node;
uid_t uid;
+ struct user_namespace *user_ns;
#ifdef CONFIG_USER_SCHED
struct task_group *tg;
diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
index b5f41d4..f9477c3 100644
--- a/include/linux/user_namespace.h
+++ b/include/linux/user_namespace.h
@@ -13,6 +13,7 @@ struct user_namespace {
struct kref kref;
struct hlist_head uidhash_table[UIDHASH_SZ];
struct user_struct *root_user;
+ struct user_struct *creator;
};
extern struct user_namespace init_user_ns;
diff --git a/kernel/user.c b/kernel/user.c
index 865ecf5..ee841c7 100644
--- a/kernel/user.c
+++ b/kernel/user.c
@@ -22,6 +22,7 @@ struct user_namespace init_user_ns = {
.refcount = ATOMIC_INIT(2),
},
.root_user = &root_user,
+ .creator = &root_user,
};
EXPORT_SYMBOL_GPL(init_user_ns);
@@ -53,6 +54,7 @@ struct user_struct root_user = {
.files = ATOMIC_INIT(0),
.sigpending = ATOMIC_INIT(0),
.locked_shm = 0,
+ .user_ns = &init_user_ns,
#ifdef CONFIG_USER_SCHED
.tg = &init_task_group,
#endif
@@ -319,12 +321,13 @@ done:
* IRQ state (as stored in flags) is restored and uidhash_lock released
* upon function exit.
*/
-static inline void free_user(struct user_struct *up, unsigned long flags)
+static void free_user(struct user_struct *up, unsigned long flags)
{
/* restore back the count */
atomic_inc(&up->__count);
spin_unlock_irqrestore(&uidhash_lock, flags);
+ put_user_ns(up->user_ns);
INIT_WORK(&up->work, remove_user_sysfs_dir);
schedule_work(&up->work);
}
@@ -340,13 +343,14 @@ static inline void uids_mutex_unlock(void) { }
* IRQ state (as stored in flags) is restored and uidhash_lock released
* upon function exit.
*/
-static inline void free_user(struct user_struct *up, unsigned long flags)
+static void free_user(struct user_struct *up, unsigned long flags)
{
uid_hash_remove(up);
spin_unlock_irqrestore(&uidhash_lock, flags);
sched_destroy_user(up);
key_put(up->uid_keyring);
key_put(up->session_keyring);
+ put_user_ns(up->user_ns);
kmem_cache_free(uid_cachep, up);
}
@@ -409,6 +413,8 @@ struct user_struct *alloc_uid(struct user_namespace *ns, uid_t uid)
if (sched_create_user(new) < 0)
goto out_free_user;
+ new->user_ns = get_user_ns(ns);
+
if (uids_user_create(new))
goto out_destoy_sched;
@@ -441,6 +447,7 @@ struct user_struct *alloc_uid(struct user_namespace *ns, uid_t uid)
out_destoy_sched:
sched_destroy_user(new);
+ put_user_ns(new->user_ns);
out_free_user:
kmem_cache_free(uid_cachep, new);
out_unlock:
diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
index 532858f..f9f7ad7 100644
--- a/kernel/user_namespace.c
+++ b/kernel/user_namespace.c
@@ -18,7 +18,6 @@
static struct user_namespace *clone_user_ns(struct user_namespace *old_ns)
{
struct user_namespace *ns;
- struct user_struct *new_user;
int n;
ns = kmalloc(sizeof(struct user_namespace), GFP_KERNEL);
@@ -37,15 +36,17 @@ static struct user_namespace *clone_user_ns(struct user_namespace *old_ns)
return ERR_PTR(-ENOMEM);
}
- /* Reset current->user with a new one */
- new_user = alloc_uid(ns, current->uid);
- if (!new_user) {
- free_uid(ns->root_user);
- kfree(ns);
- return ERR_PTR(-ENOMEM);
- }
+ /* pin the creating user */
+ ns->creator = current->user;
+ atomic_inc(&ns->creator->__count);
+
+ /*
+ * The alloc_uid() incremented the userns refcount,
+ * so drop it again
+ */
+ put_user_ns(ns);
- switch_uid(new_user);
+ switch_uid(ns->root_user);
return ns;
}
@@ -71,6 +72,7 @@ void free_user_ns(struct kref *kref)
ns = container_of(kref, struct user_namespace, kref);
release_uids(ns);
+ free_uid(ns->creator);
kfree(ns);
}
EXPORT_SYMBOL(free_user_ns);
--
1.5.4.3
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [PATCH 1/3] user namespaces: introduce user_struct->user_namespace relationship
2008-08-26 18:53 [PATCH 1/3] user namespaces: introduce user_struct->user_namespace relationship Serge E. Hallyn
@ 2008-08-28 0:07 ` Andrew Morton
2008-08-28 0:52 ` Serge E. Hallyn
0 siblings, 1 reply; 13+ messages in thread
From: Andrew Morton @ 2008-08-28 0:07 UTC (permalink / raw)
To: Serge E. Hallyn; +Cc: linux-kernel, ebiederm
On Tue, 26 Aug 2008 13:53:41 -0500
"Serge E. Hallyn" <serue@us.ibm.com> wrote:
> When a task does clone(CLONE_NEWNS), the task's user is the 'creator' of the
> new user_namespace, and the user_namespace is tacked onto a list of those
> created by this user.
>
> Changelog:
> Aug 25: make free_user not inlined as it's not trivial. (Eric
> Biederman suggestion)
> Aug 1: renamed user->user_namespace to user_ns, as the next
> patch did anyway.
> Aug 1: move put_user_ns call in one free_user() definition
> to move it outside the lock in free_user. put_user_ns
> calls free_user on the user_ns->creator, which in
> turn would grab the lock again.
>
> Signed-off-by: Serge Hallyn <serue@us.ibm.com>
> ---
> include/linux/sched.h | 1 +
> include/linux/user_namespace.h | 1 +
> kernel/user.c | 11 +++++++++--
> kernel/user_namespace.c | 20 +++++++++++---------
The credentials code in linux-next is changing the same code which
you're changing, in more-than-trivially-textual ways.
I'd suggest a dhowells cc on these changes, as he's also working
in this area, and as you touch the keyring code a bit.
And, of course, please remove that almost-always-wrong
extern-declaration-in-C which checkpatch told you about. init_groups
is already declared in include/linux/init_task.h anyway...
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/3] user namespaces: introduce user_struct->user_namespace relationship
2008-08-28 0:07 ` Andrew Morton
@ 2008-08-28 0:52 ` Serge E. Hallyn
0 siblings, 0 replies; 13+ messages in thread
From: Serge E. Hallyn @ 2008-08-28 0:52 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, ebiederm, David Howells
Quoting Andrew Morton (akpm@linux-foundation.org):
> On Tue, 26 Aug 2008 13:53:41 -0500
> "Serge E. Hallyn" <serue@us.ibm.com> wrote:
>
> > When a task does clone(CLONE_NEWNS), the task's user is the 'creator' of the
> > new user_namespace, and the user_namespace is tacked onto a list of those
> > created by this user.
> >
> > Changelog:
> > Aug 25: make free_user not inlined as it's not trivial. (Eric
> > Biederman suggestion)
> > Aug 1: renamed user->user_namespace to user_ns, as the next
> > patch did anyway.
> > Aug 1: move put_user_ns call in one free_user() definition
> > to move it outside the lock in free_user. put_user_ns
> > calls free_user on the user_ns->creator, which in
> > turn would grab the lock again.
> >
> > Signed-off-by: Serge Hallyn <serue@us.ibm.com>
> > ---
> > include/linux/sched.h | 1 +
> > include/linux/user_namespace.h | 1 +
> > kernel/user.c | 11 +++++++++--
> > kernel/user_namespace.c | 20 +++++++++++---------
>
> The credentials code in linux-next is changing the same code which
> you're changing, in more-than-trivially-textual ways.
Ok, I knew that was coming eventually. I'll rebase.
> I'd suggest a dhowells cc on these changes, as he's also working
> in this area, and as you touch the keyring code a bit.
Ok.
> And, of course, please remove that almost-always-wrong
> extern-declaration-in-C which checkpatch told you about. init_groups
> is already declared in include/linux/init_task.h anyway...
Sorry, will do with the rebase.
Thanks, Andrew.
-serge
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH 1/3] user namespaces: introduce user_struct->user_namespace relationship
@ 2008-10-04 1:36 Serge E. Hallyn
2008-10-05 21:50 ` James Morris
0 siblings, 1 reply; 13+ messages in thread
From: Serge E. Hallyn @ 2008-10-04 1:36 UTC (permalink / raw)
To: James Morris; +Cc: David Howells, Andrew Morton, Linux Containers, lkml
Hi James,
here are 3 patches to fix up the user namespaces a bit in preparation
for real userns work to begin. Andrew had suggested that these be
rebased on top of your -next tree because they will conflict with
the credentials work. But it looks like much of the credentials stuff
isn't in your next branch. If you'd prefer that I port these to
creds-next, please let me know. I'll have to do it eventually :)
Yet-another-ltp-test shows no regressions.
thanks,
-serge
Subject: [PATCH] user namespaces: introduce user_struct->user_namespace relationship
From: Serge Hallyn <serue@us.ibm.com>
Date: 1223047324 -0400
When a task does clone(CLONE_NEWNS), the task's user is the 'creator' of the
new user_namespace, and the user_namespace is tacked onto a list of those
created by this user.
Changelog:
Aug 25: make free_user not inlined as it's not trivial. (Eric
Biederman suggestion)
Aug 1: renamed user->user_namespace to user_ns, as the next
patch did anyway.
Aug 1: move put_user_ns call in one free_user() definition
to move it outside the lock in free_user. put_user_ns
calls free_user on the user_ns->creator, which in
turn would grab the lock again.
Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
---
include/linux/sched.h | 1 +
include/linux/user_namespace.h | 1 +
kernel/user.c | 11 +++++++++--
kernel/user_namespace.c | 20 +++++++++++---------
4 files changed, 22 insertions(+), 11 deletions(-)
02b90654b57d650819ff3265161d95f4cf91cc94
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 3d9120c..1cf17d9 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -601,6 +601,7 @@ struct user_struct {
/* Hash table maintenance information */
struct hlist_node uidhash_node;
uid_t uid;
+ struct user_namespace *user_ns;
#ifdef CONFIG_USER_SCHED
struct task_group *tg;
diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
index b5f41d4..f9477c3 100644
--- a/include/linux/user_namespace.h
+++ b/include/linux/user_namespace.h
@@ -13,6 +13,7 @@ struct user_namespace {
struct kref kref;
struct hlist_head uidhash_table[UIDHASH_SZ];
struct user_struct *root_user;
+ struct user_struct *creator;
};
extern struct user_namespace init_user_ns;
diff --git a/kernel/user.c b/kernel/user.c
index 865ecf5..ee841c7 100644
--- a/kernel/user.c
+++ b/kernel/user.c
@@ -22,6 +22,7 @@ struct user_namespace init_user_ns = {
.refcount = ATOMIC_INIT(2),
},
.root_user = &root_user,
+ .creator = &root_user,
};
EXPORT_SYMBOL_GPL(init_user_ns);
@@ -53,6 +54,7 @@ struct user_struct root_user = {
.files = ATOMIC_INIT(0),
.sigpending = ATOMIC_INIT(0),
.locked_shm = 0,
+ .user_ns = &init_user_ns,
#ifdef CONFIG_USER_SCHED
.tg = &init_task_group,
#endif
@@ -319,12 +321,13 @@ done:
* IRQ state (as stored in flags) is restored and uidhash_lock released
* upon function exit.
*/
-static inline void free_user(struct user_struct *up, unsigned long flags)
+static void free_user(struct user_struct *up, unsigned long flags)
{
/* restore back the count */
atomic_inc(&up->__count);
spin_unlock_irqrestore(&uidhash_lock, flags);
+ put_user_ns(up->user_ns);
INIT_WORK(&up->work, remove_user_sysfs_dir);
schedule_work(&up->work);
}
@@ -340,13 +343,14 @@ static inline void uids_mutex_unlock(voi
* IRQ state (as stored in flags) is restored and uidhash_lock released
* upon function exit.
*/
-static inline void free_user(struct user_struct *up, unsigned long flags)
+static void free_user(struct user_struct *up, unsigned long flags)
{
uid_hash_remove(up);
spin_unlock_irqrestore(&uidhash_lock, flags);
sched_destroy_user(up);
key_put(up->uid_keyring);
key_put(up->session_keyring);
+ put_user_ns(up->user_ns);
kmem_cache_free(uid_cachep, up);
}
@@ -409,6 +413,8 @@ struct user_struct *alloc_uid(struct use
if (sched_create_user(new) < 0)
goto out_free_user;
+ new->user_ns = get_user_ns(ns);
+
if (uids_user_create(new))
goto out_destoy_sched;
@@ -441,6 +447,7 @@ struct user_struct *alloc_uid(struct use
out_destoy_sched:
sched_destroy_user(new);
+ put_user_ns(new->user_ns);
out_free_user:
kmem_cache_free(uid_cachep, new);
out_unlock:
diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
index 532858f..f9f7ad7 100644
--- a/kernel/user_namespace.c
+++ b/kernel/user_namespace.c
@@ -18,7 +18,6 @@
static struct user_namespace *clone_user_ns(struct user_namespace *old_ns)
{
struct user_namespace *ns;
- struct user_struct *new_user;
int n;
ns = kmalloc(sizeof(struct user_namespace), GFP_KERNEL);
@@ -37,15 +36,17 @@ static struct user_namespace *clone_user
return ERR_PTR(-ENOMEM);
}
- /* Reset current->user with a new one */
- new_user = alloc_uid(ns, current->uid);
- if (!new_user) {
- free_uid(ns->root_user);
- kfree(ns);
- return ERR_PTR(-ENOMEM);
- }
+ /* pin the creating user */
+ ns->creator = current->user;
+ atomic_inc(&ns->creator->__count);
+
+ /*
+ * The alloc_uid() incremented the userns refcount,
+ * so drop it again
+ */
+ put_user_ns(ns);
- switch_uid(new_user);
+ switch_uid(ns->root_user);
return ns;
}
@@ -71,6 +72,7 @@ void free_user_ns(struct kref *kref)
ns = container_of(kref, struct user_namespace, kref);
release_uids(ns);
+ free_uid(ns->creator);
kfree(ns);
}
EXPORT_SYMBOL(free_user_ns);
--
1.1.6
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [PATCH 1/3] user namespaces: introduce user_struct->user_namespace relationship
2008-10-04 1:36 Serge E. Hallyn
@ 2008-10-05 21:50 ` James Morris
2008-10-06 14:11 ` Serge E. Hallyn
0 siblings, 1 reply; 13+ messages in thread
From: James Morris @ 2008-10-05 21:50 UTC (permalink / raw)
To: Serge E. Hallyn; +Cc: David Howells, Andrew Morton, Linux Containers, lkml
On Fri, 3 Oct 2008, Serge E. Hallyn wrote:
> Hi James,
>
> here are 3 patches to fix up the user namespaces a bit in preparation
> for real userns work to begin. Andrew had suggested that these be
> rebased on top of your -next tree because they will conflict with
> the credentials work. But it looks like much of the credentials stuff
> isn't in your next branch. If you'd prefer that I port these to
> creds-next, please let me know. I'll have to do it eventually :)
creds-next is dead.
Code ready for the next merge window is in the 'next' branch, while the
current creds code is in the 'creds-next-subsys' branch, which hasn't been
picked up in linux-next yet because of LPC and sfr's vacation.
When do you expect these patches to be sent upstream? Are they ready now
as an incremental change for 2.6.27?
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/3] user namespaces: introduce user_struct->user_namespace relationship
2008-10-05 21:50 ` James Morris
@ 2008-10-06 14:11 ` Serge E. Hallyn
2008-10-06 21:50 ` James Morris
0 siblings, 1 reply; 13+ messages in thread
From: Serge E. Hallyn @ 2008-10-06 14:11 UTC (permalink / raw)
To: James Morris; +Cc: David Howells, Andrew Morton, Linux Containers, lkml
Quoting James Morris (jmorris@namei.org):
> On Fri, 3 Oct 2008, Serge E. Hallyn wrote:
>
> > Hi James,
> >
> > here are 3 patches to fix up the user namespaces a bit in preparation
> > for real userns work to begin. Andrew had suggested that these be
> > rebased on top of your -next tree because they will conflict with
> > the credentials work. But it looks like much of the credentials stuff
> > isn't in your next branch. If you'd prefer that I port these to
> > creds-next, please let me know. I'll have to do it eventually :)
>
> creds-next is dead.
>
> Code ready for the next merge window is in the 'next' branch, while the
> current creds code is in the 'creds-next-subsys' branch, which hasn't been
> picked up in linux-next yet because of LPC and sfr's vacation.
>
> When do you expect these patches to be sent upstream? Are they ready now
> as an incremental change for 2.6.27?
Oh I'm not trying to get them into 2.6.28, I'm just trying to get them
more widely tested, hopefully aiming for 2.6.29. They have been stable
in all of my tests, and the last patch fixes a real (behavioral - not
oops-inducing) bug in the current code, but I'm trying to figure out
which path they should take.
thanks,
-serge
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/3] user namespaces: introduce user_struct->user_namespace relationship
2008-10-06 14:11 ` Serge E. Hallyn
@ 2008-10-06 21:50 ` James Morris
2008-10-07 17:05 ` Serge E. Hallyn
0 siblings, 1 reply; 13+ messages in thread
From: James Morris @ 2008-10-06 21:50 UTC (permalink / raw)
To: Serge E. Hallyn; +Cc: David Howells, Andrew Morton, Linux Containers, lkml
On Mon, 6 Oct 2008, Serge E. Hallyn wrote:
> Quoting James Morris (jmorris@namei.org):
> > On Fri, 3 Oct 2008, Serge E. Hallyn wrote:
> >
> > > Hi James,
> > >
> > > here are 3 patches to fix up the user namespaces a bit in preparation
> > > for real userns work to begin. Andrew had suggested that these be
> > > rebased on top of your -next tree because they will conflict with
> > > the credentials work. But it looks like much of the credentials stuff
> > > isn't in your next branch. If you'd prefer that I port these to
> > > creds-next, please let me know. I'll have to do it eventually :)
> >
> > creds-next is dead.
> >
> > Code ready for the next merge window is in the 'next' branch, while the
> > current creds code is in the 'creds-next-subsys' branch, which hasn't been
> > picked up in linux-next yet because of LPC and sfr's vacation.
> >
> > When do you expect these patches to be sent upstream? Are they ready now
> > as an incremental change for 2.6.27?
>
> Oh I'm not trying to get them into 2.6.28, I'm just trying to get them
> more widely tested, hopefully aiming for 2.6.29. They have been stable
> in all of my tests, and the last patch fixes a real (behavioral - not
> oops-inducing) bug in the current code, but I'm trying to figure out
> which path they should take.
I suggest feeding them into linux-next directly until you want them merged
with another tree. Are there known clashes with the creds work? If so,
the fixups could be carried in linux-next, or generate them against
creds-next-subsys for inclusion after that.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/3] user namespaces: introduce user_struct->user_namespace relationship
2008-10-06 21:50 ` James Morris
@ 2008-10-07 17:05 ` Serge E. Hallyn
[not found] ` <20081007170539.GA525-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
0 siblings, 1 reply; 13+ messages in thread
From: Serge E. Hallyn @ 2008-10-07 17:05 UTC (permalink / raw)
To: James Morris; +Cc: David Howells, Andrew Morton, Linux Containers, lkml
Quoting James Morris (jmorris@namei.org):
> On Mon, 6 Oct 2008, Serge E. Hallyn wrote:
>
> > Quoting James Morris (jmorris@namei.org):
> > > On Fri, 3 Oct 2008, Serge E. Hallyn wrote:
> > >
> > > > Hi James,
> > > >
> > > > here are 3 patches to fix up the user namespaces a bit in preparation
> > > > for real userns work to begin. Andrew had suggested that these be
> > > > rebased on top of your -next tree because they will conflict with
> > > > the credentials work. But it looks like much of the credentials stuff
> > > > isn't in your next branch. If you'd prefer that I port these to
> > > > creds-next, please let me know. I'll have to do it eventually :)
> > >
> > > creds-next is dead.
> > >
> > > Code ready for the next merge window is in the 'next' branch, while the
> > > current creds code is in the 'creds-next-subsys' branch, which hasn't been
> > > picked up in linux-next yet because of LPC and sfr's vacation.
> > >
> > > When do you expect these patches to be sent upstream? Are they ready now
> > > as an incremental change for 2.6.27?
> >
> > Oh I'm not trying to get them into 2.6.28, I'm just trying to get them
> > more widely tested, hopefully aiming for 2.6.29. They have been stable
> > in all of my tests, and the last patch fixes a real (behavioral - not
> > oops-inducing) bug in the current code, but I'm trying to figure out
> > which path they should take.
>
> I suggest feeding them into linux-next directly until you want them merged
> with another tree. Are there known clashes with the creds work? If so,
Certainly with the overall creds work. I haven't looked in
creds-next-subsys yet to see if it conflicts. I'll go ahead and port
later this week or early next.
> the fixups could be carried in linux-next, or generate them against
> creds-next-subsys for inclusion after that.
creds-next-subsys is not yet feeding into linux-next, right? So I
should wait until they hit linux-next?
(It makes more sense for me to port userns on top of creds than for
David to port creds on top of my patches anyway. I'm actually a bit
afraid that my refcounting will be complicated by struct creds, but
we'll see)
thanks,
-serge
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2008-10-07 21:09 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-08-02 0:54 [PATCH 1/3] user namespaces: introduce user_struct->user_namespace relationship Serge E. Hallyn
[not found] ` <20080802005405.GA1269-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-08-02 0:54 ` [PATCH 2/3] user namespaces: move user_ns from nsproxy into user struct Serge E. Hallyn
2008-08-02 0:54 ` [PATCH 3/3] user namespaces: enforce user namespaces for file permission Serge E. Hallyn
-- strict thread matches above, loose matches on Subject: below --
2008-08-26 18:53 [PATCH 1/3] user namespaces: introduce user_struct->user_namespace relationship Serge E. Hallyn
2008-08-28 0:07 ` Andrew Morton
2008-08-28 0:52 ` Serge E. Hallyn
2008-10-04 1:36 Serge E. Hallyn
2008-10-05 21:50 ` James Morris
2008-10-06 14:11 ` Serge E. Hallyn
2008-10-06 21:50 ` James Morris
2008-10-07 17:05 ` Serge E. Hallyn
[not found] ` <20081007170539.GA525-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-10-07 21:08 ` James Morris
2008-10-07 21:08 ` James Morris
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.