user namespaces: introduce user_struct->user_namespace relationship

PATCH In review Serge E. Hallyn 2 participants 8 messages Oct 4, 2008 – Oct 7, 2008

Subsystems (5)

MM core Scheduler Security (LSM) exec and binfmt +1 more subsystems

lore

Share & tools

lore

Serge E. Hallyn

author

2008-10-04 01:36 UTC #0 lore raw

PATCH 1/3 user namespaces: introduce user_struct->user_namespace relationship

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 <[email protected]>
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 <[email protected]>

---

 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

include/linux/sched.h +1 -0

index 3d9120c..1cf17d9 100644
@@ -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;

include/linux/user_namespace.h +1 -0

index b5f41d4..f9477c3 100644
@@ -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;

kernel/user.c +9 -2

index 865ecf5..ee841c7 100644
@@ -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:

kernel/user_namespace.c +11 -9

index 532858f..f9f7ad7 100644
@@ -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);

Signature · 1 line

1.1.6

Serge E. Hallyn

author

2008-10-04 01:37 UTC #1 lore raw

PATCH 2/3 user namespaces: move user_ns from nsproxy into user struct

When we get the sysfs support needed to support fair user scheduling along with user namespaces, then we will need to be able to get the user namespace from the user struct.

So we need the user_ns to be a part of struct user. Once we can access it from tsk->user, we no longer have a use for tsk->nsproxy->user_ns.

When a user_namespace is created, the user which created it is marked as its 'creator'. The user_namespace pins the creator. Each userid in a user_ns pins the user_ns. This keeps refcounting nice and simple.

At the same time, this patch simplifies the refcounting. The current user and userns locking works as follows:

The task pins the user struct.

The task pins the nsproxy, the nsproxy pins the user_ns.

When a new user_ns is created, it creates a root user for it, and pins it. When the nsproxy releases the user_ns, the userns tries to release all its user structs.

So you see that the refcounting "works" for now, but only because the nsproxy (and therefore usr_ns) and user structs will be freed at the same time - when the last task using them is released.

Now we need to put the user_ns in the struct user. You can see that will mess up the refcounting.

Fortunately, once the user_ns is available from tsk->user, we don't need it in nsproxy.

So here is how the refcounting *should* be done:

The task pins the user struct.

The user struct pins its user namespace.

The user namespace pins the struct user which created it.

A user namespace now doesn't need to release its userids, because it is only released when its last user disappears.

This patch makes those changes.

Signed-off-by Serge Hallyn <[email protected]>

---

 include/linux/init_task.h      |    1 -
 include/linux/key.h            |    3 +++
 include/linux/nsproxy.h        |    1 -
 include/linux/sched.h          |    1 +
 include/linux/user_namespace.h |   10 ++++------
 kernel/fork.c                  |    3 +--
 kernel/nsproxy.c               |   10 ++--------
 kernel/sys.c                   |    4 ++--
 kernel/user.c                  |   42 ++++++++++------------------------------
 kernel/user_namespace.c        |   36 ++++++++++------------------------
 security/keys/process_keys.c   |    7 ++++++-
 11 files changed, 39 insertions(+), 79 deletions(-)

678772929a58271cb5daf44b973b2e69d7ac7d5d

include/linux/init_task.h +0 -1

index 021d8e7..550058b 100644
@@ -57,7 +57,6 @@ extern struct nsproxy init_nsproxy;
 	.mnt_ns		= NULL,						\
 	INIT_NET_NS(net_ns)                                             \
 	INIT_IPC_NS(ipc_ns)						\
-	.user_ns	= &init_user_ns,				\
 }
 
 #define INIT_SIGHAND(sighand) {						\

include/linux/key.h +3 -0

index c45c962..861a383 100644
@@ -277,6 +277,8 @@ extern ctl_table key_sysctls[];
  * the userspace interface
  */
 extern void switch_uid_keyring(struct user_struct *new_user);
+extern void switch_uid_keyring_task(struct task_struct *tsk,
+				struct user_struct *new_user);
 extern int copy_keys(unsigned long clone_flags, struct task_struct *tsk);
 extern int copy_thread_group_keys(struct task_struct *tsk);
 extern void exit_keys(struct task_struct *tsk);

@@ -305,6 +307,7 @@ extern void key_init(void);
 #define key_ref_to_ptr(k)		({ NULL; })
 #define is_key_possessed(k)		0
 #define switch_uid_keyring(u)		do { } while(0)
+#define switch_uid_keyring_task(t, u)	do { } while(0)
 #define __install_session_keyring(t, k)	({ NULL; })
 #define copy_keys(f,t)			0
 #define copy_thread_group_keys(t)	0

include/linux/nsproxy.h +0 -1

index c8a768e..afad7de 100644
@@ -27,7 +27,6 @@ struct nsproxy {
 	struct ipc_namespace *ipc_ns;
 	struct mnt_namespace *mnt_ns;
 	struct pid_namespace *pid_ns;
-	struct user_namespace *user_ns;
 	struct net 	     *net_ns;
 };
 extern struct nsproxy init_nsproxy;

include/linux/sched.h +1 -0

index 1cf17d9..edf086f 100644
@@ -1720,6 +1720,7 @@ static inline struct user_struct *get_ui
 }
 extern void free_uid(struct user_struct *);
 extern void switch_uid(struct user_struct *);
+extern void task_switch_uid(struct task_struct *tsk, struct user_struct *);
 extern void release_uids(struct user_namespace *ns);
 
 #include <asm/current.h>

include/linux/user_namespace.h +4 -6

index f9477c3..1b4959d 100644
@@ -27,8 +27,7 @@ static inline struct user_namespace *get
 	return ns;
 }
 
-extern struct user_namespace *copy_user_ns(int flags,
-					   struct user_namespace *old_ns);
+extern int create_new_userns(int flags, struct task_struct *tsk);
 extern void free_user_ns(struct kref *kref);
 
 static inline void put_user_ns(struct user_namespace *ns)

@@ -44,13 +43,12 @@ static inline struct user_namespace *get
 	return &init_user_ns;
 }
 
-static inline struct user_namespace *copy_user_ns(int flags,
-						  struct user_namespace *old_ns)
+static inline int create_new_userns(int flags, struct task_struct *tsk)
 {
 	if (flags & CLONE_NEWUSER)
-		return ERR_PTR(-EINVAL);
+		return -EINVAL;
 
-	return old_ns;
+	return 0;
 }
 
 static inline void put_user_ns(struct user_namespace *ns)

kernel/fork.c +1 -2

index 7ce2ebe..b5d4dc5 100644
@@ -941,8 +941,7 @@ static struct task_struct *copy_process(
 	retval = -EAGAIN;
 	if (atomic_read(&p->user->processes) >=
 			p->signal->rlim[RLIMIT_NPROC].rlim_cur) {
-		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_SYS_RESOURCE) &&
-		    p->user != current->nsproxy->user_ns->root_user)
+		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_SYS_RESOURCE))
 			goto bad_fork_free;
 	}

kernel/nsproxy.c +2 -8

index 1d3ef29..766c672 100644
@@ -80,11 +80,9 @@ static struct nsproxy *create_new_namesp
 		goto out_pid;
 	}
 
-	new_nsp->user_ns = copy_user_ns(flags, tsk->nsproxy->user_ns);
-	if (IS_ERR(new_nsp->user_ns)) {
-		err = PTR_ERR(new_nsp->user_ns);
+	err = create_new_userns(flags, tsk);
+	if (err)
 		goto out_user;
-	}
 
 	new_nsp->net_ns = copy_net_ns(flags, tsk->nsproxy->net_ns);
 	if (IS_ERR(new_nsp->net_ns)) {

@@ -95,8 +93,6 @@ static struct nsproxy *create_new_namesp
 	return new_nsp;
 
 out_net:
-	if (new_nsp->user_ns)
-		put_user_ns(new_nsp->user_ns);
 out_user:
 	if (new_nsp->pid_ns)
 		put_pid_ns(new_nsp->pid_ns);

@@ -173,8 +169,6 @@ void free_nsproxy(struct nsproxy *ns)
 		put_ipc_ns(ns->ipc_ns);
 	if (ns->pid_ns)
 		put_pid_ns(ns->pid_ns);
-	if (ns->user_ns)
-		put_user_ns(ns->user_ns);
 	put_net(ns->net_ns);
 	kmem_cache_free(nsproxy_cachep, ns);
 }

kernel/sys.c +2 -2

index 038a7bc..d89ddd9 100644
@@ -553,13 +553,13 @@ static int set_user(uid_t new_ruid, int 
 {
 	struct user_struct *new_user;
 
-	new_user = alloc_uid(current->nsproxy->user_ns, new_ruid);
+	new_user = alloc_uid(current->user->user_ns, new_ruid);
 	if (!new_user)
 		return -EAGAIN;
 
 	if (atomic_read(&new_user->processes) >=
 				current->signal->rlim[RLIMIT_NPROC].rlim_cur &&
-			new_user != current->nsproxy->user_ns->root_user) {
+			!capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN)) {
 		free_uid(new_user);
 		return -EAGAIN;
 	}

kernel/user.c +10 ~~-32~~

74 lines not on this page · raw message

kernel/user_namespace.c +10 ~~-26~~

index f9f7ad7..d59f193 100644
@@ -15,14 +15,17 @@
  * @old_ns: namespace to clone
  * Return NULL on error (failure to kmalloc), new ns otherwise
  */
-static struct user_namespace *clone_user_ns(struct user_namespace *old_ns)
+int create_new_userns(int flags, struct task_struct *tsk)
 {
 	struct user_namespace *ns;
 	int n;
 
+	if (!(flags & CLONE_NEWUSER))
+		return 0;
+
 	ns = kmalloc(sizeof(struct user_namespace), GFP_KERNEL);
 	if (!ns)
-		return ERR_PTR(-ENOMEM);
+		return -ENOMEM;
 
 	kref_init(&ns->kref);

@@ -33,37 +36,19 @@ static struct user_namespace *clone_user
 	ns->root_user = alloc_uid(ns, 0);
 	if (!ns->root_user) {
 		kfree(ns);
-		return ERR_PTR(-ENOMEM);
+		return -ENOMEM;
 	}
 
 	/* pin the creating user */
-	ns->creator = current->user;
+	ns->creator = tsk->user;
 	atomic_inc(&ns->creator->__count);
 
-	/*
-	 * The alloc_uid() incremented the userns refcount,
-	 * so drop it again
-	 */
+	/* alloc_uid() incremented the userns refcount.  drop it again */
 	put_user_ns(ns);
 
-	switch_uid(ns->root_user);
-	return ns;
-}
-
-struct user_namespace * copy_user_ns(int flags, struct user_namespace *old_ns)
-{
-	struct user_namespace *new_ns;
-
-	BUG_ON(!old_ns);
-	get_user_ns(old_ns);
-
-	if (!(flags & CLONE_NEWUSER))
-		return old_ns;
-
-	new_ns = clone_user_ns(old_ns);
+	task_switch_uid(tsk, ns->root_user);
 
-	put_user_ns(old_ns);
-	return new_ns;
+	return 0;
 }
 
 void free_user_ns(struct kref *kref)

@@ -71,7 +56,6 @@ void free_user_ns(struct kref *kref)
 	struct user_namespace *ns;
 
 	ns = container_of(kref, struct user_namespace, kref);
-	release_uids(ns);
 	free_uid(ns->creator);
 	kfree(ns);
 }

security/keys/process_keys.c +6 -1

index 5be6d01..8d1cfb2 100644
@@ -119,7 +119,8 @@ error:
 /*
  * deal with the UID changing
  */
