commit 3c80dd9904552b4c98de228b731b3e3c48f6bada Author: Greg Kroah-Hartman Date: Tue Sep 8 20:39:34 2009 -0700 Linux 2.6.30.6 commit e38d22518cad8f3e1805bf17482b8bd2a5ec7de0 Author: Sunil Mushran Date: Fri Sep 4 11:12:01 2009 -0700 ocfs2: ocfs2_write_begin_nolock() should handle len=0 commit 8379e7c46cc48f51197dd663fc6676f47f2a1e71 upstream. Bug introduced by mainline commit e7432675f8ca868a4af365759a8d4c3779a3d922 The bug causes ocfs2_write_begin_nolock() to oops when len=0. Signed-off-by: Sunil Mushran Signed-off-by: Joel Becker Signed-off-by: Greg Kroah-Hartman commit 94a92d5f9ece6fb4bb9e23114413c5f1dcf305ef Author: Jiri Slaby Date: Sun Aug 23 22:55:51 2009 -0700 NET: llc, zero sockaddr_llc struct commit 28e9fc592cb8c7a43e4d3147b38be6032a0e81bc upstream. sllc_arphrd member of sockaddr_llc might not be changed. Zero sllc before copying to the above layer's structure. Signed-off-by: Jiri Slaby Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6966703e42de2262a11cbada59645820045ea186 Author: Eric Dumazet Date: Thu Aug 6 03:34:06 2009 +0000 rose: Fix rose_getname() leak commit 17ac2e9c58b69a1e25460a568eae1b0dc0188c25 upstream. rose_getname() can leak kernel memory to user. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 88b694de0b4789b4cd9efc2321366c75059baa6b Author: Eric Dumazet Date: Thu Aug 6 03:48:36 2009 +0000 econet: Fix econet_getname() leak commit 80922bbb12a105f858a8f0abb879cb4302d0ecaa upstream. econet_getname() can leak kernel memory to user. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0535beef12f0d415e334516b981b2994b76b78cf Author: Eric Dumazet Date: Thu Aug 6 03:31:07 2009 +0000 netrom: Fix nr_getname() leak commit f6b97b29513950bfbf621a83d85b6f86b39ec8db upstream. nr_getname() can leak kernel memory to user. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e9ddac8017a55bd2ab3ba5611403dcfcbf29e7be Author: Eric Dumazet Date: Thu Aug 6 02:27:43 2009 +0000 appletalk: fix atalk_getname() leak commit 3d392475c873c10c10d6d96b94d092a34ebd4791 upstream. atalk_getname() can leak 8 bytes of kernel memory to user Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 03300f07d8e955ef16b7bfcd62c77cb8cf5aab6a Author: Eric Dumazet Date: Thu Aug 6 03:55:04 2009 +0000 irda: Fix irda_getname() leak commit 09384dfc76e526c3993c09c42e016372dc9dd22c upstream. irda_getname() can leak kernel memory to user. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3020cf2a8341ebe53d689826fb569f309286e654 Author: Eric Dumazet Date: Thu Aug 6 20:27:04 2009 +0000 can: Fix raw_getname() leak commit e84b90ae5eb3c112d1f208964df1d8156a538289 upstream. raw_getname() can leak 10 bytes of kernel memory to user (two bytes hole between can_family and can_ifindex, 8 bytes at the end of sockaddr_can structure) Signed-off-by: Eric Dumazet Acked-by: Oliver Hartkopp Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 27a473ee7017dabac9073d0c57db72bd680409a8 Author: Michal Schmidt Date: Thu Aug 27 12:22:43 2009 -0700 xenfb: connect to backend before registering fb commit 0a80fb10239b04c45e5e80aad8d4b2ca5ac407b2 upstream. As soon as the framebuffer is registered, our methods may be called by the kernel. This leads to a crash as xenfb_refresh() gets called before we have the irq. Connect to the backend before registering our framebuffer with the kernel. [ Fixes bug http://bugzilla.kernel.org/show_bug.cgi?id=14059 ] Signed-off-by: Michal Schmidt Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 92a110d0d892b93bac2d5d862ad1f41a508a1865 Author: Dan Carpenter Date: Sun Aug 9 14:24:09 2009 +0200 ar9170: fix read & write outside array bounds commit e9d126cdfa60b575f1b5b02024c4faee27dccf07 upstream. Backport done by Christian Lamparter queue == __AR9170_NUM_TXQ would cause a bug on the next line. found by Smatch ( http://repo.or.cz/w/smatch.git ). Reported-by: Dan Carpenter Signed-off-by: Dan Carpenter Signed-off-by: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 72b57bef7b0e7e3bae7ef607a05435d8fa115c31 Author: Julien TINNES Date: Thu Aug 27 15:26:58 2009 +0200 ipv4: make ip_append_data() handle NULL routing table commit 788d908f2879a17e5f80924f3da2e23f1034482d upstream. Add a check in ip_append_data() for NULL *rtp to prevent future bugs in callers from being exploitable. Signed-off-by: Julien Tinnes Signed-off-by: Tavis Ormandy Acked-by: David S. Miller Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 36c32cab609e449a3b9fbb0543717799a287eb63 Author: Geert Uytterhoeven Date: Sun Aug 23 22:54:32 2009 +0000 powerpc/ps3: Add missing check for PS3 to rtc-ps3 platform device registration commit 7b6a09f3d6aedeaac923824af2a5df30300b56e9 upstream. On non-PS3, we get: | kernel BUG at drivers/rtc/rtc-ps3.c:36! because the rtc-ps3 platform device is registered unconditionally in a kernel with builtin support for PS3. Reported-by: Sachin Sant Signed-off-by: Geert Uytterhoeven Acked-by: Geoff Levand Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit a33dc3b8f8d2065a3aa3e874100b7f00713d3825 Author: Alan Stern Date: Fri Jul 31 10:40:22 2009 -0400 USB: EHCI: fix two new bugs related to Clear-TT-Buffer commit 7a0f0d951273eee889c2441846842348ebc00a2a upstream. This patch (as1273) fixes two(!) bugs introduced by the new Clear-TT-Buffer implementation in ehci-hcd. It is now possible for an idle QH to have some URBs on its queue -- this will happen if a Clear-TT-Buffer is pending for the QH's endpoint. Consequently we should not issue a warning when someone tries to unlink an URB from an idle QH; instead we should process the request immediately. The refcounts for QHs could get messed up, because submit_async() would increment the refcount when calling qh_link_async() and qh_link_async() would then refuse to link the QH into the schedule if a Clear-TT-Buffer was pending. Instead we should increment the refcount only when the QH actually is added to the schedule. The current code tries to be clever by leaving the refcount alone if an unlink is immediately followed by a relink; the patch changes this to an unconditional decrement and increment (although they occur in the opposite order). Signed-off-by: Alan Stern CC: David Brownell Tested-by: Manuel Lauss Tested-by: Matthijs Kooijman Signed-off-by: Greg Kroah-Hartman commit 6e7b7f694c29fe24c7e51296599027e9bdbce557 Author: Alan Stern Date: Mon Jun 29 10:47:30 2009 -0400 USB: EHCI: use the new clear_tt_buffer interface commit 914b701280a76f96890ad63eb0fa99bf204b961c upstream. This patch (as1256) changes ehci-hcd and all the other drivers in the EHCI family to make use of the new clear_tt_buffer callbacks. When a Clear-TT-Buffer request is in progress for a QH, the QH is not allowed to be linked into the async schedule until the request is finished. At that time, if there are any URBs queued for the QH, it is linked into the async schedule. Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit d34b435e14c18f29e15660e6fa2121297fb50018 Author: Alan Stern Date: Mon Jun 29 10:43:32 2009 -0400 USB: fix the clear_tt_buffer interface commit cb88a1b887bb8908f6e00ce29e893ea52b074940 upstream. This patch (as1255) updates the interface for calling usb_hub_clear_tt_buffer(). Even the name of the function is changed! When an async URB (i.e., Control or Bulk) going through a high-speed hub to a non-high-speed device is cancelled or fails, the hub's Transaction Translator buffer may be left busy still trying to complete the transaction. The buffer has to be cleared; that's what usb_hub_clear_tt_buffer() does. It isn't safe to send any more URBs to the same endpoint until the TT buffer is fully clear. Therefore the HCD needs to be told when the Clear-TT-Buffer request has finished. This patch adds a callback method to struct hc_driver for that purpose, and makes the hub driver invoke the callback at the proper time. The patch also changes a couple of names; "hub_tt_kevent" and "tt.kevent" now look rather antiquated. Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 3970742fce3383231a240f5bcd018c7f7106f5ea Author: Bruno Prémont Date: Sun Aug 23 19:06:28 2009 -0700 ipv6: Fix commit 63d9950b08184e6531adceb65f64b429909cc101 (ipv6: Make v4-mapped bindings consistent with IPv4) commit ca6982b858e1d08010c1d29d8e8255b2ac2ad70a upstream. Commit 63d9950b08184e6531adceb65f64b429909cc101 (ipv6: Make v4-mapped bindings consistent with IPv4) changes behavior of inet6_bind() for v4-mapped addresses so it should behave the same way as inet_bind(). During this change setting of err to -EADDRNOTAVAIL got lost: af_inet.c:469 inet_bind() err = -EADDRNOTAVAIL; if (!sysctl_ip_nonlocal_bind && !(inet->freebind || inet->transparent) && addr->sin_addr.s_addr != htonl(INADDR_ANY) && chk_addr_ret != RTN_LOCAL && chk_addr_ret != RTN_MULTICAST && chk_addr_ret != RTN_BROADCAST) goto out; af_inet6.c:463 inet6_bind() if (addr_type == IPV6_ADDR_MAPPED) { int chk_addr_ret; /* Binding to v4-mapped address on a v6-only socket * makes no sense */ if (np->ipv6only) { err = -EINVAL; goto out; } /* Reproduce AF_INET checks to make the bindings consitant */ v4addr = addr->sin6_addr.s6_addr32[3]; chk_addr_ret = inet_addr_type(net, v4addr); if (!sysctl_ip_nonlocal_bind && !(inet->freebind || inet->transparent) && v4addr != htonl(INADDR_ANY) && chk_addr_ret != RTN_LOCAL && chk_addr_ret != RTN_MULTICAST && chk_addr_ret != RTN_BROADCAST) goto out; } else { Signed-off-by: Bruno Prémont Signed-off-by: David S. Miller commit df221c536aa18008724e57acc4170e0ba38fb11c Author: Oleg Nesterov Date: Mon Aug 24 12:45:29 2009 +0200 kthreads: fix kthread_create() vs kthread_stop() race The bug should be "accidently" fixed by recent changes in 2.6.31, all kernels <= 2.6.30 need the fix. The problem was never noticed before, it was found because it causes mysterious failures with GFS mount/umount. Credits to Robert Peterson. He blaimed kthread.c from the very beginning. But, despite my promise, I forgot to inspect the old implementation until he did a lot of testing and reminded me. This led to huge delay in fixing this bug. kthread_stop() does put_task_struct(k) before it clears kthread_stop_info.k. This means another kthread_create() can re-use this task_struct, but the new kthread can still see kthread_should_stop() == T and exit even without calling threadfn(). Reported-by: Robert Peterson Tested-by: Robert Peterson Signed-off-by: Oleg Nesterov Acked-by: Rusty Russell Signed-off-by: Greg Kroah-Hartman commit 85fa9e247d081a087bed949983dde603a46114dc Author: Jean-Francois Moine Date: Wed Aug 19 17:46:18 2009 -0400 gspca - ov534: Fix ov772x The scan of the image packets of the sensor ov772x was broken when the sensor ov965x was added. [ Based on upstream c874f3aa, modified slightly for v2.6.30.5 ] Signed-off-by: Jim Paris Acked-by: Jean-Francois Moine Signed-off-by: Greg Kroah-Hartman commit 85481d89414655115270dc891d8604d299269c58 Author: Christoph Hellwig Date: Wed Aug 19 14:43:02 2009 -0400 xfs: fix spin_is_locked assert on uni-processor builds upstream commit a8914f3a6d72c97328597a556a99daaf5cc288ae Without SMP or preemption spin_is_locked always returns false, so we can't do an assert with it. Instead use assert_spin_locked, which does the right thing on all builds. Signed-off-by: Christoph Hellwig Reviewed-by: Eric Sandeen Reported-by: Johannes Engel Tested-by: Johannes Engel Signed-off-by: Felix Blyakher Signed-off-by: Greg Kroah-Hartman commit f3cae744a8cae0b07d2798cac77a4be1e222409d Author: Christoph Hellwig Date: Wed Aug 19 14:43:01 2009 -0400 xfs: fix freeing of inodes not yet added to the inode cache upstream commit b36ec0428a06fcbdb67d61e9e664154e5dd9a8c7 When freeing an inode that lost race getting added to the inode cache we must not call into ->destroy_inode, because that would delete the inode that won the race from the inode cache radix tree. This patch uses splits a new xfs_inode_free helper out of xfs_ireclaim and uses that plus __destroy_inode to make sure we really only free the memory allocted for the inode that lost the race, and not mess with the inode cache state. Signed-off-by: Christoph Hellwig Reviewed-by: Eric Sandeen Reported-by: Alex Samad Reported-by: Andrew Randrianasulu Reported-by: Stephane Reported-by: Tommy Reported-by: Miah Gregory Reported-by: Gabriel Barazer Reported-by: Leandro Lucarella Reported-by: Daniel Burr Reported-by: Nickolay Reported-by: Michael Guntsche Reported-by: Dan Carley Reported-by: Michael Ole Olsen Reported-by: Michael Weissenbacher Reported-by: Martin Spott Reported-by: Christian Kujau Tested-by: Michael Guntsche Tested-by: Dan Carley Tested-by: Christian Kujau Signed-off-by: Greg Kroah-Hartman commit e22d4dae5a805ca986063fa304d2125b98910fc2 Author: Christoph Hellwig Date: Wed Aug 19 14:43:00 2009 -0400 vfs: add __destroy_inode backport of upstream commit 2e00c97e2c1d2ffc9e26252ca26b237678b0b772 When we want to tear down an inode that lost the add to the cache race in XFS we must not call into ->destroy_inode because that would delete the inode that won the race from the inode cache radix tree. This patch provides the __destroy_inode helper needed to fix this, the actual fix will be in th next patch. As XFS was the only reason destroy_inode was exported we shift the export to the new __destroy_inode. Signed-off-by: Christoph Hellwig Reviewed-by: Eric Sandeen Signed-off-by: Greg Kroah-Hartman commit b1abc2814585a3a13ce725ba62f62e9dc531010c Author: Christoph Hellwig Date: Wed Aug 19 14:42:59 2009 -0400 vfs: fix inode_init_always calling convention backport of upstream commit 54e346215e4fe2ca8c94c54e546cc61902060510 Currently inode_init_always calls into ->destroy_inode if the additional initialization fails. That's not only counter-intuitive because inode_init_always did not allocate the inode structure, but in case of XFS it's actively harmful as ->destroy_inode might delete the inode from a radix-tree that has never been added. This in turn might end up deleting the inode for the same inum that has been instanciated by another process and cause lots of cause subtile problems. Also in the case of re-initializing a reclaimable inode in XFS it would free an inode we still want to keep alive. Signed-off-by: Christoph Hellwig Reviewed-by: Eric Sandeen Signed-off-by: Greg Kroah-Hartman commit 3723aab300dfc33a8e90cfd53cd122c097bfa437 Author: Frans Pop Date: Wed Aug 26 14:29:29 2009 -0700 ACPI processor: force throttling state when BIOS returns incorrect value commit 2a908002c7b1b666616103e9df2419b38d7c6f1f upstream. If the BIOS reports an invalid throttling state (which seems to be fairly common after system boot), a reset is done to state T0. Because of a check in acpi_processor_get_throttling_ptc(), the reset never actually gets executed, which results in the error reoccurring on every access of for example /proc/acpi/processor/CPU0/throttling. Add a 'force' option to acpi_processor_set_throttling() to ensure the reset really takes effect. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13389 This patch, together with the next one, fixes a regression introduced in 2.6.30, listed on the regression list. They have been available for 2.5 months now in bugzilla, but have not been picked up, despite various reminders and without any reason given. Google shows that numerous people are hitting this issue. The issue is in itself relatively minor, but the bug in the code is clear. The patches have been in all my kernels and today testing has shown that throttling works correctly with the patches applied when the system overheats (http://bugzilla.kernel.org/show_bug.cgi?id=13918#c14). Signed-off-by: Frans Pop Acked-by: Zhang Rui Cc: Len Brown Cc: "Rafael J. Wysocki" Cc: Rusty Russell Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9baf278cca4043a1312f3a40bf17b979b6238ebc Author: Sunil Mushran Date: Thu Aug 6 16:12:58 2009 -0700 ocfs2: Initialize the cluster we're writing to in a non-sparse extend commit e7432675f8ca868a4af365759a8d4c3779a3d922 upstream. In a non-sparse extend, we correctly allocate (and zero) the clusters between the old_i_size and pos, but we don't zero the portions of the cluster we're writing to outside of pos<->len. It handles clustersize > pagesize and blocksize < pagesize. [Cleaned up by Joel Becker.] Signed-off-by: Sunil Mushran Signed-off-by: Joel Becker Signed-off-by: Greg Kroah-Hartman commit 8c668814e3e2be7d633447bf6e78237d4cedabb7 Author: Jeremy Fitzhardinge Date: Wed Jul 22 09:59:35 2009 -0700 x86, amd: Don't probe for extended APIC ID if APICs are disabled commit 2cb078603abb612e3bcd428fb8122c3d39e08832 upstream. If we've logically disabled apics, don't probe the PCI space for the AMD extended APIC ID. [ Impact: prevent boot crash under Xen. ] Signed-off-by: Jeremy Fitzhardinge Reported-by: Bastian Blank Signed-off-by: H. Peter Anvin Cc: Andreas Herrmann Signed-off-by: Greg Kroah-Hartman commit cd20a4e8b2a7f2d10ef23978ccd8c85eff3ac3a2 Author: Fenghua Yu <[fenghua.yu@intel.com]> Date: Tue Aug 11 14:52:10 2009 -0700 Bug Fix arch/ia64/kernel/pci-dma.c: fix recursive dma_supported() call in iommu_dma_supported() commit 51b89f7a6615eca184aa0b85db5781d931e9c8d1 upstream. In commit 160c1d8e40866edfeae7d68816b7005d70acf391, dma_ops->dma_supported = iommu_dma_supported; This dma_ops->dma_supported is first called in platform_dma_init() during kernel boot. Then dma_ops->dma_supported will be called recursively in iommu_dma_supported. Kernel can not boot because kernel can not get out of iommu_dma_supported until it runs out of stack memory. Signed-off-by: Fenghua Yu Signed-off-by: Greg Kroah-Hartman commit 108c7d85e4f7e2c5e01dd554d7a13bb0dbab7768 Author: Linus Torvalds Date: Sat Aug 1 10:34:56 2009 -0700 do_sigaltstack: avoid copying 'stack_t' as a structure to user space commit 0083fc2c50e6c5127c2802ad323adf8143ab7856 upstream. Ulrich Drepper correctly points out that there is generally padding in the structure on 64-bit hosts, and that copying the structure from kernel to user space can leak information from the kernel stack in those padding bytes. Avoid the whole issue by just copying the three members one by one instead, which also means that the function also can avoid the need for a stack frame. This also happens to match how we copy the new structure from user space, so it all even makes sense. [ The obvious solution of adding a memset() generates horrid code, gcc does really stupid things. ] Reported-by: Ulrich Drepper Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit eec3155c9187314b70ae4e495fea1de57ffe4783 Author: Kashyap, Desai Date: Fri Aug 14 15:01:35 2009 +0530 mpt2sas: fix config request and diag reset deadlock commit 388ce4beb7135722c584b0af18f215e3ec657adf upstream. Moving the setting and clearing of the mutex's to _config_request. There was a mutex deadlock when diag reset is called from inside _config_request, so diag reset was moved to outside the mutexs. Signed-off-by: James Bottomley Signed-off-by: Kashyap Desai Signed-off-by: Eric Moore Signed-off-by: Greg Kroah-Hartman commit 838c463532b6de9cdc3075e45bf8487e7d5c0336 Author: Kashyap, Desai Date: Fri Aug 7 19:38:48 2009 +0530 SCSI: mpt2sas: fix oops because drv data points to NULL on resume from hibernate commit fcfe6392d18283df3c561b5ef59c330d485ff8ca upstream. Fix another ocurring when the system resumes. This oops was due to driver setting the pci drvdata to NULL on the prior hibernation. Becuase it was set to NULL, upon resmume we assume the pci drvdata is non-zero, and we oops. To fix the ooops, we don't set pci drvdata to NULL at hibernation time. Signed-off-by: Kashyap Desai Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit fd7f94c8e002056350bcc59d6d0b960b85d5aa51 Author: Kashyap, Desai Date: Fri Aug 7 19:37:59 2009 +0530 SCSI: mpt2sas: fix crash due to Watchdog is active while OS in standby mode commit e4750c989f732555fca86dd73d488c79972362db upstream. Fix oops ocurring at hibernation time. This oops was due to the firmware fault watchdog timer still running after we freed resources. To fix the issue we need to terminate the watchdog timer at hibernation time. Signed-off-by: Kashyap Desai Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 8b5e2bf4efa0aff2a427ab7eef2ee39de7501233 Author: Kashyap, Desai Date: Fri Aug 7 19:37:14 2009 +0530 SCSI: mpt2sas: fix infinite loop inside config request commit 6bd4e1e4d6023f4da069fd68729c502cc4e6dfd0 upstream. This restriction is introduced just to avoid loop of config_request. Retry must be limited so we have restricted config request to maximum 2 times. Signed-off-by: Kashyap Desai Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit a58c05338b9173b821d6d47b564e02431df4eb54 Author: Kashyap, Desai Date: Fri Aug 7 19:36:43 2009 +0530 SCSI: mpt2sas: Excessive log info causes sas iounit page time out commit be9e8cd75ce8d94ae4aab721fdcc337fa78a9090 upstream. Inhibit 0x3117 loginfos - during cable pull, there are too many printks going to the syslog, this is have impact on how fast the interrupt routine can handle keeping up with command completions; this was the root cause to the config pages timeouts. Signed-off-by: Kashyap Desai Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit a253c70d2055450420b756fb5a351dc0ece719d4 Author: Kashyap, Desai Date: Fri Aug 7 19:35:18 2009 +0530 SCSI: mpt2sas: Raid 10 Value is showing as Raid 1E in /va/log/messages commit 62727a7ba43c0abf2673e3877079c136a9721792 upstream. When a volume is activated, the driver will recieve a pair of ir config change events to remove the foreign volume, then add the native. In the process of the removal event, the hidden raid componet is removed from the parent.When the disks is added back, the adding of the port fails becuase there is no instance of the device in its parent. To fix this issue, the driver needs to call mpt2sas_transport_update_links() prior to calling _scsih_add_device. In addition, we added sanity checks on volume add and removal to ignore events for foreign volumes. Signed-off-by: Kashyap Desai Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 4f2d0e9e2bb51e8de0ac989f3023d8340813b2cc Author: Kashyap, Desai Date: Fri Aug 7 19:34:26 2009 +0530 SCSI: mpt2sas: Expander fix oops saying "Already part of another port" commit 20f5895d55d9281830bfb7819c5c5b70b05297a6 upstream. Kernel panic is seen because driver did not tear down the port which should be dnoe using mpt2sas_transport_port_remove(). without this fix When expander is added back we would oops inside sas_port_add_phy. Signed-off-by: Kashyap Desai Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 34f5fef1b6038f7b85ff685b3676915a9668e1a8 Author: Kashyap, Desai Date: Fri Aug 7 19:33:17 2009 +0530 SCSI: mpt2sas: Introduced check for enclosure_handle to avoid crash commit 15052c9e85bf0cdadcb69eb89623bf12bad8b4f8 upstream. Kernel panic is seen because of enclosure_handle received from FW is zero. Check is introduced before calling mpt2sas_config_get_enclosure_pg0. Signed-off-by: Kashyap Desai Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit cbac26a3241f857e24fede1944aa825a4549cc17 Author: Tejun Heo Date: Fri Aug 7 01:59:15 2009 +0900 libata: OCZ Vertex can't do HPA commit 7831387bda72af3059be48d39846d3eb6d8ce2f6 upstream. OCZ Vertex SSD can't do HPA and not in a usual way. It reports HPA, allows unlocking but then fails all IOs which fall in the unlocked area. Quirk it so that HPA unlocking is not used for the device. Reported by Daniel Perup in bnc#522414. https://bugzilla.novell.com/show_bug.cgi?id=522414 Signed-off-by: Tejun Heo Reported-by: Daniel Perup Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit 6cb7c2af438ae469703159a5ed83ccaf13cf2487 Author: Reinette Chatre Date: Mon Aug 3 12:10:16 2009 -0700 iwlagn: do not send key clear commands when rfkill enabled commit 99f1b01562b7dcae75b043114f76163fbf84fcab upstream. Do all key clearing except sending sommands to device when rfkill enabled. When rfkill enabled the interface is brought down and will be brought back up correctly after rfkill is enabled again. Same change is not needed for iwl3945 as it ignores return code when sending key clearing command to device. This fixes http://bugzilla.kernel.org/show_bug.cgi?id=13742 Signed-off-by: Reinette Chatre Tested-by: Frans Pop Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 559850bb1cb43fe20be82e068ef232df18e4ea21 Author: Stanislaw Gruszka Date: Thu Aug 13 14:29:08 2009 +0200 iwl3945: fix rfkill switch (Not needed upstream, due to the major rewrite in 2.6.31) Due to rfkill and iwlwifi mishmash of SW / HW killswitch representation, we have race conditions which make unable turn wifi radio on, after enable and disable again killswitch. I can observe this problem on my laptop with iwl3945 device. In rfkill core HW switch and SW switch are separate 'states'. Device can be only in one of 3 states: RFKILL_STATE_SOFT_BLOCKED, RFKILL_STATE_UNBLOCKED, RFKILL_STATE_HARD_BLOCKED. Whereas in iwlwifi driver we have separate bits STATUS_RF_KILL_HW and STATUS_RF_KILL_SW for HW and SW switches - radio can be turned on, only if both bits are cleared. In this particular race conditions, radio can not be turned on if in driver STATUS_RF_KILL_SW bit is set, and rfkill core is in state RFKILL_STATE_HARD_BLOCKED, because rfkill core is unable to call rfkill->toggle_radio(). This situation can be entered in case: - killswitch is turned on - rfkill core 'see' button change first and move to RFKILL_STATE_SOFT_BLOCKED also call ->toggle_radio() and STATE_RF_KILL_SW in driver is set - iwl3945 get info about button from hardware to set STATUS_RF_KILL_HW bit and force rfkill to move to RFKILL_STATE_HARD_BLOCKED - killsiwtch is turend off - driver clear STATUS_RF_KILL_HW - rfkill core is unable to clear STATUS_RF_KILL_SW in driver Additionally call to rfkill_epo() when STATUS_RF_KILL_HW in driver is set cause move to the same situation. In 2.6.31 this problem is fixed due to _total_ rewrite of rfkill subsystem. This is a quite small fix for 2.6.30.x in iwlwifi driver. We are changing internal rfkill state to always have below relations true: STATUS_RF_KILL_HW=1 STATUS_RF_KILL_SW=1 <-> RFKILL_STATUS_SOFT_BLOCKED STATUS_RF_KILL_HW=0 STATUS_RF_KILL_SW=1 <-> RFKILL_STATUS_SOFT_BLOCKED STATUS_RF_KILL_HW=1 STATUS_RF_KILL_SW=0 <-> RFKILL_STATUS_HARD_BLOCKED STATUS_RF_KILL_HW=0 STATUS_RF_KILL_SW=0 <-> RFKILL_STATUS_UNBLOCKED Signed-off-by: Stanislaw Gruszka Acked-by: Reinette Chatre Acked-by: John W. Linville commit 378392b260dbe265401948d5d5b77fe6d537501c Author: Jan Kiszka Date: Thu Jul 2 21:45:47 2009 +0200 KVM: Fix KVM_GET_MSR_INDEX_LIST commit e125e7b6944898831b56739a5448e705578bf7e2 upstream. So far, KVM copied the emulated_msrs (only MSR_IA32_MISC_ENABLE) to a wrong address in user space due to broken pointer arithmetic. This caused subtle corruption up there (missing MSR_IA32_MISC_ENABLE had probably no practical relevance). Moreover, the size check for the user-provided kvm_msr_list forgot about emulated MSRs. Signed-off-by: Jan Kiszka Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit a9baf6a17556ebc308cf569ef6459e486735717b Author: Michael S. Tsirkin Date: Tue Sep 1 12:15:14 2009 -0300 KVM: fix ack not being delivered when msi present (cherry picked from commit 5116d8f6b977970ebefc1932c0f313163a6ec91f) kvm_notify_acked_irq does not check irq type, so that it sometimes interprets msi vector as irq. As a result, ack notifiers are not called, which typially hangs the guest. The fix is to track and check irq type. Signed-off-by: Michael S. Tsirkin Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit 14596338f2a9ad1f461f2683d41a8bc279962c40 Author: Marcelo Tosatti Date: Tue Sep 1 12:15:13 2009 -0300 KVM: MMU: limit rmap chain length (cherry picked from commit 53a27b39ff4d2492f84b1fdc2f0047175f0b0b93) Otherwise the host can spend too long traversing an rmap chain, which happens under a spinlock. Signed-off-by: Marcelo Tosatti Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit 64fdbdd67cf0779b79ba763ee3b4d1ca560006d1 Author: Marcelo Tosatti Date: Tue Sep 1 12:15:12 2009 -0300 KVM: MMU: handle n_free_mmu_pages > n_alloc_mmu_pages in kvm_mmu_change_mmu_pages (cherry picked from commit 025dbbf36a7680bffe54d9dcbf0a8bc01a7cbd10) kvm_mmu_change_mmu_pages mishandles the case where n_alloc_mmu_pages is smaller then n_free_mmu_pages, by not checking if the result of the subtraction is negative. Its a valid condition which can happen if a large number of pages has been recently freed. Signed-off-by: Marcelo Tosatti Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit a6582e7e2ab9b52b331e40fc6d0226ff0707a9f4 Author: Marcelo Tosatti Date: Tue Sep 1 12:15:11 2009 -0300 KVM: SVM: force new asid on vcpu migration (cherry picked from commit 4b656b1202498184a0ecef86b3b89ff613b9c6ab) If a migrated vcpu matches the asid_generation value of the target pcpu, there will be no TLB flush via TLB_CONTROL_FLUSH_ALL_ASID. The check for vcpu.cpu in pre_svm_run is meaningless since svm_vcpu_load already updated it on schedule in. Such vcpu will VMRUN with stale TLB entries. Based on original patch from Joerg Roedel (http://patchwork.kernel.org/patch/10021/) Signed-off-by: Marcelo Tosatti Acked-by: Joerg Roedel Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit 912ae90af5061a6f6af1263863910609da7f3b1d Author: Marcelo Tosatti Date: Tue Sep 1 12:15:10 2009 -0300 KVM: x86: verify MTRR/PAT validity (cherry picked from commit d6289b9365c3f622a8cfe62c4fb054bb70b5061a) Do not allow invalid memory types in MTRR/PAT (generating a #GP otherwise). Signed-off-by: Marcelo Tosatti Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit 01564e293011944c3cae1470b39c3697dac3c9b8 Author: Avi Kivity Date: Mon Aug 3 14:57:57 2009 -0300 KVM: Fix cpuid feature misreporting (cherry picked from commit 8d753f369bd28fff1706ffe9fb9fea4fd88cf85b) MTRR, PAT, MCE, and MCA are all supported (to some extent) but not reported. Vista requires these features, so if userspace relies on kernel cpuid reporting, it loses support for Vista. Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit 424db486d8dd65c6ddc8b9e05dbe0a87eb5c8a87 Author: Amit Shah Date: Mon Aug 3 14:57:56 2009 -0300 KVM: Ignore reads to K7 EVNTSEL MSRs (cherry picked from commit 9e6996240afcbe61682eab8eeaeb65c34333164d) In commit 7fe29e0faacb650d31b9e9f538203a157bec821d we ignored the reads to the P6 EVNTSEL MSRs. That fixed crashes on Intel machines. Ignore the reads to K7 EVNTSEL MSRs as well to fix this on AMD hosts. This fixes Kaspersky antivirus crashing Windows guests on AMD hosts. Signed-off-by: Amit Shah Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit 70f04604e099f62de013c7910cd43a3507433541 Author: Amit Shah Date: Mon Aug 3 14:57:55 2009 -0300 KVM: x86: Ignore reads to EVNTSEL MSRs (cherry picked from commit 7fe29e0faacb650d31b9e9f538203a157bec821d) We ignore writes to the performance counters and performance event selector registers already. Kaspersky antivirus reads the eventsel MSR causing it to crash with the current behaviour. Return 0 as data when the eventsel registers are read to stop the crash. Signed-off-by: Amit Shah Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit 2c108bfdf0859f16788c15d289b0eed1bfd8363e Author: Avi Kivity Date: Mon Aug 3 14:57:54 2009 -0300 KVM: MMU: Use different shadows when EFER.NXE changes (cherry picked from commit 9645bb56b31a1b70ab9e470387b5264cafc04aa9) A pte that is shadowed when the guest EFER.NXE=1 is not valid when EFER.NXE=0; if bit 63 is set, the pte should cause a fault, and since the shadow EFER always has NX enabled, this won't happen. Fix by using a different shadow page table for different EFER.NXE bits. This allows vcpus to run correctly with different values of EFER.NXE, and for transitions on this bit to be handled correctly without requiring a full flush. Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit 9661bf29e0bcfb17f64a4145bb283d3ab53c0971 Author: Glauber Costa Date: Mon Aug 3 14:57:53 2009 -0300 KVM: Deal with interrupt shadow state for emulated instructions (cherry picked from commit 310b5d306c1aee7ebe32f702c0e33e7988d50646) We currently unblock shadow interrupt state when we skip an instruction, but failing to do so when we actually emulate one. This blocks interrupts in key instruction blocks, in particular sti; hlt; sequences If the instruction emulated is an sti, we have to block shadow interrupts. The same goes for mov ss. pop ss also needs it, but we don't currently emulate it. Without this patch, I cannot boot gpxe option roms at vmx machines. This is described at https://bugzilla.redhat.com/show_bug.cgi?id=494469 Signed-off-by: Glauber Costa CC: H. Peter Anvin CC: Gleb Natapov Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit d4a81389f6643898ecd2f7f5976fd59f37d65e54 Author: Glauber Costa Date: Mon Aug 3 14:57:52 2009 -0300 KVM: Introduce {set/get}_interrupt_shadow() This patch introduces set/get_interrupt_shadow(), that does exactly what the name suggests. It also replaces open code that explicitly does it with the now existent functions. It differs slightly from upstream, because upstream merged it after gleb's interrupt rework, that we don't ship. Just for reference, upstream changelog is (2809f5d2c4cfad171167b131bb2a21ab65eba40f): This patch replaces drop_interrupt_shadow with the more general set_interrupt_shadow, that can either drop or raise it, depending on its parameter. It also adds ->get_interrupt_shadow() for future use. Signed-off-by: Glauber Costa Signed-off-by: Avi Kivity Signed-off-by: Marcelo Tosatti Signed-off-by: Greg Kroah-Hartman commit 038851e38586ded536dca8349dc8457c0d21f674 Author: Gleb Natapov Date: Mon Aug 3 14:57:51 2009 -0300 KVM: MMU: do not free active mmu pages in free_mmu_pages() (cherry picked from commit f00be0cae4e6ad0a8c7be381c6d9be3586800b3e) free_mmu_pages() should only undo what alloc_mmu_pages() does. Free mmu pages from the generic VM destruction function, kvm_destroy_vm(). Signed-off-by: Gleb Natapov Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit 529fcfcdbe644664b02ce292f2c1628592ff07d2 Author: Marcelo Tosatti Date: Mon Aug 3 14:57:50 2009 -0300 KVM: MMU: protect kvm_mmu_change_mmu_pages with mmu_lock (cherry picked from commit 7c8a83b75a38a807d37f5a4398eca2a42c8cf513) kvm_handle_hva, called by MMU notifiers, manipulates mmu data only with the protection of mmu_lock. Update kvm_mmu_change_mmu_pages callers to take mmu_lock, thus protecting against kvm_handle_hva. Signed-off-by: Marcelo Tosatti Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit 8d31fceee486d4f75ece5efcb02f53ffd25e1513 Author: Marcelo Tosatti Date: Mon Aug 3 14:57:49 2009 -0300 KVM: x86: check for cr3 validity in mmu_alloc_roots (cherry picked from commit 8986ecc0ef58c96eec48d8502c048f3ab67fd8e2) Verify the cr3 address stored in vcpu->arch.cr3 points to an existant memslot. If not, inject a triple fault. Signed-off-by: Marcelo Tosatti Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit 4877f4a4c8d80472228e0c843fee5957ae1f94d1 Author: Marcelo Tosatti Date: Mon Aug 3 14:57:48 2009 -0300 KVM: take mmu_lock when updating a deleted slot (cherry picked from commit b43b1901ad282aeb74161837fb403927102687a1) kvm_handle_hva relies on mmu_lock protection to safely access the memslot structures. Signed-off-by: Marcelo Tosatti Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit cbceeda22d9e11693b9ba81b8fd2c78acc87e341 Author: Takashi Iwai Date: Mon Aug 31 08:15:26 2009 +0200 ALSA: hda - Fix MacBookPro 3,1/4,1 quirk with ALC889A commit a3f730af7e33cea10ea66f05b2565fde1f9512df upstream. This patch fixes the wrong headphone output routing for MacBookPro 3,1/4,1 quirk with ALC889A codec, which caused the silent headphone output. Also, this gives the individual Headphone and Speaker volume controls. Reference: kernel bug#14078 http://bugzilla.kernel.org/show_bug.cgi?id=14078 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 820eeda9c642baf97f908b042b9dc3c6c0bf8995 Author: Trond Myklebust Date: Fri Aug 28 11:12:12 2009 -0400 SUNRPC: Fix rpc_task_force_reencode commit 2574cc9f4ffc6c681c9177111357efe5b76f0e36 upstream. This patch fixes the bug that was reported in http://bugzilla.kernel.org/show_bug.cgi?id=14053 If we're in the case where we need to force a reencode and then resend of the RPC request, due to xprt_transmit failing with a networking error, then we _must_ retransmit the entire request. Signed-off-by: Trond Myklebust Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 64aeda1a592f38c5d419993d403d2ea1df03ea12 Author: Costantino Leandro Date: Wed Aug 26 14:29:28 2009 -0700 wmi: fix kernel panic when stack protection enabled. commit f3d83e2415445e5b157bef404d38674e9e8de169 upstream. Summary: Kernel panic arise when stack protection is enabled, since strncat will add a null terminating byte '\0'; So in functions like this one (wmi_query_block): char wc[4]="WC"; .... strncat(method, block->object_id, 2); ... the length of wc should be n+1 (wc[5]) or stack protection fault will arise. This is not noticeable when stack protection is disabled,but , isn't good either. Config used: [CONFIG_CC_STACKPROTECTOR_ALL=y, CONFIG_CC_STACKPROTECTOR=y] Panic Trace ------------ .... stack-protector: kernel stack corrupted in : fa7b182c 2.6.30-rc8-obelisco-generic call_trace: [] ? panic+0x45/0xd9 [] ? __stack_chk_fail+0x1c/0x40 [] ? wmi_query_block+0x15a/0x162 [wmi] [] ? wmi_query_block+0x15a/0x162 [wmi] [] ? acer_wmi_init+0x00/0x61a [acer_wmi] [] ? acer_wmi_init+0x135/0x61a [acer_wmi] [] ? do_one_initcall+0x50+0x126 Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13514 Signed-off-by: Costantino Leandro Signed-off-by: Carlos Corbacho Cc: Len Brown Cc: Bjorn Helgaas Cc: "Rafael J. Wysocki" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9c3239fd2f55924bf333b9cb4d2c28f27388c728 Author: Oleg Nesterov Date: Wed Aug 26 14:29:24 2009 -0700 clone(): fix race between copy_process() and de_thread() commit 4ab6c08336535f8c8e42cf45d7adeda882eff06e upstream. Spotted by Hiroshi Shimamoto who also provided the test-case below. copy_process() uses signal->count as a reference counter, but it is not. This test case #include #include #include #include #include #include void *null_thread(void *p) { for (;;) sleep(1); return NULL; } void *exec_thread(void *p) { execl("/bin/true", "/bin/true", NULL); return null_thread(p); } int main(int argc, char **argv) { for (;;) { pid_t pid; int ret, status; pid = fork(); if (pid < 0) break; if (!pid) { pthread_t tid; pthread_create(&tid, NULL, exec_thread, NULL); for (;;) pthread_create(&tid, NULL, null_thread, NULL); } do { ret = waitpid(pid, &status, 0); } while (ret == -1 && errno == EINTR); } return 0; } quickly creates an unkillable task. If copy_process(CLONE_THREAD) races with de_thread() copy_signal()->atomic(signal->count) breaks the signal->notify_count logic, and the execing thread can hang forever in kernel space. Change copy_process() to increment count/live only when we know for sure we can't fail. In this case the forked thread will take care of its reference to signal correctly. If copy_process() fails, check CLONE_THREAD flag. If it it set - do nothing, the counters were not changed and current belongs to the same thread group. If it is not set, ->signal must be released in any case (and ->count must be == 1), the forked child is the only thread in the thread group. We need more cleanups here, in particular signal->count should not be used by de_thread/__exit_signal at all. This patch only fixes the bug. Reported-by: Hiroshi Shimamoto Tested-by: Hiroshi Shimamoto Signed-off-by: Oleg Nesterov Acked-by: Roland McGrath Cc: KAMEZAWA Hiroyuki Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 05ef392f96688bb1e9628c821da3ea75dca38215 Author: Clemens Ladisch Date: Tue Aug 25 08:15:41 2009 +0200 sound: pcm_lib: fix unsorted list constraint handling commit b1ddaf681e362ed453182ddee1699d7487069a16 upstream. snd_interval_list() expected a sorted list but did not document this, so there are drivers that give it an unsorted list. To fix this, change the algorithm to work with any list. This fixes the "Slave PCM not usable" error with USB devices that have multiple alternate settings with sample rates in decreasing order, such as the Philips Askey VC010 WebCam. http://bugzilla.kernel.org/show_bug.cgi?id=14028 Reported-and-tested-by: Andrzej Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit cd88717a8a863f15762e9125636e123ec10f8f4f Author: Ingo Molnar Date: Fri Aug 21 12:53:36 2009 +0200 tracing: Fix too large stack usage in do_one_initcall() commit 4a683bf94b8a10e2bb0da07aec3ac0a55e5de61f upstream. One of my testboxes triggered this nasty stack overflow crash during SCSI probing: [ 5.874004] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 5.875004] device: 'sda': device_add [ 5.878004] BUG: unable to handle kernel NULL pointer dereference at 00000a0c [ 5.878004] IP: [] print_context_stack+0x81/0x110 [ 5.878004] *pde = 00000000 [ 5.878004] Thread overran stack, or stack corrupted [ 5.878004] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 5.878004] last sysfs file: [ 5.878004] [ 5.878004] Pid: 1, comm: swapper Not tainted (2.6.31-rc6-tip-01272-g9919e28-dirty #5685) [ 5.878004] EIP: 0060:[] EFLAGS: 00010083 CPU: 0 [ 5.878004] EIP is at print_context_stack+0x81/0x110 [ 5.878004] EAX: cf8a3000 EBX: cf8a3fe4 ECX: 00000049 EDX: 00000000 [ 5.878004] ESI: b1cfce84 EDI: 00000000 EBP: cf8a3018 ESP: cf8a2ff4 [ 5.878004] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 [ 5.878004] Process swapper (pid: 1, ti=cf8a2000 task=cf8a8000 task.ti=cf8a3000) [ 5.878004] Stack: [ 5.878004] b1004867 fffff000 cf8a3ffc [ 5.878004] Call Trace: [ 5.878004] [] ? kernel_thread_helper+0x7/0x10 [ 5.878004] BUG: unable to handle kernel NULL pointer dereference at 00000a0c [ 5.878004] IP: [] print_context_stack+0x81/0x110 [ 5.878004] *pde = 00000000 [ 5.878004] Thread overran stack, or stack corrupted [ 5.878004] Oops: 0000 [#2] PREEMPT SMP DEBUG_PAGEALLOC The oops did not reveal any more details about the real stack that we have and the system got into an infinite loop of recursive pagefaults. So i booted with CONFIG_STACK_TRACER=y and the 'stacktrace' boot parameter. The box did not crash (timings/conditions probably changed a tiny bit to trigger the catastrophic crash), but the /debug/tracing/stack_trace file was rather revealing: Depth Size Location (72 entries) ----- ---- -------- 0) 3704 52 __change_page_attr+0xb8/0x290 1) 3652 24 __change_page_attr_set_clr+0x43/0x90 2) 3628 60 kernel_map_pages+0x108/0x120 3) 3568 40 prep_new_page+0x7d/0x130 4) 3528 84 get_page_from_freelist+0x106/0x420 5) 3444 116 __alloc_pages_nodemask+0xd7/0x550 6) 3328 36 allocate_slab+0xb1/0x100 7) 3292 36 new_slab+0x1c/0x160 8) 3256 36 __slab_alloc+0x133/0x2b0 9) 3220 4 kmem_cache_alloc+0x1bb/0x1d0 10) 3216 108 create_object+0x28/0x250 11) 3108 40 kmemleak_alloc+0x81/0xc0 12) 3068 24 kmem_cache_alloc+0x162/0x1d0 13) 3044 52 scsi_pool_alloc_command+0x29/0x70 14) 2992 20 scsi_host_alloc_command+0x22/0x70 15) 2972 24 __scsi_get_command+0x1b/0x90 16) 2948 28 scsi_get_command+0x35/0x90 17) 2920 24 scsi_setup_blk_pc_cmnd+0xd4/0x100 18) 2896 128 sd_prep_fn+0x332/0xa70 19) 2768 36 blk_peek_request+0xe7/0x1d0 20) 2732 56 scsi_request_fn+0x54/0x520 21) 2676 12 __generic_unplug_device+0x2b/0x40 22) 2664 24 blk_execute_rq_nowait+0x59/0x80 23) 2640 172 blk_execute_rq+0x6b/0xb0 24) 2468 32 scsi_execute+0xe0/0x140 25) 2436 64 scsi_execute_req+0x152/0x160 26) 2372 60 scsi_vpd_inquiry+0x6c/0x90 27) 2312 44 scsi_get_vpd_page+0x112/0x160 28) 2268 52 sd_revalidate_disk+0x1df/0x320 29) 2216 92 rescan_partitions+0x98/0x330 30) 2124 52 __blkdev_get+0x309/0x350 31) 2072 8 blkdev_get+0xf/0x20 32) 2064 44 register_disk+0xff/0x120 33) 2020 36 add_disk+0x6e/0xb0 34) 1984 44 sd_probe_async+0xfb/0x1d0 35) 1940 44 __async_schedule+0xf4/0x1b0 36) 1896 8 async_schedule+0x12/0x20 37) 1888 60 sd_probe+0x305/0x360 38) 1828 44 really_probe+0x63/0x170 39) 1784 36 driver_probe_device+0x5d/0x60 40) 1748 16 __device_attach+0x49/0x50 41) 1732 32 bus_for_each_drv+0x5b/0x80 42) 1700 24 device_attach+0x6b/0x70 43) 1676 16 bus_attach_device+0x47/0x60 44) 1660 76 device_add+0x33d/0x400 45) 1584 52 scsi_sysfs_add_sdev+0x6a/0x2c0 46) 1532 108 scsi_add_lun+0x44b/0x460 47) 1424 116 scsi_probe_and_add_lun+0x182/0x4e0 48) 1308 36 __scsi_add_device+0xd9/0xe0 49) 1272 44 ata_scsi_scan_host+0x10b/0x190 50) 1228 24 async_port_probe+0x96/0xd0 51) 1204 44 __async_schedule+0xf4/0x1b0 52) 1160 8 async_schedule+0x12/0x20 53) 1152 48 ata_host_register+0x171/0x1d0 54) 1104 60 ata_pci_sff_activate_host+0xf3/0x230 55) 1044 44 ata_pci_sff_init_one+0xea/0x100 56) 1000 48 amd_init_one+0xb2/0x190 57) 952 8 local_pci_probe+0x13/0x20 58) 944 32 pci_device_probe+0x68/0x90 59) 912 44 really_probe+0x63/0x170 60) 868 36 driver_probe_device+0x5d/0x60 61) 832 20 __driver_attach+0x89/0xa0 62) 812 32 bus_for_each_dev+0x5b/0x80 63) 780 12 driver_attach+0x1e/0x20 64) 768 72 bus_add_driver+0x14b/0x2d0 65) 696 36 driver_register+0x6e/0x150 66) 660 20 __pci_register_driver+0x53/0xc0 67) 640 8 amd_init+0x14/0x16 68) 632 572 do_one_initcall+0x2b/0x1d0 69) 60 12 do_basic_setup+0x56/0x6a 70) 48 20 kernel_init+0x84/0xce 71) 28 28 kernel_thread_helper+0x7/0x10 There's a lot of fat functions on that stack trace, but the largest of all is do_one_initcall(). This is due to the boot trace entry variables being on the stack. Fixing this is relatively easy, initcalls are fundamentally serialized, so we can move the local variables to file scope. Note that this large stack footprint was present for a couple of months already - what pushed my system over the edge was the addition of kmemleak to the call-chain: 6) 3328 36 allocate_slab+0xb1/0x100 7) 3292 36 new_slab+0x1c/0x160 8) 3256 36 __slab_alloc+0x133/0x2b0 9) 3220 4 kmem_cache_alloc+0x1bb/0x1d0 10) 3216 108 create_object+0x28/0x250 11) 3108 40 kmemleak_alloc+0x81/0xc0 12) 3068 24 kmem_cache_alloc+0x162/0x1d0 13) 3044 52 scsi_pool_alloc_command+0x29/0x70 This pushes the total to ~3800 bytes, only a tiny bit more was needed to corrupt the on-kernel-stack thread_info. The fix reduces the stack footprint from 572 bytes to 28 bytes. Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Frederic Weisbecker Cc: Steven Rostedt Cc: Catalin Marinas Cc: Jens Axboe Cc: Linus Torvalds LKML-Reference: Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit c80dd82ff1f0a39fb8153f0c6719cfca8e4493a0 Author: Mimi Zohar Date: Fri Aug 21 14:32:48 2009 -0400 kernel_read: redefine offset type commit 6777d773a463ac045d333b989d4e44660f8d92ad upstream. vfs_read() offset is defined as loff_t, but kernel_read() offset is only defined as unsigned long. Redefine kernel_read() offset as loff_t. Signed-off-by: Mimi Zohar Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit 392647fca76640773e16a701c94faa94423f57bf Author: Mimi Zohar Date: Fri Aug 21 14:32:49 2009 -0400 ima: hashing large files bug fix commit 16bfa38b1936212428cb38fbfbbb8f6c62b8d81f upstream. Hashing files larger than INT_MAX causes process to loop. Dependent on redefining kernel_read() offset type to loff_t. (http://bugzilla.kernel.org/show_bug.cgi?id=13909) Signed-off-by: Mimi Zohar Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit 00ba05d158a04889546092400b5d76443d01f112 Author: Hugh Dickins Date: Mon Aug 24 16:30:28 2009 +0100 mm: fix hugetlb bug due to user_shm_unlock call commit 353d5c30c666580347515da609dd74a2b8e9b828 upstream. 2.6.30's commit 8a0bdec194c21c8fdef840989d0d7b742bb5d4bc removed user_shm_lock() calls in hugetlb_file_setup() but left the user_shm_unlock call in shm_destroy(). In detail: Assume that can_do_hugetlb_shm() returns true and hence user_shm_lock() is not called in hugetlb_file_setup(). However, user_shm_unlock() is called in any case in shm_destroy() and in the following atomic_dec_and_lock(&up->__count) in free_uid() is executed and if up->__count gets zero, also cleanup_user_struct() is scheduled. Note that sched_destroy_user() is empty if CONFIG_USER_SCHED is not set. However, the ref counter up->__count gets unexpectedly non-positive and the corresponding structs are freed even though there are live references to them, resulting in a kernel oops after a lots of shmget(SHM_HUGETLB)/shmctl(IPC_RMID) cycles and CONFIG_USER_SCHED set. Hugh changed Stefan's suggested patch: can_do_hugetlb_shm() at the time of shm_destroy() may give a different answer from at the time of hugetlb_file_setup(). And fixed newseg()'s no_id error path, which has missed user_shm_unlock() ever since it came in 2.6.9. Reported-by: Stefan Huber Signed-off-by: Hugh Dickins Tested-by: Stefan Huber Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 006fb349ae9699ccc9a27483b6a94be0bd87cdd0 Author: Linus Torvalds Date: Fri Aug 21 17:40:08 2009 -0700 Re-introduce page mapping check in mark_buffer_dirty() commit 8e9d78edea3ce5c0036f85b93091483f2f15443a upstream. In commit a8e7d49aa7be728c4ae241a75a2a124cdcabc0c5 ("Fix race in create_empty_buffers() vs __set_page_dirty_buffers()"), I removed a test for a NULL page mapping unintentionally when some of the code inside __set_page_dirty() was moved to the callers. That removal generally didn't matter, since a filesystem would serialize truncation (which clears the page mapping) against writing (which marks the buffer dirty), so locking at a higher level (either per-page or an inode at a time) should mean that the buffer page would be stable. And indeed, nothing bad seemed to happen. Except it turns out that apparently reiserfs does something odd when under load and writing out the journal, and we have a number of bugzilla entries that look similar: http://bugzilla.kernel.org/show_bug.cgi?id=13556 http://bugzilla.kernel.org/show_bug.cgi?id=13756 http://bugzilla.kernel.org/show_bug.cgi?id=13876 and it looks like reiserfs depended on that check (the common theme seems to be "data=journal", and a journal writeback during a truncate). I suspect reiserfs should have some additional locking, but in the meantime this should get us back to the pre-2.6.29 behavior. Pattern-pointed-out-by: Roland Kletzing Cc: Jeff Mahoney Cc: Nick Piggin Cc: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 8eea73b35d71b7f8d839150f86ce7df66427ec4f Author: Luis R. Rodriguez Date: Tue Aug 11 13:10:33 2009 -0700 mac80211: fix panic when splicing unprepared TIDs commit 416fbdff2137e8d8cc8f23f517bee3a26b11526f upstream. We splice skbs from the pending queue for a TID onto the local pending queue when tearing down a block ack request. This is not necessary unless we actually have received a request to start a block ack request (rate control, for example). If we never received that request we should not be splicing the tid pending queue as it would be null, causing a panic. Not sure yet how exactly we allowed through a call when the tid state does not have at least HT_ADDBA_REQUESTED_MSK set, that will require some further review as it is not quite obvious. For more information see the bug report: http://bugzilla.kernel.org/show_bug.cgi?id=13922 This fixes this oops: BUG: unable to handle kernel NULL pointer dereference at 00000030 IP: [] ieee80211_agg_splice_packets+0x40/0xc0 [mac80211] *pdpt = 0000000002d1e001 *pde = 0000000000000000 Thread overran stack, or stack corrupted Oops: 0000 [#1] SMP last sysfs file: /sys/module/aes_generic/initstate Modules linked in: Pid: 0, comm: swapper Not tainted (2.6.31-rc5-wl #2) Dell DV051 EIP: 0060:[] EFLAGS: 00010292 CPU: 0 EIP is at ieee80211_agg_splice_packets+0x40/0xc0 [mac80211] EAX: 00000030 EBX: 0000004c ECX: 00000003 EDX: 00000000 ESI: c1c98000 EDI: f745a1c0 EBP: c076be58 ESP: c076be38 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 Process swapper (pid: 0, ti=c076a000 task=c0709160 task.ti=c076a000) Stack: Call Trace: [] ? ieee80211_stop_tx_ba_cb+0xab/0x150 [mac80211] [] ? ieee80211_tasklet_handler+0xce/0x110 [mac80211] [] ? net_rx_action+0xef/0x1d0 [] ? tasklet_action+0x58/0xc0 [] ? __do_softirq+0xc2/0x190 [] ? handle_IRQ_event+0x58/0x140 [] ? ack_apic_level+0x7e/0x270 [] ? do_softirq+0x3d/0x40 [] ? irq_exit+0x65/0x90 [] ? do_IRQ+0x4f/0xc0 [] ? irq_exit+0x7d/0x90 [] ? smp_apic_timer_interrupt+0x57/0x90 [] ? common_interrupt+0x29/0x30 [] ? mwait_idle+0xbe/0x100 [] ? cpu_idle+0x52/0x90 [] ? rest_init+0x55/0x60 [] ? start_kernel+0x315/0x37d [] ? unknown_bootoption+0x0/0x1f9 [] ? i386_start_kernel+0x79/0x81 Code: EIP: [] ieee80211_agg_splice_packets+0x40/0xc0 [mac80211] SS:ESP 0068:c076be38 CR2: 0000000000000030 Testedy-by: Jack Lau Signed-off-by: Luis R. Rodriguez Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 97fbdb9896762c050f9791518383c04242ec243c Author: Pavel Roskin Date: Tue Aug 4 17:48:16 2009 -0400 rt2x00: fix memory corruption in rf cache, add a sanity check commit 6b26dead3ce97d016b57724b01974d5ca5c84bd5 upstream. Change rt2x00_rf_read() and rt2x00_rf_write() to subtract 1 from the rf register number. This is needed because the rf registers are enumerated starting with one. The size of the rf register cache is just enough to hold all registers, so writing to the highest register was corrupting memory. Add a check to make sure that the rf register number is valid. Signed-off-by: Pavel Roskin Acked-by: Ivo van Doorn Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 687b51397caa23be0f3c82733e35aa03429b5894 Author: Bo Liu Date: Tue Aug 18 14:11:19 2009 -0700 mm: build_zonelists(): move clear node_load[] to __build_all_zonelists() commit 7f9cfb31030737a7fc9a1cbca3fd01bec184c849 upstream. If node_load[] is cleared everytime build_zonelists() is called,node_load[] will have no help to find the next node that should appear in the given node's fallback list. Because of the bug, zonelist's node_order is not calculated as expected. This bug affects on big machine, which has asynmetric node distance. [synmetric NUMA's node distance] 0 1 2 0 10 12 12 1 12 10 12 2 12 12 10 [asynmetric NUMA's node distance] 0 1 2 0 10 12 20 1 12 10 14 2 20 14 10 This (my bug) is very old but no one has reported this for a long time. Maybe because the number of asynmetric NUMA is very small and they use cpuset for customizing node memory allocation fallback. [akpm@linux-foundation.org: fix CONFIG_NUMA=n build] Signed-off-by: Bo Liu Reviewed-by: KAMEZAWA Hiroyuki Cc: Mel Gorman Cc: Christoph Lameter Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5d884ca27c645691b20817c09a0e810f81975655 Author: Linus Torvalds Date: Fri Aug 21 09:48:10 2009 -0700 x86: don't call '->send_IPI_mask()' with an empty mask commit b04e6373d694e977c95ae0ae000e2c1e2cf92d73 upstream. As noted in 83d349f35e1ae72268c5104dbf9ab2ae635425d4 ("x86: don't send an IPI to the empty set of CPU's"), some APIC's will be very unhappy with an empty destination mask. That commit added a WARN_ON() for that case, and avoided the resulting problem, but didn't fix the underlying reason for why those empty mask cases happened. This fixes that, by checking the result of 'cpumask_andnot()' of the current CPU actually has any other CPU's left in the set of CPU's to be sent a TLB flush, and not calling down to the IPI code if the mask is empty. The reason this started happening at all is that we started passing just the CPU mask pointers around in commit 4595f9620 ("x86: change flush_tlb_others to take a const struct cpumask"), and when we did that, the cpumask was no longer thread-local. Before that commit, flush_tlb_mm() used to create it's own copy of 'mm->cpu_vm_mask' and pass that copy down to the low-level flush routines after having tested that it was not empty. But after changing it to just pass down the CPU mask pointer, the lower level TLB flush routines would now get a pointer to that 'mm->cpu_vm_mask', and that could still change - and become empty - after the test due to other CPU's having flushed their own TLB's. See http://bugzilla.kernel.org/show_bug.cgi?id=13933 for details. Tested-by: Thomas Björnell Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ff3d5a667d97fa518760f1492e0f3ed7f542770f Author: Linus Torvalds Date: Fri Aug 21 09:23:57 2009 -0700 x86: don't send an IPI to the empty set of CPU's commit 83d349f35e1ae72268c5104dbf9ab2ae635425d4 upstream. The default_send_IPI_mask_logical() function uses the "flat" APIC mode to send an IPI to a set of CPU's at once, but if that set happens to be empty, some older local APIC's will apparently be rather unhappy. So just warn if a caller gives us an empty mask, and ignore it. This fixes a regression in 2.6.30.x, due to commit 4595f9620 ("x86: change flush_tlb_others to take a const struct cpumask"), documented here: http://bugzilla.kernel.org/show_bug.cgi?id=13933 which causes a silent lock-up. It only seems to happen on PPro, P2, P3 and Athlon XP cores. Most developers sadly (or not so sadly, if you're a developer..) have more modern CPU's. Also, on x86-64 we don't use the flat APIC mode, so it would never trigger there even if the APIC didn't like sending an empty IPI mask. Reported-by: Pavel Vilim Reported-and-tested-by: Thomas Björnell Reported-and-tested-by: Martin Rogge Cc: Mike Travis Cc: Ingo Molnar Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a2e92be0bd1e4b4c34b52e413dee30efa204d1d6 Author: Linus Torvalds Date: Fri Aug 21 09:26:15 2009 -0700 Make bitmask 'and' operators return a result code commit f4b0373b26567cafd421d91101852ed7a34e9e94 upstream. When 'and'ing two bitmasks (where 'andnot' is a variation on it), some cases want to know whether the result is the empty set or not. In particular, the TLB IPI sending code wants to do cpumask operations and determine if there are any CPU's left in the final set. So this just makes the bitmask (and cpumask) functions return a boolean for whether the result has any bits set. Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5638301d05015b68a5577bdf9c61813b3839fa1c Author: Guillaume Knispel Date: Sat Aug 15 19:30:24 2009 +0200 poll/select: initialize triggered field of struct poll_wqueues commit b2add73dbf93fd50f00564d7abc3e2b9aa9dd20c upstream. The triggered field of struct poll_wqueues introduced in commit 5f820f648c92a5ecc771a96b3c29aa6e90013bba ("poll: allow f_op->poll to sleep"). It was first set to 1 in pollwake() (now __pollwake() ), tested and later set to 0 in poll_schedule_timeout(), but not initialized before. As a result when the process needs to sleep, triggered was likely to be non-zero even if pollwake() is not called before the first poll_schedule_timeout(), meaning schedule_hrtimeout_range() would not be called and an extra loop calling all ->poll() would be done. This patch initialize triggered to 0 in poll_initwait() so the ->poll() are not called twice before the process goes to sleep when it needs to. Signed-off-by: Guillaume Knispel Acked-by: Thomas Gleixner Acked-by: Tejun Heo Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c197608b8510c6a50ff643842374a799a9cba774 Author: Hannes Hering Date: Tue Aug 4 11:48:39 2009 -0700 ehea: Fix napi list corruption on ifconfig down commit 357eb46d8f275b4e8484541234ea3ba06065e258 upstream. This patch fixes the napi list handling when an ehea interface is shut down to avoid corruption of the napi list. Signed-off-by: Hannes Hering Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman