If de_thread() fails in flush_old_exec() then we try to fail the execve().

That is a bad move, because exec_mmap() has already switched the current
process over to the new mm.  The new process is not yet sufficiently set up
to handle the error and the kernel doublefaults and dies.  exec_mmap() is the
point of no return.

Change flush_old_exec() to call de_thread() before running exec_mmap() so the
execing program sees the error.  I added fault injection to both de_thread()
and exec_mmap() - everything now survives OK.

   - Make the VFS pass the struct nameidata as an optional parameter
     to the permission() inode operation.

   - Patch may_create()/may_open() so it passes the struct nameidata from
     vfs_create()/open_namei() as an argument to permission().

   - Add an intent flag for the sys_access() function.

 - Add open intent information to the 'struct nameidata'.
 - Pass the struct nameidata as an optional parameter to the
   lookup() inode operation.
 - Pass the struct nameidata as an optional parameter to the
   d_revalidate() dentry operation.
 - Make link_path_walk() set the LOOKUP_CONTINUE flag in nd->flags instead
   of passing it as an extra parameter to d_revalidate().
 - Make open_namei(), and sys_uselib() set the open()/create() intent
   data.

If load_elf_binary() (and the other binary handlers) fail after
flush_old_exec() (for example, in setup_arg_pages()) then do_execve() will go
through and do mmdrop(bprm.mm).

But bprm.mm is now current->mm.  We've just freed the current process's mm.
The kernel dies in a most ghastly manner.

Fix that up by nulling out bprm.mm in flush_old_exec(), at the point where we
consumed the mm.  Handle the null pointer in the do_execve() error path.

Also: don't open-code free_arg_pages() in do_execve(): call it instead.

From: Stephen Smalley <sds@epoch.ncsc.mil>

This patch against 2.5.73 replaces vm_enough_memory with a security hook
per Alan Cox's suggestion so that security modules can completely replace
the logic if desired.

Note that the patch changes the interface to follow the convention of the
other security hooks, i.e.  return 0 if ok or -errno on failure (-ENOMEM in
this case) rather than returning a boolean.  It also exports various
variables and functions required for the vm_enough_memory logic.

From: Ingo Molnar <mingo@elte.hu>

Apparently this BUG is triggerable due to correct and expected events.

From: Manfred Spraul <manfred@colorfullife.com>

de_thread is called by exec to kill all threads in the thread group except
the threads required for exec.

The waiting is implemented by waiting for a wakeup from __exit_signal: If
the reference count is less or equal to 2, then the waiter is woken up.  If
exec is called by a non-leader thread, then two threads are required for
exec.

But if a thread group leader calls exec, then only one thread is required
for exec.  Thus the hardcoded "2" leads to a superfluous wakeup.  The patch
fixes that by adding a "notify_count" field to the signal structure.

__unhash_process acquires the dcache_lock while holding the
tasklist_lock for writing. This can deadlock. Additionally,
fs/proc/base.c incorrectly assumed that p->pid would be set to 0 during
release_task.

The patch fixes that by adding a new spinlock to the task structure and
fixing all references to (!p->pid).

The alternative to the new spinlock would be to hold dcache_lock around
__unhash_process.

- fs/proc/base.c assumed that p->pid is reset to 0 during exit.  This is
  not the case anymore.  I now look at the count of the pid structure for
  PIDTYPE_PID.

- de_thread now tested - as broken as it was before: open handles to
  /proc/<pid> are either stale or invalid after an exec of a nptl process,
  if the exec was call from a secondary thread.

- a few lock_kernels removed - that part of /proc doesn't need it.

- additional instances of 'if(current->pid)' replaced with pid_alive.

This is what a lot of the callers really wanted.

put_dirty_page() currently assumes PAGE_COPY for the stack page's ptes.  But
for x86_64 (at least) this is not the case.

The patch adds the extra arg to put_dirty_page(), updates all callers and fixes
x86_64.

