linux-toradex.git/kernel/fork.c, branch v2.6.17.12

[PATCH] move call of audit_free() into do_exit()

2006-05-01T10:06:13+00:00

Signed-off-by: Al Viro

[PATCH] Don't inherit ->splice_pipe across forks

2006-04-20T11:05:33+00:00

It's really task private, so clear that field on fork after copying
task structure.

Signed-off-by: Jens Axboe

[PATCH] task: Make task list manipulations RCU safe

2006-04-19T16:13:49+00:00

While we can currently walk through thread groups, process groups, and
sessions with just the rcu_read_lock, this opens the door to walking the
entire task list.

We already have all of the other RCU guarantees so there is no cost in
doing this, this should be enough so that proc can stop taking the
tasklist lock during readdir.

prev_task was killed because it has no users, and using it will miss new
tasks when doing an rcu traversal.

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

[PATCH] kill unushed __put_task_struct_cb

2006-04-15T00:43:57+00:00

Somehow in the midst of dotting i's and crossing t's during
the merge up to rc1 we wound up keeping __put_task_struct_cb
when it should have been killed as it no longer has any users.
Sorry I probably should have caught this while it was
still in the -mm tree.

Having the old code there gets confusing when reading
through the code and trying to understand what is
happening.

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

[PATCH] wrong error path in dup_fd() leading to oopses in RCU

2006-03-31T20:25:46+00:00

Wrong error path in dup_fd() - it should return NULL on error,
not an address of already freed memory :/

Triggered by OpenVZ stress test suite.

What is interesting is that it was causing different oopses in RCU like
below:
Call Trace:
   [] rcu_do_batch+0x2c/0x80
   [] rcu_process_callbacks+0x3d/0x70
   [] tasklet_action+0x73/0xe0
   [] __do_softirq+0x10a/0x130
   [] do_softirq+0x4f/0x60
   =======================
   [] smp_apic_timer_interrupt+0x77/0x110
   [] apic_timer_interrupt+0x1c/0x24
  Code:  Bad EIP value.
   <0>Kernel panic - not syncing: Fatal exception in interrupt

Signed-Off-By: Pavel Emelianov 
Signed-Off-By: Dmitry Mishin 
Signed-Off-By: Kirill Korotaev 
Signed-Off-By: Linus Torvalds

[PATCH] pidhash: Refactor the pid hash table

2006-03-31T20:19:00+00:00

Simplifies the code, reduces the need for 4 pid hash tables, and makes the
code more capable.

In the discussions I had with Oleg it was felt that to a large extent the
cleanup itself justified the work.  With struct pid being dynamically
allocated meant we could create the hash table entry when the pid was
allocated and free the hash table entry when the pid was freed.  Instead of
playing with the hash lists when ever a process would attach or detach to a
process.

For myself the fact that it gave what my previous task_ref patch gave for free
with simpler code was a big win.  The problem is that if you hold a reference
to struct task_struct you lock in 10K of low memory.  If you do that in a user
controllable way like /proc does, with an unprivileged but hostile user space
application with typical resource limits of 1000 fds and 100 processes I can
trigger the OOM killer by consuming all of low memory with task structs, on a
machine wight 1GB of low memory.

If I instead hold a reference to struct pid which holds a pointer to my
task_struct, I don't suffer from that problem because struct pid is 2 orders
of magnitude smaller.  In fact struct pid is small enough that most other
kernel data structures dwarf it, so simply limiting the number of referring
data structures is enough to prevent exhaustion of low memory.

This splits the current struct pid into two structures, struct pid and struct
pid_link, and reduces our number of hash tables from PIDTYPE_MAX to just one.
struct pid_link is the per process linkage into the hash tables and lives in
struct task_struct.  struct pid is given an indepedent lifetime, and holds
pointers to each of the pid types.

The independent life of struct pid simplifies attach_pid, and detach_pid,
because we are always manipulating the list of pids and not the hash table.
In addition in giving struct pid an indpendent life it makes the concept much
more powerful.

Kernel data structures can now embed a struct pid * instead of a pid_t and
not suffer from pid wrap around problems or from keeping unnecessarily
large amounts of memory allocated.

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

[PATCH] resurrect __put_task_struct

2006-03-31T20:18:59+00:00

This just got nuked in mainline.  Bring it back because Eric's patches use it.

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

[PATCH] cleanup __exit_signal->cleanup_sighand path

2006-03-29T02:36:44+00:00

Move 'tsk->sighand = NULL' from cleanup_sighand() to __exit_signal().  This
makes the exit path more understandable and allows us to do
cleanup_sighand() outside of ->siglock protected section.

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

[PATCH] make fork() atomic wrt pgrp/session signals

2006-03-29T02:36:44+00:00

Eric W. Biederman wrote:
>
> Ok. SUSV3/Posix is clear, fork is atomic with respect
> to signals.  Either a signal comes before or after a
> fork but not during. (See the rationale section).
> http://www.opengroup.org/onlinepubs/000095399/functions/fork.html
>
> The tasklist_lock does not stop forks from adding to a process
> group. The forks stall while the tasklist_lock is held, but a fork
> that began before we grabbed the tasklist_lock simply completes
> afterwards, and the child does not receive the signal.

This also means that SIGSTOP or sig_kernel_coredump() signal can't
be delivered to pgrp/session reliably.

With this patch copy_process() returns -ERESTARTNOINTR when it
detects a pending signal, fork() will be restarted transparently
after handling the signals.

This patch also deletes now unneeded "group_stop_count > 0" check,
copy_process() can no longer succeed while group stop in progress.

Signed-off-by: Oleg Nesterov 
Acked-By: Eric Biederman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] pids: kill PIDTYPE_TGID

2006-03-29T02:36:44+00:00

This patch kills PIDTYPE_TGID pid_type thus saving one hash table in
kernel/pid.c and speeding up subthreads create/destroy a bit.  It is also a
preparation for the further tref/pids rework.

This patch adds 'struct list_head thread_group' to 'struct task_struct'
instead.

We don't detach group leader from PIDTYPE_PID namespace until another
thread inherits it's ->pid == ->tgid, so we are safe wrt premature
free_pidmap(->tgid) call.

Currently there are no users of find_task_by_pid_type(PIDTYPE_TGID).
Should the need arise, we can use find_task_by_pid()->group_leader.

Signed-off-by: Oleg Nesterov 
Acked-By: Eric Biederman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds