commit 92a7adfb8118f64787beb27b597d43f0202715d2 Author: Greg Kroah-Hartman Date: Thu Mar 14 11:30:25 2013 -0700 Linux 3.4.36 commit 8420d82e3a25e0f64526db253056945b1585dc08 Author: Sarah Sharp Date: Wed Mar 13 10:59:21 2013 -0700 USB: Fix connected device switch to Inactive state. [This is upstream commit d3b9d7a9051d7024a93c76a84b2f84b3b66ad6d5. It needs to be backported to kernels as old as 3.2, because it fixes the buggy commit 9dbcaec830cd97f44a0b91b315844e0d7144746b "USB: Handle warm reset failure on empty port."] A USB 3.0 device can transition to the Inactive state if a U1 or U2 exit transition fails. The current code in hub_events simply issues a warm reset, but does not call any pre-reset or post-reset driver methods (or unbind/rebind drivers without them). Therefore the drivers won't know their device has just been reset. hub_events should instead call usb_reset_device. This means hub_port_reset now needs to figure out whether it should issue a warm reset or a hot reset. Remove the FIXME note about needing disconnect() for a NOTATTACHED device. This patch fixes that. Signed-off-by: Sarah Sharp Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 983c9b4e483b7720e72378d69ef18b6188d17ab1 Author: Greg Kroah-Hartman Date: Tue Mar 12 15:18:13 2013 -0700 Revert "ALSA: hda - hdmi: Make jacks phantom, if they're not detectable" This reverts commit 30efd8debd1ef30be342d374f01e993509f5b76b upstream (dd54ec4067a23236736afecbda120030d7ce8fe9 in this tree) as it is not needed for the 3.4-stable tree. Cc: David Henningsson Cc: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit beabe20445c60322719d8f58e9eb9dd4660c1b3e Author: Sarah Sharp Date: Thu Mar 7 16:24:24 2013 -0800 USB: Rip out recursive call on warm port reset. [This is upstream commit 24a6078754f28528bc91e7e7b3e6ae86bd936d8. It needs to be backported to kernels as old as 3.2, because it fixes the buggy commit 9dbcaec830cd97f44a0b91b315844e0d7144746b "USB: Handle warm reset failure on empty port."] When a hot reset fails on a USB 3.0 port, the current port reset code recursively calls hub_port_reset inside hub_port_wait_reset. This isn't ideal, since we should avoid recursive calls in the kernel, and it also doesn't allow us to issue multiple warm resets on reset failures. Rip out the recursive call. Instead, add code to hub_port_reset to issue a warm reset if the hot reset fails, and try multiple warm resets before giving up on the port. In hub_port_wait_reset, remove the recursive call and re-indent. The code is basically the same, except: 1. It bails out early if the port has transitioned to Inactive or Compliance Mode after the reset completed. 2. It doesn't consider a connect status change to be a failed reset. If multiple warm resets needed to be issued, the connect status may have changed, so we need to ignore that and look at the port link state instead. hub_port_reset will now do that. 3. It unconditionally sets udev->speed on all types of successful resets. The old recursive code would set the port speed when the second hub_port_reset returned. The old code did not handle connected devices needing a warm reset well. There were only two situations that the old code handled correctly: an empty port needing a warm reset, and a hot reset that migrated to a warm reset. When an empty port needed a warm reset, hub_port_reset was called with the warm variable set. The code in hub_port_finish_reset would skip telling the USB core and the xHC host that the device was reset, because otherwise that would result in a NULL pointer dereference. When a USB 3.0 device reset migrated to a warm reset, the recursive call made the call stack look like this: hub_port_reset(warm = false) hub_wait_port_reset(warm = false) hub_port_reset(warm = true) hub_wait_port_reset(warm = true) hub_port_finish_reset(warm = true) (return up the call stack to the first wait) hub_port_finish_reset(warm = false) The old code didn't want to notify the USB core or the xHC host of device reset twice, so it only did it in the second call to hub_port_finish_reset, when warm was set to false. This was necessary because before patch two ("USB: Ignore xHCI Reset Device status."), the USB core would pay attention to the xHC Reset Device command error status, and the second call would always fail. Now that we no longer have the recursive call, and warm can change from false to true in hub_port_reset, we need to have hub_port_finish_reset unconditionally notify the USB core and the xHC of the device reset. In hub_port_finish_reset, unconditionally clear the connect status change (CSC) bit for USB 3.0 hubs when the port reset is done. If we had to issue multiple warm resets for a device, that bit may have been set if the device went into SS.Inactive and then was successfully warm reset. Signed-off-by: Sarah Sharp Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit e850004e595d6322c6b7ccbfe21a4582051ad56b Author: Sarah Sharp Date: Thu Mar 7 16:24:22 2013 -0800 USB: Prepare for refactoring by adding extra udev checks. [This is upstream commit 2d4fa940f99663c82ba55b2244638833b388e4e2. It needs to be backported to kernels as old as 3.2, because it fixes the buggy commit 9dbcaec830cd97f44a0b91b315844e0d7144746b "USB: Handle warm reset failure on empty port."] The next patch will refactor the hub port code to rip out the recursive call to hub_port_reset on a failed hot reset. In preparation for that, make sure all code paths can deal with being called with a NULL udev. The usb_device will not be valid if warm reset was issued because a port transitioned to the Inactive or Compliance Mode on a device connect. This patch should have no effect on current behavior. Signed-off-by: Sarah Sharp Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit ac79dc9b4a929bd8c0d9e4a2fccd3b7215cbaee4 Author: Sarah Sharp Date: Thu Mar 7 16:24:19 2013 -0800 USB: Don't use EHCI port sempahore for USB 3.0 hubs. [This is upstream commit 0fe51aa5eee51db7c7ecd201d42a977ad79c58b6. It needs to be backported to kernels as old as 3.2, because it fixes the buggy commit 9dbcaec830cd97f44a0b91b315844e0d7144746b "USB: Handle warm reset failure on empty port."] The EHCI host controller needs to prevent EHCI initialization when the UHCI or OHCI companion controller is in the middle of a port reset. It uses ehci_cf_port_reset_rwsem to do this. USB 3.0 hubs can't be under an EHCI host controller, so it makes no sense to down the semaphore for USB 3.0 hubs. It also makes the warm port reset code more complex. Don't down ehci_cf_port_reset_rwsem for USB 3.0 hubs. Signed-off-by: Sarah Sharp Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit d2c96b7257048e9a558f2ebe4fe884b51fd9016f Author: Ben Hutchings Date: Fri Mar 8 12:43:32 2013 -0800 dmi_scan: fix missing check for _DMI_ signature in smbios_present() commit a40e7cf8f06b4e322ba902e4e9f6a6b0c2daa907 upstream. Commit 9f9c9cbb6057 ("drivers/firmware/dmi_scan.c: fetch dmi version from SMBIOS if it exists") hoisted the check for "_DMI_" into dmi_scan_machine(), which means that we don't bother to check for "_DMI_" at offset 16 in an SMBIOS entry. smbios_present() may also call dmi_present() for an address where we found "_SM_", if it failed further validation. Check for "_DMI_" in smbios_present() before calling dmi_present(). [akpm@linux-foundation.org: fix build] Signed-off-by: Ben Hutchings Reported-by: Tim McGrath Tested-by: Tim Mcgrath Cc: Zhenzhong Duan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit abf73cb191a83045c3cc6f46ea78b94439957585 Author: Steven Rostedt Date: Wed Feb 27 21:48:09 2013 -0500 ftrace: Update the kconfig for DYNAMIC_FTRACE commit db05021d49a994ee40a9735d9c3cb0060c9babb8 upstream. The prompt to enable DYNAMIC_FTRACE (the ability to nop and enable function tracing at run time) had a confusing statement: "enable/disable ftrace tracepoints dynamically" This was written before tracepoints were added to the kernel, but now that tracepoints have been added, this is very confusing and has confused people enough to give wrong information during presentations. Not only that, I looked at the help text, and it still references that dreaded daemon that use to wake up once a second to update the nop locations and brick NICs, that hasn't been around for over five years. Time to bring the text up to the current decade. Reported-by: Ezequiel Garcia Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit f39e4f133d52fad48f5c823b6c8a867caf101677 Author: Tu, Xiaobing Date: Tue Oct 23 01:03:00 2012 +0200 Fix memory leak in cpufreq stats. commit e37736777254ce1abc85493a5cacbefe5983b896 upstream. When system enters sleep, non-boot CPUs will be disabled. Cpufreq stats sysfs is created when the CPU is up, but it is not freed when the CPU is going down. This will cause memory leak. Signed-off-by: xiaobing tu Signed-off-by: guifang tang Signed-off-by: Rafael J. Wysocki Cc: Colin Cross Signed-off-by: Greg Kroah-Hartman commit cc6de71e8c24edbad16e45c011013d40eb903ffd Author: Al Viro Date: Tue Mar 12 02:59:49 2013 +0000 vfs: fix pipe counter breakage commit a930d8790552658140d7d0d2e316af4f0d76a512 upstream. If you open a pipe for neither read nor write, the pipe code will not add any usage counters to the pipe, causing the 'struct pipe_inode_info" to be potentially released early. That doesn't normally matter, since you cannot actually use the pipe, but the pipe release code - particularly fasync handling - still expects the actual pipe infrastructure to all be there. And rather than adding NULL pointer checks, let's just disallow this case, the same way we already do for the named pipe ("fifo") case. This is ancient going back to pre-2.4 days, and until trinity, nobody naver noticed. Reported-by: Dave Jones Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3126603e01babcec7cfe2f284099e2adff095bff Author: Mathieu Desnoyers Date: Mon Feb 25 10:20:36 2013 -0500 Fix: compat_rw_copy_check_uvector() misuse in aio, readv, writev, and security keys commit 8aec0f5d4137532de14e6554fd5dd201ff3a3c49 upstream. Looking at mm/process_vm_access.c:process_vm_rw() and comparing it to compat_process_vm_rw() shows that the compatibility code requires an explicit "access_ok()" check before calling compat_rw_copy_check_uvector(). The same difference seems to appear when we compare fs/read_write.c:do_readv_writev() to fs/compat.c:compat_do_readv_writev(). This subtle difference between the compat and non-compat requirements should probably be debated, as it seems to be error-prone. In fact, there are two others sites that use this function in the Linux kernel, and they both seem to get it wrong: Now shifting our attention to fs/aio.c, we see that aio_setup_iocb() also ends up calling compat_rw_copy_check_uvector() through aio_setup_vectored_rw(). Unfortunately, the access_ok() check appears to be missing. Same situation for security/keys/compat.c:compat_keyctl_instantiate_key_iov(). I propose that we add the access_ok() check directly into compat_rw_copy_check_uvector(), so callers don't have to worry about it, and it therefore makes the compat call code similar to its non-compat counterpart. Place the access_ok() check in the same location where copy_from_user() can trigger a -EFAULT error in the non-compat code, so the ABI behaviors are alike on both compat and non-compat. While we are here, fix compat_do_readv_writev() so it checks for compat_rw_copy_check_uvector() negative return values. And also, fix a memory leak in compat_keyctl_instantiate_key_iov() error handling. Acked-by: Linus Torvalds Acked-by: Al Viro Signed-off-by: Mathieu Desnoyers Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 96ace773358d2989ea522a1cdccf65d75c1335f3 Author: David Howells Date: Tue Mar 12 16:44:31 2013 +1100 keys: fix race with concurrent install_user_keyrings() commit 0da9dfdd2cd9889201bc6f6f43580c99165cd087 upstream. This fixes CVE-2013-1792. There is a race in install_user_keyrings() that can cause a NULL pointer dereference when called concurrently for the same user if the uid and uid-session keyrings are not yet created. It might be possible for an unprivileged user to trigger this by calling keyctl() from userspace in parallel immediately after logging in. Assume that we have two threads both executing lookup_user_key(), both looking for KEY_SPEC_USER_SESSION_KEYRING. THREAD A THREAD B =============================== =============================== ==>call install_user_keyrings(); if (!cred->user->session_keyring) ==>call install_user_keyrings() ... user->uid_keyring = uid_keyring; if (user->uid_keyring) return 0; <== key = cred->user->session_keyring [== NULL] user->session_keyring = session_keyring; atomic_inc(&key->usage); [oops] At the point thread A dereferences cred->user->session_keyring, thread B hasn't updated user->session_keyring yet, but thread A assumes it is populated because install_user_keyrings() returned ok. The race window is really small but can be exploited if, for example, thread B is interrupted or preempted after initializing uid_keyring, but before doing setting session_keyring. This couldn't be reproduced on a stock kernel. However, after placing systemtap probe on 'user->session_keyring = session_keyring;' that introduced some delay, the kernel could be crashed reliably. Fix this by checking both pointers before deciding whether to return. Alternatively, the test could be done away with entirely as it is checked inside the mutex - but since the mutex is global, that may not be the best way. Signed-off-by: David Howells Reported-by: Mateusz Guzik Signed-off-by: Andrew Morton Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit 30e39b7c57422b29533a1bf43f2fd921e088a71d Author: Mathias Krause Date: Tue Feb 5 18:19:13 2013 +0100 crypto: user - fix info leaks in report API commit 9a5467bf7b6e9e02ec9c3da4e23747c05faeaac6 upstream. Three errors resulting in kernel memory disclosure: 1/ The structures used for the netlink based crypto algorithm report API are located on the stack. As snprintf() does not fill the remainder of the buffer with null bytes, those stack bytes will be disclosed to users of the API. Switch to strncpy() to fix this. 2/ crypto_report_one() does not initialize all field of struct crypto_user_alg. Fix this to fix the heap info leak. 3/ For the module name we should copy only as many bytes as module_name() returns -- not as much as the destination buffer could hold. But the current code does not and therefore copies random data from behind the end of the module name, as the module name is always shorter than CRYPTO_MAX_ALG_NAME. Also switch to use strncpy() to copy the algorithm's name and driver_name. They are strings, after all. Signed-off-by: Mathias Krause Cc: Steffen Klassert Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 76de736ea670500c46e84bff7ae0e040f69d4397 Author: Konrad Rzeszutek Wilk Date: Tue Feb 26 12:51:27 2013 -0500 xen/pat: Disable PAT using pat_enabled value. commit c79c49826270b8b0061b2fca840fc3f013c8a78a upstream. The git commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1 (xen/pat: Disable PAT support for now) explains in details why we want to disable PAT for right now. However that change was not enough and we should have also disabled the pat_enabled value. Otherwise we end up with: mmap-example:3481 map pfn expected mapping type write-back for [mem 0x00010000-0x00010fff], got uncached-minus ------------[ cut here ]------------ WARNING: at /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774 untrack_pfn+0xb8/0xd0() mem 0x00010000-0x00010fff], got uncached-minus ------------[ cut here ]------------ WARNING: at /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774 untrack_pfn+0xb8/0xd0() ... Pid: 3481, comm: mmap-example Tainted: GF 3.8.0-6-generic #13-Ubuntu Call Trace: [] warn_slowpath_common+0x7f/0xc0 [] warn_slowpath_null+0x1a/0x20 [] untrack_pfn+0xb8/0xd0 [] unmap_single_vma+0xac/0x100 [] unmap_vmas+0x49/0x90 [] exit_mmap+0x98/0x170 [] mmput+0x64/0x100 [] dup_mm+0x445/0x660 [] copy_process.part.22+0xa5f/0x1510 [] do_fork+0x91/0x350 [] sys_clone+0x16/0x20 [] stub_clone+0x69/0x90 [] ? system_call_fastpath+0x1a/0x1f ---[ end trace 4918cdd0a4c9fea4 ]--- (a similar message shows up if you end up launching 'mcelog') The call chain is (as analyzed by Liu, Jinsong): do_fork --> copy_process --> dup_mm --> dup_mmap --> copy_page_range --> track_pfn_copy --> reserve_pfn_range --> line 624: flags != want_flags It comes from different memory types of page table (_PAGE_CACHE_WB) and MTRR (_PAGE_CACHE_UC_MINUS). Stefan Bader dug in this deep and found out that: "That makes it clearer as this will do reserve_memtype(...) --> pat_x_mtrr_type --> mtrr_type_lookup --> __mtrr_type_lookup And that can return -1/0xff in case of MTRR not being enabled/initialized. Which is not the case (given there are no messages for it in dmesg). This is not equal to MTRR_TYPE_WRBACK and thus becomes _PAGE_CACHE_UC_MINUS. It looks like the problem starts early in reserve_memtype: if (!pat_enabled) { /* This is identical to page table setting without PAT */ if (new_type) { if (req_type == _PAGE_CACHE_WC) *new_type = _PAGE_CACHE_UC_MINUS; else *new_type = req_type & _PAGE_CACHE_MASK; } return 0; } This would be what we want, that is clearing the PWT and PCD flags from the supported flags - if pat_enabled is disabled." This patch does that - disabling PAT. Reported-by: Sander Eikelenboom Reported-and-Tested-by: Konrad Rzeszutek Wilk Reported-and-Tested-by: Stefan Bader Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit 626614bf45e336d2623c90a812e6bd141e86949e Author: Benjamin Tissoires Date: Tue Mar 5 17:09:00 2013 +0100 HID: logitech-dj: do not directly call hid_output_raw_report() during probe commit dcd9006b1b053c7b1cebe81333261d4fd492ffeb upstream. hid_output_raw_report() makes a direct call to usb_control_msg(). However, some USB3 boards have shown that the usb device is not ready during the .probe(). This blocks the entire usb device, and the paired mice, keyboards are not functional. The dmesg output is the following: [ 11.912287] logitech-djreceiver 0003:046D:C52B.0003: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-2/input2 [ 11.912537] logitech-djreceiver 0003:046D:C52B.0003: logi_dj_probe:logi_dj_recv_query_paired_devices error:-32 [ 11.912636] logitech-djreceiver: probe of 0003:046D:C52B.0003 failed with error -32 Relying on the scheduled call to usbhid_submit_report() fixes the problem. related bugs: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1072082 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1039143 https://bugzilla.redhat.com/show_bug.cgi?id=840391 https://bugzilla.kernel.org/show_bug.cgi?id=49781 Reported-and-tested-by: Bob Bowles Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 1c48233e2eea4790e4b85b0e8b40537cecdba841 Author: Konstantin Khlebnikov Date: Tue Mar 5 09:42:59 2013 +0000 e1000e: fix pci-device enable-counter balance commit 4e0855dff094b0d56d6b5b271e0ce7851cc1e063 upstream. This patch removes redundant and unbalanced pci_disable_device() from __e1000_shutdown(). pci_clear_master() is enough, device can go into suspended state with elevated enable_cnt. Bug was introduced in commit 23606cf5d1192c2b17912cb2ef6e62f9b11de133 ("e1000e / PCI / PM: Add basic runtime PM support (rev. 4)") in v2.6.35 Signed-off-by: Konstantin Khlebnikov Cc: Bruce Allan Acked-by: Rafael J. Wysocki Tested-by: Borislav Petkov Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman commit f4ec9b23b178caab8e4ecc8b4a4c3531211411a9 Author: Takashi Iwai Date: Tue Mar 5 15:43:39 2013 +0100 ALSA: vmaster: Fix slave change notification commit 2069d483b39a603a5f3428a19d3b4ac89aa97f48 upstream. When a value of a vmaster slave control is changed, the ctl change notification is sometimes ignored. This happens when the master control overrides, e.g. when the corresponding master control is muted. The reason is that slave_put() returns the value of the actual slave put callback, and it doesn't reflect the virtual slave value change. This patch fixes the function just to return 1 whenever a slave value is changed. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1515f18665088e33e35706bd35268a16e8e7665d Author: Sean Connor Date: Thu Feb 28 09:20:00 2013 -0500 ALSA: ice1712: Initialize card->private_data properly commit 69a4cfdd444d1fe5c24d29b3a063964ac165d2cd upstream. Set card->private_data in snd_ice1712_create for fixing NULL dereference in snd_ice1712_remove(). Signed-off-by: Sean Connor Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 724285cf2c0ef53c2217a6a866ab50d57c386292 Author: Will Deacon Date: Thu Feb 28 17:49:11 2013 +0100 ARM: 7663/1: perf: fix ARMv7 EVTYPE_MASK to include NSH bit commit f2fe09b055e2549de41fb107b34c60bac4a1b0cf upstream. Masked out PMXEVTYPER.NSH means that we can't enable profiling at PL2, regardless of the settings in the HDCR. This patch fixes the broken mask. Reported-by: Christoffer Dall Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit b08994da73be68f17f82a522f4f129c18dbbf77f Author: Alex Deucher Date: Wed Feb 27 12:01:58 2013 -0500 drm/radeon: add primary dac adj quirk for R200 board commit e8fc41377f5037ff7a661ea06adc05f1daec1548 upstream. vbios values are wrong leading to colors that are too bright. Use the default values instead. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit bc37694dbaf8604619228ccc6e34528182b3a987 Author: Guenter Roeck Date: Thu Feb 21 10:49:40 2013 -0800 hwmon: (pmbus/ltc2978) Use detected chip ID to select supported functionality commit f366fccd0809f13ba20d64cae3c83f7338c88af7 upstream. We read the chip ID from the chip, use it to determine if the chip ID provided to the driver is correct, and report it if wrong. We should also use the correct chip ID to select supported functionality. Signed-off-by: Guenter Roeck Acked-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit ec2bc2f65c469aa5d0a1eb21f8404e0e3114bde4 Author: Guenter Roeck Date: Thu Feb 21 09:33:25 2013 -0800 hwmon: (pmbus/ltc2978) Fix peak attribute handling commit dbd712c2272764a536e29ad6841dba74989a39d9 upstream. Peak attributes were not initialized and cleared correctly. Also, temp2_max is only supported on page 0 and thus does not need to be an array. Signed-off-by: Guenter Roeck Acked-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit cca30bd4c94123776dc3620cd13c6aedb76e4b55 Author: Mark Brown Date: Sat Mar 2 15:33:30 2013 +0800 hwmon: (sht15) Check return value of regulator_enable() commit 3e78080f81481aa8340374d5a37ae033c1cf4272 upstream. Not having power is a pretty serious error so check that we are able to enable the supply and error out if we can't. Signed-off-by: Mark Brown Signed-off-by: Guenter Roeck commit fbad8075baa695da5da4952969682172966a4fac Author: NeilBrown Date: Thu Feb 21 15:36:38 2013 +1100 md: raid0: fix error return from create_stripe_zones. commit 58ebb34c49fcfcaa029e4b1c1453d92583900f9a upstream. Create_stripe_zones returns an error slightly differently to raid0_run and to raid0_takeover_*. The error returned used by the second was wrong and an error would result in mddev->private being set to NULL and sooner or later a crash. So never return NULL, return ERR_PTR(err), not NULL from create_stripe_zones. This bug has been present since 2.6.35 so the fix is suitable for any kernel since then. Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit c443082d1998879713ecf9f97ee4ba8c76f8b7f0 Author: NeilBrown Date: Thu Feb 21 14:33:17 2013 +1100 md: fix two bugs when attempting to resize RAID0 array. commit a64685399181780998281fe07309a94b25dd24c3 upstream. You cannot resize a RAID0 array (in terms of making the devices bigger), but the code doesn't entirely stop you. So: disable setting of the available size on each device for RAID0 and Linear devices. This must not change as doing so can change the effective layout of data. Make sure that the size that raid0_size() reports is accurate, but rounding devices sizes to chunk sizes. As the device sizes cannot change now, this isn't so important, but it is best to be safe. Without this change: mdadm --grow /dev/md0 -z max mdadm --grow /dev/md0 -Z max then read to the end of the array can cause a BUG in a RAID0 array. These bugs have been present ever since it became possible to resize any device, which is a long time. So the fix is suitable for any -stable kerenl. Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 517557f2323d11a1a355e9c9155a1e315d87d487 Author: Sebastian Riemer Date: Thu Feb 21 13:28:09 2013 +1100 md: protect against crash upon fsync on ro array commit bbfa57c0f2243a7c31fd248d22e9861a2802cad5 upstream. If an fsync occurs on a read-only array, we need to send a completion for the IO and may not increment the active IO count. Otherwise, we hit a bug trace and can't stop the MD array anymore. By advice of Christoph Hellwig we return success upon a flush request but we return -EROFS for other writes. We detect flush requests by checking if the bio has zero sectors. This patch is suitable to any -stable kernel to which it applies. Signed-off-by: Sebastian Riemer Cc: Christoph Hellwig Cc: Ben Hutchings Cc: NeilBrown Reported-by: Ben Hutchings Acked-by: Paul Menzel Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit f9c89dac69cb99c00d4c273cad43f466fb9a1c8b Author: Felix Fietkau Date: Mon Feb 25 20:51:07 2013 +0100 ath9k_hw: improve reset reliability after errors commit 3412f2f086ea7531378fabe756bd4a1109994ae6 upstream. On many different chips, important aspects of the MAC state are not fully cleared by a warm reset. This can show up as tx/rx hangs, those annoying "DMA failed to stop in 10 ms..." messages or other quirks. On AR933x, the chip can occasionally get stuck in a way that only a driver unload/reload or a reboot would bring it back to life. With this patch, a full reset is issued when bringing the chip out of FULL-SLEEP state (after idle), or if either Rx or Tx was not shut down properly. This makes the DMA related error messages disappear completely in my tests on AR933x, and the chip does not get stuck anymore. Signed-off-by: Felix Fietkau Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 34127f32d576cb64717afade55c6fcff6b062451 Author: Felix Fietkau Date: Fri Feb 22 21:09:17 2013 +0100 ath9k: fix RSSI dummy marker value commit a3d63cadbad97671d740a9698acc2c95d1ca6e79 upstream. RSSI is being stored internally as s8 in several places. The indication of an unset RSSI value, ATH_RSSI_DUMMY_MARKER, was supposed to have been set to 127, but ended up being set to 0x127 because of a code cleanup mistake. This could lead to invalid signal strength values in a few places. Signed-off-by: Felix Fietkau Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 97cf710a238290b049f1f09dd220ca2f813d5fb9 Author: Avinash Patil Date: Mon Feb 25 16:01:34 2013 -0800 mwifiex: correct sleep delay counter commit 3e7a4ff7c5b6423ddb644df9c41b8b6d2fb79d30 upstream. Maximum delay for waking up card is 50 ms. Because of typo in counter, this delay goes to 500ms. This patch fixes the bug. Signed-off-by: Avinash Patil Signed-off-by: Amitkumar Karwar Signed-off-by: Yogesh Ashok Powar Signed-off-by: Bing Zhao Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 681e3b15fef858a9512d5fb2baceb85b0913385f Author: Rusty Russell Date: Tue Mar 5 10:07:08 2013 +1030 hw_random: make buffer usable in scatterlist. commit f7f154f1246ccc5a0a7e9ce50932627d60a0c878 upstream. virtio_rng feeds the randomness buffer handed by the core directly into the scatterlist, since commit bb347d98079a547e80bd4722dee1de61e4dca0e8. However, if CONFIG_HW_RANDOM=m, the static buffer isn't a linear address (at least on most archs). We could fix this in virtio_rng, but it's actually far easier to just do it in the core as virtio_rng would have to allocate a buffer every time (it doesn't know how much the core will want to read). Reported-by: Aurelien Jarno Tested-by: Aurelien Jarno Signed-off-by: Rusty Russell Signed-off-by: Greg Kroah-Hartman commit 7ae6c92933a962e3ff8b3999f88b5c7c86841b7f Author: Olaf Hering Date: Tue Sep 18 17:48:01 2012 +0200 ata_piix: reenable MS Virtual PC guests commit d9904344fc4052fbe7e4dc137eba0dcdadf326bd upstream. An earlier commit cd006086fa5d91414d8ff9ff2b78fbb593878e3c ("ata_piix: defer disks to the Hyper-V drivers by default") broke MS Virtual PC guests. Hyper-V guests and Virtual PC guests have nearly identical DMI info. As a result the driver does currently ignore the emulated hardware in Virtual PC guests and defers the handling to hv_blkvsc. Since Virtual PC does not offer paravirtualized drivers no disks will be found in the guest. One difference in the DMI info is the product version. This patch adds a match for MS Virtual PC 2007 and "unignores" the emulated hardware. This was reported for openSuSE 12.1 in bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=737532 Here is a detailed list of DMI info from example guests: hwinfo --bios: virtual pc guest: System Info: #1 Manufacturer: "Microsoft Corporation" Product: "Virtual Machine" Version: "VS2005R2" Serial: "3178-9905-1533-4840-9282-0569-59" UUID: undefined, but settable Wake-up: 0x06 (Power Switch) Board Info: #2 Manufacturer: "Microsoft Corporation" Product: "Virtual Machine" Version: "5.0" Serial: "3178-9905-1533-4840-9282-0569-59" Chassis Info: #3 Manufacturer: "Microsoft Corporation" Version: "5.0" Serial: "3178-9905-1533-4840-9282-0569-59" Asset Tag: "7188-3705-6309-9738-9645-0364-00" Type: 0x03 (Desktop) Bootup State: 0x03 (Safe) Power Supply State: 0x03 (Safe) Thermal State: 0x01 (Other) Security Status: 0x01 (Other) win2k8 guest: System Info: #1 Manufacturer: "Microsoft Corporation" Product: "Virtual Machine" Version: "7.0" Serial: "9106-3420-9819-5495-1514-2075-48" UUID: undefined, but settable Wake-up: 0x06 (Power Switch) Board Info: #2 Manufacturer: "Microsoft Corporation" Product: "Virtual Machine" Version: "7.0" Serial: "9106-3420-9819-5495-1514-2075-48" Chassis Info: #3 Manufacturer: "Microsoft Corporation" Version: "7.0" Serial: "9106-3420-9819-5495-1514-2075-48" Asset Tag: "7076-9522-6699-1042-9501-1785-77" Type: 0x03 (Desktop) Bootup State: 0x03 (Safe) Power Supply State: 0x03 (Safe) Thermal State: 0x01 (Other) Security Status: 0x01 (Other) win2k12 guest: System Info: #1 Manufacturer: "Microsoft Corporation" Product: "Virtual Machine" Version: "7.0" Serial: "8179-1954-0187-0085-3868-2270-14" UUID: undefined, but settable Wake-up: 0x06 (Power Switch) Board Info: #2 Manufacturer: "Microsoft Corporation" Product: "Virtual Machine" Version: "7.0" Serial: "8179-1954-0187-0085-3868-2270-14" Chassis Info: #3 Manufacturer: "Microsoft Corporation" Version: "7.0" Serial: "8179-1954-0187-0085-3868-2270-14" Asset Tag: "8374-0485-4557-6331-0620-5845-25" Type: 0x03 (Desktop) Bootup State: 0x03 (Safe) Power Supply State: 0x03 (Safe) Thermal State: 0x01 (Other) Security Status: 0x01 (Other) Signed-off-by: Olaf Hering Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit 1ecb6934fa86281d26d60d984f0e0e6554531813 Author: Trond Myklebust Date: Fri Feb 22 14:57:57 2013 -0500 SUNRPC: Don't start the retransmission timer when out of socket space commit a9a6b52ee1baa865283a91eb8d443ee91adfca56 upstream. If the socket is full, we're better off just waiting until it empties, or until the connection is broken. The reason why we generally don't want to time out is that the call to xprt->ops->release_xprt() will trigger a connection reset, which isn't helpful... Let's make an exception for soft RPC calls, since they have to provide timeout guarantees. Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit d3e8a1806bb6a9f2b4d56de44a87efc18e3e82fd Author: Trond Myklebust Date: Fri Feb 22 12:53:43 2013 -0500 NFS: Don't allow NFS silly-renamed files to be deleted, no signal commit 5a7a613a47a715711b3f2d3322a0eac21d459166 upstream. Commit 73ca100 broke the code that prevents the client from deleting a silly renamed dentry. This affected "delete on last close" semantics as after that commit, nothing prevented removal of silly-renamed files. As a result, a process holding a file open could easily get an ESTALE on the file in a directory where some other process issued 'rm -rf some_dir_containing_the_file' twice. Before the commit, any attempt at unlinking silly renamed files would fail inside may_delete() with -EBUSY because of the DCACHE_NFSFS_RENAMED flag. The following testcase demonstrates the problem: tail -f /nfsmnt/dir/file & rm -rf /nfsmnt/dir rm -rf /nfsmnt/dir # second removal does not fail, 'tail' process receives ESTALE The problem with the above commit is that it unhashes the old and new dentries from the lookup path, even in the normal case when a signal is not encountered and it would have been safe to call d_move. Unfortunately the old dentry has the special DCACHE_NFSFS_RENAMED flag set on it. Unhashing has the side-effect that future lookups call d_alloc(), allocating a new dentry without the special flag for any silly-renamed files. As a result, subsequent calls to unlink silly renamed files do not fail but allow the removal to go through. This will result in ESTALE errors for any other process doing operations on the file. To fix this, go back to using d_move on success. For the signal case, it's unclear what we may safely do beyond d_drop. Reported-by: Dave Wysochanski Signed-off-by: Trond Myklebust Acked-by: Jeff Layton Signed-off-by: Greg Kroah-Hartman commit 18d2c795ad10c2834518b083e3c6a58400f46a1a Author: Jeff Layton Date: Fri Feb 1 15:11:01 2013 -0500 cifs: ensure that cifs_get_root() only traverses directories commit ce2ac52105aa663056dfc17966ebed1bf93e6e64 upstream. Kjell Braden reported this oops: [ 833.211970] BUG: unable to handle kernel NULL pointer dereference at (null) [ 833.212816] IP: [< (null)>] (null) [ 833.213280] PGD 1b9b2067 PUD e9f7067 PMD 0 [ 833.213874] Oops: 0010 [#1] SMP [ 833.214344] CPU 0 [ 833.214458] Modules linked in: des_generic md4 nls_utf8 cifs vboxvideo drm snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq bnep rfcomm snd_timer bluetooth snd_seq_device ppdev snd vboxguest parport_pc joydev mac_hid soundcore snd_page_alloc psmouse i2c_piix4 serio_raw lp parport usbhid hid e1000 [ 833.215629] [ 833.215629] Pid: 1752, comm: mount.cifs Not tainted 3.0.0-rc7-bisectcifs-fec11dd9a0+ #18 innotek GmbH VirtualBox/VirtualBox [ 833.215629] RIP: 0010:[<0000000000000000>] [< (null)>] (null) [ 833.215629] RSP: 0018:ffff8800119c9c50 EFLAGS: 00010282 [ 833.215629] RAX: ffffffffa02186c0 RBX: ffff88000c427780 RCX: 0000000000000000 [ 833.215629] RDX: 0000000000000000 RSI: ffff88000c427780 RDI: ffff88000c4362e8 [ 833.215629] RBP: ffff8800119c9c88 R08: ffff88001fc15e30 R09: 00000000d69515c7 [ 833.215629] R10: ffffffffa0201972 R11: ffff88000e8f6a28 R12: ffff88000c4362e8 [ 833.215629] R13: 0000000000000000 R14: 0000000000000000 R15: ffff88001181aaa6 [ 833.215629] FS: 00007f2986171700(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000 [ 833.215629] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 833.215629] CR2: 0000000000000000 CR3: 000000001b982000 CR4: 00000000000006f0 [ 833.215629] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 833.215629] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 833.215629] Process mount.cifs (pid: 1752, threadinfo ffff8800119c8000, task ffff88001c1c16f0) [ 833.215629] Stack: [ 833.215629] ffffffff8116a9b5 ffff8800119c9c88 ffffffff81178075 0000000000000286 [ 833.215629] 0000000000000000 ffff88000c4276c0 ffff8800119c9ce8 ffff8800119c9cc8 [ 833.215629] ffffffff8116b06e ffff88001bc6fc00 ffff88000c4276c0 ffff88000c4276c0 [ 833.215629] Call Trace: [ 833.215629] [] ? d_alloc_and_lookup+0x45/0x90 [ 833.215629] [] ? d_lookup+0x35/0x60 [ 833.215629] [] __lookup_hash.part.14+0x9e/0xc0 [ 833.215629] [] lookup_one_len+0x146/0x1e0 [ 833.215629] [] ? _raw_spin_lock+0xe/0x20 [ 833.215629] [] cifs_do_mount+0x26d/0x500 [cifs] [ 833.215629] [] mount_fs+0x43/0x1b0 [ 833.215629] [] vfs_kern_mount+0x6a/0xd0 [ 833.215629] [] do_kern_mount+0x54/0x110 [ 833.215629] [] do_mount+0x262/0x840 [ 833.215629] [] ? __get_free_pages+0xe/0x50 [ 833.215629] [] ? copy_mount_options+0x3a/0x180 [ 833.215629] [] sys_mount+0x8d/0xe0 [ 833.215629] [] system_call_fastpath+0x16/0x1b [ 833.215629] Code: Bad RIP value. [ 833.215629] RIP [< (null)>] (null) [ 833.215629] RSP [ 833.215629] CR2: 0000000000000000 [ 833.238525] ---[ end trace ec00758b8d44f529 ]--- When walking down the path on the server, it's possible to hit a symlink. The path walking code assumes that the caller will handle that situation properly, but cifs_get_root() isn't set up for it. This patch prevents the oops by simply returning an error. A better solution would be to try and chase the symlinks here, but that's fairly complicated to handle. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=53221 Reported-and-tested-by: Kjell Braden Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit d0e44ede196b82c0448776b4b0c7c59989e3bea8 Author: Thomas Gleixner Date: Wed Feb 20 14:06:20 2013 -0500 btrfs: Init io_lock after cloning btrfs device struct commit 1cba0cdf5e4dbcd9e5fa5b54d7a028e55e2ca057 upstream. __btrfs_close_devices() clones btrfs device structs with memcpy(). Some of the fields in the clone are reinitialized, but it's missing to init io_lock. In mainline this goes unnoticed, but on RT it leaves the plist pointing to the original about to be freed lock struct. Initialize io_lock after cloning, so no references to the original struct are left. Reported-and-tested-by: Mike Galbraith Signed-off-by: Thomas Gleixner Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit a5646410c2d80c4dd4692f5f6bc2fcdfc3aa557b Author: Asias He Date: Wed Feb 27 13:29:29 2013 +0800 target/pscsi: Fix page increment commit 472b72f2db7831d7dbe22ffdff4adee3bd49b05d upstream. The page++ is wrong. It makes bio_add_pc_page() pointing to a wrong page address if the 'while (len > 0 && data_len > 0) { ... }' loop is executed more than one once. Signed-off-by: Asias He Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit c60de9344ceeedd5f61a655af34306002fda9167 Author: K. Y. Srinivasan Date: Wed Feb 6 05:15:28 2013 -0800 SCSI: storvsc: Initialize the sglist commit 9d2696e658ef4f209955ddaa987d43f1a1bd81a1 upstream. Properly initialize scatterlist before using it. Signed-off-by: K. Y. Srinivasan Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 76284215d03e98df97e12fa5b41ce5241ba47c35 Author: Dan Carpenter Date: Mon Feb 11 22:03:18 2013 +0300 SCSI: dc395x: uninitialized variable in device_alloc() commit 208afec4f3be8c51ad6eebe6611dd6d2ad2fa298 upstream. This bug was introduced back in bitkeeper days in 2003. We use "dcb->dev_mode" before it has been initialized. Signed-off-by: Dan Carpenter Acked-by: Oliver Neukum Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit f8ac69742302f0571303c7b21157295a122bec5d Author: Konrad Rzeszutek Wilk Date: Thu Feb 28 09:05:41 2013 -0500 xen/pci: We don't do multiple MSI's. commit 884ac2978a295b7df3c4a686d3bff6932bbbb460 upstream. There is no hypercall to setup multiple MSI per PCI device. As such with these two new commits: - 08261d87f7d1b6253ab3223756625a5c74532293 PCI/MSI: Enable multiple MSIs with pci_enable_msi_block_auto() - 5ca72c4f7c412c2002363218901eba5516c476b1 AHCI: Support multiple MSIs we would call the PHYSDEVOP_map_pirq 'nvec' times with the same contents of the PCI device. Sander discovered that we would get the same PIRQ value 'nvec' times and return said values to the caller. That of course meant that the device was configured only with one MSI and AHCI would fail with: ahci 0000:00:11.0: version 3.0 xen: registering gsi 19 triggering 0 polarity 1 xen: --> pirq=19 -> irq=19 (gsi=19) (XEN) [2013-02-27 19:43:07] IOAPIC[0]: Set PCI routing entry (6-19 -> 0x99 -> IRQ 19 Mode:1 Active:1) ahci 0000:00:11.0: AHCI 0001.0200 32 slots 4 ports 6 Gbps 0xf impl SATA mode ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part ahci: probe of 0000:00:11.0 failed with error -22 That is b/c in ahci_host_activate the second call to devm_request_threaded_irq would return -EINVAL as we passed in (on the second run) an IRQ that was never initialized. Reported-and-Tested-by: Sander Eikelenboom Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit b9dfac7b1a9263181f7027285d5335f25b1eabfd Author: Russell King Date: Mon Feb 25 16:10:42 2013 +0000 ARM: fix scheduling while atomic warning in alignment handling code commit b255188f90e2bade1bd11a986dd1ca4861869f4d upstream. Paolo Pisati reports that IPv6 triggers this warning: BUG: scheduling while atomic: swapper/0/0/0x40000100 Modules linked in: [] (unwind_backtrace+0x0/0xf0) from [] (__schedule_bug+0x48/0x5c) [] (__schedule_bug+0x48/0x5c) from [] (__schedule+0x700/0x740) [] (__schedule+0x700/0x740) from [] (__cond_resched+0x24/0x34) [] (__cond_resched+0x24/0x34) from [] (_cond_resched+0x3c/0x44) [] (_cond_resched+0x3c/0x44) from [] (do_alignment+0x178/0x78c) [] (do_alignment+0x178/0x78c) from [] (do_DataAbort+0x34/0x98) [] (do_DataAbort+0x34/0x98) from [] (__dabt_svc+0x40/0x60) Exception stack(0xc0763d70 to 0xc0763db8) 3d60: e97e805e e97e806e 2c000000 11000000 3d80: ea86bb00 0000002c 00000011 e97e807e c076d2a8 e97e805e e97e806e 0000002c 3da0: 3d000000 c0763dbc c04b98fc c02a8490 00000113 ffffffff [] (__dabt_svc+0x40/0x60) from [] (__csum_ipv6_magic+0x8/0xc8) Fix this by using probe_kernel_address() stead of __get_user(). Reported-by: Paolo Pisati Tested-by: Paolo Pisati Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 65723919649125f443ecfb2373b00f9febc62c47 Author: Russell King Date: Mon Feb 25 16:09:12 2013 +0000 ARM: VFP: fix emulation of second VFP instruction commit 5e4ba617c1b584b2e376f31a63bd4e734109318a upstream. Martin Storsjö reports that the sequence: ee312ac1 vsub.f32 s4, s3, s2 ee702ac0 vsub.f32 s5, s1, s0 e59f0028 ldr r0, [pc, #40] ee111a90 vmov r1, s3 on Raspberry Pi (implementor 41 architecture 1 part 20 variant b rev 5) where s3 is a denormal and s2 is zero results in incorrect behaviour - the instruction "vsub.f32 s5, s1, s0" is not executed: VFP: bounce: trigger ee111a90 fpexc d0000780 VFP: emulate: INST=0xee312ac1 SCR=0x00000000 ... As we can see, the instruction triggering the exception is the "vmov" instruction, and we emulate the "vsub.f32 s4, s3, s2" but fail to properly take account of the FPEXC_FP2V flag in FPEXC. This is because the test for the second instruction register being valid is bogus, and will always skip emulation of the second instruction. Reported-by: Martin Storsjö Tested-by: Martin Storsjö Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman