linux-stable.git/kernel, branch linux-2.6.29.y

bsdacct: fix access to invalid filp in acct_on()

2009-07-02T23:41:00+00:00

commit df279ca8966c3de83105428e3391ab17690802a9 upstream.

The file opened in acct_on and freshly stored in the ns->bacct struct can
be closed in acct_file_reopen by a concurrent call after we release
acct_lock and before we call mntput(file->f_path.mnt).

Record file->f_path.mnt in a local variable and use this variable only.

Signed-off-by: Renaud Lottiaux 
Signed-off-by: Louis Rilling 
Cc: Al Viro 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

ptrace: fix possible zombie leak on PTRACE_DETACH

2009-06-15T16:40:20+00:00

commit 4576145c1ecdaaea9ef8976a48335206aa1ebf91 upstream.

When ptrace_detach() takes tasklist, the tracee can be SIGKILL'ed.  If it
has already passed exit_notify() we can leak a zombie, because a) ptracing
disables the auto-reaping logic, and b) ->real_parent was not notified
about the child's death.

ptrace_detach() should follow the ptrace_exit's logic, change the code
accordingly.

Signed-off-by: Oleg Nesterov 
Cc: Jerome Marchand 
Cc: Roland McGrath 
Tested-by: Denys Vlasenko 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

ptrace: reintroduce __ptrace_detach() as a callee of ptrace_exit()

2009-06-15T16:40:19+00:00

commit b1b4c6799fb59e710454bfe0ab477cb8523a8667 upstream.

No functional changes, preparation for the next patch.

Move the "should we release this child" logic into the separate handler,
__ptrace_detach().

Signed-off-by: Oleg Nesterov 
Cc: Jerome Marchand 
Cc: Roland McGrath 
Cc: Denys Vlasenko 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

ptrace: simplify ptrace_exit()->ignoring_children() path

2009-06-15T16:40:19+00:00

commit 6d69cb87f05eef3b02370b2f7bae608ad2301a00 upstream.

ignoring_children() takes parent->sighand->siglock and checks
k_sigaction[SIGCHLD] atomically.  But this buys nothing, we can't get the
"really" wrong result even if we race with sigaction(SIGCHLD).  If we read
the "stale" sa_handler/sa_flags we can pretend it was changed right after
the check.

Remove spin_lock(->siglock), and kill "int ign" which caches the result of
ignoring_children() which becomes rather trivial.

Perhaps it makes sense to export this helper, do_notify_parent() can use
it too.

Signed-off-by: Oleg Nesterov 
Cc: Jerome Marchand 
Cc: Roland McGrath 
Cc: Denys Vlasenko 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

ptrace: kill __ptrace_detach(), fix ->exit_state check

2009-06-15T16:40:18+00:00

commit 95c3eb76dc07fd81289888ffc42948196b34b444 upstream.

Move the code from __ptrace_detach() to its single caller and kill this
helper.

Also, fix the ->exit_state check, we shouldn't wake up EXIT_DEAD tasks.
Actually, I think task_is_stopped_or_traced() makes more sense, but this
needs another patch.

Signed-off-by: Oleg Nesterov 
Cc: Jerome Marchand 
Cc: Roland McGrath 
Cc: Denys Vlasenko 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

futex: setup writeable mapping for futex ops which modify user space data

2009-06-15T16:39:59+00:00

commit 64d1304a64477629cb16b75491a77bafe6f86963 upstream.

The futex code installs a read only mapping via get_user_pages_fast()
even if the futex op function has to modify user space data. The
eventual fault was fixed up by futex_handle_fault() which walked the
VMA with mmap_sem held.

After the cleanup patches which removed the mmap_sem dependency of the
futex code commit 4dc5b7a36a49eff97050894cf1b3a9a02523717 (futex:
clean up fault logic) removed the private VMA walk logic from the
futex code. This change results in a stale RO mapping which is not
fixed up.

Instead of reintroducing the previous fault logic we set up the
mapping in get_user_pages_fast() read/write for all operations which
modify user space data. Also handle private futexes in the same way
and make the current unconditional access_ok(VERIFY_WRITE) depend on
the futex op.

Reported-by: Andreas Schwab 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

sched: account system time properly

2009-05-08T22:45:12+00:00

commit f5f293a4e3d0a0c52cec31de6762c95050156516 upstream.

Andrew Gallatin reported that IRQ and SOFTIRQ times were
sometime not reported correctly on recent kernels, and even
bisected to commit 457533a7d3402d1d91fbc125c8bd1bd16dcd3cd4
([PATCH] fix scaled & unscaled cputime accounting) as the first
bad commit.

Further analysis pointed that commit
79741dd35713ff4f6fd0eafd59fa94e8a4ba922d ([PATCH] idle cputime
accounting) was the real cause of the problem.

account_process_tick() was not taking into account timer IRQ
interrupting the idle task servicing a hard or soft irq.

On mostly idle cpu, irqs were thus not accounted and top or
mpstat could tell user/admin that cpu was 100 % idle, 0.00 %
irq, 0.00 % softirq, while it was not.

[ Impact: fix occasionally incorrect CPU statistics in top/mpstat ]

Reported-by: Andrew Gallatin 
Re-reported-by: Andrew Morton 
Signed-off-by: Eric Dumazet 
Acked-by: Martin Schwidefsky 
Cc: rick.jones2@hp.com
Cc: brice@myri.com
Cc: Paul Mackerras 
Cc: Benjamin Herrenschmidt 
LKML-Reference: <49F84BC1.7080602@cosmosbay.com>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

clockevents: prevent endless loop in tick_handle_periodic()

2009-05-08T22:45:10+00:00

commit 74a03b69d1b5ce00a568e142ca97e76b7f5239c6 upstream.

tick_handle_periodic() can lock up hard when a one shot clock event
device is used in combination with jiffies clocksource.

Avoid an endless loop issue by requiring that a highres valid
clocksource be installed before we call tick_periodic() in a loop when
using ONESHOT mode. The result is we will only increment jiffies once
per interrupt until a continuous hardware clocksource is available.

Without this, we can run into a endless loop, where each cycle through
the loop, jiffies is updated which increments time by tick_period or
more (due to clock steering), which can cause the event programming to
think the next event was before the newly incremented time and fail
causing tick_periodic() to be called again and the whole process loops
forever.

[ Impact: prevent hard lock up ]

Signed-off-by: John Stultz 
Signed-off-by: Andrew Morton 
Signed-off-by: Thomas Gleixner 
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman

New locking/refcounting for fs_struct

2009-05-08T22:45:08+00:00

commit 498052bba55ecaff58db6a1436b0e25bfd75a7ff upstream.

* all changes of current->fs are done under task_lock and write_lock of
  old fs->lock
* refcount is not atomic anymore (same protection)
* its decrements are done when removing reference from current; at the
  same time we decide whether to free it.
* put_fs_struct() is gone
* new field - ->in_exec.  Set by check_unsafe_exec() if we are trying to do
  execve() and only subthreads share fs_struct.  Cleared when finishing exec
  (success and failure alike).  Makes CLONE_FS fail with -EAGAIN if set.
* check_unsafe_exec() may fail with -EAGAIN if another execve() from subthread
  is in progress.

Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman

Take fs_struct handling to new file (fs/fs_struct.c)

2009-05-08T22:45:07+00:00

commit 3e93cd671813e204c258f1e6c797959920cf7772 upstream.

Pure code move; two new helper functions for nfsd and daemonize
(unshare_fs_struct() and daemonize_fs_struct() resp.; for now -
the same code as used to be in callers).  unshare_fs_struct()
exported (for nfsd, as copy_fs_struct()/exit_fs() used to be),
copy_fs_struct() and exit_fs() don't need exports anymore.

Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman