linux.git/fs/exec.c, branch v2.6.33

fs/exec.c: fix initial stack reservation

2010-02-23T03:50:34+00:00

803bf5ec259941936262d10ecc84511b76a20921 ("fs/exec.c: restrict initial
stack space expansion to rlimit") attempts to limit the initial stack to
20*PAGE_SIZE.  Unfortunately, in attempting ensure the stack is not
reduced in size, we ended up not changing the stack at all.

This size reduction check is not necessary as the expand_stack call does
this already.

This caused a regression in UML resulting in most guest processes being
killed.

Signed-off-by: Michael Neuling 
Reviewed-by: KOSAKI Motohiro 
Acked-by: WANG Cong 
Cc: Anton Blanchard 
Cc: Oleg Nesterov 
Cc: James Morris 
Cc: Serge Hallyn 
Cc: Benjamin Herrenschmidt 
Cc: Jouni Malinen 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fs/exec.c: restrict initial stack space expansion to rlimit

2010-02-11T21:59:43+00:00

When reserving stack space for a new process, make sure we're not
attempting to expand the stack by more than rlimit allows.

This fixes a bug caused by b6a2fea39318e43fee84fa7b0b90d68bed92d2ba ("mm:
variable length argument support") and unmasked by
fc63cf237078c86214abcb2ee9926d8ad289da9b ("exec: setup_arg_pages() fails
to return errors").

This bug means that when limiting the stack to less the 20*PAGE_SIZE (eg.
80K on 4K pages or 'ulimit -s 79') all processes will be killed before
they start.  This is particularly bad with 64K pages, where a ulimit below
1280K will kill every process.

To test, do:

  'ulimit -s 15; ls'

before and after the patch is applied.  Before it's applied, 'ls' should
be killed.  After the patch is applied, 'ls' should no longer be killed.

A stack limit of 15KB since it's small enough to trigger 20*PAGE_SIZE.
Also 15KB not a multiple of PAGE_SIZE, which is a trickier case to handle
correctly with this code.

4K pages should be fine to test with.

[kosaki.motohiro@jp.fujitsu.com: cleanup]
[akpm@linux-foundation.org: cleanup cleanup]
Signed-off-by: Michael Neuling 
Signed-off-by: KOSAKI Motohiro 
Cc: Americo Wang 
Cc: Anton Blanchard 
Cc: Oleg Nesterov 
Cc: James Morris 
Cc: Ingo Molnar 
Cc: Serge Hallyn 
Cc: Benjamin Herrenschmidt 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Fix 'flush_old_exec()/setup_new_exec()' split

2010-02-02T20:37:44+00:00

Commit 221af7f87b9 ("Split 'flush_old_exec' into two functions") split
the function at the point of no return - ie right where there were no
more error cases to check.  That made sense from a technical standpoint,
but when we then also combined it with the actual personality setting
going in between flush_old_exec() and setup_new_exec(), it needs to be a
bit more careful.

In particular, we need to make sure that we really flush the old
personality bits in the 'flush' stage, rather than later in the 'setup'
stage, since otherwise we might be flushing the _new_ personality state
that we're just setting up.

So this moves the flags and personality flushing (and 'flush_thread()',
which is the arch-specific function that generally resets lazy FP state
etc) of the old process into flush_old_exec(), so that it doesn't affect
any state that execve() is setting up for the new process environment.

This was reported by Michal Simek as breaking his Microblaze qemu
environment.

Reported-and-tested-by: Michal Simek 
Cc: Peter Anvin 
Signed-off-by: Linus Torvalds

Split 'flush_old_exec' into two functions

2010-01-29T16:22:01+00:00

'flush_old_exec()' is the point of no return when doing an execve(), and
it is pretty badly misnamed.  It doesn't just flush the old executable
environment, it also starts up the new one.

Which is very inconvenient for things like setting up the new
personality, because we want the new personality to affect the starting
of the new environment, but at the same time we do _not_ want the new
personality to take effect if flushing the old one fails.

As a result, the x86-64 '32-bit' personality is actually done using this
insane "I'm going to change the ABI, but I haven't done it yet" bit
(TIF_ABI_PENDING), with SET_PERSONALITY() not actually setting the
personality, but just the "pending" bit, so that "flush_thread()" can do
the actual personality magic.

This patch in no way changes any of that insanity, but it does split the
'flush_old_exec()' function up into a preparatory part that can fail
(still called flush_old_exec()), and a new part that will actually set
up the new exec environment (setup_new_exec()).  All callers are changed
to trivially comply with the new world order.

Signed-off-by: H. Peter Anvin 
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds

mm: introduce coredump parameter structure

2009-12-17T23:45:31+00:00

Introduce coredump parameter data structure (struct coredump_params) to
simplify binfmt->core_dump() arguments.

Signed-off-by: Masami Hiramatsu 
Suggested-by: Ingo Molnar 
Cc: Hidehiro Kawai 
Cc: Oleg Nesterov 
Cc: Roland McGrath 
Cc: KOSAKI Motohiro 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

do_wait() optimization: do not place sub-threads on task_struct->children list

2009-12-17T23:45:31+00:00

Thanks to Roland who pointed out de_thread() issues.

Currently we add sub-threads to ->real_parent->children list.  This buys
nothing but slows down do_wait().

With this patch ->children contains only main threads (group leaders).
The only complication is that forget_original_parent() should iterate over
sub-threads by hand, and de_thread() needs another list_replace() when it
changes ->group_leader.

Henceforth do_wait_thread() can never see task_detached() && !EXIT_DEAD
tasks, we can remove this check (and we can unify do_wait_thread() and
ptrace_do_wait()).

This change can confuse the optimistic search in mm_update_next_owner(),
but this is fixable and minor.

Perhaps badness() and oom_kill_process() should be updated, but they
should be fixed in any case.

Signed-off-by: Oleg Nesterov 
Cc: Roland McGrath 
Cc: Ingo Molnar 
Cc: Ratan Nalumasu 
Cc: Vitaly Mayatskikh 
Cc: David Rientjes 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

procfs: allow threads to rename siblings via /proc/pid/tasks/tid/comm

2009-12-15T16:53:24+00:00

Setting a thread's comm to be something unique is a very useful ability
and is helpful for debugging complicated threaded applications.  However
currently the only way to set a thread name is for the thread to name
itself via the PR_SET_NAME prctl.

However, there may be situations where it would be advantageous for a
thread dispatcher to be naming the threads its managing, rather then
having the threads self-describe themselves.  This sort of behavior is
available on other systems via the pthread_setname_np() interface.

This patch exports a task's comm via proc/pid/comm and
proc/pid/task/tid/comm interfaces, and allows thread siblings to write to
these values.

[akpm@linux-foundation.org: cleanups]
Signed-off-by: John Stultz 
Cc: Andi Kleen 
Cc: Arjan van de Ven 
Cc: Mike Fulton 
Cc: Sean Foley 
Cc: Darren Hart 
Cc: KOSAKI Motohiro 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge branch 'master' into next

2009-12-03T06:33:40+00:00

exec: setup_arg_pages() fails to return errors

2009-11-12T15:25:58+00:00

In setup_arg_pages we work hard to assign a value to ret, but on exit we
always return 0.

Also remove a now duplicated exit path and branch to out_unlock instead.

Signed-off-by: Anton Blanchard 
Acked-by: Serge Hallyn 
Reviewed-by: WANG Cong 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

LSM: imbed ima calls in the security hooks

2009-10-25T04:22:48+00:00

Based on discussions on LKML and LSM, where there are consecutive
security_ and ima_ calls in the vfs layer, move the ima_ calls to
the existing security_ hooks.

Signed-off-by: Mimi Zohar 
Signed-off-by: James Morris