user/sven/linux.git/kernel, branch v2.6.17.2

[PATCH] Link error when futexes are disabled on 64bit architectures

2006-06-30T00:17:17Z

From: Anton Blanchard If futexes are disabled we fail to link on ppc64. Signed-off-by: Anton Blanchard Cc: Signed-off-by: Andrew Morton Signed-off-by: Chris Wright

[PATCH] arm_timer: remove a racy and obsolete PF_EXITING check

2006-06-17T17:52:13Z

arm_timer() checks PF_EXITING to prevent BUG_ON(->exit_state) in run_posix_cpu_timers(). However, for some reason it does so only for CPUCLOCK_PERTHREAD case (which is imho wrong). Also, this check is not reliable, PF_EXITING could be set on another cpu without any locks/barriers just after the check, so it can't prevent from attaching the timer to the exiting task. The previous patch makes this check unneeded. Signed-off-by: Oleg Nesterov Signed-off-by: Linus Torvalds

[PATCH] run_posix_cpu_timers: remove a bogus BUG_ON()

2006-06-17T17:52:13Z

do_exit() clears ->it_##clock##_expires, but nothing prevents another cpu to attach the timer to exiting process after that. arm_timer() tries to protect against this race, but the check is racy. After exit_notify() does 'write_unlock_irq(&tasklist_lock)' and before do_exit() calls 'schedule() local timer interrupt can find tsk->exit_state != 0. If that state was EXIT_DEAD (or another cpu does sys_wait4) interrupted task has ->signal == NULL. At this moment exiting task has no pending cpu timers, they were cleanuped in __exit_signal()->posix_cpu_timers_exit{,_group}(), so we can just return from irq. John Stultz recently confirmed this bug, see http://marc.theaimsgroup.com/?l=linux-kernel&m=115015841413687 Signed-off-by: Oleg Nesterov Signed-off-by: Linus Torvalds

[PATCH] check_process_timers: fix possible lockup

2006-06-17T17:52:13Z

If the local timer interrupt happens just after do_exit() sets PF_EXITING (and before it clears ->it_xxx_expires) run_posix_cpu_timers() will call check_process_timers() with tasklist_lock + ->siglock held and check_process_timers: t = tsk; do { .... do { t = next_thread(t); } while (unlikely(t->flags & PF_EXITING)); } while (t != tsk); the outer loop will never stop. Actually, the window is bigger. Another process can attach the timer after ->it_xxx_expires was cleared (see the next commit) and the 'if (PF_EXITING)' check in arm_timer() is racy (see the one after that). Signed-off-by: Oleg Nesterov Signed-off-by: Linus Torvalds

[PATCH] hrtimer: export symbols

2006-05-31T23:27:11Z

From: Stephen Hemminger I want to use the hrtimer's in the netem (Network Emulator) qdisc. But the necessary symbols aren't exported for module use. Also needed by SystemTap. Signed-off-by: Stephen Hemminger Acked-by: Ingo Molnar Cc: Thomas Gleixner Cc: "Stone, Joshua I" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Revert "[PATCH] sched: fix interactive task starvation"

2006-05-22T01:54:09Z

This reverts commit 5ce74abe788a26698876e66b9c9ce7e7acc25413 (and its dependent commit 8a5bc075b8d8cf7a87b3f08fad2fba0f5d13295e), because of audio underruns. Reported by Rene Herman , who also pinpointed the exact cause of the underruns: "Audio underruns galore, with only ogg123 and firefox (browsing the GIT tree online is also a nice trigger by the way). If I back it out, everything is fine for me again." Cc: Rene Herman Cc: Mike Galbraith Acked-by: Con Kolivas Signed-off-by: Linus Torvalds

[PATCH] Fix a NO_IDLE_HZ timer bug

2006-05-21T19:59:21Z

Under certain timing conditions, a race during boot occurs where timer ticks are being processed on remote CPUs. The remote timer ticks can increment jiffies, and if this happens during a window when a timeout is very close to expiring but a local tick has not yet been delivered, you can end up with 1) No softirq pending 2) A local timer wheel which is not synced to jiffies 3) No high resolution timer active 4) A local timer which is supposed to fire before the current jiffies value. In this circumstance, the comparison in next_timer_interrupt overflows, because the base of the comparison for high resolution timers is jiffies, but for the softirq timer wheel, it is relative the the current base of the wheel (jiffies_base). Signed-off-by: Zachary Amsden Cc: Martin Schwidefsky Cc: Oleg Nesterov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] cpuset: might_sleep_if check in cpuset_zones_allowed

2006-05-21T19:59:18Z

It's too easy to incorrectly call cpuset_zone_allowed() in an atomic context without __GFP_HARDWALL set, and when done, it is not noticed until a tight memory situation forces allocations to be tried outside the current cpuset. Add a 'might_sleep_if()' check, to catch this earlier on, instead of waiting for a similar check in the mutex_lock() code, which is only rarely invoked. Signed-off-by: Paul Jackson Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] cpuset: update cpuset_zones_allowed comment

2006-05-21T19:59:18Z

Update the kernel/cpuset.c:cpuset_zone_allowed() comment. The rule for when mm/page_alloc.c should call cpuset_zone_allowed() was intended to be: Don't call cpuset_zone_allowed() if you can't sleep, unless you pass in the __GFP_HARDWALL flag set in gfp_flag, which disables the code that might scan up ancestor cpusets and sleep. The explanation of this rule in the comment above cpuset_zone_allowed() was stale, as a result of a restructuring of some __alloc_pages() code in November 2005. Rewrite that comment ... Signed-off-by: Paul Jackson Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] symbol_put_addr() locks kernel

2006-05-15T18:20:55Z

Even since a previous patch: Fix race between CONFIG_DEBUG_SLABALLOC and modules Sun, 27 Jun 2004 17:55:19 +0000 (17:55 +0000) http://www.kernel.org/git/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;a=commit;h=92b3db26d31cf21b70e3c1eadc56c179506d8fbe The function symbol_put_addr() will deadlock the kernel. symbol_put_addr() would acquire modlist_lock, then while holding the lock call two functions kernel_text_address() and module_text_address() which also try to acquire the same lock. This deadlocks the kernel of course. This patch changes symbol_put_addr() to not acquire the modlist_lock, it doesn't need it since it never looks at the module list directly. Also, it now uses core_kernel_text() instead of kernel_text_address(). The latter has an additional check for addr inside a module, but we don't need to do that since we call module_text_address() (the same function kernel_text_address uses) ourselves. Signed-off-by: Trent Piepho Cc: Zwane Mwaikambo Acked-by: Rusty Russell Cc: Johannes Stezenbach Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds