commit fa490cfd15d7ce0900097cc4e60cfd7a76381138 Author: Linus Torvalds Date: Mon Jun 18 09:34:40 2007 -0700 Fix possible runqueue lock starvation in wait_task_inactive() Miklos Szeredi reported very long pauses (several seconds, sometimes more) on his T60 (with a Core2Duo) which he managed to track down to wait_task_inactive()'s open-coded busy-loop. He observed that an interrupt on one core tries to acquire the runqueue-lock but does not succeed in doing so for a very long time - while wait_task_inactive() on the other core loops waiting for the first core to deschedule a task (which it wont do while spinning in an interrupt handler). This rewrites wait_task_inactive() to do all its waiting optimistically without any locks taken at all, and then just double-check the end result with the proper runqueue lock held over just a very short section. If there were races in the optimistic wait, of a preemption event scheduled the process away, we simply re-synchronize, and start over. So the code now looks like this: repeat: /* Unlocked, optimistic looping! */ rq = task_rq(p); while (task_running(rq, p)) cpu_relax(); /* Get the *real* values */ rq = task_rq_lock(p, &flags); running = task_running(rq, p); array = p->array; task_rq_unlock(rq, &flags); /* Check them.. */ if (unlikely(running)) { cpu_relax(); goto repeat; } /* Preempted away? Yield if so.. */ if (unlikely(array)) { yield(); goto repeat; } Basically, that first "while()" loop is done entirely without any locking at all (and doesn't check for the case where the target process might have been preempted away), and so it's possibly "incorrect", but we don't really care. Both the runqueue used, and the "task_running()" check might be the wrong tests, but they won't oops - they just mean that we could possibly get the wrong results due to lack of locking and exit the loop early in the case of a race condition. So once we've exited the loop, we then get the proper (and careful) rq lock, and check the running/runnable state _safely_. And if it turns out that our quick-and-dirty and unsafe loop was wrong after all, we just go back and try it all again. (The patch also adds a lot of comments, which is the actual bulk of it all, to make it more obvious why we can do these things without holding the locks). Thanks to Miklos for all the testing and tracking it down. Tested-by: Miklos Szeredi Acked-by: Ingo Molnar Signed-off-by: Linus Torvalds commit a0f98a1cb7d27c656de450ba56efd31bdc59065e Author: Ingo Molnar Date: Sun Jun 17 18:37:45 2007 +0200 sched: fix SysRq-N (normalize RT tasks) Gene Heskett reported the following problem while testing CFS: SysRq-N is not always effective in normalizing tasks back to SCHED_OTHER. The reason for that turns out to be the following bug: - normalize_rt_tasks() uses for_each_process() to iterate through all tasks in the system. The problem is, this method does not iterate through all tasks, it iterates through all thread groups. The proper mechanism to enumerate over all threads is to use a do_each_thread() + while_each_thread() loop. Reported-by: Gene Heskett Signed-off-by: Ingo Molnar Signed-off-by: Linus Torvalds commit 4cc21505a09354ade787de368bd697a1bba3b213 Merge: caec4e8... 204abf2... Author: Linus Torvalds Date: Mon Jun 18 10:38:09 2007 -0700 Merge master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6 * master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6: [SCSI] ESP: Don't forget to clear ESP_FLAG_RESETTING. [SCSI] fusion: fix for BZ 8426 - massive slowdown on SCSI CD/DVD drive commit caec4e8dc85e0644ec24aeb36285e1ba02da58cc Author: Benjamin Herrenschmidt Date: Tue Jun 12 08:16:18 2007 +1000 Fix signalfd interaction with thread-private signals Don't let signalfd dequeue private signals off other threads (in the case of things like SIGILL or SIGSEGV, trying to do so would result in undefined behaviour on who actually gets the signal, since they are force unblocked). Signed-off-by: Benjamin Herrenschmidt Acked-by: Davide Libenzi Signed-off-by: Linus Torvalds commit bd197234b0a616c8f04f6b682326a5a24b33ca92 Author: Thomas Gleixner Date: Sun Jun 17 21:11:10 2007 +0200 Revert "futex_requeue_pi optimization" This reverts commit d0aa7a70bf03b9de9e995ab272293be1f7937822. It not only introduced user space visible changes to the futex syscall, it is also non-functional and there is no way to fix it proper before the 2.6.22 release. The breakage report ( http://lkml.org/lkml/2007/5/12/17 ) went unanswered, and unfortunately it turned out that the concept is not feasible at all. It violates the rtmutex semantics badly by introducing a virtual owner, which hacks around the coupling of the user-space pi_futex and the kernel internal rt_mutex representation. At the moment the only safe option is to remove it fully as it contains user-space visible changes to broken kernel code, which we do not want to expose in the 2.6.22 release. The patch reverts the original patch mostly 1:1, but contains a couple of trivial manual cleanups which were necessary due to patches, which touched the same area of code later. Verified against the glibc tests and my own PI futex tests. Signed-off-by: Thomas Gleixner Acked-by: Ingo Molnar Acked-by: Ulrich Drepper Cc: Pierre Peiffer Signed-off-by: Linus Torvalds commit 204abf28679cd55a8e254b18965583bb1c8bc739 Author: Thomas Bogendoerfer Date: Wed Jun 13 12:58:53 2007 -0700 [SCSI] ESP: Don't forget to clear ESP_FLAG_RESETTING. esp_reset_cleanup() does everything necessary except clear the flag, so we never exit resetting state. Signed-off-by: David S. Miller Signed-off-by: James Bottomley commit 29982e9acd3e81a289c73321401427d02eaa8adc Author: Doug Chapman Date: Mon May 7 15:59:46 2007 -0400 [SCSI] fusion: fix for BZ 8426 - massive slowdown on SCSI CD/DVD drive Patch for: http://bugzilla.kernel.org/show_bug.cgi?id=8426 A recent code cleanup that moved code from mptscsih to mptspi inadvertently change the order some code was called. This caused a massive slowdown (of 150x to 300x) on the CD/DVD drive on the high-end HP Integrity servers. Signed-off-by: Doug Chapman Acked-by: Eric Moore Signed-off-by: James Bottomley