commit 678562e527fd9979f1765ffa1eb34738fc174425 Author: Greg Kroah-Hartman Date: Mon May 9 15:16:23 2011 -0700 Linux 2.6.38.6 commit 1e79fafb77908cd89d3ece2b297ff21ac55e0bef Author: Linus Torvalds Date: Wed May 4 21:30:28 2011 -0700 VM: skip the stack guard page lookup in get_user_pages only for mlock commit a1fde08c74e90accd62d4cfdbf580d2ede938fe7 upstream. The logic in __get_user_pages() used to skip the stack guard page lookup whenever the caller wasn't interested in seeing what the actual page was. But Michel Lespinasse points out that there are cases where we don't care about the physical page itself (so 'pages' may be NULL), but do want to make sure a page is mapped into the virtual address space. So using the existence of the "pages" array as an indication of whether to look up the guard page or not isn't actually so great, and we really should just use the FOLL_MLOCK bit. But because that bit was only set for the VM_LOCKED case (and not all vma's necessarily have it, even for mlock()), we couldn't do that originally. Fix that by moving the VM_LOCKED check deeper into the call-chain, which actually simplifies many things. Now mlock() gets simpler, and we can also check for FOLL_MLOCK in __get_user_pages() and the code ends up much more straightforward. Reported-and-reviewed-by: Michel Lespinasse Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a4dbc2902ff426f9ded7542eeb3f347442f7fc1f Author: James Bottomley Date: Sun May 1 09:42:07 2011 -0500 fix oops in scsi_run_queue() commit c055f5b2614b4f758ae6cc86733f31fa4c2c5844 upstream. The recent commit closing the race window in device teardown: commit 86cbfb5607d4b81b1a993ff689bbd2addd5d3a9b Author: James Bottomley Date: Fri Apr 22 10:39:59 2011 -0500 [SCSI] put stricter guards on queue dead checks is causing a potential NULL deref in scsi_run_queue() because the q->queuedata may already be NULL by the time this function is called. Since we shouldn't be running a queue that is being torn down, simply add a NULL check in scsi_run_queue() to forestall this. Tested-by: Jim Schutt Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 8bd26179f756612921ff54dbf4f9d2bd0afa01cd Author: Oliver Hartkopp Date: Wed Apr 20 01:57:15 2011 +0000 can: add missing socket check in can/raw release commit 10022a6c66e199d8f61d9044543f38785713cbbd upstream. v2: added space after 'if' according code style. We can get here with a NULL socket argument passed from userspace, so we need to handle it accordingly. Thanks to Dave Jones pointing at this issue in net/can/bcm.c Signed-off-by: Oliver Hartkopp Signed-off-by: David S. Miller Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman commit 8fac1f02574d9b19a805d19cea24bc74d19cd3e4 Author: Alex Deucher Date: Tue May 3 15:15:55 2011 -0400 drm/radeon/kms: add some new pci ids commit e2c85d8e3974c9041ad7b080846b28d2243e771b upstream. Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 5ea2c1536c7e93485849c3eb05a022ea26144c6a Author: Avi Kivity Date: Thu Feb 3 15:29:52 2011 +0200 KVM: SVM: check for progress after IRET interception commit bd3d1ec3d26b61120bb4f60b18ee99aa81839e6b upstream. When we enable an NMI window, we ask for an IRET intercept, since the IRET re-enables NMIs. However, the IRET intercept happens before the instruction executes, while the NMI window architecturally opens afterwards. To compensate for this mismatch, we only open the NMI window in the following exit, assuming that the IRET has by then executed; however, this assumption is not always correct; we may exit due to a host interrupt or page fault, without having executed the instruction. Fix by checking for forward progress by recording and comparing the IRET's rip. This is somewhat of a hack, since an unchaging rip does not mean that no forward progress has been made, but is the simplest fix for now. Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit fcd9079e754fa9050ed50ef2ba294ccf5825b837 Author: Lawrence Rust Date: Wed May 4 23:25:10 2011 -0300 cx88: Fix HVR4000 IR keymap [fixed in .39 in a much different way that is too big to backport to .38 - gregkh] Fixes the RC key input for Nova-S plus, HVR1100, HVR3000 and HVR4000 in the 2.6.38 kernel. Signed-off-by: Lawrence Rust Acked-by: Jarod Wilson Signed-off-by: Mauro Carvalho Chehab commit c99afaf0385d61a8e1747511904c66838270b02b Author: Timo Warns Date: Thu Apr 14 15:21:56 2011 -0700 fs/partitions/ldm.c: fix oops caused by corrupted partition table commit c340b1d640001c8c9ecff74f68fd90422ae2448a upstream. The kernel automatically evaluates partition tables of storage devices. The code for evaluating LDM partitions (in fs/partitions/ldm.c) contains a bug that causes a kernel oops on certain corrupted LDM partitions. A kernel subsystem seems to crash, because, after the oops, the kernel no longer recognizes newly connected storage devices. The patch validates the value of vblk_size. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Timo Warns Cc: Eugene Teo Cc: Harvey Harrison Cc: Richard Russon Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ba1ba1c0aaa659914bf9d47616453f6378add40f Author: Dave Jones Date: Tue Apr 19 20:36:59 2011 -0700 can: Add missing socket check in can/bcm release. commit c6914a6f261aca0c9f715f883a353ae7ff51fe83 upstream. We can get here with a NULL socket argument passed from userspace, so we need to handle it accordingly. Signed-off-by: Dave Jones Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6f0a6240e8ce1659574e944eac04e871a9dc1fe7 Author: Sachin Prabhu Date: Wed Apr 20 13:09:35 2011 +0100 Open with O_CREAT flag set fails to open existing files on non writable directories commit 1574dff8996ab1ed92c09012f8038b5566fce313 upstream. An open on a NFS4 share using the O_CREAT flag on an existing file for which we have permissions to open but contained in a directory with no write permissions will fail with EACCES. A tcpdump shows that the client had set the open mode to UNCHECKED which indicates that the file should be created if it doesn't exist and encountering an existing flag is not an error. Since in this case the file exists and can be opened by the user, the NFS server is wrong in attempting to check create permissions on the parent directory. The patch adds a conditional statement to check for create permissions only if the file doesn't exist. Signed-off-by: Sachin S. Prabhu Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 7b17624a7f6b41678d7452ebd5a525ddc3aaf3d3 Author: Lasse Collin Date: Sun May 1 19:38:42 2011 +0300 XZ decompressor: Fix decoding of empty LZMA2 streams commit 646032e3b05b32d3f20cb108a030593d9d792eb5 upstream. The old code considered valid empty LZMA2 streams to be corrupt. Note that a typical empty .xz file has no LZMA2 data at all, and thus most .xz files having no uncompressed data are handled correctly even without this fix. Signed-off-by: Lasse Collin Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 36f96751ce09f4ab400e93408cc602d2e080a799 Author: Dan Rosenberg Date: Fri Apr 29 15:48:07 2011 +0100 ARM: 6891/1: prevent heap corruption in OABI semtimedop commit 0f22072ab50cac7983f9660d33974b45184da4f9 upstream. When CONFIG_OABI_COMPAT is set, the wrapper for semtimedop does not bound the nsops argument. A sufficiently large value will cause an integer overflow in allocation size, followed by copying too much data into the allocated buffer. Fix this by restricting nsops to SEMOPM. Untested. Signed-off-by: Dan Rosenberg Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 7a1bbc3614696ea5e90d728f570f3ded8d49b487 Author: Eric W. Biederman Date: Sun Apr 24 01:54:57 2011 +0000 af_unix: Only allow recv on connected seqpacket sockets. commit a05d2ad1c1f391c7f514a1d1e09b5417968a7d07 upstream. This fixes the following oops discovered by Dan Aloni: > Anyway, the following is the output of the Oops that I got on the > Ubuntu kernel on which I first detected the problem > (2.6.37-12-generic). The Oops that followed will be more useful, I > guess. >[ 5594.669852] BUG: unable to handle kernel NULL pointer dereference > at           (null) > [ 5594.681606] IP: [] unix_dgram_recvmsg+0x1fb/0x420 > [ 5594.687576] PGD 2a05d067 PUD 2b951067 PMD 0 > [ 5594.693720] Oops: 0002 [#1] SMP > [ 5594.699888] last sysfs file: The bug was that unix domain sockets use a pseduo packet for connecting and accept uses that psudo packet to get the socket. In the buggy seqpacket case we were allowing unconnected sockets to call recvmsg and try to receive the pseudo packet. That is always wrong and as of commit 7361c36c5 the pseudo packet had become enough different from a normal packet that the kernel started oopsing. Do for seqpacket_recv what was done for seqpacket_send in 2.5 and only allow it on connected seqpacket sockets. Tested-by: Dan Aloni Signed-off-by: Eric W. Biederman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6ee931e9812bdf3774cbd74571d2fdfba037aac9 Author: Johannes Berg Date: Tue Apr 19 20:44:04 2011 +0200 mac80211: fix SMPS debugfs locking commit 243e6df4ed919880d079d717641ad699c6530a03 upstream. The locking with SMPS requests means that the debugs file should lock the mgd mutex, not the iflist mutex. Calls to __ieee80211_request_smps() need to hold that mutex, so add an assertion. This has always been wrong, but for some reason never been noticed, probably because the locking error only happens while unassociated. Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit bf4b1d070aeb3669d4b4e95c59c404d0e055c41c Author: Felix Fietkau Date: Fri Apr 15 00:41:43 2011 +0200 ath9k: fix the return value of ath_stoprecv commit 2232d31bf18ba02f5cd632bbfc3466aeca394c75 upstream. The patch 'ath9k_hw: fix stopping rx DMA during resets' added code to detect a condition where rx DMA was stopped, but the MAC failed to enter the idle state. This condition requires a hardware reset, however the return value of ath_stoprecv was 'true' in that case, which allowed it to skip the reset when issuing a fast channel change. Signed-off-by: Felix Fietkau Reported-by: Paul Stewart Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 15f0758f185241ad9c358a5bf60ff0a21eccc218 Author: Boris Ostrovsky Date: Fri Apr 29 17:47:43 2011 -0400 x86, AMD: Fix APIC timer erratum 400 affecting K8 Rev.A-E processors commit e20a2d205c05cef6b5783df339a7d54adeb50962 upstream. Older AMD K8 processors (Revisions A-E) are affected by erratum 400 (APIC timer interrupts don't occur in C states greater than C1). This, for example, means that X86_FEATURE_ARAT flag should not be set for these parts. This addresses regression introduced by commit b87cf80af3ba4b4c008b4face3c68d604e1715c6 ("x86, AMD: Set ARAT feature on AMD processors") where the system may become unresponsive until external interrupt (such as keyboard input) occurs. This results, for example, in time not being reported correctly, lack of progress on the system and other lockups. Reported-by: Joerg-Volker Peetz Tested-by: Joerg-Volker Peetz Acked-by: Borislav Petkov Signed-off-by: Boris Ostrovsky Link: http://lkml.kernel.org/r/1304113663-6586-1-git-send-email-ostr@amd64.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 18ab890cdc1e014d2ced35a5b8e606871ed5e6fc Author: Eric Paris Date: Thu Apr 28 15:55:52 2011 -0400 flex_arrays: allow zero length flex arrays commit bf69d41d198138e3c601e9a6645f4f1369aff7e0 upstream. Just like kmalloc will allow one to allocate a 0 length segment of memory flex arrays should do the same thing. It should bomb if you try to use something, but it should at least allow the allocation. This is needed because when SELinux switched to using flex_arrays in 2.6.38 the inability to allocate a 0 length array resulted in SELinux policy load returning -ENOSPC when previously it worked. Based-on-patch-by: Steffen Klassert Signed-off-by: Eric Paris Tested-by: Chris Richards Signed-off-by: Greg Kroah-Hartman commit c4ac4195df7fcb85ade58dd0497e273dd10600e7 Author: Eric Paris Date: Thu Apr 28 15:55:52 2011 -0400 flex_array: flex_array_prealloc takes a number of elements, not an end commit 5d30b10bd68df007e7ae21e77d1e0ce184b53040 upstream. Change flex_array_prealloc to take the number of elements for which space should be allocated instead of the last (inclusive) element. Users and documentation are updated accordingly. flex_arrays got introduced before they had users. When folks started using it, they ended up needing a different API than was coded up originally. This swaps over to the API that folks apparently need. Based-on-patch-by: Steffen Klassert Signed-off-by: Eric Paris Tested-by: Chris Richards Acked-by: Dave Hansen Signed-off-by: Greg Kroah-Hartman commit a9e7fb583786f69426aae4e569f16c8d34b6bdf5 Author: Jarod Wilson Date: Wed Apr 27 19:01:44 2011 -0300 imon: add conditional locking in change_protocol commit 23ef710e1a6c4d6b9ef1c2fa19410f7f1479401e upstream. The imon_ir_change_protocol function gets called two different ways, one way is from rc_register_device, for initial protocol selection/setup, and the other is via a userspace-initiated protocol change request, either by direct sysfs prodding or by something like ir-keytable. In the rc_register_device case, the imon context lock is already held, but when initiated from userspace, it is not, so we must acquire it, prior to calling send_packet, which requires that the lock is held. Without this change, there's an easily reproduceable deadlock when another function calls send_packet (such as either of the display write fops) after a userspace-initiated change_protocol. With a lock-debugging-enabled kernel, I was getting this: [ 15.014153] ===================================== [ 15.015048] [ BUG: bad unlock balance detected! ] [ 15.015048] ------------------------------------- [ 15.015048] ir-keytable/773 is trying to release lock (&ictx->lock) at: [ 15.015048] [] mutex_unlock+0xe/0x10 [ 15.015048] but there are no more locks to release! [ 15.015048] [ 15.015048] other info that might help us debug this: [ 15.015048] 2 locks held by ir-keytable/773: [ 15.015048] #0: (&buffer->mutex){+.+.+.}, at: [] sysfs_write_file+0x3c/0x144 [ 15.015048] #1: (s_active#87){.+.+.+}, at: [] sysfs_write_file+0xe7/0x144 [ 15.015048] [ 15.015048] stack backtrace: [ 15.015048] Pid: 773, comm: ir-keytable Not tainted 2.6.38.4-20.fc15.x86_64.debug #1 [ 15.015048] Call Trace: [ 15.015048] [] ? print_unlock_inbalance_bug+0xca/0xd5 [ 15.015048] [] ? lock_release_non_nested+0xc1/0x263 [ 15.015048] [] ? mutex_unlock+0xe/0x10 [ 15.015048] [] ? mutex_unlock+0xe/0x10 [ 15.015048] [] ? lock_release+0x17d/0x1a4 [ 15.015048] [] ? __mutex_unlock_slowpath+0xc5/0x125 [ 15.015048] [] ? mutex_unlock+0xe/0x10 [ 15.015048] [] ? send_packet+0x1c9/0x264 [imon] [ 15.015048] [] ? lock_release_non_nested+0xdb/0x263 [ 15.015048] [] ? imon_ir_change_protocol+0x126/0x15e [imon] [ 15.015048] [] ? store_protocols+0x1c3/0x286 [rc_core] [ 15.015048] [] ? dev_attr_store+0x20/0x22 [ 15.015048] [] ? sysfs_write_file+0x108/0x144 ... The original report that led to the investigation was the following: [ 1679.457305] INFO: task LCDd:8460 blocked for more than 120 seconds. [ 1679.457307] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1679.457309] LCDd D ffff88010fcd89c8 0 8460 1 0x00000000 [ 1679.457312] ffff8800d5a03b48 0000000000000082 0000000000000000 ffff8800d5a03fd8 [ 1679.457314] 00000000012dcd30 fffffffffffffffd ffff8800d5a03fd8 ffff88010fcd86f0 [ 1679.457316] ffff8800d5a03fd8 ffff8800d5a03fd8 ffff88010fcd89d0 ffff8800d5a03fd8 [ 1679.457319] Call Trace: [ 1679.457324] [] ? zone_statistics+0x75/0x90 [ 1679.457327] [] ? get_page_from_freelist+0x3c7/0x820 [ 1679.457330] [] __mutex_lock_slowpath+0x139/0x320 [ 1679.457335] [] mutex_lock+0x11/0x30 [ 1679.457338] [] display_open+0x66/0x130 [imon] [ 1679.457345] [] usb_open+0x180/0x310 [usbcore] [ 1679.457349] [] chrdev_open+0x1bb/0x2d0 [ 1679.457350] [] __dentry_open+0x10d/0x370 [ 1679.457352] [] ? chrdev_open+0x0/0x2d0 ... Bump the driver version here so its easier to tell if people have this locking fix or not, and also make locking during probe easier to follow. Reported-by: Benjamin Hodgetts Signed-off-by: Jarod Wilson Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 658bdc683c81e8016a6be9e3d0c1e5aa139a9b5d Author: Herton Ronaldo Krzesinski Date: Fri Apr 1 14:12:02 2011 -0300 v4l: make sure drivers supply a zeroed struct v4l2_subdev commit 80845a33165278f3236812009e9c568ba8c29938 upstream. Some v4l drivers currently don't initialize their struct v4l2_subdev with zeros, and this is a problem since some of the v4l2 code expects this. One example is the addition of internal_ops in commit 45f6f84, after that we are at risk of random oopses with these drivers when code in v4l2_device_register_subdev tries to dereference sd->internal_ops->*, as can be shown by the report at http://bugs.launchpad.net/bugs/745213 and analysis of its crash at https://lkml.org/lkml/2011/4/1/168 Use kzalloc within problematic drivers to ensure we have a zeroed struct v4l2_subdev. BugLink: http://bugs.launchpad.net/bugs/745213 Signed-off-by: Herton Ronaldo Krzesinski Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 4475d537057ad92380f3365ed10f876156a16766 Author: Dan Williams Date: Wed Apr 27 09:54:28 2011 +0000 usbnet: add support for some Huawei modems with cdc-ether ports commit b3c914aa84f4e4bbb3efc8f41c359d96e5e932d2 upstream. Some newer Huawei devices (T-Mobile Rocket, others) have cdc-ether compatible ports, so recognize and expose them. Signed-off-by: Dan Williams Acked-by: Oliver Neukum Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 74f85b46c2c2ddb5af3c26de627a4701c1951eb6 Author: B.J. Buchalter Date: Mon May 2 13:33:42 2011 -0400 firewire: Fix for broken configrom updates in quick succession commit 2e053a27d9d5ad5e0831e002cbf8043836fb2060 upstream. Current implementation of ohci_set_config_rom() uses a deferred bus reset via fw_schedule_bus_reset(). If clients add multiple unit descriptors to the config_rom in quick succession, the deferred bus reset may not have fired before succeeding update requests have come in. This can lead to an incorrect partial update of the config_rom for both addition and removal of config_rom descriptors, as the ohci_set_config_rom() routine will return -EBUSY if a previous pending update has not been completed yet; the requested update just gets dropped on the floor. This patch recognizes that the "in-flight" update can be modified until it has been processed by the bus-reset, and the locking in the bus_reset_tasklet ensures that the update is done atomically with respect to modifications made by ohci_set_config_rom(). The -EBUSY error case is simply removed. [Stefan R: The bug always existed at least theoretically. But it became easy to trigger since 2.6.36 commit 02d37bed188c "firewire: core: integrate software-forced bus resets with bus management" which introduced long mandatory delays between janitorial bus resets.] Signed-off-by: Benjamin Buchalter Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman commit a41ee1d9242adc1cd4eaad4fcae727f778c394a9 Author: Alan Stern Date: Mon May 2 14:21:44 2011 -0400 USB: fix regression in usbip by setting has_tt flag commit cee6a262550f53a13acfefbc1e3e5ff35c96182c upstream. This patch (as1460) fixes a regression in the usbip driver caused by the new check for Transaction Translators in USB-2 hubs. The root hub registered by vhci_hcd needs to have the has_tt flag set, because it can connect to low- and full-speed devices as well as high-speed devices. Signed-off-by: Alan Stern Reported-and-tested-by: Nikola Ciprich Signed-off-by: Greg Kroah-Hartman commit c8873543070f8593ff52422d55802423ad64be31 Author: Dave Airlie Date: Sun May 1 20:16:30 2011 +1000 drm/radeon: fix regression on atom cards with hardcoded EDID record. commit eaa4f5e1d0b816291a59a47917e569c0384f2b6f upstream. Since fafcf94e2b5732d1e13b440291c53115d2b172e9 introduced an edid size, it seems to have broken this path. This manifest as oops on T500 Lenovo laptops with dual graphics primarily. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=33812 Reviewed-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit d688cdef6b4638f6e4f8127770468a04758487e3 Author: Chris Ball Date: Wed Apr 27 17:35:31 2011 -0400 mmc: sdhci: Check mrq != NULL in sdhci_tasklet_finish commit 0c9c99a765321104cc5f9c97f949382a9ba4927e upstream. It seems that under certain circumstances the sdhci_tasklet_finish() call can be entered with mrq set to NULL, causing the system to crash with a NULL pointer de-reference. Seen on S3C6410 system. Based on a patch by Dimitris Papastamos. Reported-by: Dimitris Papastamos Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman commit 40e6af80dbcb551530b6c442564df01f9db3af33 Author: Ben Dooks Date: Wed Apr 27 14:24:19 2011 +0100 mmc: sdhci: Check mrq->cmd in sdhci_tasklet_finish commit b7b4d3426d2b5ecab21578eb20d8e456a1aace8f upstream. It seems that under certain circumstances that the sdhci_tasklet_finish() call can be entered with mrq->cmd set to NULL, causing the system to crash with a NULL pointer de-reference. Unable to handle kernel NULL pointer dereference at virtual address 00000000 PC is at sdhci_tasklet_finish+0x34/0xe8 LR is at sdhci_tasklet_finish+0x24/0xe8 Seen on S3C6410 system. Signed-off-by: Ben Dooks Signed-off-by: Mark Brown Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman commit 4e90d9686addf31f74821cacd54cda8c70a67038 Author: Chris Ball Date: Tue Mar 29 00:46:12 2011 -0400 mmc: sdhci-pci: Fix error case in sdhci_pci_probe_slot() commit 9fdcdbb0d84922e7ccda2f717a04ea62629f7e18 upstream. If pci_ioremap_bar() fails during probe, we "goto release;" and free the host, but then we return 0 -- which tells sdhci_pci_probe() that the probe succeeded. Since we think the probe succeeded, when we unload sdhci we'll go to sdhci_pci_remove_slot() and it will try to dereference slot->host, which is now NULL because we freed it in the error path earlier. The patch simply sets ret appropriately, so that sdhci_pci_probe() will detect the failure immediately and bail out. Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman commit 3fe962c04818a4634255beb3be9f236d36350543 Author: Guennadi Liakhovetski Date: Fri Apr 15 20:08:19 2011 +0200 mmc: fix a race between card-detect rescan and clock-gate work instances commit 26fc8775b51484d8c0a671198639c6d5ae60533e upstream. Currently there is a race in the MMC core between a card-detect rescan work and the clock-gating work, scheduled from a command completion. Fix it by removing the dedicated clock-gating mutex and using the MMC standard locking mechanism instead. Signed-off-by: Guennadi Liakhovetski Cc: Simon Horman Cc: Magnus Damm Acked-by: Linus Walleij Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman commit f038f4d893e9ef35dd38f1ca01001dfe21c5f8f5 Author: Artem Bityutskiy Date: Mon Apr 25 18:46:31 2011 +0300 UBIFS: seek journal heads to the latest bud in replay commit 52c6e6f990669deac3f370f1603815adb55a1dbd upstream. This is the second fix of the following symptom: UBIFS error (pid 34456): could not find an empty LEB which sometimes happens after power cuts when we mount the file-system - UBIFS refuses it with the above error message which comes from the 'ubifs_rcvry_gc_commit()' function. I can reproduce this using the integck test with the UBIFS power cut emulation enabled. Analysis of the problem. Currently UBIFS replay seeks the journal heads to the last _replayed_ bud. But the buds are replayed out-of-order, so the replay basically seeks journal heads to the "random" bud belonging to this head, and not to the _last_ one. The result of this is that the GC head may be seeked to a full LEB with no free space, or very little free space. And 'ubifs_rcvry_gc_commit()' tries to find a fully or mostly dirty LEB to match the current GC head (because we need to garbage-collect that dirty LEB at one go, because we do not have @c->gc_lnum). So 'ubifs_find_dirty_leb()' fails and we fall back to finding an empty LEB and also fail. As a result - recovery fails and mounting fails. This patch teaches the replay to initialize the GC heads exactly to the latest buds, i.e. the buds which have the largest sequence number in corresponding log reference nodes. Signed-off-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman commit 21fb89793df408cc116aa52399a5e6f7af459596 Author: Artem Bityutskiy Date: Mon Apr 25 18:17:09 2011 +0300 UBIFS: do not free write-buffers when in R/O mode commit b50b9f408502a2ea90459ae36ba8cdc9cc005cfe upstream. Currently UBIFS has a small optimization - it frees write-buffers when it is re-mounted from R/W mode to R/O mode. Of course, when it is mounted R/O, it does not allocate write-buffers as well. This optimization is nice but it leads to subtle problems and complications in recovery, which I can reproduce using the integck test. The symptoms are that after a power cut the file-system cannot be mounted if we first mount it R/O, and then re-mount R/W - 'ubifs_rcvry_gc_commit()' prints: UBIFS error (pid 34456): could not find an empty LEB Analysis of the problem. When mounting R/W, the reply process sets journal heads to buds [1], but when mounting R/O - it does not do this, because the write-buffers are not allocated. So 'ubifs_rcvry_gc_commit()' works completely differently for the same file-system but for the following 2 cases: 1. mounting R/W after a power cut and recover 2. mounting R/O after a power cut, re-mounting R/W and run deferred recovery In the former case, we have journal heads seeked to the a bud, in the latter case, they are non-seeked (wbuf->lnum == -1). So in the latter case we do not try to recover the GC LEB by garbage-collecting to the GC head, but we just try to find an empty LEB, and there may be no empty LEBs, so we just fail. On the other hand, in the former case (mount R/W), we are able to make a GC LEB (@c->gc_lnum) by garbage-collecting. Thus, let's remove this small nice optimization and always allocate write-buffers. This should not make too big difference - we have only 3 of them, each of max. write unit size, which is usually 2KiB. So this is about 6KiB of RAM for the typical case, and only when mounted R/O. [1]: Note, currently the replay process is setting (seeking) the journal heads to _some_ buds, not necessarily to the buds which had been the journal heads before the power cut happened. This will be fixed separately. Signed-off-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman commit b000ec13075615ace30250ab6e355a3f0c956735 Author: Tim Gardner Date: Wed Apr 20 09:00:49 2011 +0000 atl1c: Fix work event interrupt/task races commit cb771838715b1c470bc5735bdae709b33b18e0ad upstream. The mechanism used to initiate work events from the interrupt handler has a classic read/modify/write race between the interrupt handler that sets the condition, and the worker task that reads and clears the condition. Close these races by using atomic bit fields. Cc: Jie Yang Signed-off-by: Tim Gardner Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 40b2b978ebc16d96805c8330883967a0ca8aedf9 Author: Stanislaw Gruszka Date: Fri Apr 29 17:51:06 2011 +0200 iwlagn: fix "Received BA when not expected" commit bfd36103ec26599557c2bd3225a1f1c9267f8fcb upstream. Need to use broadcast sta_id for management frames, otherwise we broke BA session in the firmware and get messages like that: "Received BA when not expected" or (on older kernels): "BA scd_flow 0 does not match txq_id 10" This fix regression introduced in 2.6.35 during station management code rewrite by: commit 2a87c26bbe9587baeb9e56d3ce0b4971bd777643 Author: Johannes Berg Date: Fri Apr 30 11:30:45 2010 -0700 iwlwifi: use iwl_find_station less Patch partially resolve: https://bugzilla.kernel.org/show_bug.cgi?id=16691 However, there are still 11n performance problems on 4965 and 5xxx devices that need to be investigated. Signed-off-by: Stanislaw Gruszka Acked-by: Johannes Berg Acked-by: Wey-Yi Guy Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 0d15c412b9d90238f94d1ec0100f4035582b29cf Author: Stanislaw Gruszka Date: Wed Apr 20 15:57:14 2011 +0200 iwlwifi: fix skb usage after free commit b25026981aecde3685dd0e45ad980fff9f528daa upstream. Since commit a120e912eb51e347f36c71b60a1d13af74d30e83 Author: Stanislaw Gruszka Date: Fri Feb 19 15:47:33 2010 -0800 iwlwifi: sanity check before counting number of tfds can be free we use skb->data after calling ieee80211_tx_status_irqsafe(), which could free skb instantly. On current kernels I do not observe practical problems related with bug, but on 2.6.35.y it cause random system hangs when stressing wireless link. Signed-off-by: Stanislaw Gruszka Acked-by: Wey-Yi Guy Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 5a19c7ecdc631407d490d206b80ed790daad99cd Author: Tejun Heo Date: Fri Apr 29 18:08:37 2011 +0200 workqueue: fix deadlock in worker_maybe_bind_and_lock() commit 5035b20fa5cd146b66f5f89619c20a4177fb736d upstream. If a rescuer and stop_machine() bringing down a CPU race with each other, they may deadlock on non-preemptive kernel. The CPU won't accept a new task, so the rescuer can't migrate to the target CPU, while stop_machine() can't proceed because the rescuer is holding one of the CPU retrying migration. GCWQ_DISASSOCIATED is never cleared and worker_maybe_bind_and_lock() retries indefinitely. This problem can be reproduced semi reliably while the system is entering suspend. http://thread.gmane.org/gmane.linux.kernel/1122051 A lot of kudos to Thilo-Alexander for reporting this tricky issue and painstaking testing. stable: This affects all kernels with cmwq, so all kernels since and including v2.6.36 need this fix. Signed-off-by: Tejun Heo Reported-by: Thilo-Alexander Ginkel Tested-by: Thilo-Alexander Ginkel Signed-off-by: Greg Kroah-Hartman commit bcd0df39767d1c4352566d909291deac099b222b Author: Jean Delvare Date: Sun May 1 18:18:49 2011 +0200 i2c-parport: Fix adapter list handling commit 56acc7a39ac4ac7638cdc32cd3d0832ebbc834e4 upstream. Use a standard list with proper locking to handle the list of adapters. Thankfully it only matters on systems with more than one parallel port, which are very rare. Thanks to Lukasz Kapiec for reporting the problem to me. Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit bbb267c7d49c3a9be39e7f59bae56500afee0ab3 Author: Takashi Iwai Date: Mon May 2 13:55:36 2011 +0200 ALSA: hda - Fix Realtek's chained fixup checks commit 24af2b1cc418d6791b1d9e56bf6070cccb752db3 upstream. The check of chained fixup list entry was done against the wrong element. A stupid mistake during refactoring. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit cd529bb9b1e202f289ff9c2182f7d274e5e7160f Author: Takashi Iwai Date: Mon May 2 10:37:29 2011 +0200 Revert "ALSA: hda - Fix pin-config of Gigabyte mobo" commit ebb47241ea0eac6a5a23404821a2d62f64c68496 upstream. This reverts commit c6b358748e19ce7e230b0926ac42696bc485a562. It turned out that there are different pin configurations for this PCI SSID, including multi-channel modes. And more proper fix for allowing line-out mutes will come up in 2.6.40 tree, so we won't need this fixup any more there. Reported-by: Andrew Clayton Reported-by: Emmanuel Benisty Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 13ec44a014c358e98cdc6a9af3d891b7d3753d59 Author: David Henningsson Date: Fri Apr 29 14:10:55 2011 +0200 ALSA: HDA: Fix automute for Gateway NV79 commit 94024cd1aefa0f8bcc9dfe46c05bd7ce3f471a1c upstream. The PCI SSID is 1025:031c and the codec SSID is 1025:031d, so the driver mistakes this for a SKU value, but looking at the numbers, this is obviously wrong. BugLink: http://bugs.launchpad.net/bugs/761861 Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1f74c190e1e97a38823c07fdc71780580a0fc03f Author: James Bottomley Date: Fri Apr 22 10:39:59 2011 -0500 put stricter guards on queue dead checks commit 86cbfb5607d4b81b1a993ff689bbd2addd5d3a9b upstream. SCSI uses request_queue->queuedata == NULL as a signal that the queue is dying. We set this state in the sdev release function. However, this allows a small window where we release the last reference but haven't quite got to this stage yet and so something will try to take a reference in scsi_request_fn and oops. It's very rare, but we had a report here, so we're pushing this as a bug fix The actual fix is to set request_queue->queuedata to NULL in scsi_remove_device() before we drop the reference. This causes correct automatic rejects from scsi_request_fn as people who hold additional references try to submit work and prevents anything from getting a new reference to the sdev that way. Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 52adc5764d7cbeddce5e70aac1a14f534d004b60 Author: Mike Snitzer Date: Fri Apr 8 15:05:36 2011 -0400 scsi_dh: fix reference counting in scsi_dh_activate error path commit 0b8393578c70bc1f09790eeae7d918f38da2e010 upstream. Commit db422318cbca55168cf965f655471dbf8be82433 ([SCSI] scsi_dh: propagate SCSI device deletion) introduced a regression where the device reference is not dropped prior to scsi_dh_activate's early return from the error path. Signed-off-by: Mike Snitzer Reviewed-by: Mike Christie Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 5c9843ab660296536df95d53f44979bece79a87b Author: Dan Rosenberg Date: Tue Apr 5 12:45:59 2011 -0400 mpt2sas: prevent heap overflows and unchecked reads commit a1f74ae82d133ebb2aabb19d181944b4e83e9960 upstream. At two points in handling device ioctls via /dev/mpt2ctl, user-supplied length values are used to copy data from userspace into heap buffers without bounds checking, allowing controllable heap corruption and subsequently privilege escalation. Additionally, user-supplied values are used to determine the size of a copy_to_user() as well as the offset into the buffer to be read, with no bounds checking, allowing users to read arbitrary kernel memory. Signed-off-by: Dan Rosenberg Acked-by: Eric Moore Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit cf546a1fd7fd736f1cd471f059900d477a4b7096 Author: Dan Rosenberg Date: Tue Apr 5 13:27:31 2011 -0400 pmcraid: reject negative request size commit 5f6279da3760ce48f478f2856aacebe0c59a39f3 upstream. There's a code path in pmcraid that can be reached via device ioctl that causes all sorts of ugliness, including heap corruption or triggering the OOM killer due to consecutive allocation of large numbers of pages. Not especially relevant from a security perspective, since users must have CAP_SYS_ADMIN to open the character device. First, the user can call pmcraid_chr_ioctl() with a type PMCRAID_PASSTHROUGH_IOCTL. A pmcraid_passthrough_ioctl_buffer is copied in, and the request_size variable is set to buffer->ioarcb.data_transfer_length, which is an arbitrary 32-bit signed value provided by the user. If a negative value is provided here, bad things can happen. For example, pmcraid_build_passthrough_ioadls() is called with this request_size, which immediately calls pmcraid_alloc_sglist() with a negative size. The resulting math on allocating a scatter list can result in an overflow in the kzalloc() call (if num_elem is 0, the sglist will be smaller than expected), or if num_elem is unexpectedly large the subsequent loop will call alloc_pages() repeatedly, a high number of pages will be allocated and the OOM killer might be invoked. Prevent this value from being negative in pmcraid_ioctl_passthrough(). Signed-off-by: Dan Rosenberg Cc: Anil Ravindranath Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman