linux-toradex.git/kernel, branch v2.6.29.4

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

Kill unsharing fs_struct in __set_personality()

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

commit 11d06b2a1e5658f448a308aa3beb97bacd64a940 upstream.

That's a rudiment of altroot support.  I.e. it should've been buried
a long time ago.

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

ptrace: ptrace_attach: fix the usage of ->cred_exec_mutex

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

commit cad81bc2529ab8c62b6fdc83a1c0c7f4a87209eb upstream.

ptrace_attach() needs task->cred_exec_mutex, not current->cred_exec_mutex.

Signed-off-by: Oleg Nesterov 
Acked-by: Roland McGrath 
Acked-by: David Howells 
Signed-off-by: James Morris 
Signed-off-by: Greg Kroah-Hartman

exit_notify: kill the wrong capable(CAP_KILL) check (CVE-2009-1337)

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

CVE-2009-1337

commit 432870dab85a2f69dc417022646cb9a70acf7f94 upstream.

The CAP_KILL check in exit_notify() looks just wrong, kill it.

Whatever logic we have to reset ->exit_signal, the malicious user
can bypass it if it execs the setuid application before exiting.

Signed-off-by: Oleg Nesterov 
Acked-by: Serge Hallyn 
Acked-by: Roland McGrath 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

hrtimer: fix rq->lock inversion (again)

2009-04-27T17:37:00+00:00

upstream commit: 7f1e2ca9f04b02794597f60e7b1d43f0a1317939

It appears I inadvertly introduced rq->lock recursion to the
hrtimer_start() path when I delegated running already expired
timers to softirq context.

This patch fixes it by introducing a __hrtimer_start_range_ns()
method that will not use raise_softirq_irqoff() but
__raise_softirq_irqoff() which avoids the wakeup.

It then also changes schedule() to check for pending softirqs and
do the wakeup then, I'm not quite sure I like this last bit, nor
am I convinced its really needed.

Signed-off-by: Peter Zijlstra 
Cc: Peter Zijlstra 
Cc: paulus@samba.org
LKML-Reference: <20090313112301.096138802@chello.nl>
Signed-off-by: Ingo Molnar 
Tested-by: Mikael Pettersson 
Signed-off-by: Chris Wright

posix-timers: fix RLIMIT_CPU && setitimer(CPUCLOCK_PROF)

2009-04-27T17:36:59+00:00

upstream commit: 8f2e586567b1bad72dac7c3810fe9a2ef7117506

update_rlimit_cpu() tries to optimize out set_process_cpu_timer() in case
when we already have CPUCLOCK_PROF timer which should expire first. But it
uses cputime_lt() instead of cputime_gt().

Test case:

	int main(void)
	{
		struct itimerval it = {
			.it_value = { .tv_sec = 1000 },
		};

		assert(!setitimer(ITIMER_PROF, &it, NULL));

		struct rlimit rl = {
			.rlim_cur = 1,
			.rlim_max = 1,
		};

		assert(!setrlimit(RLIMIT_CPU, &rl));

		for (;;)
			;

		return 0;
	}

Without this patch, the task is not killed as RLIMIT_CPU demands.

Signed-off-by: Oleg Nesterov 
Acked-by: Peter Zijlstra 
Cc: Peter Lojkin 
Cc: Roland McGrath 
Cc: stable@kernel.org
LKML-Reference: <20090327000610.GA10108@redhat.com>
Signed-off-by: Ingo Molnar 
Signed-off-by: Chris Wright

posix-timers: fix RLIMIT_CPU && fork()

2009-04-27T17:36:59+00:00

upstream commit: 6279a751fe096a21dc7704e918d570d3ff06e769

See http://bugzilla.kernel.org/show_bug.cgi?id=12911

copy_signal() copies signal->rlim, but RLIMIT_CPU is "lost". Because
posix_cpu_timers_init_group() sets cputime_expires.prof_exp = 0 and thus
fastpath_timer_check() returns false unless we have other expired cpu timers.

Change copy_signal() to set cputime_expires.prof_exp if we have RLIMIT_CPU.
Also, set cputimer.running = 1 in that case. This is not strictly necessary,
but imho makes sense.

Reported-by: Peter Lojkin 
Signed-off-by: Oleg Nesterov 
Acked-by: Peter Zijlstra 
Cc: Peter Lojkin 
Cc: Roland McGrath 
Cc: stable@kernel.org
LKML-Reference: <20090327000607.GA10104@redhat.com>
Signed-off-by: Ingo Molnar 
Signed-off-by: Chris Wright