Time to write a 2M file, one byte at a time:

Before:
        1.09s user 4.92s system 99% cpu 6.014 total
        0.74s user 5.28s system 99% cpu 6.023 total
        1.03s user 4.97s system 100% cpu 5.991 total

After:
	0.79s user 5.17s system 99% cpu 5.993 total
	0.79s user 5.17s system 100% cpu 5.957 total
	0.84s user 5.11s system 100% cpu 5.942 total

From: David Mosberger <davidm@napali.hpl.hp.com>

The patch below is needed to make it possible to map stack pages
without execution permission (as we do on ia64).

From: Hugh Dickins <hugh@veritas.com>

This patch removes the long deprecated flush_page_to_ram.  We have
two different schemes for doing this cache flushing stuff, the old
flush_page_to_ram way and the not so old flush_dcache_page etc. way:
see DaveM's Documentation/cachetlb.txt.  Keeping flush_page_to_ram
around is confusing, and makes it harder to get this done right.

All architectures are updated, but the only ones where it amounts
to more than deleting a line or two are m68k, mips, mips64 and v850.

I followed a prescription from DaveM (though not to the letter), that
those arches with non-nop flush_page_to_ram need to do what it did
in their clear_user_page and copy_user_page and flush_dcache_page.

Dave is consterned that, in the v850 nb85e case, this patch leaves its
flush_dcache_page as was, uses it in clear_user_page and copy_user_page,
instead of making them all flush icache as well.  That may be wrong:
I'm just hesitant to add cruft blindly, changing a flush_dcache macro
to flush icache too; and naively hope that the necessary flush_icache
calls are already in place.  Miles, please let us know which way is
right for v850 nb85e - thanks.

From Christoph Hellwig I think

Patch from Robert Love <rml@tech9.net>

This patch is by Inaky Perez-Gonzalez.

There are a couple uses of 'p->state=foo' in fs/ which are open coded.
This patch converts them to the proper [__]set_current_state() function.

Make kmod force default handlers before executing the user process.

This is version 23 or so of the POSIX timer code.

Internal changelog:

 - Changed the signals code to match the new order of things.  Also the
   new xtime_lock code needed to be picked up.  It made some things a lot
   simpler.

 - Fixed a spin lock hand off problem in locking timers (thanks
   to Randy).

 - Fixed nanosleep to test for out of bound nanoseconds
   (thanks to Julie).

 - Fixed a couple of id deallocation bugs that left old ids
   laying around (hey I get this one).

 - This version has a new timer id manager.  Andrew Morton
   suggested elimination of recursion (done) and I added code
   to allow it to release unused nodes.  The prior version only
   released the leaf nodes.  (The id manager uses radix tree
   type nodes.)  Also added is a reuse count so ids will not
   repeat for at least 256 alloc/ free cycles.

 - The changes for the new sys_call restart now allow one
   restart function to handle both nanosleep and clock_nanosleep.
   Saves a bit of code, nice.

 - All the requested changes and Lindent too :).

 - I also broke clock_nanosleep() apart much the same way
   nanosleep() was with the 2.5.50-bk5 changes.

TIMER STORMS

The POSIX clocks and timers code prevents "timer storms" by
not putting repeating timers back in the timer list until
the signal is delivered for the prior expiry.  Timer events
missed by this delay are accounted for in the timer overrun
count.  The net result is MUCH lower system overhead while
presenting the same info to the user as would be the case if
an interrupt and timer processing were required for each
increment in the overrun count.

This is required to get make the old LinuxThread semantics work
together with the fixed-for-POSIX full signal sharing. A traditional
CLONE_SIGHAND thread (LinuxThread) will not see any other shared
signal state, while a new-style CLONE_THREAD thread will share all
of it.

This way the two methods don't confuse each other.

this is the current threading patchset, which accumulated up during the
past two weeks. It consists of a biggest set of changes from Roland, to
make threaded signals work. There were still tons of testcases and
boundary conditions (mostly in the signal/exit/ptrace area) that we did
not handle correctly.

