commit 1a45c310b2102c58e37f84abba67fe21d5d6edcf Author: Greg Kroah-Hartman Date: Thu Mar 14 11:27:14 2013 -0700 Linux 3.8.3 commit 3bc7100a73bb90ad7aa4ca6b65b43dcc88343bb2 Author: David S. Miller Date: Wed Feb 6 15:54:38 2013 -0500 6lowpan: Remove __init tag from lowpan_netlink_fini(). commit a07fdceccf9d9f1b87f781e9a87662182e590d70 upstream. It's called from both __init and __exit code, so neither tag is appropriate. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 364709ddeaaec519bc9014b05474aa071f3afc6f Author: Eric W. Biederman Date: Wed Mar 13 11:51:49 2013 -0700 userns: Don't allow CLONE_NEWUSER | CLONE_FS commit e66eded8309ebf679d3d3c1f5820d1f2ca332c71 upstream. Don't allowing sharing the root directory with processes in a different user namespace. There doesn't seem to be any point, and to allow it would require the overhead of putting a user namespace reference in fs_struct (for permission checks) and incrementing that reference count on practically every call to fork. So just perform the inexpensive test of forbidding sharing fs_struct acrosss processes in different user namespaces. We already disallow other forms of threading when unsharing a user namespace so this should be no real burden in practice. This updates setns, clone, and unshare to disallow multiple user namespaces sharing an fs_struct. Signed-off-by: "Eric W. Biederman" Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f7322a37359d76075db32f826ce5c2c473391a5a Author: Hauke Mehrtens Date: Sun Jan 27 21:07:57 2013 +0100 w1-gpio: fix section mismatch commit 06a8f1feb9e82e5b66f781ba3e39055e3f89a641 upstream. This fixes the following section mismatch: WARNING: drivers/w1/masters/w1-gpio.o(.data+0x188): Section mismatch in reference from the variable w1_gpio_driver to the function .init.text:w1_gpio_probe() The variable w1_gpio_driver references the function __init w1_gpio_probe() If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console Signed-off-by: Hauke Mehrtens Acked-by: Evgeniy Polyakov Signed-off-by: Greg Kroah-Hartman commit 32f4d10ed8fd7ef4cebbf02c5326e8bb6aeca9b1 Author: Greg Kroah-Hartman Date: Tue Mar 12 15:08:26 2013 -0700 Revert "xen/blkback: Don't trust the handle from the frontend." This reverts commit 01c681d4c70d64cb72142a2823f27c4146a02e63 upstream (ef56ca64ea733c3b88f0bb74b04da128b1dc35d8 in this tree), as it wasn't supposed to have been applied to the stable tree. Cc: Jan Beulich Cc: Ian Campbell Cc: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit d79303047f25957a3e00d25cc1eddb82b3ee0f89 Author: Sarah Sharp Date: Thu Mar 7 16:23:43 2013 -0800 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 65bdac5effd15d6af619b3b7218627ef4d84ed6a "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 2373f5aef636cde0cdb552ee0cf7a15c99d43283 Author: Sarah Sharp Date: Thu Mar 7 16:23:39 2013 -0800 USB: Rip out recursive call on warm port reset. [This is upstream commit a24a6078754f28528bc91e7e7b3e6ae86bd936d8. It needs to be backported to kernels as old as 3.2, because it fixes the buggy commit 65bdac5effd15d6af619b3b7218627ef4d84ed6a "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 1d4b0111773fea4159e056aa8384d561c5d0fe0e Author: Sarah Sharp Date: Thu Mar 7 16:23:34 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 65bdac5effd15d6af619b3b7218627ef4d84ed6a "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 4b996365813db4759bf923cec9647e92ca1c213d Author: Sarah Sharp Date: Thu Mar 7 16:23:30 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 65bdac5effd15d6af619b3b7218627ef4d84ed6a "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 9f677cf27341b7a53915ad0e018912dc022a2a24 Author: Matthew Garrett Date: Sat Mar 2 19:40:17 2013 -0500 efi: be more paranoid about available space when creating variables commit 68d929862e29a8b52a7f2f2f86a0600423b093cd upstream. UEFI variables are typically stored in flash. For various reasons, avaiable space is typically not reclaimed immediately upon the deletion of a variable - instead, the system will garbage collect during initialisation after a reboot. Some systems appear to handle this garbage collection extremely poorly, failing if more than 50% of the system flash is in use. This can result in the machine refusing to boot. The safest thing to do for the moment is to forbid writes if they'd end up using more than half of the storage space. We can make this more finegrained later if we come up with a method for identifying the broken machines. Signed-off-by: Matthew Garrett Cc: Josh Boyer Signed-off-by: Matt Fleming Signed-off-by: Greg Kroah-Hartman commit 71727cd9524ab33f702ef47ad32c2c5842c30e39 Author: Seiji Aguchi Date: Tue Feb 12 12:59:07 2013 -0800 efivars: Disable external interrupt while holding efivars->lock commit 81fa4e581d9283f7992a0d8c534bb141eb840a14 upstream. [Problem] There is a scenario which efi_pstore fails to log messages in a panic case. - CPUA holds an efi_var->lock in either efivarfs parts or efi_pstore with interrupt enabled. - CPUB panics and sends IPI to CPUA in smp_send_stop(). - CPUA stops with holding the lock. - CPUB kicks efi_pstore_write() via kmsg_dump(KSMG_DUMP_PANIC) but it returns without logging messages. [Patch Description] This patch disables an external interruption while holding efivars->lock as follows. In efi_pstore_write() and get_var_data(), spin_lock/spin_unlock is replaced by spin_lock_irqsave/spin_unlock_irqrestore because they may be called in an interrupt context. In other functions, they are replaced by spin_lock_irq/spin_unlock_irq. because they are all called from a process context. By applying this patch, we can avoid the problem above with a following senario. - CPUA holds an efi_var->lock with interrupt disabled. - CPUB panics and sends IPI to CPUA in smp_send_stop(). - CPUA receives the IPI after releasing the lock because it is disabling interrupt while holding the lock. - CPUB waits for one sec until CPUA releases the lock. - CPUB kicks efi_pstore_write() via kmsg_dump(KSMG_DUMP_PANIC) And it can hold the lock successfully. Signed-off-by: Seiji Aguchi Acked-by: Mike Waychison Acked-by: Matt Fleming Signed-off-by: Tony Luck Cc: Josh Boyer Signed-off-by: Greg Kroah-Hartman commit 33452b6bd29d457aa17a5c60fe3c7564909fdfdd 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 849149f2dfcf52e682e3e04cf3fe80bb0ce0e61c Author: Michael Ellerman Date: Tue Feb 12 14:44:50 2013 +0000 powerpc: Apply early paca fixups to boot_paca and the boot cpu's paca commit 25e138149c19fa0680147b825be475f5fd57f155 upstream. In commit 466921c we added a hack to set the paca data_offset to zero so that per-cpu accesses would work on the boot cpu prior to per-cpu areas being setup. This fixed a problem with lockdep touching per-cpu areas very early in boot. However if we combine CONFIG_LOCK_STAT=y with any of the PPC_EARLY_DEBUG options, we can hit the same problem in udbg_early_init(). To avoid that we need to set the data_offset of the boot_paca also. So factor out the fixup logic and call it for both the boot_paca, and "the paca of the boot cpu". Signed-off-by: Michael Ellerman Tested-by: Geoff Levand Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 9fae6bc0fb93a9bba7c8f668624473bcfc032f37 Author: Jason Cooper Date: Tue Jan 29 20:36:43 2013 +0000 ARM: kirkwood: of_serial: fix clock gating by removing clock-frequency commit 93fff4ce19f9978cc1c59db42760717477939249 upstream. When DT support for kirkwood was first introduced, there was no clock infrastructure. As a result, we had to manually pass the clock-frequency to the driver from the device node. Unfortunately, on kirkwood, with minimal config or all module configs, clock-frequency breaks booting because of_serial doesn't consume the gate_clk when clock-frequency is defined. The end result on kirkwood is that runit gets gated, and then the boot fails when the kernel tries to write to the serial port. Fix the issue by removing the clock-frequency parameter from all kirkwood dts files. Booted on dreamplug without earlyprintk and successfully logged in via ttyS0. Reported-by: Simon Baatz Tested-by: Simon Baatz Signed-off-by: Jason Cooper Signed-off-by: Greg Kroah-Hartman commit f64d7275f82e8cde0c78a6804faeb579c25711a3 Author: Fabio Estevam Date: Wed Feb 27 14:03:58 2013 -0300 ARM: mxs_defconfig: Make USB host functional again commit f6c49da98dd6eacb85034d21d16e1428e03e190f upstream. commit 09f6ffde2e (USB: EHCI: fix build error by making ChipIdea host a normal EHCI driver) introduced CONFIG_USB_EHCI_HCD as a dependency for USB_CHIPIDEA_HOST. Select CONFIG_USB_EHCI_HCD, so that USB host can be functional again. Signed-off-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit d10d54ce540f6c68acc547442ba629abbd410dd6 Author: Andrew Lunn Date: Sun Feb 3 11:34:26 2013 +0100 gpio: mvebu: Add clk support to prevent lockup commit de88747f514a4e0cca416a8871de2302f4f77790 upstream. The kirkwood SoC GPIO cores use the runit clock. Add code to clk_prepare_enable() runit, otherwise there is a danger of locking up the SoC by accessing the GPIO registers when runit clock is not ticking. Reported-by: Simon Baatz Signed-off-by: Andrew Lunn Tested-by: Simon Baatz Acked-by: Linus Walleij Signed-off-by: Jason Cooper Signed-off-by: Greg Kroah-Hartman commit 728bcbfa3be6770d56ca9a22202b80939940fd83 Author: Andrew Lunn Date: Sun Feb 3 12:32:06 2013 +0100 rtc: rtc-mv: Add support for clk to avoid lockups commit 89c58c198b252f2bc20657fdd72a2aea788c435c upstream. The Marvell RTC on Kirkwood makes use of the runit clock. Ensure the driver clk_prepare_enable() this clock, otherwise there is a danger the SoC will lockup when accessing RTC registers with the clock disabled. Reported-by: Simon Baatz Signed-off-by: Andrew Lunn Tested-by: Simon Baatz Signed-off-by: Jason Cooper Signed-off-by: Greg Kroah-Hartman commit 1d37307ac159185e3bfdd4189a3ac8643ce7cc0e 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 5f4027c67cc437eb44721435bb9916995bb1de6d 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 71d039e231396724ffedc4cfe8a3476f810f4ff2 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 53be86cb15c4a7b1a0f5bbfa0c566c168891ae52 Author: Ming Lei Date: Fri Feb 22 03:05:03 2013 +0000 usbnet: smsc95xx: fix suspend failure commit 7643721471117d5f62ca36f328d3dc8d84af4402 upstream. The three below functions: smsc95xx_enter_suspend0() smsc95xx_enter_suspend1() smsc95xx_enter_suspend2() return > 0 in case of success, so they will cause smsc95xx_suspend() to return > 0 and cause suspend failure. The bug is introduced in commit 3b9f7d(smsc95xx: fix error handling in suspend failure case). Signed-off-by: Ming Lei Cc: Steve Glendinning Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d79ba09797140b624e8b0e71e67c5afc6bca797d Author: Lee, Chun-Yi Date: Thu Jan 3 10:37:45 2013 +0800 acer-wmi: avoid the warning of 'devices' may be used uninitialized commit f24c96eae58aeea4c36fb064cf3ee9734933f8fc upstream. Fengguang Wu run kernel build test to platform-drivers-x86/linux-next git tree on x86_64 architecture and found a warning that was introduced by 727651bf738b6b917335025d09323d0962eda114 commit: drivers/platform/x86/acer-wmi.c: In function ‘WMID_set_capabilities’: drivers/platform/x86/acer-wmi.c:1211: warning: ‘devices’ may be used uninitialized in this function This patch fixes the above warning message. Signed-off-by: Lee, Chun-Yi Cc: Carlos Corbacho Cc: Matthew Garrett Cc: Dmitry Torokhov Cc: Corentin Chary Cc: Fengguang Wu Signed-off-by: Matthew Garrett Signed-off-by: Paul Bolle Signed-off-by: Greg Kroah-Hartman commit 71ed58b0e4a26079b1c868c7a5922db9ede99585 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 58e0b94e48bc225343102f9debe626359dffab57 Author: Wei WANG Date: Fri Feb 8 15:24:27 2013 +0800 mfd: rtsx: Fix issue that booting OS with SD card inserted commit c3481955f6c78c8dd99921759306d7469c999ec2 upstream. Realtek card reader supports both SD and MS card. According to the settings of rtsx MFD driver, SD host will be probed before MS host. If we boot/reboot Linux with SD card inserted, the resetting flow of SD card will succeed, and the following resetting flow of MS is sure to fail. Then MS upper-level driver will ask rtsx driver to turn power off. This request leads to the result that the following SD commands fail and SD card can't be accessed again. In this commit, Realtek's SD and MS host driver will check whether the card that upper driver requesting is the one existing in the slot. If not, Realtek's host driver will refuse the operation to make sure the exlusive accessing at the same time. Signed-off-by: Wei WANG Signed-off-by: Samuel Ortiz Cc: Tim Gardner Signed-off-by: Greg Kroah-Hartman commit d233157ab0476cb80e6fb73817a6979597d759e4 Author: Wei WANG Date: Tue Jan 29 15:21:37 2013 +0800 mfd: rtsx: Optimize card detect flow commit 504decc0a063e6a09a1e5b203ca68bc21dfffde9 upstream. 1. Schedule card detect work at the end of the ISR 2. Callback function ops->cd_deglitch may delay for a period of time. It is not proper to call this callback when local irq disabled. 3. Card detect flow can't be executed in parallel with other card reader operations, so it's better to be protected by mutex. Signed-off-by: Wei WANG Signed-off-by: Samuel Ortiz Cc: Tim Gardner Signed-off-by: Greg Kroah-Hartman commit ff8b1fdc4aefc77d12f776b967aea8e2e0143949 Author: Peter Hurley Date: Wed Feb 27 15:28:28 2013 -0500 x86/kvm: Fix pvclock vsyscall fixmap commit 3d2a80a230250c2534ce5b17503670adaf1d7fff upstream. The physical memory fixmapped for the pvclock clock_gettime vsyscall was allocated, and thus is not a kernel symbol. __pa() is the proper method to use in this case. Fixes the crash below when booting a next-20130204+ smp guest on a 3.8-rc5+ KVM host. [ 0.666410] udevd[97]: starting version 175 [ 0.674043] udevd[97]: udevd:[97]: segfault at ffffffffff5fd020 ip 00007fff069e277f sp 00007fff068c9ef8 error d Acked-by: Marcelo Tosatti Signed-off-by: Peter Hurley Signed-off-by: Gleb Natapov Signed-off-by: Greg Kroah-Hartman commit 5cb065d3405ac7549caedccd92e7e51adce916bd Author: Josef Bacik Date: Thu Feb 7 16:27:28 2013 -0500 Btrfs: cleanup orphan reservation if truncate fails commit 4a7d0f6854c4a4ad1dba00a3b128a32d39b9a742 upstream. I noticed we were getting lots of warnings with xfstest 83 because we have reservations outstanding. This is because we moved the orphan add outside of the truncate, but we don't actually cleanup our reservation if something fails. This fixes the problem and I no longer see warnings. Thanks, Signed-off-by: Josef Bacik Signed-off-by: Greg Kroah-Hartman commit 5f62c696e2fed435824de55e6ceba73abe2304bf Author: Josef Bacik Date: Fri Feb 1 15:57:47 2013 -0500 Btrfs: account for orphan inodes properly during cleanup commit 925396ecf251432d6d0f703a6cfd0cb9e651d936 upstream. Dave sent me a panic where we were doing the orphan cleanup and panic'ed trying to release our reservation from the orphan block rsv. The reason for this is because our orphan block rsv had been free'd out from underneath us because the transaction commit found that there were no orphan inodes according to its count and decided to free it. This is incorrect so make sure we inc the orphan inodes count so the accounting is all done properly. This would also cause the warning in the orphan commit code normally if you had any orphans to cleanup as they would only decrement the orphan count so you'd get a negative orphan count which could cause problems during runtime. Thanks, Signed-off-by: Josef Bacik Signed-off-by: Greg Kroah-Hartman commit f3df1362f80a077d32b1d15069e1ee5697937336 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 054489e166e385af36a4c3b1928f230663da8f02 Author: Marcelo Tosatti Date: Mon Feb 18 22:58:14 2013 -0300 x86: pvclock kvm: align allocation size to page size commit ed55705dd5008b408c48a8459b8b34b01f3de985 upstream. To match whats mapped via vsyscalls to userspace. Reported-by: Peter Hurley Signed-off-by: Marcelo Tosatti Signed-off-by: Greg Kroah-Hartman commit f6eff272a1e78c492d37e354733e9bec59d6b3af Author: Eric W. Biederman Date: Sat Mar 2 19:14:03 2013 -0800 userns: Stop oopsing in key_change_session_keyring commit ba0e3427b03c3d1550239779eca5c1c5a53a2152 upstream. Dave Jones writes: > Just hit this on Linus' current tree. > > [ 89.621770] BUG: unable to handle kernel NULL pointer dereference at 00000000000000c8 > [ 89.623111] IP: [] commit_creds+0x250/0x2f0 > [ 89.624062] PGD 122bfd067 PUD 122bfe067 PMD 0 > [ 89.624901] Oops: 0000 [#1] PREEMPT SMP > [ 89.625678] Modules linked in: caif_socket caif netrom bridge hidp 8021q garp stp mrp rose llc2 af_rxrpc phonet af_key binfmt_misc bnep l2tp_ppp can_bcm l2tp_core pppoe pppox can_raw scsi_transport_iscsi ppp_generic slhc nfnetlink can ipt_ULOG ax25 decnet irda nfc rds x25 crc_ccitt appletalk atm ipx p8023 psnap p8022 llc lockd sunrpc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack nf_conntrack ip6table_filter ip6_tables btusb bluetooth snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_pcm vhost_net snd_page_alloc snd_timer tun macvtap usb_debug snd rfkill microcode macvlan edac_core pcspkr serio_raw kvm_amd soundcore kvm r8169 mii > [ 89.637846] CPU 2 > [ 89.638175] Pid: 782, comm: trinity-main Not tainted 3.8.0+ #63 Gigabyte Technology Co., Ltd. GA-MA78GM-S2H/GA-MA78GM-S2H > [ 89.639850] RIP: 0010:[] [] commit_creds+0x250/0x2f0 > [ 89.641161] RSP: 0018:ffff880115657eb8 EFLAGS: 00010207 > [ 89.641984] RAX: 00000000000003e8 RBX: ffff88012688b000 RCX: 0000000000000000 > [ 89.643069] RDX: 0000000000000000 RSI: ffffffff81c32960 RDI: ffff880105839600 > [ 89.644167] RBP: ffff880115657ed8 R08: 0000000000000000 R09: 0000000000000000 > [ 89.645254] R10: 0000000000000001 R11: 0000000000000246 R12: ffff880105839600 > [ 89.646340] R13: ffff88011beea490 R14: ffff88011beea490 R15: 0000000000000000 > [ 89.647431] FS: 00007f3ac063b740(0000) GS:ffff88012b200000(0000) knlGS:0000000000000000 > [ 89.648660] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > [ 89.649548] CR2: 00000000000000c8 CR3: 0000000122bfc000 CR4: 00000000000007e0 > [ 89.650635] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 89.651723] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > [ 89.652812] Process trinity-main (pid: 782, threadinfo ffff880115656000, task ffff88011beea490) > [ 89.654128] Stack: > [ 89.654433] 0000000000000000 ffff8801058396a0 ffff880105839600 ffff88011beeaa78 > [ 89.655769] ffff880115657ef8 ffffffff812c7d9b ffffffff82079be0 0000000000000000 > [ 89.657073] ffff880115657f28 ffffffff8106c665 0000000000000002 ffff880115657f58 > [ 89.658399] Call Trace: > [ 89.658822] [] key_change_session_keyring+0xfb/0x140 > [ 89.659845] [] task_work_run+0xa5/0xd0 > [ 89.660698] [] do_notify_resume+0x71/0xb0 > [ 89.661581] [] int_signal+0x12/0x17 > [ 89.662385] Code: 24 90 00 00 00 48 8b b3 90 00 00 00 49 8b 4c 24 40 48 39 f2 75 08 e9 83 00 00 00 48 89 ca 48 81 fa 60 29 c3 81 0f 84 41 fe ff ff <48> 8b 8a c8 00 00 00 48 39 ce 75 e4 3b 82 d0 00 00 00 0f 84 4b > [ 89.667778] RIP [] commit_creds+0x250/0x2f0 > [ 89.668733] RSP > [ 89.669301] CR2: 00000000000000c8 > > My fastest trinity induced oops yet! > > > Appears to be.. > > if ((set_ns == subset_ns->parent) && > 850: 48 8b 8a c8 00 00 00 mov 0xc8(%rdx),%rcx > > from the inlined cred_cap_issubset By historical accident we have been reading trying to set new->user_ns from new->user_ns. Which is totally silly as new->user_ns is NULL (as is every other field in new except session_keyring at that point). The intent is clearly to copy all of the fields from old to new so copy old->user_ns into into new->user_ns. Reported-by: Dave Jones Tested-by: Dave Jones Acked-by: Serge Hallyn Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 4040a8aa3b0feb80776a993bdf315bfaa5a10dc8 Author: Matt Fleming Date: Tue Mar 5 12:46:30 2013 +0000 efivarfs: return accurate error code in efivarfs_fill_super() commit feff5dc4f98330d8152b521acc2e18c16712e6c8 upstream. Joseph was hitting a failure case when mounting efivarfs which resulted in an incorrect error message, $ sudo mount -v /sys/firmware/efi/efivars mount: Cannot allocate memory triggered when efivarfs_valid_name() returned -EINVAL. Make sure we pass accurate return values up the stack if efivarfs_fill_super() fails to build inodes for EFI variables. Reported-by: Joseph Yasi Reported-by: Lingzhu Xiang Cc: Josh Boyer Cc: Jeremy Kerr Cc: Matthew Garrett Signed-off-by: Matt Fleming Signed-off-by: Greg Kroah-Hartman commit e59bcdae87ec116dde25da6d725f79fefb253693 Author: Matt Fleming Date: Tue Mar 5 07:40:16 2013 +0000 efivars: efivarfs_valid_name() should handle pstore syntax commit 123abd76edf56c02a76b46d3d673897177ef067b upstream. Stricter validation was introduced with commit da27a24383b2b ("efivarfs: guid part of filenames are case-insensitive") and commit 47f531e8ba3b ("efivarfs: Validate filenames much more aggressively"), which is necessary for the guid portion of efivarfs filenames, but we don't need to be so strict with the first part, the variable name. The UEFI specification doesn't impose any constraints on variable names other than they be a NULL-terminated string. The above commits caused a regression that resulted in users seeing the following message, $ sudo mount -v /sys/firmware/efi/efivars mount: Cannot allocate memory whenever pstore EFI variables were present in the variable store, since their variable names failed to pass the following check, /* GUID should be right after the first '-' */ if (s - 1 != strchr(str, '-')) as a typical pstore filename is of the form, dump-type0-10-1-. The fix is trivial since the guid portion of the filename is GUID_LEN bytes, we can use (len - GUID_LEN) to ensure the '-' character is where we expect it to be. (The bogus ENOMEM error value will be fixed in a separate patch.) Reported-by: Joseph Yasi Tested-by: Joseph Yasi Reported-by: Lingzhu Xiang Cc: Josh Boyer Cc: Jeremy Kerr Cc: Matthew Garrett Signed-off-by: Matt Fleming Signed-off-by: Greg Kroah-Hartman commit c9fa7329af2e71971687a83ad1acaca31d73fd92 Author: Nithin Sujir Date: Fri Mar 8 08:01:24 2013 +0000 tg3: Update link_up flag for phylib devices commit 84421b99cedc3443e76d2a594f3c815d5cb9a8e1 upstream. Commit f4a46d1f46a8fece34edd2023e054072b02e110d introduced a bug where the ifconfig stats would remain 0 for phylib devices. This is due to tp->link_up flag never becoming true causing tg3_periodic_fetch_stats() to return. The link_up flag was being updated in tg3_test_and_report_link_chg() after setting up the phy. This function however, is not called for phylib devices since the driver does not do the phy setup. This patch moves the link_up flag update into the common tg3_link_report() function that gets called for phylib devices as well for non phylib devices when the link state changes. To avoid updating link_up twice, we replace tg3_carrier_...() calls that are followed by tg3_link_report(), with netif_carrier_...(). We can then remove the unused tg3_carrier_on() function. Reported-by: OGAWA Hirofumi Signed-off-by: Nithin Nayak Sujir Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 31eb1a20a9d717afa227464b782a3b78cb0f7d21 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 3bd535950181900d349d0d453ea97e5efd23a275 Author: Ben Greear Date: Wed Feb 20 09:41:09 2013 -0800 mac80211: Fix crash due to un-canceled work-items commit 499218595a2e8296b7492af32fcca141b7b8184a upstream. Some mlme work structs are not cancelled on disassociation nor interface deletion, which leads to them running after the memory has been freed There is not a clean way to cancel these in the disassociation logic because they must be canceled outside of the ifmgd->mtx lock, so just cancel them in mgd_stop logic that tears down the station. This fixes the crashes we see in 3.7.9+. The crash stack trace itself isn't so helpful, but this warning gives more useful info: WARNING: at /home/greearb/git/linux-3.7.dev.y/lib/debugobjects.c:261 debug_print_object+0x7c/0x8d() ODEBUG: free active (active state 0) object type: work_struct hint: ieee80211_sta_monitor_work+0x0/0x14 [mac80211] Modules linked in: [...] Pid: 14743, comm: iw Tainted: G C O 3.7.9+ #11 Call Trace: [] warn_slowpath_common+0x80/0x98 [] warn_slowpath_fmt+0x41/0x43 [] debug_print_object+0x7c/0x8d [] debug_check_no_obj_freed+0x95/0x1c3 [] slab_free_hook+0x70/0x79 [] kfree+0x62/0xb7 [] netdev_release+0x39/0x3e [] device_release+0x52/0x8a [] kobject_release+0x121/0x158 [] kobject_put+0x4c/0x50 [] netdev_run_todo+0x25c/0x27e Signed-off-by: Ben Greear Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 0a1710dc673b7c94f31f487b9a735c0305061f82 Author: Pavel Shilovsky Date: Wed Mar 6 19:38:36 2013 +0400 CIFS: Fix missing of oplock_read value in smb30_values structure commit 067785c40e52089993757afa28988c05f3cb2694 upstream. Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 87b07931632bc4a4c032a49b2fb00701ecef6320 Author: Hillf Danton Date: Fri Mar 8 12:43:28 2013 -0800 mm/mempolicy.c: fix wrong sp_node insertion commit 5ca3957510b9fc2a14d3647db518014842f9a2b4 upstream. n->end is accessed in sp_insert(). Thus it should be update before calling sp_insert(). This mistake may make kernel panic. Signed-off-by: Hillf Danton Signed-off-by: KOSAKI Motohiro Cc: Sasha Levin Cc: Hugh Dickins Cc: Mel Gorman Cc: Dave Jones Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3479cfd6f589c4d49494c046fabdbfdcb5c4c8e6 Author: Theodore Ts'o Date: Mon Mar 4 11:59:12 2013 -0500 random: fix locking dependency with the tasklist_lock commit b980955236922ae6106774511c5c05003d3ad225 upstream. Commit 6133705494bb introduced a circular lock dependency because posix_cpu_timers_exit() is called by release_task(), which is holding a writer lock on tasklist_lock, and this can cause a deadlock since kill_fasync() gets called with nonblocking_pool.lock taken. There's no reason why kill_fasync() needs to be taken while the random pool is locked, so move it out to fix this locking dependency. Signed-off-by: "Theodore Ts'o" Reported-by: Russ Dill Signed-off-by: Greg Kroah-Hartman commit 04825f04ac5042a966865ecc8fd6359fe59fa883 Author: Chris Metcalf Date: Mon Mar 4 11:19:09 2013 -0500 tile: work around bug in the generic sys_llseek commit 5a114b98661e3aaa0ac085eb931584dce3b0ef9b upstream. sys_llseek should specify the high and low 32-bit seek values as "unsigned int" but instead it specifies "unsigned long". Since compat syscall arguments are always sign-extended on tile, this means that a seek value of 0xffffffff will be incorrectly interpreted as a value of -1ULL. To avoid the risk of breaking binary compatibility on architectures that already use sys_llseek this way, we follow the same path as MIPS and provide a wrapper override. Signed-off-by: Chris Metcalf Signed-off-by: Greg Kroah-Hartman commit 6474cd4cf32ac9edf960903db0f7b9955618ae4a Author: Eric W. Biederman Date: Sat Mar 9 00:14:45 2013 -0800 proc: Use nd_jump_link in proc_ns_follow_link commit db04dc679bcc780ad6907943afe24a30de974a1b upstream. Update proc_ns_follow_link to use nd_jump_link instead of just manually updating nd.path.dentry. This fixes the BUG_ON(nd->inode != parent->d_inode) reported by Dave Jones and reproduced trivially with mkdir /proc/self/ns/uts/a. Sigh it looks like the VFS change to require use of nd_jump_link happend while proc_ns_follow_link was baking and since the common case of proc_ns_follow_link continued to work without problems the need for making this change was overlooked. Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 9e424eb1c5e3650a486f0c9997d12081b999d1b4 Author: Linus Torvalds Date: Fri Mar 8 09:03:07 2013 -0800 vfs: don't BUG_ON() if following a /proc fd pseudo-symlink results in a symlink commit 7b54c165a0c012edbaeaa73c5c87cb73721eb580 upstream. It's "normal" - it can happen if the file descriptor you followed was opened with O_NOFOLLOW. Reported-by: Dave Jones Cc: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 34d8bb52ecd8182b74ed57ac3f17970fb7af024e 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 e54d986a8fe9daab94cb7faefb352557557c41f0 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 0bb19997b82e46cb13697adf076145a6c12f19dd 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 f273e02595b5b2ea6fca976ec7c19f16b366c057 Author: Peter Hurley Date: Fri Mar 8 12:43:27 2013 -0800 ipc: don't allocate a copy larger than max commit 88b9e456b1649722673ffa147914299799dc9041 upstream. When MSG_COPY is set, a duplicate message must be allocated for the copy before locking the queue. However, the copy could not be larger than was sent which is limited to msg_ctlmax. Signed-off-by: Peter Hurley Acked-by: Stanislav Kinsbursky Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 32b25b63c222ff910834d577a6baa1f5a39b0a06 Author: Peter Hurley Date: Fri Mar 8 12:43:26 2013 -0800 ipc: fix potential oops when src msg > 4k w/ MSG_COPY commit e1082f45f1e2bbf6e25f6b614fc6616ebf709d19 upstream. If the src msg is > 4k, then dest->next points to the next allocated segment; resetting it just prior to dereferencing is bad. Signed-off-by: Peter Hurley Acked-by: Stanislav Kinsbursky Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit aaf4a8519e2582203e6de1f2e2b21954c68dca7a Author: Patrik Jakobsson Date: Tue Mar 5 14:24:48 2013 +0100 drm/i915: Turn off hsync and vsync on ADPA when disabling crt commit f40ebd6bcbbd0d30591f42dc16be52b5086a366b upstream. According to PRM we need to disable hsync and vsync even though ADPA is disabled. The previous code did infact do the opposite so we fix it. Signed-off-by: Patrik Jakobsson Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56359 Tested-by: max Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 31f14f4219d2a74b7a6d86c7798f49141b5eccbe Author: Daniel Vetter Date: Tue Mar 5 09:50:58 2013 +0100 drm/i915: enable irqs earlier when resuming commit 15239099d7a7a9ecdc1ccb5b187ae4cda5488ff9 upstream. We need it to restore the ilk rc6 context, since the gpu wait no requires interrupts. But in general having interrupts around should help in code sanity, since more and more stuff is interrupt driven. This regression has been introduced in commit 3e9605018ab3e333d51cc90fccfde2031886763b Author: Chris Wilson Date: Tue Nov 27 16:22:54 2012 +0000 drm/i915: Rearrange code to only have a single method for waiting upon the ring Like in the driver load code we need to make sure that hotplug interrupts don't cause havoc with our modeset state, hence block them with the existing infrastructure. Again we ignore races where we might loose hotplug interrupts ... Note that the driver load part of the regression has already been fixed in commit 52d7ecedac3f96fb562cb482c139015372728638 Author: Daniel Vetter Date: Sat Dec 1 21:03:22 2012 +0100 drm/i915: reorder setup sequence to have irqs for output setup v2: Add a note to the commit message about which patch fixed the driver load part of the regression. Stable kernels need to backport both patches. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=54691 Cc: Chris Wilson Cc: Mika Kuoppala Reported-and-Tested-by: Ilya Tumaykin Reviewed-by: Chris wilson (v1) Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 2a9810441fcc26cf3f006f015f8a62094fe57a90 Author: Daniel Vetter Date: Sat Dec 1 21:03:22 2012 +0100 drm/i915: reorder setup sequence to have irqs for output setup commit 52d7ecedac3f96fb562cb482c139015372728638 upstream. Otherwise the new&shiny irq-driven gmbus and dp aux code won't work that well. Noticed since the dp aux code doesn't have an automatic fallback with a timeout (since the hw provides for that already). v2: Simple move drm_irq_install before intel_modeset_gem_init, as suggested by Ben Widawsky. v3: Now that interrupts are enabled before all connectors are fully set up, we might fall over serving a HPD interrupt while things are still being set up. Instead of jumping through massive hoops and complicating the code with a separate hpd irq enable step, simply block out the hotplug work item from doing anything until things are in place. v4: Actually, we can enable hotplug processing only after the fbdev is fully set up, since we call down into the fbdev from the hotplug work functions. So stick the hpd enabling right next to the poll helper initialization. v5: We need to enable irqs before intel_modeset_init, since that function sets up the outputs. v6: Fixup cleanup sequence, too. Reviewed-by: Imre Deak Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit f49b7242e6220ace73138ccae5caa85c59499ed7 Author: Kenneth Graunke Date: Fri Mar 1 17:00:50 2013 -0800 drm/i915: Fix Haswell/CRW PCI IDs. commit 86c268ed0f9b3b4d51d81dd8fcec533a164414d1 upstream. The second digit was off by one, which meant we accidentally treated GT(n) as GT(n-1). This also meant no support for GT1 at all. Signed-off-by: Kenneth Graunke Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 57a2ae96227a8c56f3929f1a47de0019dd133b05 Author: Stéphane Marchesin Date: Tue Jan 29 19:41:59 2013 -0800 drm/i915: Increase the RC6p threshold. commit 0920a48719f1ceefc909387a64f97563848c7854 upstream. This increases GEN6_RC6p_THRESHOLD from 100000 to 150000. For some reason this avoids the gen6_gt_check_fifodbg.isra warnings and associated GPU lockups, which makes my ivy bridge machine stable. Signed-off-by: Stéphane Marchesin Acked-by: Jesse Barnes Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 424c61856b2d932f032a7327374a1d3cbc90881e 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 9f400745af791e5c9bf43bd07ee316a02afa13e0 Author: Will Deacon Date: Thu Feb 28 17:47:36 2013 +0100 ARM: 7659/1: mm: make mm->context.id an atomic64_t variable commit 8a4e3a9ead7e37ce1505602b564c15da09ac039f upstream. mm->context.id is updated under asid_lock when a new ASID is allocated to an mm_struct. However, it is also read without the lock when a task is being scheduled and checking whether or not the current ASID generation is up-to-date. If two threads of the same process are being scheduled in parallel and the bottom bits of the generation in their mm->context.id match the current generation (that is, the mm_struct has not been used for ~2^24 rollovers) then the non-atomic, lockless access to mm->context.id may yield the incorrect ASID. This patch fixes this issue by making mm->context.id and atomic64_t, ensuring that the generation is always read consistently. For code that only requires access to the ASID bits (e.g. TLB flushing by mm), then the value is accessed directly, which GCC converts to an ldrb. Reviewed-by: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 810f63799982d066cdc2781ba366fcee508918a8 Author: Will Deacon Date: Thu Feb 28 17:47:20 2013 +0100 ARM: 7658/1: mm: fix race updating mm->context.id on ASID rollover commit 37f47e3d62533c931b04cb409f2eb299e6342331 upstream. If a thread triggers an ASID rollover, other threads of the same process must be made to wait until the mm->context.id for the shared mm_struct has been updated to new generation and associated book-keeping (e.g. TLB invalidation) has ben performed. However, there is a *tiny* window where both mm->context.id and the relevant active_asids entry are updated to the new generation, but the TLB flush has not been performed, which could allow another thread to return to userspace with a dirty TLB, potentially leading to data corruption. In reality this will never occur because one CPU would need to perform a context-switch in the time it takes another to do a couple of atomic test/set operations but we should plug the race anyway. This patch moves the active_asids update until after the potential TLB flush on context-switch. Reviewed-by: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 2eef33c7acacbbff8e5090f4a584ff1e36b17e41 Author: Will Deacon Date: Thu Feb 28 17:46:16 2013 +0100 ARM: 7657/1: head: fix swapper and idmap population with LPAE and big-endian commit d61947a164760ac520cb416768afdf38c33d60e7 upstream. The LPAE page table format uses 64-bit descriptors, so we need to take endianness into account when populating the swapper and idmap tables during early initialisation. This patch ensures that we store the two words making up each page table entry in the correct order when running big-endian. Acked-by: Catalin Marinas Tested-by: Marc Zyngier Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit ffa812bbea31d029404173ed1184bffaab426a6f 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 dad07bf9c8ffd5327399737a9da5d8780a0e57a6 Author: Alex Deucher Date: Tue Feb 26 16:17:33 2013 -0500 drm/radeon: don't set hpd, afmt interrupts when interrupts are disabled commit cc9945bf9cac03860b2f7d59882263c965c6e3af upstream. Avoids splatter if the interrupt handler is not registered due to acceleration being disabled. Signed-off-by: Alex Deucher Reviewed-by: Jerome Glisse Signed-off-by: Greg Kroah-Hartman commit 1dde5a361f21ed7d606593c3b8814c6f2232fedc 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 4404ee445fdf033a17781c7d80adb5b14e198577 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 6d29c5ec4f2f59b5d0426b14722481510a1ef233 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 71192d4685c1a1fbaff5a1c6023095901bbb1cee Author: NeilBrown Date: Mon Feb 25 12:38:29 2013 +1100 md/raid1,raid10: fix deadlock with freeze_array() commit ee0b0244030434cdda26777bfb98962447e080cd upstream. When raid1/raid10 needs to fix a read error, it first drains all pending requests by calling freeze_array(). This calls flush_pending_writes() if it needs to sleep, but some writes may be pending in a per-process plug rather than in the per-array request queue. When raid1{,0}_unplug() moves the request from the per-process plug to the per-array request queue (from which flush_pending_writes() can flush them), it needs to wake up freeze_array(), or freeze_array() will never flush them and so it will block forever. So add the requires wake_up() calls. This bug was introduced by commit f54a9d0e59c4bea3db733921ca9147612a6f292c for raid1 and a similar commit for RAID10, and so has been present since linux-3.6. As the bug causes a deadlock I believe this fix is suitable for -stable. Reported-by: Tregaron Bayly Tested-by: Tregaron Bayly Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 5260b2b544e14287a9d6eab457d89f1658356102 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 cac9a265334043f9500d385c358e07daa4636d7d 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 22c776d64040e9ba838dd89e856bc7f5d73f46ba 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 0cb205ec4f5252cced9cc488e85b0317e843fbd8 Author: Frederic Weisbecker Date: Wed Feb 20 16:15:36 2013 +0100 nohz: Make tick_nohz_irq_exit() irq safe commit e5ab012c3271990e8457055c25cafddc1ae8aa6b upstream. As it stands, irq_exit() may or may not be called with irqs disabled, depending on __ARCH_IRQ_EXIT_IRQS_DISABLED that the arch can define. It makes tick_nohz_irq_exit() unsafe. For example two interrupts can race in tick_nohz_stop_sched_tick(): the inner most one computes the expiring time on top of the timer list, then it's interrupted right before reprogramming the clock. The new interrupt enqueues a new timer list timer, it reprogram the clock to take it into account and it exits. The CPUs resumes the inner most interrupt and performs the clock reprogramming without considering the new timer list timer. This regression has been introduced by: 280f06774afedf849f0b34248ed6aff57d0f6908 ("nohz: Separate out irq exit and idle loop dyntick logic") Let's fix it right now with the appropriate protections. A saner long term solution will be to remove __ARCH_IRQ_EXIT_IRQS_DISABLED and mandate that irq_exit() is called with interrupts disabled. Signed-off-by: Frederic Weisbecker Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Linus Torvalds Link: http://lkml.kernel.org/r/1361373336-11337-1-git-send-email-fweisbec@gmail.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 5836682c53c66176c7c4fe2be178c9b436e2daca Author: Kees Cook Date: Mon Feb 25 21:32:25 2013 +0000 proc connector: reject unprivileged listener bumps commit e70ab977991964a5a7ad1182799451d067e62669 upstream. While PROC_CN_MCAST_LISTEN/IGNORE is entirely advisory, it was possible for an unprivileged user to turn off notifications for all listeners by sending PROC_CN_MCAST_IGNORE. Instead, require the same privileges as required for a multicast bind. Signed-off-by: Kees Cook Cc: Evgeniy Polyakov Cc: Matt Helsley Acked-by: Evgeniy Polyakov Acked-by: Matt Helsley Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a9382b7791f46b85a17841e5970ac3da7f5a9ca5 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 97fe3c32eed4cb11963eac7b5b88e01f24db411e Author: Felix Fietkau Date: Fri Feb 22 21:37:25 2013 +0100 ath9k_htc: fix signal strength handling issues commit 838f427955dcfd16858b0108ce29029da0d56a4e upstream. The ath9k commit 2ef167557c0a26c88162ecffb017bfcc51eb7b29 (ath9k: fix signal strength reporting issues) fixed an issue where the reported per-frame signal strength reported to mac80211 was being overwritten with an internal average. The same issue is also present in ath9k_htc. In addition to preventing the driver from overwriting the value, this commit also ensures that the internal average (which is used for ANI) only tracks beacons of the AP that we're connected to. Signed-off-by: Felix Fietkau Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 7e928048028e71641cfa363cb742c961098ef606 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 556b1db438e71bd2dddf638fec3c680eb9d19272 Author: Bing Zhao Date: Tue Feb 26 12:58:35 2013 -0800 libertas: fix crash for SD8688 commit 466026989f112e0546ca39ab00a759af82dbe83a upstream. For SD8688, FUNC_INIT command is queued before fw_ready flag is set. This causes the following crash as lbs_thread blocks any command if fw_ready is not set. [ 209.338953] [] (__schedule+0x610/0x764) from [] (__lbs_cmd+0xb8/0x130 [libertas]) [ 209.348340] [] (__lbs_cmd+0xb8/0x130 [libertas]) from [] (if_sdio_finish_power_on+0xec/0x1b0 [libertas_sdio]) [ 209.360136] [] (if_sdio_finish_power_on+0xec/0x1b0 [libertas_sdio]) from [] (if_sdio_power_on+0x18c/0x20c [libertas_sdio]) [ 209.373052] [] (if_sdio_power_on+0x18c/0x20c [libertas_sdio]) from [] (if_sdio_probe+0x200/0x31c [libertas_sdio]) [ 209.385316] [] (if_sdio_probe+0x200/0x31c [libertas_sdio]) from [] (sdio_bus_probe+0x94/0xfc [mmc_core]) [ 209.396748] [] (sdio_bus_probe+0x94/0xfc [mmc_core]) from [] (driver_probe_device+0x12c/0x348) [ 209.407214] [] (driver_probe_device+0x12c/0x348) from [] (__driver_attach+0x78/0x9c) [ 209.416798] [] (__driver_attach+0x78/0x9c) from [] (bus_for_each_dev+0x50/0x88) [ 209.425946] [] (bus_for_each_dev+0x50/0x88) from [] (bus_add_driver+0x108/0x268) [ 209.435180] [] (bus_add_driver+0x108/0x268) from [] (driver_register+0xa4/0x134) [ 209.444426] [] (driver_register+0xa4/0x134) from [] (if_sdio_init_module+0x1c/0x3c [libertas_sdio]) [ 209.455339] [] (if_sdio_init_module+0x1c/0x3c [libertas_sdio]) from [] (do_one_initcall+0x98/0x174) [ 209.466236] [] (do_one_initcall+0x98/0x174) from [] (load_module+0x1c5c/0x1f80) [ 209.475390] [] (load_module+0x1c5c/0x1f80) from [] (sys_init_module+0x104/0x128) [ 209.484632] [] (sys_init_module+0x104/0x128) from [] (ret_fast_syscall+0x0/0x38) Fix it by setting fw_ready flag prior to queuing FUNC_INIT command. Reported-by: Lubomir Rintel Tested-by: Lubomir Rintel Signed-off-by: Bing Zhao Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 107725a545f73f42d10bb3613d653b229eb2a265 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 0ad547e724efb4044804e907a063f9d15f3cc186 Author: Johannes Berg Date: Mon Feb 25 16:01:34 2013 +0100 iwlwifi: always copy first 16 bytes of commands commit 8a964f44e01ad3bbc208c3e80d931ba91b9ea786 upstream. The FH hardware will always write back to the scratch field in commands, even host commands not just TX commands, which can overwrite parts of the command. This is problematic if the command is re-used (with IWL_HCMD_DFL_NOCOPY) and can cause calibration issues. Address this problem by always putting at least the first 16 bytes into the buffer we also use for the command header and therefore make the DMA engine write back into this. For commands that are smaller than 16 bytes also always map enough memory for the DMA engine to write back to. Reviewed-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit ea967e9c279ea465ef144360b2a46fff574c93ae 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 216e418695182cfbcceab88dd129eaef1d23127c Author: Weston Andros Adamson Date: Mon Feb 25 21:27:33 2013 -0500 NFSv4.1: Hold reference to layout hdr in layoutget commit a47970ff7814718fec31b7d966747c6aa1a3545f upstream. This fixes an oops where a LAYOUTGET is in still in the rpciod queue, but the requesting processes has been killed. Without this, killing the process does the final pnfs_put_layout_hdr() and sets NFS_I(inode)->layout to NULL while the LAYOUTGET rpc task still references it. Example oops: BUG: unable to handle kernel NULL pointer dereference at 0000000000000080 IP: [] pnfs_choose_layoutget_stateid+0x37/0xef [nfsv4] PGD 7365b067 PUD 7365d067 PMD 0 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC Modules linked in: nfs_layout_nfsv41_files nfsv4 auth_rpcgss nfs lockd sunrpc ipt_MASQUERADE ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 iptable_nat nf_nat_ipv4 nf_nat iptable_mangle ip6table_filter ip6_tables ppdev e1000 i2c_piix4 i2c_core shpchp parport_pc parport crc32c_intel aesni_intel xts aes_x86_64 lrw gf128mul ablk_helper cryptd mptspi scsi_transport_spi mptscsih mptbase floppy autofs4 CPU 0 Pid: 27, comm: kworker/0:1 Not tainted 3.8.0-dros_cthon2013+ #4 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform RIP: 0010:[] [] pnfs_choose_layoutget_stateid+0x37/0xef [nfsv4] RSP: 0018:ffff88007b0c1c88 EFLAGS: 00010246 RAX: ffff88006ed36678 RBX: 0000000000000000 RCX: 0000000ea877e3bc RDX: ffff88007a729da8 RSI: 0000000000000000 RDI: ffff88007a72b958 RBP: ffff88007b0c1ca8 R08: 0000000000000002 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff88007a72b958 R13: ffff88007a729da8 R14: 0000000000000000 R15: ffffffffa011077e FS: 0000000000000000(0000) GS:ffff88007f600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000080 CR3: 00000000735f8000 CR4: 00000000001407f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process kworker/0:1 (pid: 27, threadinfo ffff88007b0c0000, task ffff88007c2fa0c0) Stack: ffff88006fc05388 ffff88007a72b908 ffff88007b240900 ffff88006fc05388 ffff88007b0c1cd8 ffffffffa01a2170 ffff88007b240900 ffff88007b240900 ffff88007b240970 ffffffffa011077e ffff88007b0c1ce8 ffffffffa0110791 Call Trace: [] nfs4_layoutget_prepare+0x7b/0x92 [nfsv4] [] ? __rpc_atrun+0x15/0x15 [sunrpc] [] rpc_prepare_task+0x13/0x15 [sunrpc] Reported-by: Tigran Mkrtchyan Signed-off-by: Weston Andros Adamson Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit a6b9a1d3a8763502150bebc0158ffd586f898643 Author: Benny Halevy Date: Sun Feb 24 09:55:57 2013 -0500 pnfs: fix resend_to_mds for directio commit 78f33277f96430ea001c39e952f6b8200b2ab850 upstream. Pass the directio request on pageio_init to clean up the API. Percolate pg_dreq from original nfs_pageio_descriptor to the pnfs_{read,write}_done_resend_to_mds and use it on respective call to nfs_pageio_init_{read,write} on the newly created nfs_pageio_descriptor. Reproduced by command: mount -o vers=4.1 server:/ /mnt dd bs=128k count=8 if=/dev/zero of=/mnt/dd.out oflag=direct BUG: unable to handle kernel NULL pointer dereference at 0000000000000028 IP: [] atomic_inc+0x4/0x9 [nfs] PGD 34786067 PUD 34794067 PMD 0 Oops: 0002 [#1] SMP Modules linked in: nfs_layout_nfsv41_files nfsv4 nfs nfsd lockd nfs_acl auth_rpcgss exportfs sunrpc btrfs zlib_deflate libcrc32c ipv6 autofs4 CPU 1 Pid: 259, comm: kworker/1:2 Not tainted 3.8.0-rc6 #2 Bochs Bochs RIP: 0010:[] [] atomic_inc+0x4/0x9 [nfs] RSP: 0018:ffff880038f8fa68 EFLAGS: 00010206 RAX: ffffffffa021a6a9 RBX: ffff880038f8fb48 RCX: 00000000000a0000 RDX: ffffffffa021e616 RSI: ffff8800385e9a40 RDI: 0000000000000028 RBP: ffff880038f8fa68 R08: ffffffff81ad6720 R09: ffff8800385e9510 R10: ffffffffa0228450 R11: ffff880038e87418 R12: ffff8800385e9a40 R13: ffff8800385e9a70 R14: ffff880038f8fb38 R15: ffffffffa0148878 FS: 0000000000000000(0000) GS:ffff88003e400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000028 CR3: 0000000034789000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process kworker/1:2 (pid: 259, threadinfo ffff880038f8e000, task ffff880038302480) Stack: ffff880038f8fa78 ffffffffa021a6bf ffff880038f8fa88 ffffffffa021bb82 ffff880038f8fae8 ffffffffa021f454 ffff880038f8fae8 ffffffff8109689d ffff880038f8fab8 ffffffff00000006 0000000000000000 ffff880038f8fb48 Call Trace: [] nfs_direct_pgio_init+0x16/0x18 [nfs] [] nfs_pgheader_init+0x6a/0x6c [nfs] [] nfs_generic_pg_writepages+0x51/0xf8 [nfs] [] ? mark_held_locks+0x71/0x99 [] ? rpc_release_resources_task+0x37/0x37 [sunrpc] [] nfs_pageio_doio+0x1a/0x43 [nfs] [] nfs_pageio_complete+0x16/0x2c [nfs] [] pnfs_write_done_resend_to_mds+0x95/0xc5 [nfsv4] [] ? rpc_release_resources_task+0x37/0x37 [sunrpc] [] filelayout_reset_write+0x8c/0x99 [nfs_layout_nfsv41_files] [] filelayout_write_done_cb+0x4d/0xc1 [nfs_layout_nfsv41_files] [] nfs4_write_done+0x36/0x49 [nfsv4] [] nfs_writeback_done+0x53/0x1cc [nfs] [] nfs_writeback_done_common+0xe/0x10 [nfs] [] filelayout_write_call_done+0x28/0x2a [nfs_layout_nfsv41_files] [] rpc_exit_task+0x29/0x87 [sunrpc] [] __rpc_execute+0x11d/0x3cc [sunrpc] [] ? trace_hardirqs_on_caller+0x117/0x173 [] rpc_async_schedule+0x27/0x32 [sunrpc] [] ? __rpc_execute+0x3cc/0x3cc [sunrpc] [] process_one_work+0x226/0x422 [] ? process_one_work+0x159/0x422 [] ? lock_acquired+0x210/0x249 [] ? __rpc_execute+0x3cc/0x3cc [sunrpc] [] worker_thread+0x126/0x1c4 [] ? manage_workers+0x240/0x240 [] kthread+0xb1/0xb9 [] ? __kthread_parkme+0x65/0x65 [] ret_from_fork+0x7c/0xb0 [] ? __kthread_parkme+0x65/0x65 Code: 00 83 38 02 74 12 48 81 4b 50 00 00 01 00 c7 83 60 07 00 00 01 00 00 00 48 89 df e8 55 fe ff ff 5b 41 5c 5d c3 66 90 55 48 89 e5 ff 07 5d c3 55 48 89 e5 f0 ff 0f 0f 94 c0 84 c0 0f 95 c0 0f RIP [] atomic_inc+0x4/0x9 [nfs] RSP CR2: 0000000000000028 Signed-off-by: Benny Halevy Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit f1c0d40a55ba1dba9513a1796c26ebcb1b09e4d1 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 8a14f843b1a8bc230023762c18cd9af1225cf47f 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 9de9853227dd16156a01f01ed7e7774d47dce0d1 Author: Mikulas Patocka Date: Fri Mar 1 22:45:47 2013 +0000 dm snapshot: add missing module aliases commit 23cb21092eb9dcec9d3604b68d95192b79915890 upstream. Add module aliases so that autoloading works correctly if the user tries to activate "snapshot-origin" or "snapshot-merge" targets. Reference: https://bugzilla.redhat.com/889973 Reported-by: Chao Yang Signed-off-by: Mikulas Patocka Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit 6d2c84a053b338cb932d497b425cdc18845732f5 Author: Mike Christie Date: Fri Mar 1 22:45:48 2013 +0000 dm: fix limits initialization when there are no data devices commit 87eb5b21d92a92ac2da3163039d62df88c2b8422 upstream. dm_calculate_queue_limits will first reset the provided limits to defaults using blk_set_stacking_limits; whereby defeating the purpose of retaining the original live table's limits -- as was intended via commit 3ae706561637331aa578e52bb89ecbba5edcb7a9 ("dm: retain table limits when swapping to new table with no devices"). Fix this improper limits initialization (in the no data devices case) by avoiding the call to dm_calculate_queue_limits. [patch header revised by Mike Snitzer] Signed-off-by: Mike Christie Signed-off-by: Mike Snitzer Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit f7ed89f011514839a5935629f27042edb2fdc981 Author: Jun'ichi Nomura Date: Fri Mar 1 22:45:44 2013 +0000 dm: do not replace bioset for request based dm commit 16245bdc9d3e22d1460341a655c8b5288953bc14 upstream. This patch fixes a regression introduced in v3.8, which causes oops like this when dm-multipath is used: general protection fault: 0000 [#1] SMP RIP: 0010:[] [] mempool_free+0x24/0xb0 Call Trace: [] bio_put+0x97/0xc0 [] end_clone_bio+0x35/0x90 [dm_mod] [] bio_endio+0x1d/0x30 [] req_bio_endio.isra.51+0xa3/0xe0 [] blk_update_request+0x118/0x520 [] blk_update_bidi_request+0x27/0xa0 [] blk_end_bidi_request+0x2c/0x80 [] blk_end_request+0x10/0x20 [] scsi_io_completion+0xfb/0x6c0 [scsi_mod] [] scsi_finish_command+0xbd/0x120 [scsi_mod] [] scsi_softirq_done+0x13f/0x160 [scsi_mod] [] blk_done_softirq+0x80/0xa0 [] __do_softirq+0xf1/0x250 [] call_softirq+0x1c/0x30 [] do_softirq+0x8d/0xc0 [] irq_exit+0xd5/0xe0 [] do_IRQ+0x63/0xe0 [] common_interrupt+0x6f/0x6f [] srp_queuecommand+0x8c/0xcb0 [ib_srp] [] scsi_dispatch_cmd+0x148/0x310 [scsi_mod] [] scsi_request_fn+0x31e/0x520 [scsi_mod] [] __blk_run_queue+0x37/0x50 [] blk_delay_work+0x29/0x40 [] process_one_work+0x1c3/0x5c0 [] worker_thread+0x15e/0x440 [] kthread+0xdb/0xe0 [] ret_from_fork+0x7c/0xb0 The regression was introduced by the change c0820cf5 "dm: introduce per_bio_data", where dm started to replace bioset during table replacement. For bio-based dm, it is good because clone bios do not exist during the table replacement. For request-based dm, however, (not-yet-mapped) clone bios may stay in request queue and survive during the table replacement. So freeing the old bioset could cause the oops in bio_put(). Since the size of front_pad may change only with bio-based dm, it is not necessary to replace bioset for request-based dm. Reported-by: Bart Van Assche Tested-by: Bart Van Assche Signed-off-by: Jun'ichi Nomura Acked-by: Mikulas Patocka Acked-by: Mike Snitzer Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit a9317072827484b03a0959e85663d729537b8e05 Author: Mikulas Patocka Date: Fri Mar 1 22:45:44 2013 +0000 dm: fix truncated status strings commit fd7c092e711ebab55b2688d3859d95dfd0301f73 upstream. Avoid returning a truncated table or status string instead of setting the DM_BUFFER_FULL_FLAG when the last target of a table fills the buffer. When processing a table or status request, the function retrieve_status calls ti->type->status. If ti->type->status returns non-zero, retrieve_status assumes that the buffer overflowed and sets DM_BUFFER_FULL_FLAG. However, targets don't return non-zero values from their status method on overflow. Most targets returns always zero. If a buffer overflow happens in a target that is not the last in the table, it gets noticed during the next iteration of the loop in retrieve_status; but if a buffer overflow happens in the last target, it goes unnoticed and erroneously truncated data is returned. In the current code, the targets behave in the following way: * dm-crypt returns -ENOMEM if there is not enough space to store the key, but it returns 0 on all other overflows. * dm-thin returns errors from the status method if a disk error happened. This is incorrect because retrieve_status doesn't check the error code, it assumes that all non-zero values mean buffer overflow. * all the other targets always return 0. This patch changes the ti->type->status function to return void (because most targets don't use the return code). Overflow is detected in retrieve_status: if the status method fills up the remaining space completely, it is assumed that buffer overflow happened. Signed-off-by: Mikulas Patocka Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit ceab37b0c6013b8d179743ff16f309925db01153 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 53fc95ead12d00f7e08554d395875c899fd93c91 Author: Josef Bacik Date: Fri Mar 1 11:47:21 2013 -0500 Btrfs: delete inline extents when we find them during logging commit 124fe663f93162d17b7e391705cac122101e93d8 upstream. Apparently when we do inline extents we allow the data to overlap the last chunk of the btrfs_file_extent_item, which means that we can possibly have a btrfs_file_extent_item that isn't actually as large as a btrfs_file_extent_item. This messes with us when we try to overwrite the extent when logging new extents since we expect for it to be the right size. To fix this just delete the item and try to do the insert again which will give us the proper sized btrfs_file_extent_item. This fixes a panic where map_private_extent_buffer would blow up because we're trying to write past the end of the leaf. Thanks, Signed-off-by: Josef Bacik Signed-off-by: Greg Kroah-Hartman commit 0a8c4b4e2101b6fb45f4510fed204384d468826a Author: Josef Bacik Date: Thu Feb 28 13:23:38 2013 -0500 Btrfs: copy everything if we've created an inline extent commit bdc20e67e82cfc4901d3a5a0d79104b0e2296d83 upstream. I noticed while looking into a tree logging bug that we aren't logging inline extents properly. Since this requires copying and it shouldn't happen too often just force us to copy everything for the inode into the tree log when we have an inline extent. With this patch we have valid data after a crash when we write an inline extent. Thanks, Signed-off-by: Josef Bacik Signed-off-by: Greg Kroah-Hartman commit 9cf1259793a09ae8d01631167a7cdb8882665e1e 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 a4352d7ee81d77ff3e850d98b5fe44dc8d69929f Author: Lukas Czerner Date: Sat Mar 2 17:18:58 2013 -0500 ext4: convert number of blocks to clusters properly commit 810da240f221d64bf90020f25941b05b378186fe upstream. We're using macro EXT4_B2C() to convert number of blocks to number of clusters for bigalloc file systems. However, we should be using EXT4_NUM_B2C(). Signed-off-by: Lukas Czerner Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit f8d5ba6c2562b423d072cf66b7c8ae09c239a728 Author: Nicholas Bellinger Date: Wed Feb 27 17:53:52 2013 -0800 iscsi-target: Fix immediate queue starvation regression with DATAIN commit fd3a9025c0349bc9b01d627529f54e6e1e389015 upstream. This patch addresses a v3.5+ regression in iscsi-target where TX thread process context -> handle_response_queue() execution is allowed to run unbounded while servicing constant outgoing flow of ISTATE_SEND_DATAIN response state. This ends up preventing memory release of StatSN acknowledged commands in a timely manner when under heavy large block streaming DATAIN workloads. The regression bug was initially introduced with: commit 6f3c0e69a9c20441bdc6d3b2d18b83b244384ec6 Author: Andy Grover Date: Tue Apr 3 15:51:09 2012 -0700 target/iscsi: Refactor target_tx_thread immediate+response queue loops Go ahead and follow original iscsi_target_tx_thread() logic and check to break for immediate queue processing after each DataIN Sequence and/or Response PDU has been sent. Reported-by: Benjamin ESTRABAUD Cc: Andy Grover Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 50909650d88133e2231cf43632d2f4ee76266fd1 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 f8b16d21a6fc45dcf043259a69cab0c4c9e90d0f 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 3221f151902a4de1bd3dc5fc46b3befb0457fdb8 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 fddc34f963f9b9976a840606ef294d23aef4e783 Author: Mattia Dongili Date: Fri Dec 21 07:21:08 2012 +0900 sony-laptop: fully enable SNY controlled modems commit 3ec1c3983d73b1e3d4cfd72afab94c34eceafe8a upstream. The call to handlers 0x124 and 0x135 (rfkill control) seems to take a bitmask to control various states of the device. For our rfkill we need a fully on/off. SVZ1311Z9R/X's LTE modem needs more bits up. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47751 Signed-off-by: Mattia Dongili Signed-off-by: Matthew Garrett Signed-off-by: Greg Kroah-Hartman commit 5f60f42105100284d50fe8f2d8df956ae39ba6d1 Author: Takahisa Tanaka Date: Mon Jan 14 11:01:58 2013 +0900 watchdog: sp5100_tco: Write back the original value to reserved bits, instead of zero commit 41adafbd7b84c66c2cdad857b75d5d45032310a6 upstream. In case of SP5100 or SB7x0 chipsets, the sp5100_tco module writes zero to reserved bits. The module, however, shouldn't depend on specific default value, and should perform a read-merge-write operation for the reserved bits. This patch makes the sp5100_tco module perform a read-merge-write operation on all the chipset (sp5100, sb7x0, sb8x0 or later). Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43176 Signed-off-by: Takahisa Tanaka Tested-by: Paul Menzel Signed-off-by: Wim Van Sebroeck Signed-off-by: Greg Kroah-Hartman commit cc3edac76f8f5e8b0217874f80c0cb6b0774ee7a Author: Takahisa Tanaka Date: Mon Jan 14 11:01:57 2013 +0900 watchdog: sp5100_tco: Fix wrong indirect I/O access for getting value of reserved bits commit 10ab329b5db7e592a3a60b4594e4e5f40b60c45c upstream. In case of SB800 or later chipset and re-programming MMIO address(*), sp5100_tco module may read incorrect value of reserved bit, because the module reads a value from an incorrect I/O address. However, this bug doesn't cause a problem, because when re-programming MMIO address, by chance the module writes zero (this is BIOS's default value) to the low three bits of register. * In most cases, PC with SB8x0 or later chipset doesn't need to re-programming MMIO address, because such PC can enable AcpiMmio and can use 0xfed80b00 for watchdog register base address. This patch fixes this bug. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43176 Signed-off-by: Takahisa Tanaka Tested-by: Paul Menzel Signed-off-by: Wim Van Sebroeck Signed-off-by: Greg Kroah-Hartman commit f328def5abd814b392fe4dda89ca8a72eff26261 Author: Randy Dunlap Date: Mon Jan 28 08:29:48 2013 -0800 watchdog: da9055_wdt needs to select WATCHDOG_CORE commit 12a5c05cb143105d989abf728a8c769830670e54 upstream. DA9055_WATCHDOG (introduced in v3.8) needs to select WATCHDOG_CORE so that it will build cleanly. Fixes these build errors: da9055_wdt.c:(.text+0xe9bc7): undefined reference to `watchdog_unregister_device' da9055_wdt.c:(.text+0xe9f4b): undefined reference to `watchdog_register_device' Signed-off-by: Randy Dunlap Cc: David Dajun Chen Signed-off-by: Wim Van Sebroeck Cc: linux-watchdog@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ee74fecfc4c5a3d36f9e35908f38af85561feb8b 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 ca47ff970da26701d725ae1759b8bb6221c04140 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 a1c9ea4054122af173791f7431fd4484330de26e Author: Steven Noonan Date: Fri Mar 1 05:14:59 2013 -0800 xenbus: fix compile failure on ARM with Xen enabled commit 45e27161c62216c163880d7aed751cb55a65c8e9 upstream. Adding an include of linux/mm.h resolves this: drivers/xen/xenbus/xenbus_client.c: In function ‘xenbus_map_ring_valloc_hvm’: drivers/xen/xenbus/xenbus_client.c:532:66: error: implicit declaration of function ‘page_to_section’ [-Werror=implicit-function-declaration] Signed-off-by: Steven Noonan Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit 83bdd77f08b688915b17a63e73b2808da83c1d3a Author: Alan Stern Date: Tue Feb 26 13:43:41 2013 -0500 USB: EHCI: revert "remove ASS/PSS polling timeout" commit 221f8dfca89276d8aec54c6d07fbe20c281668f0 upstream. This patch (as1649) reverts commit 55bcdce8a8228223ec4d17d8ded8134ed265d2c5 (USB: EHCI: remove ASS/PSS polling timeout). That commit was written under the assumption that some controllers may take a very long time to turn off their async and periodic schedules. It now appears that in fact the schedules do get turned off reasonably quickly, but some controllers occasionally leave the schedules' status bits turned on and consequently ehci-hcd can't tell that the schedules are off. VIA controllers in particular have this problem. ehci-hcd tells the hardware to turn off the async schedule, the schedule does get turned off, but the status bit remains on. Since the EHCI spec requires that the schedules not be re-enabled until the previous disable has taken effect, with an unlimited timeout the async schedule never gets turned back on. The resulting symptom is that the system is unable to communicate with USB devices. Signed-off-by: Alan Stern Reported-and-tested-by: Ronald Reported-and-tested-by: Paul Hartman Reported-and-tested-by: Dieter Nützel Reported-and-tested-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit df97c726ff38a93d73056c1d388a720e8c3b5a96 Author: Catalin Marinas Date: Mon Feb 18 17:51:20 2013 +0100 ARM: 7654/1: Preserve L_PTE_VALID in pte_modify() commit 69dde4c52dbac2891b49ff9723d9c84efc5baf6f upstream. Following commit 26ffd0d4 (ARM: mm: introduce present, faulting entries for PAGE_NONE), if a page has been mapped as PROT_NONE, the L_PTE_VALID bit is cleared by the set_pte_ext() code. With LPAE the software and hardware pte share the same location and subsequent modifications of pte range (change_protection()) will leave the L_PTE_VALID bit cleared. This patch adds the L_PTE_VALID bit to the newprot mask in pte_modify(). Signed-off-by: Catalin Marinas Reported-by: Subash Patel Tested-by: Subash Patel Acked-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 13cfc75733aa5167b8a4578c41c49b4ea697d05c Author: Nicolas Pitre Date: Mon Feb 18 16:36:13 2013 +0100 ARM: 7653/2: do not scale loops_per_jiffy when using a constant delay clock commit 70264367a243a68b1d5636ffb570183449803cbe upstream. When udelay() is implemented using an architected timer, it is wrong to scale loops_per_jiffy when changing the CPU clock frequency since the timer clock remains constant. The lpj should probably become an implementation detail relevant to the CPU loop based delay routine only and more confined to it. In the mean time this is the minimal fix needed to have expected delays with the timer based implementation when cpufreq is also in use. Reported-by: Viresh Kumar Signed-off-by: Nicolas Pitre Tested-by: Viresh Kumar Acked-by: Liviu Dudau Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 69ac92ed67085663753c03a64cc88401b4696c61 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 908e88f285b909011dc7dbce5abaacf123f2f68d 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