-void switch_uid_keyring(struct user_struct *new_user)
+void switch_uid_keyring_task(struct task_struct *task,
+				struct user_struct *new_user)
 {
 #if 0 /* do nothing for now */
 	struct key *old;

@@ -142,6 +143,10 @@ void switch_uid_keyring(struct user_stru
 
 } /* end switch_uid_keyring() */
 
+void switch_uid_keyring(struct user_struct *new_user)
+{
+	switch_uid_keyring_task(current, new_user);
+}
 /*****************************************************************************/
 /*
  * install a fresh thread keyring, discarding the old one

Signature · 1 line

1.1.6

Serge E. Hallyn

author

2008-10-04 01:37 UTC #2 lore raw

PATCH 3/3 user namespaces: reset task's credentials on CLONE_NEWUSER

In reply to Serge E. Hallyn

Currently, creating a new user namespace does not reset the task's uid or gid. Since generally that is done as root because it requires CAP_SYS_ADMIN, and since the first uid in the new namespace is 0, one usually doesn't notice. However, if one does

capset cap_sys_admin=ep ns_exec
su - hallyn
ns_exec -U /bin/sh
id

then one will see hallyn's userid, and all preexisting groups.

With this patch, cloning a new user namespace will set the task's uid and gid to 0, and reset the group_info to the empty set assigned to init.

Signed-off-by Serge E. Hallyn <[email protected]>

---

 kernel/user_namespace.c |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

4a159b503ed06f6d999b80680538a51ee39d6bd5

kernel/user_namespace.c +12 -0

index d59f193..3fbf520 100644
@@ -9,6 +9,7 @@
 #include <linux/nsproxy.h>
 #include <linux/slab.h>
 #include <linux/user_namespace.h>
+#include <linux/init_task.h>
 
 /*
  * Clone a new ns copying an original user ns, setting refcount to 1

@@ -47,6 +48,17 @@ int create_new_userns(int flags, struct 
 	put_user_ns(ns);
 
 	task_switch_uid(tsk, ns->root_user);
+	tsk->uid = tsk->euid = tsk->suid = tsk->fsuid = 0;
+	tsk->gid = tsk->egid = tsk->sgid = tsk->fsgid = 0;
+
+	/* this can't be safe for unshare, can it?  it's safe
+	 * for fork, though.  I'm tempted to limit clone_newuser to
+	 * fork only */
+	task_lock(tsk);
+	put_group_info(tsk->group_info);
+	tsk->group_info = &init_groups;
+	get_group_info(tsk->group_info);
+	task_unlock(tsk);
 
 	return 0;
 }

Signature · 1 line

1.1.6

James Morris

maintainer

2008-10-05 21:50 UTC #3 lore raw

In reply to Serge E. Hallyn

Quoted 8 lines · Serge E. Hallyn

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

Signature · 2 lines

James Morris
<[email protected]>

Serge E. Hallyn

author

2008-10-06 14:11 UTC #4 lore raw

Quoted 11 lines · James Morris

Quoted 8 lines · Serge E. Hallyn
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 :)

Quoted 8 lines

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

James Morris

maintainer

2008-10-06 21:50 UTC #5 lore raw

Quoted 18 lines · Serge E. Hallyn

Quoted 17 lines · James Morris
Quoted 8 lines · Serge E. Hallyn
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.

Quoted 8 lines

Quoted 2 lines
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.

Signature · 2 lines

James Morris
<[email protected]>

Serge E. Hallyn

author

2008-10-07 17:05 UTC #6 lore raw

Quoted 23 lines · James Morris

Quoted 21 lines · Serge E. Hallyn
Quoted 19 lines · James Morris
Quoted 8 lines · Serge E. Hallyn
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?

Quoted 8 lines

Quoted 5 lines
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.

Quoted 2 lines

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

James Morris

maintainer

2008-10-07 21:08 UTC #7 lore raw

Quoted 4 lines · Serge E. Hallyn

Quoted 2 lines
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?

Correct.

Quoted 1 line

So I should wait until they hit linux-next?

Unless akpm wants to pick up the branch.

Quoted 14 lines

(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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Signature · 2 lines

James Morris
<jmorris-gx6/[email protected]>