Roland's thread-signal semantics/behavior/ptrace fixes:

 - fix signal delivery race with do_exit() => signals are re-queued to the
   'process' if do_exit() finds pending unhandled ones. This prevents
   signals getting lost upon thread-sys_exit().

 - a non-main thread has died on one processor and gone to TASK_ZOMBIE,
   but before it's gotten to release_task a sys_wait4 on the other
   processor reaps it.  It's only because it's ptraced that this gets
   through eligible_child.  Somewhere in there the main thread is also
   dying so it reparents the child thread to hit that case.  This means
   that there is a race where P might be totally invalid.

 - forget_original_parent is not doing the right thing when the group
   leader dies, i.e. reparenting threads to init when there is a zombie
   group leader.  Perhaps it doesn't matter for any practical purpose
   without ptrace, though it makes for ppid=1 for each thread in core
   dumps, which looks funny. Incidentally, SIGCHLD here really should be
   p->exit_signal.

 - one of the gdb tests makes a questionable assumption about what kill
   will do when it has some threads stopped by ptrace and others running.

exit races:

1. Processor A is in sys_wait4 case TASK_STOPPED considering task P.
   Processor B is about to resume P and then switch to it.

   While A is inside that case block, B starts running P and it clears
   P->exit_code, or takes a pending fatal signal and sets it to a new
   value. Depending on the interleaving, the possible failure modes are:
        a. A gets to its put_user after B has cleared P->exit_code
           => returns with WIFSTOPPED, WSTOPSIG==0
        b. A gets to its put_user after B has set P->exit_code anew
           => returns with e.g. WIFSTOPPED, WSTOPSIG==SIGKILL

   A can spend an arbitrarily long time in that case block, because
   there's getrusage and put_user that can take page faults, and
   write_lock'ing of the tasklist_lock that can block.  But even if it's
   short the race is there in principle.

2. This is new with NPTL, i.e. CLONE_THREAD.
   Two processors A and B are both in sys_wait4 case TASK_STOPPED
   considering task P.

   Both get through their tests and fetches of P->exit_code before either
   gets to P->exit_code = 0.  => two threads return the same pid from
   waitpid.

   In other interleavings where one processor gets to its put_user after
   the other has cleared P->exit_code, it's like case 1(a).


3. SMP races with stop/cont signals

   First, take:

        kill(pid, SIGSTOP);
        kill(pid, SIGCONT);

   or:

        kill(pid, SIGSTOP);
        kill(pid, SIGKILL);

   It's possible for this to leave the process stopped with a pending
   SIGCONT/SIGKILL.  That's a state that should never be possible.
   Moreover, kill(pid, SIGKILL) without any repetition should always be
   enough to kill a process.  (Likewise SIGCONT when you know it's
   sequenced after the last stop signal, must be sufficient to resume a
   process.)

4. take:

        kill(pid, SIGKILL);     // or any fatal signal
        kill(pid, SIGCONT);     // or SIGKILL

    it's possible for this to cause pid to be reaped with status 0
    instead of its true termination status.  The equivalent scenario
    happens when the process being killed is in an _exit call or a
    trap-induced fatal signal before the kills.

plus i've done stability fixes for bugs that popped up during
beta-testing, and minor tidying of Roland's changes:

 - a rare tasklist corruption during exec, causing some very spurious and
   colorful crashes.

 - a copy_process()-related dereference of already freed thread structure
   if hit with a SIGKILL in the wrong moment.

 - SMP spinlock deadlocks in the signal code

this patchset has been tested quite well in the 2.4 backport of the
threading changes - and i've done some stresstesting on 2.5.59 SMP as
well, and did an x86 UP testcompile + testboot as well.

There are several places in which the return value from pte_chain_alloc() is
not being checked, and one place in which a GFP_KERNEL allocatiopn is
happening inside spinlock.

