commit a31a9035702124423c3aa5aa848937f165753a4f Author: Greg Kroah-Hartman Date: Sat Aug 4 09:11:13 2007 -0700 Linux 2.6.21.7 commit cb8b4a0fc6d8deb72b8fba4132d8344507775a05 Author: Jelle Foks Date: Tue Jul 10 00:03:02 2007 -0400 V4L: cx88-blackbird: fix vidioc_g_tuner never ending list of tuners v4l-info and other programs would loop indefinitely while querying the tuners for cx88-blackbird cards. The cause was that vidioc_g_tuner didn't return an error value for qctrl->id != 0, making the application think there is a never ending list of tuners... This patch adds the same index check as done in vidioc_g_tuner() in cx88-video. Signed-off-by: Jelle Foks Signed-off-by: Michael Krufky Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit b13e6270f923cfa63a62343f6aef13fba4d252ce Author: Trent Piepho Date: Tue Jul 10 00:03:01 2007 -0400 V4L: bttv: fix v4l1 api usage breaking the driver If one uses a V4L *one* application, such as vlc or mplayer's v4l driver, as the first user after the driver is loaded, the driver wedges itself and will never capture properly. Even if one uses a V4L2 application later, it still won't work. If one uses a V4L *two* application first, such as tvtime or mplayer's v4l2 driver, then the driver will be ok. One can then run a V4L1 application, and it will work. It turns out the problem is with norm changing and the crop support that was added in 2.6.21. The driver defaults to PAL, and keeps the last norm it was set too across opens. If one changes the norm via V4L1, the cropping parameters are not reset like they should be, and they'll remain broken across device opens. This patch removes the direct setting of btv->tvnorm in the V4L1 ioctl VIDIOCSCHAN handler. The norm is set via the existing call to set_input(), which calls set_tvnorm(), which will reset the cropping values now that it is able to detect the norm change. Signed-off-by: Trent Piepho Signed-off-by: Michael Krufky Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit fe1fe7c982f86624c692644e8ed05e132f4753cc Author: Stephen Hemminger Date: Mon Jul 9 12:01:31 2007 -0700 sky2: workaround for lost IRQ This patch restores a couple of workarounds from 2.6.16: * restart transmit moderation timer in case it expires during IRQ routine * default to having 10 HZ watchdog timer. At this point it more important not to hang than to worry about the power cost. Signed-off-by: Stephen Hemminger Cc: Jeff Garzik Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 46164b51f5bcc2bba19d66b46297bb97195e35dd Author: Thomas Gleixner Date: Tue Jul 3 20:05:20 2007 +0200 NTP: remove clock_was_set() call to prevent deadlock The clock_was_set() call in seconds_overflow() which happens only when leap seconds are inserted / deleted is wrong in two aspects: 1. it results in a call to on_each_cpu() with interrupts disabled 2. it is potential deadlock source vs. call_lock in smp_call_function() The only possible side effect of the removal might be, that an absolute CLOCK_REALTIME timer fires 1 second too late, in the rare case of leap second deletion and an absolute CLOCK_REALTIME timer which expires in the affected time frame. It will never fire too early. This was probably observed by the reporter of a June 30th -> July 1st hang: http://lkml.org/lkml/2007/7/3/ A similar problem was observed by Dave Jones, who provided a screen shot with a lockdep back trace, which allowed to analyse the problem. Signed-off-by: Thomas Gleixner Cc: john stultz Cc: Dave Jones Cc: Ingo Molnar Cc: Vincent Fortier Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit bf35c3779ab61aa93e912679d6c30a8b689e443e Author: Jason Wessel Date: Mon Jul 2 15:53:44 2007 -0500 i386: fix infinite loop with singlestep int80 syscalls The commit 635cf99a80f4ebee59d70eb64bb85ce829e4591f introduced a regression. Executing a ptrace single step after certain int80 accesses will infinitely loop and never advance the PC. The TIF_SINGLESTEP check should be done on the return from the syscall and not before it. The new test case is below: /* Test whether singlestep through an int80 syscall works. */ #define _GNU_SOURCE #include #include #include #include #include #include #include #include static int child, status; static struct user_regs_struct regs; static void do_child() { char str[80] = "child: int80 test\n"; ptrace(PTRACE_TRACEME, 0, 0, 0); kill(getpid(), SIGUSR1); write(fileno(stdout),str,strlen(str)); asm ("int $0x80" : : "a" (20)); /* getpid */ } static void do_parent() { unsigned long eip, expected = 0; again: waitpid(child, &status, 0); if (WIFEXITED(status) || WIFSIGNALED(status)) return; if (WIFSTOPPED(status)) { ptrace(PTRACE_GETREGS, child, 0, ®s); eip = regs.eip; if (expected) fprintf(stderr, "child stop @ %08lx, expected %08lx %s\n", eip, expected, eip == expected ? "" : " <== ERROR"); if (*(unsigned short *)eip == 0x80cd) { fprintf(stderr, "int 0x80 at %08x\n", (unsigned int)eip); expected = eip + 2; } else expected = 0; ptrace(PTRACE_SINGLESTEP, child, NULL, NULL); } goto again; } int main(int argc, char * const argv[]) { child = fork(); if (child) do_parent(); else do_child(); return 0; } Signed-off-by: Jason Wessel Cc: Jeremy Fitzhardinge Cc: Chuck Ebbert Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit ed9ee0878e14d15d76ee792cac38def9d34f7f68 Author: Jay Lubomirski Date: Wed Jun 27 14:10:09 2007 -0700 serial: clear proper MPSC interrupt cause bits The interrupt clearing code in mpsc_sdma_intr_ack() mistakenly clears the interrupt for both controllers instead of just the one its supposed to. This can result in the other controller appearing to hang because its interrupt was effectively lost. So, don't clear the interrupt cause bits for both MPSC controllers when clearing the interrupt for one of them. Just clear the one that is supposed to be cleared. Signed-off-by: Jay Lubomirski Acked-by: Mark A. Greer Signed-off-by: Andrew Morton Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit e278ed8f82fd26097a2ed8772c1211f6c5865ce1 Author: Jeff Mahoney Date: Wed Jun 27 14:09:58 2007 -0700 saa7134: fix thread shutdown handling This patch changes the test for the thread pid from >= 0 to > 0. When the saa7134 driver initialization fails after a certain point, it goes through the complete shutdown process for the driver. Part of shutting it down includes tearing down the thread for tv audio. The test for tearing down the thread tests for >= 0. Since the dev structure is kzalloc'd, the test will always be true if we haven't tried to start the thread yet. We end up waiting on pid 0 to complete, which will never happen, so we lock up. This bug was observed in Novell Bugzilla 284718, when request_irq() failed. Signed-off-by: Jeff Mahoney Acked-by: Mauro Carvalho Chehab Signed-off-by: Andrew Morton Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 19210a2049713f5d5ea826ecf053ca671aeb53c7 Author: Hugh Dickins Date: Wed Jun 27 14:09:53 2007 -0700 mm: kill validate_anon_vma to avoid mapcount BUG validate_anon_vma gave a useful check on the integrity of the anon_vma list when Andrea was developing obj rmap; but it was not enabled in SLES9 itself, nor in mainline, until Nick changed commented-out RMAP_DEBUG to configurable CONFIG_DEBUG_VM in 2.6.17. Now Petr Vandrovec reports that its BUG_ON(mapcount > 100000) can easily crash a CONFIG_DEBUG_VM=y system. That limit was just an arbitrary number to protect against an infinite loop. We could raise it to something enormous (depending on sizeof struct vma and size of memory?); but I rather think validate_anon_vma has outlived its usefulness, and is better just removed - which gives a magnificent performance boost to anything like Petr's test program ;) Of course, a very long anon_vma list is bad news for preemption latency, and I believe there has been one recent report of such: let's not forget that, but validate_anon_vma only makes it worse not better. Signed-off-by: Hugh Dickins Cc: Petr Vandrovec Acked-by: Nick Piggin Cc: Andrea Arcangeli Signed-off-by: Andrew Morton Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit e1a4335b08cf41180537ec4d1d84ddc74cdddabc Author: Paul Mackerras Date: Tue Jun 26 20:10:12 2007 +1000 POWERPC: Fix subtle FP state corruption bug in signal return on SMP This fixes a bug which can cause corruption of the floating-point state on return from a signal handler. If we have a signal handler that has used the floating-point registers, and it happens to context-switch to another task while copying the interrupted floating-point state from the user stack into the thread struct (e.g. because of a page fault, or because it gets preempted), the context switch code will think that the FP registers contain valid FP state that needs to be copied into the thread_struct, and will thus overwrite the values that the signal return code has put into the thread_struct. This can occur because we clear the MSR bits that indicate the presence of valid FP state after copying the state into the thread_struct. To fix this we just move the clearing of the MSR bits to before the copy. A similar potential problem also occurs with the Altivec state, and this fixes that in the same way. Signed-off-by: Paul Mackerras Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 3072fe887a76e49d224e30bfc1cab81b6504ab1b Author: Tony Jones Date: Sat Jun 23 17:16:47 2007 -0700 audit: fix oops removing watch if audit disabled Removing a watched file will oops if audit is disabled (auditctl -e 0). To reproduce: - auditctl -e 1 - touch /tmp/foo - auditctl -w /tmp/foo - auditctl -e 0 - rm /tmp/foo (or mv) Signed-off-by: Tony Jones Cc: Al Viro Signed-off-by: Andrew Morton Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 8e9a9197b255bbbed3e674a5d1e6b6516c1f027b Author: Thomas Gleixner Date: Sat Jun 23 11:48:40 2007 +0200 FUTEX: Restore the dropped ERSCH fix The return value of futex_find_get_task() needs to be -ESRCH in case that the search fails. This was part of the original futex fixes and got accidentally dropped, when the futex-tidy-up patch was split out. Results in a NULL pointer dereference in case the search fails. Restore it. Signed-off-by: Thomas Gleixner Cc: Ingo Molnar Cc: Ulrich Drepper Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit cdd2bd2e66111c075f2fe917e206ccb2835f9359 Author: Thomas Gleixner Date: Thu Jun 21 20:45:15 2007 +0000 posix-timers: Prevent softirq starvation by small intervals and SIG_IGN posix-timers which deliver an ignored signal are currently rearmed in the timer softirq: This is necessary because the timer needs to be delivered again when SIG_IGN is removed. This is not a problem, when the interval is reasonable. With high resolution timers enabled one might arm a posix timer with a very small interval and ignore the signal. This might lead to a softirq starvation when the interval is so small that the timer is requeued onto the softirq pending list right away. This problem was pointed out by Jan Kiszka. Thanks Jan ! The correct solution would be to stop the timer, when the signal is ignored and rearm it when SIG_IGN is removed. Unfortunately this requires modification in sigaction and involves non trivial sighand locking. It's too late in the release cycle for such a change. For now we just keep the timer running and enforce that the timer only fires every jiffie. This does not break anything as we keep the overrun counter correct. It adds a little inaccuracy to the timer_gettime() interface, but... The more complex change is necessary anyway to fix another short coming of the current implementation, which I discovered while looking at this problem: A pending signal is discarded when SIG_IGN is set. In case that a posixtimer signal is pending then it is discarded as well, but when SIG_IGN is removed later nothing rearms the timer. This is not new, it's that way since posix timers have been merged. So nothing to worry about right now. I have a working solution to fix all of this, but the impact is too large for both stable and 2.6.22. I'm going to send it out for review in the next days. This should go into 2.6.21.stable as well. Signed-off-by: Thomas Gleixner Acked-by: Ingo Molnar Cc: Jan Kiszka Cc: Ulrich Drepper Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit ad2aa2d5cd8012db90cdbf32ec11e7fefab57cee Author: Christoph Lameter Date: Tue Jun 19 21:39:03 2007 +0200 sched: fix next_interval determination in idle_balance() Fix massive SMP imbalance on NUMA nodes observed on 2.6.21.5 with CFS. (and later on reproduced without CFS as well). The intervals of domains that do not have SD_BALANCE_NEWIDLE must be considered for the calculation of the time of the next balance. Otherwise we may defer rebalancing forever and nodes might stay idle for very long times. Siddha also spotted that the conversion of the balance interval to jiffies is missing. Fix that to. From: Srivatsa Vaddagiri also continue the loop if !(sd->flags & SD_LOAD_BALANCE). Tested-by: Paul E. McKenney It did in fact trigger under all three of mainline, CFS, and -rt including CFS -- see below for a couple of emails from last Friday giving results for these three on the AMD box (where it happened) and on a single-quad NUMA-Q system (where it did not, at least not with such severity). Signed-off-by: Christoph Lameter Signed-off-by: Ingo Molnar Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit c1228d7339dff95df5ea093f174372be5c1268b7 Author: Adam Litke Date: Sat Jun 16 10:16:15 2007 -0700 hugetlb: fix get_policy for stacked shared memory files Here's another breakage as a result of shared memory stacked files :( The NUMA policy for a VMA is determined by checking the following (in the order given): 1) vma->vm_ops->get_policy() (if defined) 2) vma->vm_policy (if defined) 3) task->mempolicy (if defined) 4) Fall back to default_policy By switching to stacked files for shared memory, get_policy() is now always set to shm_get_policy which is a wrapper function. This causes us to stop at step 1, which yields NULL for hugetlb instead of task->mempolicy which was the previous (and correct) result. This patch modifies the shm_get_policy() wrapper to maintain steps 1-3 for the wrapped vm_ops. (akpm: the refcounting of mempolicies is busted and this patch does nothing to improve it) Signed-off-by: Adam Litke Acked-by: William Irwin Cc: dean gaudet Cc: Christoph Lameter Cc: Andi Kleen Signed-off-by: Andrew Morton Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 4d332408463281e849c380a5505cf07bdd710419 Author: Olaf Kirch Date: Wed Jun 13 16:00:30 2007 -0400 dm crypt: fix remove first_clone Get rid of first_clone in dm-crypt This gets rid of first_clone, which is not really needed. Apparently, cloned bios used to share their bvec some time way in the past - this is no longer the case. Contrarily, this even hurts us if we try to create a clone off first_clone after it has completed, and crypt_endio has destroyed its bvec. Signed-off-by: Olaf Kirch Signed-off-by: Alasdair G Kergon Cc: Jens Axboe Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit b9eeb205abe5ecb4a20502f83fdd595517e9ba67 Author: Olaf Kirch Date: Wed Jun 13 15:59:16 2007 -0400 dm crypt: fix avoid cloned bio ref after free Do not access the bio after generic_make_request We should never access a bio after generic_make_request - there's no guarantee it still exists. Signed-off-by: Olaf Kirch Signed-off-by: Alasdair G Kergon Cc: Jens Axboe Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit c0c1813dd8f0775ea90f68ce2db5725671a68196 Author: Olaf Kirch Date: Wed Jun 13 15:57:50 2007 -0400 dm crypt: fix call to clone_init Call clone_init early We need to call clone_init as early as possible - at least before call bio_put(clone) in any error path. Otherwise, the destructor will try to dereference bi_private, which may still be NULL. Signed-off-by: Olaf Kirch Signed-off-by: Alasdair G Kergon Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit e3158d9e1f8e1439c133428e36f814208fa699dd Author: Milan Broz Date: Wed Jun 13 15:56:39 2007 -0400 dm crypt: disable barriers Disable barriers in dm-crypt because of current workqueue processing can reorder requests. This must be addresed later but for now disabling barriers is needed to prevent data corruption. Signed-off-by: Milan Broz Signed-off-by: Alasdair G Kergon Cc: Jens Axboe Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 56d39b59e95b269654940a0d26904229781380e6 Author: Mike Accetta Date: Tue Jun 12 11:09:35 2007 +1000 md: Fix bug in error handling during raid1 repair. If raid1/repair (which reads all block and fixes any differences it finds) hits a read error, it doesn't reset the bio for writing before writing correct data back, so the read error isn't fixed, and the device probably gets a zero-length write which it might complain about. Signed-off-by: Neil Brown Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 9711bd8cc17e4f0791536d72c7f330af91672b86 Author: NeilBrown Date: Tue Jun 12 11:09:29 2007 +1000 md: Fix two raid10 bugs. 1/ When resyncing a degraded raid10 which has more than 2 copies of each block, garbage can get synced on top of good data. 2/ We round the wrong way in part of the device size calculation, which can cause confusion. Signed-off-by: Neil Brown Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit b34eb784c379b9b78ebccc022ed5cc854c0da71e Author: Sergei Shtylyov Date: Fri Jun 8 15:14:32 2007 +0200 hpt366: disallow Ultra133 for HPT374 Eliminate UltraATA/133 support for HPT374 -- the chip isn't capable of this mode according to the manual, and doesn't even seem to tolerate 66 MHz DPLL clock... Signed-off-by: Sergei Shtylyov Cc: Geller Sandor Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit b6c7b07330bf7271419ce7403d2551f330986af3 Author: Alexey Kuznetsov Date: Fri Jun 8 10:29:30 2007 +0000 pi-futex: Fix exit races and locking problems 1. New entries can be added to tsk->pi_state_list after task completed exit_pi_state_list(). The result is memory leakage and deadlocks. 2. handle_mm_fault() is called under spinlock. The result is obvious. 3. results in self-inflicted deadlock inside glibc. Sometimes futex_lock_pi returns -ESRCH, when it is not expected and glibc enters to for(;;) sleep() to simulate deadlock. This problem is quite obvious and I think the patch is right. Though it looks like each "if" in futex_lock_pi() got some stupid special case "else if". :-) 4. sometimes futex_lock_pi() returns -EDEADLK, when nobody has the lock. The reason is also obvious (see comment in the patch), but correct fix is far beyond my comprehension. I guess someone already saw this, the chunk: if (rt_mutex_trylock(&q.pi_state->pi_mutex)) ret = 0; is obviously from the same opera. But it does not work, because the rtmutex is really taken at this point: wake_futex_pi() of previous owner reassigned it to us. My fix works. But it looks very stupid. I would think about removal of shift of ownership in wake_futex_pi() and making all the work in context of process taking lock. From: Thomas Gleixner Fix 1) Avoid the tasklist lock variant of the exit race fix by adding an additional state transition to the exit code. This fixes also the issue, when a task with recursive segfaults is not able to release the futexes. Fix 2) Cleanup the lookup_pi_state() failure path and solve the -ESRCH problem finally. Fix 3) Solve the fixup_pi_state_owner() problem which needs to do the fixup in the lock protected section by using the in_atomic userspace access functions. This removes also the ugly lock drop / unqueue inside of fixup_pi_state() Fix 4) Fix a stale lock in the error path of futex_wake_pi() Added some error checks for verification. The -EDEADLK problem is solved by the rtmutex fixups. Cc: Alexey Kuznetsov Signed-off-by: Thomas Gleixner Acked-by: Ingo Molnar Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 8e6a96266ae4617bc14faa1155fc35d1319fa431 Author: Thomas Gleixner Date: Fri Jun 8 10:29:29 2007 +0000 rt-mutex: Fix chain walk early wakeup bug Alexey Kuznetsov found some problems in the pi-futex code. One of the root causes is: When a wakeup happens, we do not to stop the chain walk so we we follow a non existing locking chain. Drop out when this happens. Cc: Alexey Kuznetsov Signed-off-by: Thomas Gleixner Acked-by: Ingo Molnar Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 21e3424ee9ce6760b03ed3bfc7a26e002b9de0ed Author: Thomas Gleixner Date: Fri Jun 8 10:29:28 2007 +0000 rt-mutex: Fix stale return value Alexey Kuznetsov found some problems in the pi-futex code. The major problem is a stale return value in rt_mutex_slowlock(): When the pi chain walk returns -EDEADLK, but the waiter was woken up during the phases where the locks were dropped, the rtmutex could be acquired, but due to the stale return value -EDEADLK returned to the caller. Reset the return value in the woken up path. Cc: Alexey Kuznetsov Signed-off-by: Thomas Gleixner Acked-by: Ingo Molnar Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit b6b364eaa2ec37e9d1108fcbf4a025a3a407b879 Author: Bob Picco Date: Thu Jun 7 21:01:35 2007 -0400 sparsemem: fix oops in x86_64 show_mem We aren't sampling for holes in memory. Thus we encounter a section hole with empty section map pointer for SPARSEMEM and OOPs for show_mem. This issue has been seen in 2.6.21, current git and current mm. This patch is for 2.6.21 stable. It was tested against sparsemem. Previous to commit f0a5a58aa812b31fd9f197c4ba48245942364eae memory_present was called for node_start_pfn to node_end_pfn. This would cover the hole(s) with reserved pages and valid sections. Most SPARSEMEM supported arches do a pfn_valid check in show_mem before computing the page structure address. This issue was brought to my attention on IRC by Arnaldo Carvalho de Melo at acme@redhat.com. Thanks to Arnaldo for testing. Signed-off-by: Bob Picco Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman commit 50099883039e51de64f84938a3db114b4c0cb12f Author: Michael Chan Date: Tue Jun 5 11:33:20 2007 -0700 BNX2: Fix netdev watchdog on 5708. There's a bug in the driver that only initializes half of the context memory on the 5708. Surprisingly, this works most of the time except for some occasional netdev watchdogs when sending a lot of 64-byte packets. This fix is to add the missing code to initialize the 2nd half of the context memory. Update version to 1.5.8.2. Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman