Commit 37bebc70d7ad4144c571d74500db3bb26ec0c0eb

Authored by Oleg Nesterov
Committed by Ingo Molnar
1 parent d56ffd38a9

posix timers: fix RLIMIT_CPU && fork()

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 cpu timers.

This is the minimal fix for 2.6.29 (tested) and 2.6.28. The patch is not
optimal, we need further cleanups here. With this patch update_rlimit_cpu()
is not really needed, but I don't think it should be removed.

The proper fix (I think) is:

	- set_process_cpu_timer() should just start the cputimer->running
	  logic (it does), no need to change cputime_expires.xxx_exp

	- posix_cpu_timers_init_group() should set ->running when needed

	- fastpath_timer_check() can check ->running instead of
	  task_cputime_zero(signal->cputime_expires)

Reported-by: Peter Lojkin <ia6432@inbox.ru>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Roland McGrath <roland@redhat.com>
Cc: <stable@kernel.org> [for 2.6.29.x]
LKML-Reference: <20090323193411.GA17514@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

Showing 1 changed file with 2 additions and 1 deletions Side-by-side Diff

kernel/posix-cpu-timers.c
... ... @@ -1370,7 +1370,8 @@
1370 1370 if (task_cputime_expired(&group_sample, &sig->cputime_expires))
1371 1371 return 1;
1372 1372 }
1373   - return 0;
  1373 +
  1374 + return sig->rlim[RLIMIT_CPU].rlim_cur != RLIM_INFINITY;
1374 1375 }
1375 1376  
1376 1377 /*