Patch from Manfred Spraul <manfred@colorfullife.com>

exec of setuid apps and ptrace must be synchronized, to ensure that a normal
user cannot ptrace a setuid app across exec.  ptrace_attach acquires the
task_lock around the uid checks, compute_creds acquires the BLK.  The patch
converts compute_creds to the task_lock.  Additionally, it removes the
do_unlock variable: the task_lock is not heaviliy used, there is no need to
avoid the spinlock by adding branches.

The patch is a cleanup patch, not a fix for a security problem: AFAICS the
sys_ptrace in every arch acquires the BKL before calling ptrace_attach.

sense now that we can dump all threads in one core-dump.

Fix from MAEDA Naoaki <maeda.naoaki@jp.fujitsu.com>

Patch from Michael Hohnbaum

This adds a hook, sched_balance_exec(), to the exec code, to make it
place the exec'ed task on the least loaded queue. We have less state
to move at exec time than fork time, so this is the cheapest point
to cross-node migrate. Experience in Dynix/PTX and testing on Linux
has confirmed that this is the cheapest time to move tasks between nodes.

It also macro-wraps changes to nr_running, to allow us to keep track of
per-node nr_running as well. Again, no impact on non-NUMA machines.

to properly de-activate it and make the child_tid logic work
correctly.

Clear %fs/%gs in deactivate_mm() on x86, since our LDT will no
longer be valid after this.

Update mm_release() to deactivate MM state before releasing,
and avoid the expensive child_tid FUTEX if we're the last user
of the MM.

Update page_add_rmap() callers to allocate their own pte_chain structures,
and to pass those into page_add_rmap().

The swapoff path has not yet been updated and is still oopsable.  The locking
there is tricky.

completly remove the old try_inc_mod_count()

A second start at removing them from kernel/*.c and fs/*.c.

Note that module_put is fine for a NULL argument.

This fixes one more threaded-coredumps detail reported by the glibc
people: all threads taken down by the coredump code should report the
proper exit code.  We can do this rather easily via the group_exit
mechanism.  'Other' threads used to report SIGKILL, which was highly
confusing as the shell often displayed the 'Killed' message instead of a
'Segmentation fault' message.

Another missing bit was the 0x80 bit set in the exit status for all
threads, if the coredump was successful.  (it's safe to set this bit in
->sig->group_exit_code in an unlocked way because all threads are
artificially descheduled by the coredump code.)

From:  Marcus Alanen <maalanen@ra.abo.fi>

  As far as I can see, setup_arg_pages code is hosed for the
  ARCH_STACK_GROWSUP case, completely wrong types...

  Does any arch even use this?

This fixes threaded coredumps and streamlines the code.  The old code
caused crashes and hung coredumps.  The new code has been tested for
some time already and appears to be robust.  Changes:

 - the code now uses completions instead of a semaphore and a waitqueue,
   attached to mm_struct:

        /* coredumping support */
        int core_waiters;
        struct completion *core_startup_done, core_done;

 - extended the completion concept with a 'complete all' call - all pending
   threads are woken up in that case.

 - core_waiters is a plain integer now - it's always accessed from under
   the mmap_sem. It's also used as the fastpath-check in the sys_exit()
   path, instead of ->dumpable (which was incorrect).

 - got rid of the ->core_waiter task flag - it's not needed anymore.

This cleans up the dcache code to always use the proper dcache functions
(d_unhashed and __d_drop) instead of accessing the dentry lists
directly.

In other words: use "d_unhashed(dentry)" instead of doing a manual
"list_empty(&dentry->d_hash)" test.  And use "__d_drop(dentry)" instead
of doing "list_del_init(&dentry->d_hash)" by hand.

This will help the dcache-rcu patches.

This is a preparation to get rid of the implicit includes in
dcache.h and fs_struct.h.

Stub out put_dirty_page and setup_arg_pages for !CONFIG_MMU and add
free_arg_pages that frees all arg pages (noop for CONFIG_MMU)