linux-toradex.git/include/linux/pid.h, branch v2.6.23-rc5

statically initialize struct pid for swapper

2007-05-11T15:29:35+00:00

Statically initialize a struct pid for the swapper process (pid_t == 0) and
attach it to init_task.  This is needed so task_pid(), task_pgrp() and
task_session() interfaces work on the swapper process also.

Signed-off-by: Sukadev Bhattiprolu 
Cc: Cedric Le Goater 
Cc: Dave Hansen 
Cc: Serge Hallyn 
Cc: Eric Biederman 
Cc: Herbert Poetzl 
Cc: 
Acked-by: Eric W. Biederman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

attach_pid() with struct pid parameter

2007-05-11T15:29:35+00:00

attach_pid() currently takes a pid_t and then uses find_pid() to find the
corresponding struct pid.  Sometimes we already have the struct pid.  We can
then skip find_pid() if attach_pid() were to take a struct pid parameter.

Signed-off-by: Sukadev Bhattiprolu 
Cc: Cedric Le Goater 
Cc: Dave Hansen 
Cc: Serge Hallyn 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] pid: remove now unused do_each_task_pid and while_each_task_pid

2007-02-12T17:48:32+00:00

Now that I have changed all of the users remove the old version of these
functions.  This should be a clear hint to any out of tree users that they
should use do_each_pid_task and while_each_pid_task for new code.

Signed-off-by: Eric W. Biederman 
Cc: Alan Cox 
Cc: Oleg Nesterov 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] add child reaper to pid_namespace

2006-12-08T16:28:52+00:00

Add a per pid_namespace child-reaper.  This is needed so processes are reaped
within the same pid space and do not spill over to the parent pid space.  Its
also needed so containers preserve existing semantic that pid == 1 would reap
orphaned children.

This is based on Eric Biederman's patch: http://lkml.org/lkml/2006/2/6/285

Signed-off-by: Sukadev Bhattiprolu 
Signed-off-by: Cedric Le Goater 
Cc: Kirill Korotaev 
Cc: Eric W. Biederman 
Cc: Herbert Poetzl 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] pid.h cleanup

2006-10-03T15:03:40+00:00

Make the pid.h macros look less revolting in an 80-col window.

Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] introduce get_task_pid() to fix unsafe get_pid()

2006-10-02T14:57:25+00:00

proc_pid_make_inode:

	ei->pid = get_pid(task_pid(task));

I think this is not safe.  get_pid() can be preempted after checking "pid
!= NULL".  Then the task exits, does detach_pid(), and RCU frees the pid.

Signed-off-by: Oleg Nesterov 
Cc: "Eric W. Biederman" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] pid: simplify pid iterators

2006-10-02T14:57:15+00:00

I think it is hardly possible to read the current do_each_task_pid().  The
new version is much simpler and makes the code smaller.

Only the do_each_task_pid change is tested, the do_each_pid_task isn't.

Signed-off-by: Oleg Nesterov 
Cc: "Eric W. Biederman" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] pid: implement pid_nr

2006-10-02T14:57:13+00:00

As we stop storing pid_t's and move to storing struct pid *.  We need a way to
get the pid_t from the struct pid to report to user space what we have stored.

Having a clean well defined way to do this is especially important as we move
to multiple pid spaces as may need to report a different value to the caller
depending on which pid space the caller is in.

Signed-off-by: Eric W. Biederman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] pid: add do_each_pid_task

2006-10-02T14:57:13+00:00

To avoid pid rollover confusion the kernel needs to work with struct pid *
instead of pid_t.  Currently there is not an iterator that walks through all
of the tasks of a given pid type starting with a struct pid.  This prevents us
replacing some pid_t instances with struct pid.  So this patch adds
do_each_pid_task which walks through the set of task for a given pid type
starting with a struct pid.

Signed-off-by: Eric W. Biederman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] proc: readdir race fix (take 3)

2006-10-02T14:57:12+00:00

The problem: An opendir, readdir, closedir sequence can fail to report
process ids that are continually in use throughout the sequence of system
calls.  For this race to trigger the process that proc_pid_readdir stops at
must exit before readdir is called again.

This can cause ps to fail to report processes, and it is in violation of
posix guarantees and normal application expectations with respect to
readdir.

Currently there is no way to work around this problem in user space short
of providing a gargantuan buffer to user space so the directory read all
happens in on system call.

This patch implements the normal directory semantics for proc, that
guarantee that a directory entry that is neither created nor destroyed
while reading the directory entry will be returned.  For directory that are
either created or destroyed during the readdir you may or may not see them.
 Furthermore you may seek to a directory offset you have previously seen.

These are the guarantee that ext[23] provides and that posix requires, and
more importantly that user space expects.  Plus it is a simple semantic to
implement reliable service.  It is just a matter of calling readdir a
second time if you are wondering if something new has show up.

These better semantics are implemented by scanning through the pids in
numerical order and by making the file offset a pid plus a fixed offset.

The pid scan happens on the pid bitmap, which when you look at it is
remarkably efficient for a brute force algorithm.  Given that a typical
cache line is 64 bytes and thus covers space for 64*8 == 200 pids.  There
are only 40 cache lines for the entire 32K pid space.  A typical system
will have 100 pids or more so this is actually fewer cache lines we have to
look at to scan a linked list, and the worst case of having to scan the
entire pid bitmap is pretty reasonable.

If we need something more efficient we can go to a more efficient data
structure for indexing the pids, but for now what we have should be
sufficient.

In addition this takes no additional locks and is actually less code than
what we are doing now.

Also another very subtle bug in this area has been fixed.  It is possible
to catch a task in the middle of de_thread where a thread is assuming the
thread of it's thread group leader.  This patch carefully handles that case
so if we hit it we don't fail to return the pid, that is undergoing the
de_thread dance.

Thanks to KAMEZAWA Hiroyuki  for
providing the first fix, pointing this out and working on it.

[oleg@tv-sign.ru: fix it]
Signed-off-by: Eric W. Biederman 
Acked-by: KAMEZAWA Hiroyuki 
Signed-off-by: Oleg Nesterov 
Cc: Jean Delvare 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds