OpenVZ Forum - RDF feed
type: channel
items: [RFC][PATCH 0/4] Object creation with a specified id
items: [RFC][PATCH 1/4] Provide a new procfs interface to set next ipc id
items: [RFC][PATCH 2/4] Provide a new procfs interface to set next upid nr(s)
items: [RFC][PATCH 3/4] IPC: use the target ID specified in procfs
items: [RFC][PATCH 4/4] PID: use the target ID specified in procfs
items: Re: [RFC][PATCH 4/4] PID: use the target ID specified in procfs
items: Re: [RFC][PATCH 0/4] Object creation with a specified id

[RFC][PATCH 0/4] Object creation with a specified id
type: item
description: A couple of weeks ago, a discussion has started after Pierre's proposal for a new syscall to change an ipc id (see thread http://lkml.org/lkml/2008/1/29/209). Oren's suggestion was to force an object's id during its creation, rather than 1. create it, 2. change its id. So here is an implementation of what Oren has suggested. 2 new files are defined under /proc/self: . next_ipcid --> next id to use for ipc object creation . next_pids --> next upid nr(s) to use for next task to be forked (see patch #2 for more details). When one of these files (or both of them) is filled, a structure pointed to by the calling task struct is filled with these ids. Then, when the object is created, the id(s) present in that structure are used, instead of the default ones. The patches are against 2.6.25-rc3-mm1, in the following order: [PATCH 1/4] adds the procfs facility for next ipc to be created. [PATCH 2/4] adds the procfs facility for next task to be forked. [PATCH 3/4] makes use of the specified id (if any) to allocate the new IPC object (changes the ipc_addid() path). [PATCH 4/4] uses the specified id(s) (if any) to set the upid nr(s) for a newly allocated process (changes the alloc_pid()/alloc_pidmap() paths). Any comment and/or suggestions are welcome. Cc-ing Pavel and Sukadev, since they are the pid namespace authors. Regards, Nadia -- -- _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Nadia Derbey
date: 2008-03-10T13:50:54-00:00

[RFC][PATCH 1/4] Provide a new procfs interface to set next ipc id
type: item
description: [PATCH 01/04] This patch proposes the procfs facilities needed to feed the id for the next ipc object to be allocated. if an echo XX > /proc/self/next_ipcid is issued, next ipc object to be created will have XX as its id. Signed-off-by: Nadia Derbey <Nadia.Derbey@bull.net> --- fs/proc/base.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++++ include/linux/sched.h | 3 ++ include/linux/sysids.h | 20 ++++++++++++++ kernel/Makefile | 2 - kernel/set_nextid.c | 31 +++++++++++++++++++++++ 5 files changed, 121 insertions(+), 1 deletion(-) Index: linux-2.6.25-rc3-mm1/include/linux/sysids.h =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ linux-2.6.25-rc3-mm1/include/linux/sysids.h 2008-03-10 11:39:10.000000000 +0100 @@ -0,0 +1,20 @@ +/* + * include/linux/sysids.h + * + * Definitions to support object creation with predefined id. + * + */ + +#ifndef _LINUX_SYSIDS_H +#define _LINUX_SYSIDS_H + +#define SYS_ID_IPC 1 + +struct sys_id { + int flag; /* which id should be set */ + int ipc; +}; + +extern int ipc_set_nextid(struct task_struct *, int id); + +#endif /* _LINUX_SYSIDS_H */ Index: linux-2.6.25-rc3-mm1/include/linux/sched.h =================================================================== --- linux-2.6.25-rc3-mm1.orig/include/linux/sched.h 2008-03-10 09:18:46.000000000 +0100 +++ linux-2.6.25-rc3-mm1/include/linux/sched.h 2008-03-10 09:28:30.000000000 +0100 @@ -87,6 +87,7 @@ struct sched_param { #include <linux/task_io_accounting.h> #include <linux/kobject.h> #include <linux/latencytop.h> +#include <linux/sysids.h> #include <asm/processor.h> @@ -1261,6 +1262,8 @@ struct task_struct { int latency_record_count; struct latency_record latency_record[LT_SAVECOUNT]; #endif + /* Id to assign to the next resource to be created */ + struct sys_id *next_id; }; /* Index: linux-2.6.25-rc3-mm1/fs/proc/base.c =================================================================== --- linux-2.6.25-rc3-mm1.orig/fs/pr…
creator: Nadia Derbey
date: 2008-03-10T13:50:55-00:00

[RFC][PATCH 2/4] Provide a new procfs interface to set next upid nr(s)
type: item
description: [PATCH 02/04] This patch proposes the procfs facilities needed to feed the id(s) for the next task to be forked. say n is the number of pids to be provided through procfs: if an echo "n X0 X1 ... X<n-1>" > /proc/self/next_pids is issued, the next task to be forked will have its upid nrs set as follows (say it is forked in a pid ns of level L): level upid nr L ----------> X0 .. L - i ------> Xi .. L - n + 1 --> X<n-1> Then, for levels L-n down to level 0, the pids will be left to the kernel choice. Signed-off-by: Nadia Derbey <Nadia.Derbey@bull.net> --- fs/proc/base.c | 74 ++++++++++++++++++++++++ include/linux/sysids.h | 36 +++++++++++- kernel/set_nextid.c | 147 ++++++++++++++++++++++++++++++++++++++++++++++++- 3 files changed, 254 insertions(+), 3 deletions(-) Index: linux-2.6.25-rc3-mm1/include/linux/sysids.h =================================================================== --- linux-2.6.25-rc3-mm1.orig/include/linux/sysids.h 2008-03-10 11:39:10.000000000 +0100 +++ linux-2.6.25-rc3-mm1/include/linux/sysids.h 2008-03-10 12:49:27.000000000 +0100 @@ -9,12 +9,46 @@ #define _LINUX_SYSIDS_H #define SYS_ID_IPC 1 +#define SYS_ID_PID 2 + +#define NPIDS_SMALL 32 +#define NPIDS_PER_BLOCK ((unsigned int)(PAGE_SIZE / sizeof(pid_t))) + +/* access the pids "array" with this macro */ +#define PID_AT(pi, i) \ + ((pi)->blocks[(i) / NPIDS_PER_BLOCK][(i) % NPIDS_PER_BLOCK]) + + +/* + * The next process to be created is associated to a set of upid nrs: one for + * each pid namespace level that process belongs to. + * upid nrs from level 0 up to level <npids - 1> will be automatically + * allocated. + * upid nr for level npids will be set to blocks[0][0] + * upid nr for level <npids + i> will be set to PID_AT(pids, i); + */ +struct pid_list { + int npids; + pid_t small_block[NPIDS_SMALL]; + int nblocks; + pid_t *blocks[0]; +}; + struct sys_id { int flag; /* which id should be set */ - int ipc; + struct { + int ipc; + struct pid_list *pids; + } ids; }; +#define ipc_id ids.ipc +#define…
creator: Nadia Derbey
date: 2008-03-10T13:50:56-00:00

[RFC][PATCH 3/4] IPC: use the target ID specified in procfs
type: item
description: [PATCH 03/04] This patch makes use of the target id specified by a previous write into /proc/self/next_ipcid as the id to use to allocate the next IPC object. Signed-off-by: Nadia Derbey <Nadia.Derbey@bull.net> --- ipc/util.c | 39 +++++++++++++++++++++++++++++++-------- 1 file changed, 31 insertions(+), 8 deletions(-) Index: linux-2.6.25-rc3-mm1/ipc/util.c =================================================================== --- linux-2.6.25-rc3-mm1.orig/ipc/util.c 2008-03-10 13:10:33.000000000 +0100 +++ linux-2.6.25-rc3-mm1/ipc/util.c 2008-03-10 13:11:24.000000000 +0100 @@ -35,6 +35,7 @@ #include <linux/rwsem.h> #include <linux/memory.h> #include <linux/ipc_namespace.h> +#include <linux/sysids.h> #include <asm/unistd.h> @@ -267,20 +268,42 @@ int ipc_addid(struct ipc_ids* ids, struc if (ids->in_use >= size) return -ENOSPC; - err = idr_get_new(&ids->ipcs_idr, new, &id); - if (err) - return err; + /* If there is a target id specified, try to use it */ + if (current->next_id && (current->next_id->flag & SYS_ID_IPC)) { + int new_id = current->next_id->ipc_id; + int new_lid = new_id % SEQ_MULTIPLIER; + + if (new_id != + (new_lid + (new_id / SEQ_MULTIPLIER) * SEQ_MULTIPLIER)) + return -EINVAL; + + err = idr_get_new_above(&ids->ipcs_idr, new, new_lid, &id); + if (err) + return err; + if (id != new_lid) { + idr_remove(&ids->ipcs_idr, id); + return -EBUSY; + } + + new->id = new_id; + new->seq = new_id / SEQ_MULTIPLIER; + current->next_id->flag &= ~SYS_ID_IPC; + } else { + err = idr_get_new(&ids->ipcs_idr, new, &id); + if (err) + return err; + + new->seq = ids->seq++; + if (ids->seq > ids->seq_max) + ids->seq = 0; + new->id = ipc_buildid(id, new->seq); + } ids->in_use++; new->cuid = new->uid = current->euid; new->gid = new->cgid = current->egid; - new->seq = ids->seq++; - if(ids->seq > ids->seq_max) - ids->seq = 0; - - new->id = ipc_buildid(id, new->seq); spin_lock_init(&new->lock); new->deleted = 0; rcu_read_lock(); -- _______________________________________________ Containers…
creator: Nadia Derbey
date: 2008-03-10T13:50:57-00:00

[RFC][PATCH 4/4] PID: use the target ID specified in procfs
type: item
description: [PATCH 04/04] This patch makes use of the target ids specified by a previous write to /proc/self/next_pids as the ids to use to allocate the next upid nrs. Upper levels upid nrs that are not specified in next_pids file are left to the kernel choice. Signed-off-by: Nadia Derbey <Nadia.Derbey@bull.net> --- kernel/fork.c | 5 ++- kernel/pid.c | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++-------- 2 files changed, 73 insertions(+), 12 deletions(-) Index: linux-2.6.25-rc3-mm1/kernel/pid.c =================================================================== --- linux-2.6.25-rc3-mm1.orig/kernel/pid.c 2008-03-10 09:19:02.000000000 +0100 +++ linux-2.6.25-rc3-mm1/kernel/pid.c 2008-03-10 13:45:52.000000000 +0100 @@ -122,14 +122,26 @@ static void free_pidmap(struct upid *upi atomic_inc(&map->nr_free); } -static int alloc_pidmap(struct pid_namespace *pid_ns) +static int alloc_pidmap(struct pid_namespace *pid_ns, struct pid_list *pid_l, + int level) { int i, offset, max_scan, pid, last = pid_ns->last_pid; struct pidmap *map; - pid = last + 1; - if (pid >= pid_max) - pid = RESERVED_PIDS; + if (!pid_l) { + pid = last + 1; + if (pid >= pid_max) + pid = RESERVED_PIDS; + } else { + /* + * There's a target pid, so use it instead + */ + BUG_ON(level < 0); + pid = PID_AT(pid_l, level); + if (pid >= pid_max) + return -EINVAL; + } + offset = pid & BITS_PER_PAGE_MASK; map = &pid_ns->pidmap[pid/BITS_PER_PAGE]; max_scan = (pid_max + BITS_PER_PAGE - 1)/BITS_PER_PAGE - !offset; @@ -153,9 +165,16 @@ static int alloc_pidmap(struct pid_names do { if (!test_and_set_bit(offset, map->page)) { atomic_dec(&map->nr_free); - pid_ns->last_pid = pid; + if (!pid_l) + pid_ns->last_pid = pid; + else + pid_ns->last_pid = max(last, + pid); return pid; } + if (pid_l) + /* Target pid is already in use */ + return -EBUSY; offset = find_next_offset(map, offset); pid = mk_pid(pid_ns, map, offset); /* @@ -179,7 +198,7 @@ static int alloc_pidmap(struct pid_names } pid = mk_pid(pid_ns, map, offset); } - return -…
creator: Nadia Derbey
date: 2008-03-10T13:50:58-00:00

Re: [RFC][PATCH 4/4] PID: use the target ID specified in procfs
type: item
description: Nadia.Derbey@bull.net wrote: > @@ -122,14 +122,26 @@ static void free_pidmap(struct upid *upi > atomic_inc(&map->nr_free); > } > > -static int alloc_pidmap(struct pid_namespace *pid_ns) > +static int alloc_pidmap(struct pid_namespace *pid_ns, struct pid_list *pid_l, > + int level) > { > int i, offset, max_scan, pid, last = pid_ns->last_pid; > struct pidmap *map; > > - pid = last + 1; > - if (pid >= pid_max) > - pid = RESERVED_PIDS; > + if (!pid_l) { > + pid = last + 1; > + if (pid >= pid_max) > + pid = RESERVED_PIDS; > + } else { > + /* > + * There's a target pid, so use it instead > + */ > + BUG_ON(level < 0); > + pid = PID_AT(pid_l, level); > + if (pid >= pid_max) > + return -EINVAL; > + } > + > offset = pid & BITS_PER_PAGE_MASK; > map = &pid_ns->pidmap[pid/BITS_PER_PAGE]; > max_scan = (pid_max + BITS_PER_PAGE - 1)/BITS_PER_PAGE - !offset; > @@ -153,9 +165,16 @@ static int alloc_pidmap(struct pid_names > do { > if (!test_and_set_bit(offset, map->page)) { > atomic_dec(&map->nr_free); > - pid_ns->last_pid = pid; > + if (!pid_l) > + pid_ns->last_pid = pid; > + else > + pid_ns->last_pid = max(last, > + pid); > return pid; > } > + if (pid_l) > + /* Target pid is already in use */ > + return -EBUSY; > offset = find_next_offset(map, offset); > pid = mk_pid(pid_ns, map, offset); > /* > @@ -179,7 +198,7 @@ static int alloc_pidmap(struct pid_names > } > pid = mk_pid(pid_ns, map, offset); > } > - return -1; > + return -ENOMEM; > } > > int next_pidmap(struct pid_namespace *pid_ns, int last) As fas as this particular piece of code is concerned this all can be shrunk down to static int set_vpidmap(struct pid_namespace *ns, int pid) { int offset; pidmap_t *map; offset = pid & BITS_PER_PAGE_MASK; map = ns->pidmap + vpid / BITS_PER_PAGE; if (unlikely(alloc_pidmap_page(map))) return -ENOMEM; if (test_and_set_bit(offset, map->page)) return -EEXIST; atomic_dec(&map->nr_free); return pid; } where the alloc_pidmap_page is a consolidated part of code from alloc_pidmap. And I'm scared of…
creator: Pavel Emelianov
date: 2008-03-11T12:04:39-00:00

Re: [RFC][PATCH 4/4] PID: use the target ID specified in procfs
type: item
description: Pavel Emelyanov wrote: > Nadia.Derbey@bull.net wrote: > >>@@ -122,14 +122,26 @@ static void free_pidmap(struct upid *upi >> atomic_inc(&map->nr_free); >> } >> >>-static int alloc_pidmap(struct pid_namespace *pid_ns) >>+static int alloc_pidmap(struct pid_namespace *pid_ns, struct pid_list *pid_l, >>+ int level) >> { >> int i, offset, max_scan, pid, last = pid_ns->last_pid; >> struct pidmap *map; >> >>- pid = last + 1; >>- if (pid >= pid_max) >>- pid = RESERVED_PIDS; >>+ if (!pid_l) { >>+ pid = last + 1; >>+ if (pid >= pid_max) >>+ pid = RESERVED_PIDS; >>+ } else { >>+ /* >>+ * There's a target pid, so use it instead >>+ */ >>+ BUG_ON(level < 0); >>+ pid = PID_AT(pid_l, level); >>+ if (pid >= pid_max) >>+ return -EINVAL; >>+ } >>+ >> offset = pid & BITS_PER_PAGE_MASK; >> map = &pid_ns->pidmap[pid/BITS_PER_PAGE]; >> max_scan = (pid_max + BITS_PER_PAGE - 1)/BITS_PER_PAGE - !offset; >>@@ -153,9 +165,16 @@ static int alloc_pidmap(struct pid_names >> do { >> if (!test_and_set_bit(offset, map->page)) { >> atomic_dec(&map->nr_free); >>- pid_ns->last_pid = pid; >>+ if (!pid_l) >>+ pid_ns->last_pid = pid; >>+ else >>+ pid_ns->last_pid = max(last, >>+ pid); >> return pid; >> } >>+ if (pid_l) >>+ /* Target pid is already in use */ >>+ return -EBUSY; >> offset = find_next_offset(map, offset); >> pid = mk_pid(pid_ns, map, offset); >> /* >>@@ -179,7 +198,7 @@ static int alloc_pidmap(struct pid_names >> } >> pid = mk_pid(pid_ns, map, offset); >> } >>- return -1; >>+ return -ENOMEM; >> } >> >> int next_pidmap(struct pid_namespace *pid_ns, int last) > > > As fas as this particular piece of code is concerned this all can > be shrunk down to > > static int set_vpidmap(struct pid_namespace *ns, int pid) > { > int offset; > pidmap_t *map; > > offset = pid & BITS_PER_PAGE_MASK; > map = ns->pidmap + vpid / BITS_PER_PAGE; > > if (unlikely(alloc_pidmap_page(map))) > return -ENOMEM; > > if (test_and_set_bit(offset, map->page)) > return -EEXIST; > > atomic_dec(&map->nr_free); > return pid; > } …
creator: Nadia Derbey
date: 2008-03-11T15:28:45-00:00

Re: [RFC][PATCH 4/4] PID: use the target ID specified in procfs
type: item
description: Nadia Derbey wrote: > Pavel Emelyanov wrote: >> Nadia.Derbey@bull.net wrote: >> >>> @@ -122,14 +122,26 @@ static void free_pidmap(struct upid *upi >>> atomic_inc(&map->nr_free); >>> } >>> >>> -static int alloc_pidmap(struct pid_namespace *pid_ns) >>> +static int alloc_pidmap(struct pid_namespace *pid_ns, struct pid_list *pid_l, >>> + int level) >>> { >>> int i, offset, max_scan, pid, last = pid_ns->last_pid; >>> struct pidmap *map; >>> >>> - pid = last + 1; >>> - if (pid >= pid_max) >>> - pid = RESERVED_PIDS; >>> + if (!pid_l) { >>> + pid = last + 1; >>> + if (pid >= pid_max) >>> + pid = RESERVED_PIDS; >>> + } else { >>> + /* >>> + * There's a target pid, so use it instead >>> + */ >>> + BUG_ON(level < 0); >>> + pid = PID_AT(pid_l, level); >>> + if (pid >= pid_max) >>> + return -EINVAL; >>> + } >>> + >>> offset = pid & BITS_PER_PAGE_MASK; >>> map = &pid_ns->pidmap[pid/BITS_PER_PAGE]; >>> max_scan = (pid_max + BITS_PER_PAGE - 1)/BITS_PER_PAGE - !offset; >>> @@ -153,9 +165,16 @@ static int alloc_pidmap(struct pid_names >>> do { >>> if (!test_and_set_bit(offset, map->page)) { >>> atomic_dec(&map->nr_free); >>> - pid_ns->last_pid = pid; >>> + if (!pid_l) >>> + pid_ns->last_pid = pid; >>> + else >>> + pid_ns->last_pid = max(last, >>> + pid); >>> return pid; >>> } >>> + if (pid_l) >>> + /* Target pid is already in use */ >>> + return -EBUSY; >>> offset = find_next_offset(map, offset); >>> pid = mk_pid(pid_ns, map, offset); >>> /* >>> @@ -179,7 +198,7 @@ static int alloc_pidmap(struct pid_names >>> } >>> pid = mk_pid(pid_ns, map, offset); >>> } >>> - return -1; >>> + return -ENOMEM; >>> } >>> >>> int next_pidmap(struct pid_namespace *pid_ns, int last) >> >> As fas as this particular piece of code is concerned this all can >> be shrunk down to >> >> static int set_vpidmap(struct pid_namespace *ns, int pid) >> { >> int offset; >> pidmap_t *map; >> >> offset = pid & BITS_PER_PAGE_MASK; >> map = ns->pidmap + vpid / BITS_PER_PAGE; >> >> if (unlikely(alloc_pidmap_page(map))) >> …
creator: Pavel Emelianov
date: 2008-03-11T15:37:37-00:00

Re: [RFC][PATCH 4/4] PID: use the target ID specified in procfs
type: item
description: Pavel Emelyanov wrote: > Nadia Derbey wrote: > >>Pavel Emelyanov wrote: >> >>>Nadia.Derbey@bull.net wrote: >>> >>> >>>>@@ -122,14 +122,26 @@ static void free_pidmap(struct upid *upi >>>> atomic_inc(&map->nr_free); >>>>} >>>> >>>>-static int alloc_pidmap(struct pid_namespace *pid_ns) >>>>+static int alloc_pidmap(struct pid_namespace *pid_ns, struct pid_list *pid_l, >>>>+ int level) >>>>{ >>>> int i, offset, max_scan, pid, last = pid_ns->last_pid; >>>> struct pidmap *map; >>>> >>>>- pid = last + 1; >>>>- if (pid >= pid_max) >>>>- pid = RESERVED_PIDS; >>>>+ if (!pid_l) { >>>>+ pid = last + 1; >>>>+ if (pid >= pid_max) >>>>+ pid = RESERVED_PIDS; >>>>+ } else { >>>>+ /* >>>>+ * There's a target pid, so use it instead >>>>+ */ >>>>+ BUG_ON(level < 0); >>>>+ pid = PID_AT(pid_l, level); >>>>+ if (pid >= pid_max) >>>>+ return -EINVAL; >>>>+ } >>>>+ >>>> offset = pid & BITS_PER_PAGE_MASK; >>>> map = &pid_ns->pidmap[pid/BITS_PER_PAGE]; >>>> max_scan = (pid_max + BITS_PER_PAGE - 1)/BITS_PER_PAGE - !offset; >>>>@@ -153,9 +165,16 @@ static int alloc_pidmap(struct pid_names >>>> do { >>>> if (!test_and_set_bit(offset, map->page)) { >>>> atomic_dec(&map->nr_free); >>>>- pid_ns->last_pid = pid; >>>>+ if (!pid_l) >>>>+ pid_ns->last_pid = pid; >>>>+ else >>>>+ pid_ns->last_pid = max(last, >>>>+ pid); >>>> return pid; >>>> } >>>>+ if (pid_l) >>>>+ /* Target pid is already in use */ >>>>+ return -EBUSY; >>>> offset = find_next_offset(map, offset); >>>> pid = mk_pid(pid_ns, map, offset); >>>> /* >>>>@@ -179,7 +198,7 @@ static int alloc_pidmap(struct pid_names >>>> } >>>> pid = mk_pid(pid_ns, map, offset); >>>> } >>>>- return -1; >>>>+ return -ENOMEM; >>>>} >>>> >>>>int next_pidmap(struct pid_namespace *pid_ns, int last) >>> >>>As fas as this particular piece of code is concerned this all can >>>be shrunk down to >>> >>>static int set_vpidmap(struct pid_namespace *ns, int pid) >>>{ >>> int offset; >>> pidmap_t *map; >>> >>> offset = pid & BITS_PER_PAGE_MASK; >>> map = ns->pidmap + vpid / …
creator: Nadia Derbey
date: 2008-03-11T15:55:04-00:00

Re: [RFC][PATCH 4/4] PID: use the target ID specified in procfs
type: item
description: Quoting Pavel Emelyanov (xemul@openvz.org): > Nadia Derbey wrote: > > Pavel Emelyanov wrote: > >> Nadia.Derbey@bull.net wrote: > >> > >>> @@ -122,14 +122,26 @@ static void free_pidmap(struct upid *upi > >>> atomic_inc(&map->nr_free); > >>> } > >>> > >>> -static int alloc_pidmap(struct pid_namespace *pid_ns) > >>> +static int alloc_pidmap(struct pid_namespace *pid_ns, struct pid_list *pid_l, > >>> + int level) > >>> { > >>> int i, offset, max_scan, pid, last = pid_ns->last_pid; > >>> struct pidmap *map; > >>> > >>> - pid = last + 1; > >>> - if (pid >= pid_max) > >>> - pid = RESERVED_PIDS; > >>> + if (!pid_l) { > >>> + pid = last + 1; > >>> + if (pid >= pid_max) > >>> + pid = RESERVED_PIDS; > >>> + } else { > >>> + /* > >>> + * There's a target pid, so use it instead > >>> + */ > >>> + BUG_ON(level < 0); > >>> + pid = PID_AT(pid_l, level); > >>> + if (pid >= pid_max) > >>> + return -EINVAL; > >>> + } > >>> + > >>> offset = pid & BITS_PER_PAGE_MASK; > >>> map = &pid_ns->pidmap[pid/BITS_PER_PAGE]; > >>> max_scan = (pid_max + BITS_PER_PAGE - 1)/BITS_PER_PAGE - !offset; > >>> @@ -153,9 +165,16 @@ static int alloc_pidmap(struct pid_names > >>> do { > >>> if (!test_and_set_bit(offset, map->page)) { > >>> atomic_dec(&map->nr_free); > >>> - pid_ns->last_pid = pid; > >>> + if (!pid_l) > >>> + pid_ns->last_pid = pid; > >>> + else > >>> + pid_ns->last_pid = max(last, > >>> + pid); > >>> return pid; > >>> } > >>> + if (pid_l) > >>> + /* Target pid is already in use */ > >>> + return -EBUSY; > >>> offset = find_next_offset(map, offset); > >>> pid = mk_pid(pid_ns, map, offset); > >>> /* > >>> @@ -179,7 +198,7 @@ static int alloc_pidmap(struct pid_names > >>> } > >>> pid = mk_pid(pid_ns, map, offset); > >>> } > >>> - return -1; > >>> + return -ENOMEM; > >>> } > >>> > >>> int next_pidmap(struct pid_namespace *pid_ns, int last) > >> > >> As fas as this particular piece of code is concerned this all can > >> be shrunk down to > >> > >> static int set_vpidmap(struct pid_namespace *ns, i…
creator: serue
date: 2008-03-11T16:47:25-00:00

Re: [RFC][PATCH 4/4] PID: use the target ID specified in procfs
type: item
description: Serge E. Hallyn wrote: > Quoting Pavel Emelyanov (xemul@openvz.org): >> Nadia Derbey wrote: >>> Pavel Emelyanov wrote: >>>> Nadia.Derbey@bull.net wrote: >>>> >>>>> @@ -122,14 +122,26 @@ static void free_pidmap(struct upid *upi >>>>> atomic_inc(&map->nr_free); >>>>> } >>>>> >>>>> -static int alloc_pidmap(struct pid_namespace *pid_ns) >>>>> +static int alloc_pidmap(struct pid_namespace *pid_ns, struct pid_list *pid_l, >>>>> + int level) >>>>> { >>>>> int i, offset, max_scan, pid, last = pid_ns->last_pid; >>>>> struct pidmap *map; >>>>> >>>>> - pid = last + 1; >>>>> - if (pid >= pid_max) >>>>> - pid = RESERVED_PIDS; >>>>> + if (!pid_l) { >>>>> + pid = last + 1; >>>>> + if (pid >= pid_max) >>>>> + pid = RESERVED_PIDS; >>>>> + } else { >>>>> + /* >>>>> + * There's a target pid, so use it instead >>>>> + */ >>>>> + BUG_ON(level < 0); >>>>> + pid = PID_AT(pid_l, level); >>>>> + if (pid >= pid_max) >>>>> + return -EINVAL; >>>>> + } >>>>> + >>>>> offset = pid & BITS_PER_PAGE_MASK; >>>>> map = &pid_ns->pidmap[pid/BITS_PER_PAGE]; >>>>> max_scan = (pid_max + BITS_PER_PAGE - 1)/BITS_PER_PAGE - !offset; >>>>> @@ -153,9 +165,16 @@ static int alloc_pidmap(struct pid_names >>>>> do { >>>>> if (!test_and_set_bit(offset, map->page)) { >>>>> atomic_dec(&map->nr_free); >>>>> - pid_ns->last_pid = pid; >>>>> + if (!pid_l) >>>>> + pid_ns->last_pid = pid; >>>>> + else >>>>> + pid_ns->last_pid = max(last, >>>>> + pid); >>>>> return pid; >>>>> } >>>>> + if (pid_l) >>>>> + /* Target pid is already in use */ >>>>> + return -EBUSY; >>>>> offset = find_next_offset(map, offset); >>>>> pid = mk_pid(pid_ns, map, offset); >>>>> /* >>>>> @@ -179,7 +198,7 @@ static int alloc_pidmap(struct pid_names >>>>> } >>>>> pid = mk_pid(pid_ns, map, offset); >>>>> } >>>>> - return -1; >>>>> + return -ENOMEM; >>>>> } >>>>> >>>>> int next_pidmap(struct pid_namespace *pid_ns, int last) >>>> As fas as this particular piece of code is concerned this all can >>>> be shrunk down to >>>> >>>> static int set_vpidmap(struct…
creator: Pavel Emelianov
date: 2008-03-11T16:55:44-00:00

Re: [RFC][PATCH 4/4] PID: use the target ID specified in procfs
type: item
description: Quoting Pavel Emelyanov (xemul@openvz.org): > Serge E. Hallyn wrote: > > Quoting Pavel Emelyanov (xemul@openvz.org): > >> Nadia Derbey wrote: > >>> Pavel Emelyanov wrote: > >>>> Nadia.Derbey@bull.net wrote: > >>>> > >>>>> @@ -122,14 +122,26 @@ static void free_pidmap(struct upid *upi > >>>>> atomic_inc(&map->nr_free); > >>>>> } > >>>>> > >>>>> -static int alloc_pidmap(struct pid_namespace *pid_ns) > >>>>> +static int alloc_pidmap(struct pid_namespace *pid_ns, struct pid_list *pid_l, > >>>>> + int level) > >>>>> { > >>>>> int i, offset, max_scan, pid, last = pid_ns->last_pid; > >>>>> struct pidmap *map; > >>>>> > >>>>> - pid = last + 1; > >>>>> - if (pid >= pid_max) > >>>>> - pid = RESERVED_PIDS; > >>>>> + if (!pid_l) { > >>>>> + pid = last + 1; > >>>>> + if (pid >= pid_max) > >>>>> + pid = RESERVED_PIDS; > >>>>> + } else { > >>>>> + /* > >>>>> + * There's a target pid, so use it instead > >>>>> + */ > >>>>> + BUG_ON(level < 0); > >>>>> + pid = PID_AT(pid_l, level); > >>>>> + if (pid >= pid_max) > >>>>> + return -EINVAL; > >>>>> + } > >>>>> + > >>>>> offset = pid & BITS_PER_PAGE_MASK; > >>>>> map = &pid_ns->pidmap[pid/BITS_PER_PAGE]; > >>>>> max_scan = (pid_max + BITS_PER_PAGE - 1)/BITS_PER_PAGE - !offset; > >>>>> @@ -153,9 +165,16 @@ static int alloc_pidmap(struct pid_names > >>>>> do { > >>>>> if (!test_and_set_bit(offset, map->page)) { > >>>>> atomic_dec(&map->nr_free); > >>>>> - pid_ns->last_pid = pid; > >>>>> + if (!pid_l) > >>>>> + pid_ns->last_pid = pid; > >>>>> + else > >>>>> + pid_ns->last_pid = max(last, > >>>>> + pid); > >>>>> return pid; > >>>>> } > >>>>> + if (pid_l) > >>>>> + /* Target pid is already in use */ > >>>>> + return -EBUSY; > >>>>> offset = find_next_offset(map, offset); > >>>>> pid = mk_pid(pid_ns, map, offset); > >>>>> /* > >>>>> @@ -179,7 +198,7 @@ static int alloc_pidmap(struct pid_names > >>>>> } > >>>>> pid = mk_pid(pid_ns, map, offset); > >>>>> } > >>>>> - return -1; > >>>>> + return -ENOMEM; > >>>>> } > >>>>> > >>>>> int next_pidmap(s…
creator: serue
date: 2008-03-11T17:53:28-00:00

Re: [RFC][PATCH 4/4] PID: use the target ID specified in procfs
type: item
description: "Nadia Derbey" <Nadia.Derbey@bull.net> writes: > A couple of weeks ago, a discussion has started after Pierre's proposal for > a new syscall to change an ipc id (see thread > http://lkml.org/lkml/2008/1/29/209). > > > Oren's suggestion was to force an object's id during its creation, rather > than 1. create it, 2. change its id. > > So here is an implementation of what Oren has suggested. > > 2 new files are defined under /proc/self: > . next_ipcid --> next id to use for ipc object creation > . next_pids --> next upid nr(s) to use for next task to be forked > (see patch #2 for more details). > > When one of these files (or both of them) is filled, a structure pointed to > by the calling task struct is filled with these ids. > > Then, when the object is created, the id(s) present in that structure are > used, instead of the default ones. > A couple of weeks ago, a discussion has started after Pierre's proposal for > a new syscall to change an ipc id (see thread > http://lkml.org/lkml/2008/1/29/209). > > > Oren's suggestion was to force an object's id during its creation, rather > than 1. create it, 2. change its id. > > So here is an implementation of what Oren has suggested. > > 2 new files are defined under /proc/self: > . next_ipcid --> next id to use for ipc object creation > . next_pids --> next upid nr(s) to use for next task to be forked > (see patch #2 for more details). > > When one of these files (or both of them) is filled, a structure pointed to > by the calling task struct is filled with these ids. > > Then, when the object is created, the id(s) present in that structure are > used, instead of the default ones. "Serge E. Hallyn" <serue@us.ibm.com> writes: > Right the alloc_pidmap() changes will probably be pretty much the same > no matter how we do set_it(), so it's worth discussing. But I'm > particularly curious to see what opinions are on the sys_setid(). A couple of comments. With respect to alloc_pidmap we already have the necessary controls (a mini…
creator: ebiederm
date: 2008-03-12T19:58:56-00:00

Re: [RFC][PATCH 4/4] PID: use the target ID specified in procfs
type: item
description: Eric W. Biederman wrote: > "Nadia Derbey" <Nadia.Derbey@bull.net> writes: > >>A couple of weeks ago, a discussion has started after Pierre's proposal for >>a new syscall to change an ipc id (see thread >>http://lkml.org/lkml/2008/1/29/209). >> >> >>Oren's suggestion was to force an object's id during its creation, rather >>than 1. create it, 2. change its id. >> >>So here is an implementation of what Oren has suggested. >> >>2 new files are defined under /proc/self: >> . next_ipcid --> next id to use for ipc object creation >> . next_pids --> next upid nr(s) to use for next task to be forked >> (see patch #2 for more details). >> >>When one of these files (or both of them) is filled, a structure pointed to >>by the calling task struct is filled with these ids. >> >>Then, when the object is created, the id(s) present in that structure are >>used, instead of the default ones. >>A couple of weeks ago, a discussion has started after Pierre's proposal for >>a new syscall to change an ipc id (see thread >>http://lkml.org/lkml/2008/1/29/209). >> >> >>Oren's suggestion was to force an object's id during its creation, rather >>than 1. create it, 2. change its id. >> >>So here is an implementation of what Oren has suggested. >> >>2 new files are defined under /proc/self: >> . next_ipcid --> next id to use for ipc object creation >> . next_pids --> next upid nr(s) to use for next task to be forked >> (see patch #2 for more details). >> >>When one of these files (or both of them) is filled, a structure pointed to >>by the calling task struct is filled with these ids. >> >>Then, when the object is created, the id(s) present in that structure are >>used, instead of the default ones. > > > "Serge E. Hallyn" <serue@us.ibm.com> writes: > > >>Right the alloc_pidmap() changes will probably be pretty much the same >>no matter how we do set_it(), so it's worth discussing. But I'm >>particularly curious to see what opinions are on the sys_setid(). > > > A couple of comments. With respect…
creator: Nadia Derbey
date: 2008-03-13T10:41:40-00:00

Re: [RFC][PATCH 4/4] PID: use the target ID specified in procfs
type: item
description: Nadia Derbey <Nadia.Derbey@bull.net> writes: > Eric W. Biederman wrote: >> "Nadia Derbey" <Nadia.Derbey@bull.net> writes: >> >>>A couple of weeks ago, a discussion has started after Pierre's proposal for >>>a new syscall to change an ipc id (see thread >>>http://lkml.org/lkml/2008/1/29/209). >>> >>> >>>Oren's suggestion was to force an object's id during its creation, rather >>>than 1. create it, 2. change its id. >>> >>>So here is an implementation of what Oren has suggested. >>> >>>2 new files are defined under /proc/self: >>> . next_ipcid --> next id to use for ipc object creation >>> . next_pids --> next upid nr(s) to use for next task to be forked >>> (see patch #2 for more details). >>> >>>When one of these files (or both of them) is filled, a structure pointed to >>>by the calling task struct is filled with these ids. >>> >>>Then, when the object is created, the id(s) present in that structure are >>>used, instead of the default ones. >>>A couple of weeks ago, a discussion has started after Pierre's proposal for >>>a new syscall to change an ipc id (see thread >>>http://lkml.org/lkml/2008/1/29/209). >>> >>> >>>Oren's suggestion was to force an object's id during its creation, rather >>>than 1. create it, 2. change its id. >>> >>>So here is an implementation of what Oren has suggested. >>> >>>2 new files are defined under /proc/self: >>> . next_ipcid --> next id to use for ipc object creation >>> . next_pids --> next upid nr(s) to use for next task to be forked >>> (see patch #2 for more details). >>> >>>When one of these files (or both of them) is filled, a structure pointed to >>>by the calling task struct is filled with these ids. >>> >>>Then, when the object is created, the id(s) present in that structure are >>>used, instead of the default ones. >> >> >> "Serge E. Hallyn" <serue@us.ibm.com> writes: >> >> >>>Right the alloc_pidmap() changes will probably be pretty much the same >>>no matter how we do set_it(), so it's worth discussing. But I'm >>>particula…
creator: ebiederm
date: 2008-03-13T17:40:01-00:00

Re: [RFC][PATCH 4/4] PID: use the target ID specified in procfs
type: item
description: Quoting Eric W. Biederman (ebiederm@xmission.com): > Nadia Derbey <Nadia.Derbey@bull.net> writes: > > > Eric W. Biederman wrote: > >> "Nadia Derbey" <Nadia.Derbey@bull.net> writes: > >> > >>>A couple of weeks ago, a discussion has started after Pierre's proposal for > >>>a new syscall to change an ipc id (see thread > >>>http://lkml.org/lkml/2008/1/29/209). > >>> > >>> > >>>Oren's suggestion was to force an object's id during its creation, rather > >>>than 1. create it, 2. change its id. > >>> > >>>So here is an implementation of what Oren has suggested. > >>> > >>>2 new files are defined under /proc/self: > >>> . next_ipcid --> next id to use for ipc object creation > >>> . next_pids --> next upid nr(s) to use for next task to be forked > >>> (see patch #2 for more details). > >>> > >>>When one of these files (or both of them) is filled, a structure pointed to > >>>by the calling task struct is filled with these ids. > >>> > >>>Then, when the object is created, the id(s) present in that structure are > >>>used, instead of the default ones. > >>>A couple of weeks ago, a discussion has started after Pierre's proposal for > >>>a new syscall to change an ipc id (see thread > >>>http://lkml.org/lkml/2008/1/29/209). > >>> > >>> > >>>Oren's suggestion was to force an object's id during its creation, rather > >>>than 1. create it, 2. change its id. > >>> > >>>So here is an implementation of what Oren has suggested. > >>> > >>>2 new files are defined under /proc/self: > >>> . next_ipcid --> next id to use for ipc object creation > >>> . next_pids --> next upid nr(s) to use for next task to be forked > >>> (see patch #2 for more details). > >>> > >>>When one of these files (or both of them) is filled, a structure pointed to > >>>by the calling task struct is filled with these ids. > >>> > >>>Then, when the object is created, the id(s) present in that structure are > >>>used, instead of the default ones. > >> > >> > >> "Serge E. Hallyn" <serue@us.ibm.com> writes: > >> > >> > …
creator: serue
date: 2008-03-13T19:06:57-00:00

Re: [RFC][PATCH 4/4] PID: use the target ID specified in procfs
type: item
description: Eric W. Biederman wrote: > Nadia Derbey <Nadia.Derbey@bull.net> writes: > >> Eric W. Biederman wrote: >>> "Nadia Derbey" <Nadia.Derbey@bull.net> writes: >>> >>>> A couple of weeks ago, a discussion has started after Pierre's proposal for >>>> a new syscall to change an ipc id (see thread >>>> http://lkml.org/lkml/2008/1/29/209). >>>> >>>> >>>> Oren's suggestion was to force an object's id during its creation, rather >>>> than 1. create it, 2. change its id. >>>> >>>> So here is an implementation of what Oren has suggested. >>>> >>>> 2 new files are defined under /proc/self: >>>> . next_ipcid --> next id to use for ipc object creation >>>> . next_pids --> next upid nr(s) to use for next task to be forked >>>> (see patch #2 for more details). >>>> >>>> When one of these files (or both of them) is filled, a structure pointed to >>>> by the calling task struct is filled with these ids. >>>> >>>> Then, when the object is created, the id(s) present in that structure are >>>> used, instead of the default ones. >>>> A couple of weeks ago, a discussion has started after Pierre's proposal for >>>> a new syscall to change an ipc id (see thread >>>> http://lkml.org/lkml/2008/1/29/209). >>>> >>>> >>>> Oren's suggestion was to force an object's id during its creation, rather >>>> than 1. create it, 2. change its id. >>>> >>>> So here is an implementation of what Oren has suggested. >>>> >>>> 2 new files are defined under /proc/self: >>>> . next_ipcid --> next id to use for ipc object creation >>>> . next_pids --> next upid nr(s) to use for next task to be forked >>>> (see patch #2 for more details). >>>> >>>> When one of these files (or both of them) is filled, a structure pointed to >>>> by the calling task struct is filled with these ids. >>>> >>>> Then, when the object is created, the id(s) present in that structure are >>>> used, instead of the default ones. >>> >>> "Serge E. Hallyn" <serue@us.ibm.com> writes: >>> >>> >>>> Right the alloc_pidmap() changes will probably be pre…
creator: Oren Laadan
date: 2008-03-13T20:01:02-00:00

Re: [RFC][PATCH 4/4] PID: use the target ID specified in procfs
type: item
description: Oren Laadan <orenl@cs.columbia.edu> writes: >>> I'm sorry but I'm pretty new in this domain, so I don't see what are the >>> namespaces where setting (or pre-setting) the id would be a problem? >> >> pids to some extent as people use them in all kinds of files. Being >> able to force the pid of another process could make a hard to trigger >> security hole with file permissions absolutely trivial to hit. > > Since the intent of this mechanism is to allow ckpt/restart, it makes > sense to only allow this operation during restart. For example, in zap, > containers have a state, e.g. running, stopped, ckpt, restart, and this > is only possible in restart state; Furthermore, a container can only be > put in restart state at creation time, and only by root. Of course, you > should only trust that as much as you trust the root :O Yes and thanks. The notion of the state of a container makes a lot of sense (even if we never implement explicit state bits). Eric _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: ebiederm
date: 2008-03-13T23:12:40-00:00

Re: [RFC][PATCH 0/4] Object creation with a specified id
type: item
description: Nadia.Derbey@bull.net wrote: > A couple of weeks ago, a discussion has started after Pierre's proposal for > a new syscall to change an ipc id (see thread > http://lkml.org/lkml/2008/1/29/209). > > > Oren's suggestion was to force an object's id during its creation, rather > than 1. create it, 2. change its id. > > So here is an implementation of what Oren has suggested. > > 2 new files are defined under /proc/self: > . next_ipcid --> next id to use for ipc object creation > . next_pids --> next upid nr(s) to use for next task to be forked > (see patch #2 for more details). Generally looks good. One meta-comment, though: I wonder why you use separate files for separate resources, and why you'd want to write multiple identifiers in one go; it seems to complicate the code and interface with minimal gain. In practice, a process will only do either one or the other, so a single file is enough (e.g. "next_id"). Also, writing a single value at a time followed by the syscall is enough; it's definitely not a performance issue to have multiple calls. We assume the user/caller knows what she's doing, so no need to classify the identifier (that is, tell the kernel it's a pid, or an ipc id) ahead of time. The caller simply writes a value and then calls the relevant syscall, or otherwise the results may not be what she expected... If such context is expected to be required (although I don't see any at the moment), we can require that the user write "TYPE VALUE" pair to the "next_id" file. > > When one of these files (or both of them) is filled, a structure pointed to > by the calling task struct is filled with these ids. > > Then, when the object is created, the id(s) present in that structure are > used, instead of the default ones. > > The patches are against 2.6.25-rc3-mm1, in the following order: > > [PATCH 1/4] adds the procfs facility for next ipc to be created. > [PATCH 2/4] adds the procfs facility for next task to be forked. > [PATCH 3/4] makes use of the specified id (…
creator: Oren Laadan
date: 2008-03-13T23:16:07-00:00

Re: [RFC][PATCH 4/4] PID: use the target ID specified in procfs
type: item
description: Eric W. Biederman wrote: > Oren Laadan <orenl@cs.columbia.edu> writes: > >>>> I'm sorry but I'm pretty new in this domain, so I don't see what are the >>>> namespaces where setting (or pre-setting) the id would be a problem? >>> pids to some extent as people use them in all kinds of files. Being >>> able to force the pid of another process could make a hard to trigger >>> security hole with file permissions absolutely trivial to hit. >> Since the intent of this mechanism is to allow ckpt/restart, it makes >> sense to only allow this operation during restart. For example, in zap, >> containers have a state, e.g. running, stopped, ckpt, restart, and this >> is only possible in restart state; Furthermore, a container can only be >> put in restart state at creation time, and only by root. Of course, you >> should only trust that as much as you trust the root :O > > Yes and thanks. > > The notion of the state of a container makes a lot of sense (even if > we never implement explicit state bits). I found it extremely helpful in managing containers (pods) in zap. There are three more states, actually: stopping, reviving and dead. It is like extending the notion of process state into their collective representation which is the container. In fact, restricting certain operations to specific states was instrumental in eliminating a myriad of potential races in the implementation. I believe this belongs to the ever-pending ckpt/restart discussion :) Oren. > > Eric _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Oren Laadan
date: 2008-03-13T23:24:10-00:00

Re: [RFC][PATCH 0/4] Object creation with a specified id
type: item
description: Oren Laadan wrote: > > > Nadia.Derbey@bull.net wrote: > >> A couple of weeks ago, a discussion has started after Pierre's >> proposal for >> a new syscall to change an ipc id (see thread >> http://lkml.org/lkml/2008/1/29/209). >> >> >> Oren's suggestion was to force an object's id during its creation, rather >> than 1. create it, 2. change its id. >> >> So here is an implementation of what Oren has suggested. >> >> 2 new files are defined under /proc/self: >> . next_ipcid --> next id to use for ipc object creation >> . next_pids --> next upid nr(s) to use for next task to be forked >> (see patch #2 for more details). > > > Generally looks good. One meta-comment, though: > > I wonder why you use separate files for separate resources, That would be needed in a situation wheere we don't care about next, say, ipc id to be created but we need a predefined pid. But I must admit I don't see any pratical application to it. > and why you'd > want to write multiple identifiers in one go; I used multiple identifiers only for the pid values: this is because when a new pid value is allocated for a process that belongs to nested namespaces, the lower level upid nr values are allocated in a single shot. (see alloc_pid()). > it seems to complicate the > code and interface with minimal gain. > In practice, a process will only do either one or the other, so a single > file is enough (e.g. "next_id"). > Also, writing a single value at a time followed by the syscall is enough; > it's definitely not a performance issue to have multiple calls. > We assume the user/caller knows what she's doing, so no need to classify > the identifier (that is, tell the kernel it's a pid, or an ipc id) ahead > of time. The caller simply writes a value and then calls the relevant > syscall, or otherwise the results may not be what she expected... > If such context is expected to be required (although I don't see any at > the moment), we can require that the user write "TYPE VALUE" pair to > the "next_id" f…
creator: Nadia Derbey
date: 2008-03-14T06:21:15-00:00

Re: [RFC][PATCH 0/4] Object creation with a specified id
type: item
description: Nadia Derbey wrote: > Oren Laadan wrote: >> >> >> Nadia.Derbey@bull.net wrote: >> >>> A couple of weeks ago, a discussion has started after Pierre's >>> proposal for >>> a new syscall to change an ipc id (see thread >>> http://lkml.org/lkml/2008/1/29/209). >>> >>> >>> Oren's suggestion was to force an object's id during its creation, >>> rather >>> than 1. create it, 2. change its id. >>> >>> So here is an implementation of what Oren has suggested. >>> >>> 2 new files are defined under /proc/self: >>> . next_ipcid --> next id to use for ipc object creation >>> . next_pids --> next upid nr(s) to use for next task to be forked >>> (see patch #2 for more details). >> >> >> Generally looks good. One meta-comment, though: >> >> I wonder why you use separate files for separate resources, > > That would be needed in a situation wheere we don't care about next, > say, ipc id to be created but we need a predefined pid. But I must admit > I don't see any pratical application to it. exactly; why set the next-ipc value so far in advance ? I think it's better (and less confusing) if we require that setting the next-id value be done right before the respective syscall. > >> and why you'd >> want to write multiple identifiers in one go; > > I used multiple identifiers only for the pid values: this is because > when a new pid value is allocated for a process that belongs to nested > namespaces, the lower level upid nr values are allocated in a single > shot. (see alloc_pid()). > >> it seems to complicate the >> code and interface with minimal gain. >> In practice, a process will only do either one or the other, so a single >> file is enough (e.g. "next_id"). >> Also, writing a single value at a time followed by the syscall is enough; >> it's definitely not a performance issue to have multiple calls. >> We assume the user/caller knows what she's doing, so no need to classify >> the identifier (that is, tell the kernel it's a pid, or an ipc id) ahead >> of time. The caller simply wri…
creator: Oren Laadan
date: 2008-03-14T15:50:13-00:00

Re: [RFC][PATCH 0/4] Object creation with a specified id
type: item
description: Oren Laadan wrote: > > Nadia Derbey wrote: >> Oren Laadan wrote: >>> >>> Nadia.Derbey@bull.net wrote: >>> >>>> A couple of weeks ago, a discussion has started after Pierre's >>>> proposal for >>>> a new syscall to change an ipc id (see thread >>>> http://lkml.org/lkml/2008/1/29/209). >>>> >>>> >>>> Oren's suggestion was to force an object's id during its creation, >>>> rather >>>> than 1. create it, 2. change its id. >>>> >>>> So here is an implementation of what Oren has suggested. >>>> >>>> 2 new files are defined under /proc/self: >>>> . next_ipcid --> next id to use for ipc object creation >>>> . next_pids --> next upid nr(s) to use for next task to be forked >>>> (see patch #2 for more details). >>> >>> Generally looks good. One meta-comment, though: >>> >>> I wonder why you use separate files for separate resources, >> That would be needed in a situation wheere we don't care about next, >> say, ipc id to be created but we need a predefined pid. But I must admit >> I don't see any pratical application to it. > > exactly; why set the next-ipc value so far in advance ? I think it's > better (and less confusing) if we require that setting the next-id value > be done right before the respective syscall. And race with some other syscall caller? This will only work if the next-ipc-id and the next-pid are on a task_struct. Are they (at least supposed to be such)? _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Pavel Emelianov
date: 2008-03-14T15:56:49-00:00

Re: [RFC][PATCH 0/4] Object creation with a specified id
type: item
description: Pavel Emelyanov wrote: > Oren Laadan wrote: >> Nadia Derbey wrote: >>> Oren Laadan wrote: >>>> Nadia.Derbey@bull.net wrote: >>>> >>>>> A couple of weeks ago, a discussion has started after Pierre's >>>>> proposal for >>>>> a new syscall to change an ipc id (see thread >>>>> http://lkml.org/lkml/2008/1/29/209). >>>>> >>>>> >>>>> Oren's suggestion was to force an object's id during its creation, >>>>> rather >>>>> than 1. create it, 2. change its id. >>>>> >>>>> So here is an implementation of what Oren has suggested. >>>>> >>>>> 2 new files are defined under /proc/self: >>>>> . next_ipcid --> next id to use for ipc object creation >>>>> . next_pids --> next upid nr(s) to use for next task to be forked >>>>> (see patch #2 for more details). >>>> Generally looks good. One meta-comment, though: >>>> >>>> I wonder why you use separate files for separate resources, >>> That would be needed in a situation wheere we don't care about next, >>> say, ipc id to be created but we need a predefined pid. But I must admit >>> I don't see any pratical application to it. >> exactly; why set the next-ipc value so far in advance ? I think it's >> better (and less confusing) if we require that setting the next-id value >> be done right before the respective syscall. > > And race with some other syscall caller? This will only work if the next-ipc-id > and the next-pid are on a task_struct. Are they (at least supposed to be such)? yes. that's the first detail I looked for in the patch :) _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Oren Laadan
date: 2008-03-14T16:02:46-00:00

Re: [RFC][PATCH 0/4] Object creation with a specified id
type: item
description: Oren Laadan wrote: > > Pavel Emelyanov wrote: >> Oren Laadan wrote: >>> Nadia Derbey wrote: >>>> Oren Laadan wrote: >>>>> Nadia.Derbey@bull.net wrote: >>>>> >>>>>> A couple of weeks ago, a discussion has started after Pierre's >>>>>> proposal for >>>>>> a new syscall to change an ipc id (see thread >>>>>> http://lkml.org/lkml/2008/1/29/209). >>>>>> >>>>>> >>>>>> Oren's suggestion was to force an object's id during its creation, >>>>>> rather >>>>>> than 1. create it, 2. change its id. >>>>>> >>>>>> So here is an implementation of what Oren has suggested. >>>>>> >>>>>> 2 new files are defined under /proc/self: >>>>>> . next_ipcid --> next id to use for ipc object creation >>>>>> . next_pids --> next upid nr(s) to use for next task to be forked >>>>>> (see patch #2 for more details). >>>>> Generally looks good. One meta-comment, though: >>>>> >>>>> I wonder why you use separate files for separate resources, >>>> That would be needed in a situation wheere we don't care about next, >>>> say, ipc id to be created but we need a predefined pid. But I must admit >>>> I don't see any pratical application to it. >>> exactly; why set the next-ipc value so far in advance ? I think it's >>> better (and less confusing) if we require that setting the next-id value >>> be done right before the respective syscall. >> And race with some other syscall caller? This will only work if the next-ipc-id >> and the next-pid are on a task_struct. Are they (at least supposed to be such)? > > yes. that's the first detail I looked for in the patch :) OK :) I just remembered some talks about using last_pid for pid allocations and just wanted to be sure. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Pavel Emelianov
date: 2008-03-14T16:08:38-00:00

Re: [RFC][PATCH 0/4] Object creation with a specified id
type: item
description: Oren Laadan wrote: > > > Nadia Derbey wrote: > >> Oren Laadan wrote: >> >>> >>> >>> Nadia.Derbey@bull.net wrote: >>> >>>> A couple of weeks ago, a discussion has started after Pierre's >>>> proposal for >>>> a new syscall to change an ipc id (see thread >>>> http://lkml.org/lkml/2008/1/29/209). >>>> >>>> >>>> Oren's suggestion was to force an object's id during its creation, >>>> rather >>>> than 1. create it, 2. change its id. >>>> >>>> So here is an implementation of what Oren has suggested. >>>> >>>> 2 new files are defined under /proc/self: >>>> . next_ipcid --> next id to use for ipc object creation >>>> . next_pids --> next upid nr(s) to use for next task to be forked >>>> (see patch #2 for more details). >>> >>> >>> >>> Generally looks good. One meta-comment, though: >>> >>> I wonder why you use separate files for separate resources, >> >> >> That would be needed in a situation wheere we don't care about next, >> say, ipc id to be created but we need a predefined pid. But I must >> admit I don't see any pratical application to it. > > > exactly; why set the next-ipc value so far in advance ? I think it's > better (and less confusing) if we require that setting the next-id value > be done right before the respective syscall. Ok, but this "requirement" should be widely agreed upon ;-) What I mean here is that the solution with 1 file per "object type" can easily be extended imho: I don't know how the restart is supposed to work, but we can imagine feeding all these files with all the object ids just before restart and let the process pick up the objects ids as it needs them. Of course, this would require to enhance the files formats, as well as the way things are stored in the task_struct. Hope what I'm saying is not too stupid ;-) ? Regards, Nadia > >> >>> and why you'd >>> want to write multiple identifiers in one go; >> >> >> I used multiple identifiers only for the pid values: this is because >> when a new pid value is allocated for a process that belongs t…
creator: Nadia Derbey
date: 2008-03-14T16:11:22-00:00

Re: [RFC][PATCH 0/4] Object creation with a specified id
type: item
description: Pavel Emelyanov wrote: > Oren Laadan wrote: > >>Nadia Derbey wrote: >> >>>Oren Laadan wrote: >>> >>>>Nadia.Derbey@bull.net wrote: >>>> >>>> >>>>>A couple of weeks ago, a discussion has started after Pierre's >>>>>proposal for >>>>>a new syscall to change an ipc id (see thread >>>>>http://lkml.org/lkml/2008/1/29/209). >>>>> >>>>> >>>>>Oren's suggestion was to force an object's id during its creation, >>>>>rather >>>>>than 1. create it, 2. change its id. >>>>> >>>>>So here is an implementation of what Oren has suggested. >>>>> >>>>>2 new files are defined under /proc/self: >>>>> . next_ipcid --> next id to use for ipc object creation >>>>> . next_pids --> next upid nr(s) to use for next task to be forked >>>>> (see patch #2 for more details). >>>> >>>>Generally looks good. One meta-comment, though: >>>> >>>>I wonder why you use separate files for separate resources, >>> >>>That would be needed in a situation wheere we don't care about next, >>>say, ipc id to be created but we need a predefined pid. But I must admit >>>I don't see any pratical application to it. >> >>exactly; why set the next-ipc value so far in advance ? I think it's >>better (and less confusing) if we require that setting the next-id value >>be done right before the respective syscall. > > > And race with some other syscall caller? This will only work if the next-ipc-id > and the next-pid are on a task_struct. Are they (at least supposed to be such)? > > Yes they are. Regards, Nadia _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Nadia Derbey
date: 2008-03-14T16:11:34-00:00

Re: [RFC][PATCH 0/4] Object creation with a specified id
type: item
description: Nadia Derbey wrote: > Oren Laadan wrote: >> >> >> Nadia Derbey wrote: >> >>> Oren Laadan wrote: >>> >>>> >>>> >>>> Nadia.Derbey@bull.net wrote: >>>> >>>>> A couple of weeks ago, a discussion has started after Pierre's >>>>> proposal for >>>>> a new syscall to change an ipc id (see thread >>>>> http://lkml.org/lkml/2008/1/29/209). >>>>> >>>>> >>>>> Oren's suggestion was to force an object's id during its creation, >>>>> rather >>>>> than 1. create it, 2. change its id. >>>>> >>>>> So here is an implementation of what Oren has suggested. >>>>> >>>>> 2 new files are defined under /proc/self: >>>>> . next_ipcid --> next id to use for ipc object creation >>>>> . next_pids --> next upid nr(s) to use for next task to be forked >>>>> (see patch #2 for more details). >>>> >>>> >>>> >>>> Generally looks good. One meta-comment, though: >>>> >>>> I wonder why you use separate files for separate resources, >>> >>> >>> That would be needed in a situation wheere we don't care about next, >>> say, ipc id to be created but we need a predefined pid. But I must >>> admit I don't see any pratical application to it. >> >> >> exactly; why set the next-ipc value so far in advance ? I think it's >> better (and less confusing) if we require that setting the next-id value >> be done right before the respective syscall. > > Ok, but this "requirement" should be widely agreed upon ;-) A discussion on the overall checkpoint/restart policy is certainly due (and increasingly noted recently). > What I mean here is that the solution with 1 file per "object type" can > easily be extended imho: I'm aiming at simplicity and minimal (but not restrictive) API for user space. I argue that we never really need more than one predetermined value at a time (eg see below), and the cost of setting such value is so small that there is no real benefit in setting more than one at a time (either via multiple files or via an array of values). If in fact you wanted more than one type at a time, you could still make i…
creator: Oren Laadan
date: 2008-03-14T16:45:31-00:00

Re: [RFC][PATCH 0/4] Object creation with a specified id
type: item
description: Quoting Oren Laadan (orenl@cs.columbia.edu): > > > Nadia Derbey wrote: > > Oren Laadan wrote: > >> > >> > >> Nadia Derbey wrote: > >> > >>> Oren Laadan wrote: > >>> > >>>> > >>>> > >>>> Nadia.Derbey@bull.net wrote: > >>>> > >>>>> A couple of weeks ago, a discussion has started after Pierre's > >>>>> proposal for > >>>>> a new syscall to change an ipc id (see thread > >>>>> http://lkml.org/lkml/2008/1/29/209). > >>>>> > >>>>> > >>>>> Oren's suggestion was to force an object's id during its creation, > >>>>> rather > >>>>> than 1. create it, 2. change its id. > >>>>> > >>>>> So here is an implementation of what Oren has suggested. > >>>>> > >>>>> 2 new files are defined under /proc/self: > >>>>> . next_ipcid --> next id to use for ipc object creation > >>>>> . next_pids --> next upid nr(s) to use for next task to be forked > >>>>> (see patch #2 for more details). > >>>> > >>>> > >>>> > >>>> Generally looks good. One meta-comment, though: > >>>> > >>>> I wonder why you use separate files for separate resources, > >>> > >>> > >>> That would be needed in a situation wheere we don't care about next, > >>> say, ipc id to be created but we need a predefined pid. But I must > >>> admit I don't see any pratical application to it. > >> > >> > >> exactly; why set the next-ipc value so far in advance ? I think it's > >> better (and less confusing) if we require that setting the next-id value > >> be done right before the respective syscall. > > > > Ok, but this "requirement" should be widely agreed upon ;-) > > A discussion on the overall checkpoint/restart policy is certainly due > (and increasingly noted recently). > > > What I mean here is that the solution with 1 file per "object type" can > > easily be extended imho: > > I'm aiming at simplicity and minimal (but not restrictive) API for user > space. I argue that we never really need more than one predetermined value > at a time (eg see below), and the cost of setting such value is so small > that there is no real benefit i…
creator: serue
date: 2008-03-16T03:43:20-00:00

Re: [RFC][PATCH 0/4] Object creation with a specified id
type: item
description: Serge E. Hallyn wrote: > Quoting Oren Laadan (orenl@cs.columbia.edu): >> >> Nadia Derbey wrote: >>> Oren Laadan wrote: >>>> >>>> Nadia Derbey wrote: >>>> >>>>> Oren Laadan wrote: >>>>> >>>>>> >>>>>> Nadia.Derbey@bull.net wrote: >>>>>> >>>>>>> A couple of weeks ago, a discussion has started after Pierre's >>>>>>> proposal for >>>>>>> a new syscall to change an ipc id (see thread >>>>>>> http://lkml.org/lkml/2008/1/29/209). >>>>>>> >>>>>>> >>>>>>> Oren's suggestion was to force an object's id during its creation, >>>>>>> rather >>>>>>> than 1. create it, 2. change its id. >>>>>>> >>>>>>> So here is an implementation of what Oren has suggested. >>>>>>> >>>>>>> 2 new files are defined under /proc/self: >>>>>>> . next_ipcid --> next id to use for ipc object creation >>>>>>> . next_pids --> next upid nr(s) to use for next task to be forked >>>>>>> (see patch #2 for more details). >>>>>> >>>>>> >>>>>> Generally looks good. One meta-comment, though: >>>>>> >>>>>> I wonder why you use separate files for separate resources, >>>>> >>>>> That would be needed in a situation wheere we don't care about next, >>>>> say, ipc id to be created but we need a predefined pid. But I must >>>>> admit I don't see any pratical application to it. >>>> >>>> exactly; why set the next-ipc value so far in advance ? I think it's >>>> better (and less confusing) if we require that setting the next-id value >>>> be done right before the respective syscall. >>> Ok, but this "requirement" should be widely agreed upon ;-) >> A discussion on the overall checkpoint/restart policy is certainly due >> (and increasingly noted recently). >> >>> What I mean here is that the solution with 1 file per "object type" can >>> easily be extended imho: >> I'm aiming at simplicity and minimal (but not restrictive) API for user >> space. I argue that we never really need more than one predetermined value >> at a time (eg see below), and the cost of setting such value is so small >> that there is no real benefit in sett…
creator: Oren Laadan
date: 2008-03-16T19:08:44-00:00

Re: [RFC][PATCH 0/4] Object creation with a specified id
type: item
description: Quoting Oren Laadan (orenl@cs.columbia.edu): > > > Serge E. Hallyn wrote: >> Quoting Oren Laadan (orenl@cs.columbia.edu): >>> >>> Nadia Derbey wrote: >>>> Oren Laadan wrote: >>>>> >>>>> Nadia Derbey wrote: >>>>> >>>>>> Oren Laadan wrote: >>>>>> >>>>>>> >>>>>>> Nadia.Derbey@bull.net wrote: >>>>>>> >>>>>>>> A couple of weeks ago, a discussion has started after Pierre's >>>>>>>> proposal for >>>>>>>> a new syscall to change an ipc id (see thread >>>>>>>> http://lkml.org/lkml/2008/1/29/209). >>>>>>>> >>>>>>>> >>>>>>>> Oren's suggestion was to force an object's id during its creation, >>>>>>>> rather >>>>>>>> than 1. create it, 2. change its id. >>>>>>>> >>>>>>>> So here is an implementation of what Oren has suggested. >>>>>>>> >>>>>>>> 2 new files are defined under /proc/self: >>>>>>>> . next_ipcid --> next id to use for ipc object creation >>>>>>>> . next_pids --> next upid nr(s) to use for next task to be forked >>>>>>>> (see patch #2 for more details). >>>>>>> >>>>>>> >>>>>>> Generally looks good. One meta-comment, though: >>>>>>> >>>>>>> I wonder why you use separate files for separate resources, >>>>>> >>>>>> That would be needed in a situation wheere we don't care about next, >>>>>> say, ipc id to be created but we need a predefined pid. But I must >>>>>> admit I don't see any pratical application to it. >>>>> >>>>> exactly; why set the next-ipc value so far in advance ? I think it's >>>>> better (and less confusing) if we require that setting the next-id >>>>> value >>>>> be done right before the respective syscall. >>>> Ok, but this "requirement" should be widely agreed upon ;-) >>> A discussion on the overall checkpoint/restart policy is certainly due >>> (and increasingly noted recently). >>> >>>> What I mean here is that the solution with 1 file per "object type" can >>>> easily be extended imho: >>> I'm aiming at simplicity and minimal (but not restrictive) API for user >>> space. I argue that we never really need more than one predetermined >>> value >>> at…
creator: serue
date: 2008-03-17T14:44:52-00:00

Re: [RFC][PATCH 0/4] Object creation with a specified id
type: item
description: Nick Andrew wrote: > On Fri, Apr 04, 2008 at 04:51:29PM +0200, Nadia.Derbey@bull.net wrote: > >> . echo "LONG XX" > /proc/self/next_id >> next object to be created will have an id set to XX >> . echo "LONG<n> X0 ... X<n-1>" > /proc/self/next_id >> next object to be created will have its ids set to XX0, ... X<n-1> >> This is particularly useful for processes that may have several ids if >> they belong to nested namespaces. > > > How do you handle race conditions, i.e. you specify the ID for the > next object to be created, and then some other thread goes and creates > an object before your thread creates one? > > Nick. Sorry for not answering earlier, I just saw your e-mail! It's true that the way I've done things, the "create_with_id" doesn't take into account multi-threaded apps, since "self" is related to the thread group leader. May be using something like /proc/self/task/<my_tid>/next_id would be better, but I have to think more about it... Regards, Nadia _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Nadia Derbey
date: 2008-04-15T10:30:26-00:00

Re: [RFC][PATCH 0/4] Object creation with a specified id
type: item
description: Nadia Derbey wrote: > Nick Andrew wrote: >> On Fri, Apr 04, 2008 at 04:51:29PM +0200, Nadia.Derbey@bull.net wrote: >> >>> . echo "LONG XX" > /proc/self/next_id >>> next object to be created will have an id set to XX >>> . echo "LONG<n> X0 ... X<n-1>" > /proc/self/next_id >>> next object to be created will have its ids set to XX0, ... X<n-1> >>> This is particularly useful for processes that may have several >>> ids if >>> they belong to nested namespaces. >> >> >> How do you handle race conditions, i.e. you specify the ID for the >> next object to be created, and then some other thread goes and creates >> an object before your thread creates one? >> >> Nick. > > > Sorry for not answering earlier, I just saw your e-mail! [I too managed to miss that message]. > > It's true that the way I've done things, the "create_with_id" doesn't > take into account multi-threaded apps, since "self" is related to the > thread group leader. > > May be using something like /proc/self/task/<my_tid>/next_id would be > better, but I have to think more about it... That /proc/self links to /proc/TGID slipped my mind. Definitely must be done on a per-thread basis (and /proc/<TGID>/task/<PID>/next_id will do the trick). Oren. > > Regards, > Nadia _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Oren Laadan
date: 2008-04-15T18:52:33-00:00

Re: [RFC][PATCH 0/4] Object creation with a specified id
type: item
description: Nick Andrew wrote: > On Fri, Apr 04, 2008 at 04:51:29PM +0200, Nadia.Derbey@bull.net wrote: > >> . echo "LONG XX" > /proc/self/next_id >> next object to be created will have an id set to XX >> . echo "LONG<n> X0 ... X<n-1>" > /proc/self/next_id >> next object to be created will have its ids set to XX0, ... X<n-1> >> This is particularly useful for processes that may have several ids if >> they belong to nested namespaces. > > > How do you handle race conditions, i.e. you specify the ID for the > next object to be created, and then some other thread goes and creates > an object before your thread creates one? > > Nick. OK, race problem between threads is fixed. Thanks for finding the issue! The new patch series is coming next. Regards, Nadia _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Nadia Derbey
date: 2008-04-18T05:46:29-00:00