commit 050dcf4a4cacca605dd9c94aa0a8a80078abf206 Author: Greg Kroah-Hartman Date: Fri Nov 29 11:28:26 2013 -0800 Linux 3.12.2 commit 8197da3cd698984b40ea23ac2cafeef58adf834d Author: Mauro Carvalho Chehab Date: Tue Nov 12 15:06:49 2013 -0800 cris: media platform drivers: fix build commit 72a0c5571351f5184195754d23db3e14495b2080 upstream. On cris arch, the functions below aren't defined: drivers/media/platform/sh_veu.c: In function 'sh_veu_reg_read': drivers/media/platform/sh_veu.c:228:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration] drivers/media/platform/sh_veu.c: In function 'sh_veu_reg_write': drivers/media/platform/sh_veu.c:234:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration] drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_read': drivers/media/platform/vsp1/vsp1.h:66:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration] drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_write': drivers/media/platform/vsp1/vsp1.h:71:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration] drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_read': drivers/media/platform/vsp1/vsp1.h:66:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration] drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_write': drivers/media/platform/vsp1/vsp1.h:71:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration] drivers/media/platform/soc_camera/rcar_vin.c: In function 'rcar_vin_setup': drivers/media/platform/soc_camera/rcar_vin.c:284:3: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration] drivers/media/platform/soc_camera/rcar_vin.c: In function 'rcar_vin_request_capture_stop': drivers/media/platform/soc_camera/rcar_vin.c:353:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration] Yet, they're available, as CONFIG_GENERIC_IOMAP is defined. What happens is that asm/io.h was not including asm-generic/iomap.h. Suggested-by: Ben Hutchings Signed-off-by: Mauro Carvalho Chehab Cc: Mikael Starvik Cc: Jesper Nilsson Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit abf0f6a245f013794efba9bcef60840fc9f72d13 Author: Miklos Szeredi Date: Mon Sep 23 13:21:04 2013 +0100 GFS2: fix dentry leaks commit 5ca1db41ecdeb0358b968265fadb755213558a85 upstream. We need to dput() the result of d_splice_alias(), unless it is passed to finish_no_open(). Edited by Steven Whitehouse in order to make it apply to the current GFS2 git tree, and taking account of a prerequisite patch which hasn't been applied. Signed-off-by: Miklos Szeredi Signed-off-by: Steven Whitehouse Signed-off-by: Greg Kroah-Hartman commit ae2d3f3d18e1b3be238f3b66d567f3801572e748 Author: Miklos Szeredi Date: Mon Sep 16 14:52:00 2013 +0200 GFS2: d_splice_alias() can't return error commit 0d0d110720d7960b77c03c9f2597faaff4b484ae upstream. unless it was given an IS_ERR(inode), which isn't the case here. So clean up the unnecessary error handling in gfs2_create_inode(). This paves the way for real fixes (hence the stable Cc). Signed-off-by: Miklos Szeredi Signed-off-by: Steven Whitehouse Signed-off-by: Greg Kroah-Hartman commit 84628ce030defb146b4de6bb6201882d436e49de Author: Junxiao Bi Date: Thu Nov 21 14:31:56 2013 -0800 configfs: fix race between dentry put and lookup commit 76ae281f6307331aa063288edb6422ae99f435f0 upstream. A race window in configfs, it starts from one dentry is UNHASHED and end before configfs_d_iput is called. In this window, if a lookup happen, since the original dentry was UNHASHED, so a new dentry will be allocated, and then in configfs_attach_attr(), sd->s_dentry will be updated to the new dentry. Then in configfs_d_iput(), BUG_ON(sd->s_dentry != dentry) will be triggered and system panic. sys_open: sys_close: ... fput dput dentry_kill __d_drop <--- dentry unhashed here, but sd->dentry still point to this dentry. lookup_real configfs_lookup configfs_attach_attr---> update sd->s_dentry to new allocated dentry here. d_kill configfs_d_iput <--- BUG_ON(sd->s_dentry != dentry) triggered here. To fix it, change configfs_d_iput to not update sd->s_dentry if sd->s_count > 2, that means there are another dentry is using the sd beside the one that is going to be put. Use configfs_dirent_lock in configfs_attach_attr to sync with configfs_d_iput. With the following steps, you can reproduce the bug. 1. enable ocfs2, this will mount configfs at /sys/kernel/config and fill configure in it. 2. run the following script. while [ 1 ]; do cat /sys/kernel/config/cluster/$your_cluster_name/idle_timeout_ms > /dev/null; done & while [ 1 ]; do cat /sys/kernel/config/cluster/$your_cluster_name/idle_timeout_ms > /dev/null; done & Signed-off-by: Junxiao Bi Cc: Joel Becker Cc: Al Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 00c5535698d5db83a3cd15d7f6a9b95c71044b4d Author: Martin Schwidefsky Date: Mon Oct 28 12:15:32 2013 +0100 s390/vtime: correct idle time calculation commit 4560e7c3317c7a2b370e36dadd3a3bac2ed70818 upstream. Use the ACCESS_ONCE macro for both accesses to idle->sequence in the loops to calculate the idle time. If only one access uses the macro, the compiler is free to cache the value for the second access which can cause endless loops. Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit b8600e27f208d08a5924d34d3b44f5564fa83e7f Author: Martin Schwidefsky Date: Mon Oct 28 11:17:10 2013 +0100 s390/time: fix get_tod_clock_ext inline assembly commit 7ab64a85e1a009046f97413a573e83fd85f7804d upstream. The get_tod_clock_ext inline assembly does not specify its output operands correctly. This can cause incorrect code to be generated. Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 78bf8811f05d10a9ecdbe5f1825a3b9e6b8d8fed Author: Sebastian Andrzej Siewior Date: Wed Oct 16 12:50:06 2013 +0200 usb: musb: core: properly free host / device structs in err path commit 0d2dd7eaed1dac07b266ca2c662ff4a184a3060f upstream. The patch fixes two issues in the error path cleanup: - in MUSB_PORT_MODE_DUAL_ROLE mode, if musb_gadget_setup() fails we never cleanup the host struct earlier allocated. - if musb_init_debugfs() or sysfs_create_group() fails, then we never free the host part initialization, only device part. Cc: Daniel Mack Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 35908a35cc40c44ff009611cd9054b02f37f882b Author: Sebastian Andrzej Siewior Date: Tue Oct 15 18:29:25 2013 +0200 usb: musb: dsps: redo the otg timer commit 0f901c980110cd69b63670096465b35377e73b1c upstream. According to the comments, we rely on the OTG timer because the core does not expose some important OTG details. So far this is all I know. After playing with OTG I stumbled over a problem: musb is recognized as a B-device without a problem. Whenever a cable is plugged, the VBUS rises, musb recognizes this as a starting session, sets the MUSB_DEVCTL_SESSION bit by itself and a RESET interrupt occurs, the session starts. Good. After a disconnect, the timer is started and re-starts itself because it remains in B_IDLE with the BDEVICE set. I didn't figure the the reason or the need for it. Nothing changes here except for OTG state from B to A device if the BDEVICE bit disappears. This doesn't make much sense to me because nothing happens after this. _IF_ we receive an interrupt before the state change then we may act on wrong condition. Plugging a B-device (and letting MUSB act as host) doesn't work here. The reason seems to be that the MUSB tries to start a session, it fails and then it removes the bit. So we never start as a host. This patch sets the MUSB_DEVCTL_SESSION bit in the IDLE state so musb can try to establish a session as host. After the bit is set, musb tries to start a session and if it fails it clears the bit. Therefore it will try over and over again until a session either as host or as device is established. The readout of the MUSB_DEVCTL register after the removal the MUSB_DEVCTL_SESSION (in A_WAIT_BCON) has been removed because it did not contain the BDEVICE bit set (in the second read) leading to A_IDLE. After plugging a host musb assumed that it is also a host and complained about a missing reset. However a third read of the register has has the BDEVICE bit set so it seems that it is not stable. This mostly what da8xx.c is doing except that we set the timer also after A_WAIT_BCON so the session bit can be triggered. Whit this change I was able to keep am335x-evm in OTG mode and plug in either a HOST or a DEVICE and in a random order and the device was recognized. Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit d138f3fedabca5548d0a46c471f093f44ab5c117 Author: Sebastian Andrzej Siewior Date: Tue Oct 15 18:29:23 2013 +0200 usb: musb: dsps: move try_idle to start hook commit 8b9fcce2d88586b9a120ff3e039d8f42413f0bb0 upstream. The timer is initialized right after musb is probed. There is actually no need to have this timer running because _nothing_ will happen until we have the gadget loaded. Also we need this timer only if we run in OTG mode _and_ we need it also after the gadget has been replaced with another one. I've been looking at am35x.c, da8xx.c, omap2430.c, tusb6010.c. da8xx seem to have the same problem as dsps and doing mostly the same thing. tusb6010 seem to do something different and do some actual "idle / power saving" work so I am not too comfortable to remove musb_platform_try_idle() from musb_gadget_setup(). Therefore this patch does not start the timer if there is no gadget active (which is at musb_gadget_setup() at time). In order to have the timer active after the gadget is loaded it will be triggered from dsps_musb_enable(). Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 43ac9e1999b72122ee20e942263584f95d993aaa Author: Sebastian Andrzej Siewior Date: Tue Oct 15 18:29:22 2013 +0200 usb: musb: call musb_start() only once in OTG mode commit ae44df2e21b50f9fff28ac75c57e399c04df812c upstream. In commit 001dd84 ("usb: musb: start musb on the udc side, too") it was ensured that the state engine is started also in OTG mode after a removal / insertion of the gadget. Unfortunately this change also introduced a bug: If the device is configured as OTG and it connected with a remote host _without_ loading a gadget then we bug() later (because musb->otg->gadget is not initialized). Initially I assumed it might be nice to have the host part of musb in OTG mode working without having a gadget loaded. This bug and fact that it wasn't working like this before the host/gadget split made me realize that this was a silly idea. This patch now introduces back the old behavior where in OTG mode the host mode is only working after the gadget has been loaded. Cc: Daniel Mack Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit bbc21afd5bd6d52976d74afc73ef2a9e9db631e6 Author: Sebastian Andrzej Siewior Date: Thu Oct 10 18:26:59 2013 +0200 usb: musb: cancel work on removal commit c5340bd14336b902604ab95212a8877de109d9ae upstream. So I captured this: |WARNING: CPU: 0 PID: 2078 at /home/bigeasy/work/new/TI/linux/lib/debugobjects.c:260 debug_print_object+0x94/0xc4() |ODEBUG: free active (active state 0) object type: work_struct hint: musb_irq_work+0x0/0x38 [musb_hdrc] |CPU: 0 PID: 2078 Comm: rmmod Not tainted 3.12.0-rc4+ #338 |[] (unwind_backtrace+0x0/0xf4) from [] (show_stack+0x14/0x1c) |[] (show_stack+0x14/0x1c) from [] (warn_slowpath_common+0x64/0x84) |[] (warn_slowpath_common+0x64/0x84) from [] (warn_slowpath_fmt+0x30/0x40) |[] (warn_slowpath_fmt+0x30/0x40) from [] (debug_print_object+0x94/0xc4) |[] (debug_print_object+0x94/0xc4) from [] (debug_check_no_obj_freed+0x1c0/0x228) |[] (debug_check_no_obj_freed+0x1c0/0x228) from [] (kfree+0xf8/0x228) |[] (kfree+0xf8/0x228) from [] (release_nodes+0x1a8/0x248) |[] (release_nodes+0x1a8/0x248) from [] (__device_release_driver+0x98/0xf0) |[] (__device_release_driver+0x98/0xf0) from [] (device_release_driver+0x24/0x34) |[] (device_release_driver+0x24/0x34) from [] (bus_remove_device+0x148/0x15c) |[] (bus_remove_device+0x148/0x15c) from [] (device_del+0x104/0x1c0) |[] (device_del+0x104/0x1c0) from [] (platform_device_del+0x18/0xac) |[] (platform_device_del+0x18/0xac) from [] (platform_device_unregister+0xc/0x18) |[] (platform_device_unregister+0xc/0x18) from [] (dsps_remove+0x20/0x4c [musb_dsps]) |[] (dsps_remove+0x20/0x4c [musb_dsps]) from [] (platform_drv_remove+0x1c/0x24) |[] (platform_drv_remove+0x1c/0x24) from [] (__device_release_driver+0x90/0xf0) |[] (__device_release_driver+0x90/0xf0) from [] (driver_detach+0xb4/0xb8) |[] (driver_detach+0xb4/0xb8) from [] (bus_remove_driver+0x98/0xec) |[] (bus_remove_driver+0x98/0xec) from [] (SyS_delete_module+0x1e0/0x24c) |[] (SyS_delete_module+0x1e0/0x24c) from [] (ret_fast_syscall+0x0/0x48) |---[ end trace d79045419a3e51ec ]--- The workqueue is only scheduled from the ep0 and never canceled in case the musb is removed before the work has a chance to run. Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 3cc3e73bfa6c0ed687ec72bb2fde011806fbc1c1 Author: Stanislaw Gruszka Date: Fri Oct 18 11:36:54 2013 +0200 rt2800usb: slow down TX status polling commit 36165fd5b00bf8163f89c21bb16a3e9834555b10 upstream. Polling TX statuses too frequently has two negative effects. First is randomly peek CPU usage, causing overall system functioning delays. Second bad effect is that device is not able to fill TX statuses in H/W register on some workloads and we get lot of timeouts like below: ieee80211 phy4: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2 ieee80211 phy4: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2 ieee80211 phy4: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping This not only cause flood of messages in dmesg, but also bad throughput, since rate scaling algorithm can not work optimally. In the future, we should probably make polling interval be adjusted automatically, but for now just increase values, this make mentioned problems gone. Resolve: https://bugzilla.kernel.org/show_bug.cgi?id=62781 Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 76a8bf9e36c1aeec698190e2187bc2824b69c63b Author: Thomas Pugliese Date: Wed Oct 23 14:44:26 2013 -0500 usb: wusbcore: set the RPIPE wMaxPacketSize value correctly commit 7b6bc07ab554e929c85d51b3d5b26cf7f12c6a3b upstream. For isochronous endpoints, set the RPIPE wMaxPacketSize value using wOverTheAirPacketSize from the endpoint companion descriptor instead of wMaxPacketSize from the normal endpoint descriptor. Signed-off-by: Thomas Pugliese Signed-off-by: Greg Kroah-Hartman commit 38fee62c7ded145795c8f7fc4dafe7b41cc1ffde Author: Julius Werner Date: Tue Oct 15 17:45:00 2013 -0700 usb: hub: Clear Port Reset Change during init/resume commit e92aee330837e4911553761490a8fb843f2053a6 upstream. This patch adds the Port Reset Change flag to the set of bits that are preemptively cleared on init/resume of a hub. In theory this bit should never be set unexpectedly... in practice it can still happen if BIOS, SMM or ACPI code plays around with USB devices without cleaning up correctly. This is especially dangerous for XHCI root hubs, which don't generate any more Port Status Change Events until all change bits are cleared, so this is a good precaution to have (similar to how it's already done for the Warm Port Reset Change flag). Signed-off-by: Julius Werner Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 692a66b4064dd7a600ab61652ca5167875352aca Author: Sarah Sharp Date: Mon Sep 30 17:26:29 2013 +0300 usb: Disable USB 2.0 Link PM before device reset. commit dcc01c0864823f91c3bf3ffca6613e2351702b87 upstream. Before the USB core resets a device, we need to disable the L1 timeout for the roothub, if USB 2.0 Link PM is enabled. Otherwise the port may transition into L1 in between descriptor fetches, before we know if the USB device descriptors changed. LPM will be re-enabled after the full device descriptors are fetched, and we can confirm the device still supports USB 2.0 LPM after the reset. We don't need to wait for the USB device to exit L1 before resetting the device, since the xHCI roothub port diagrams show a transition to the Reset state from any of the Ux states (see Figure 34 in the 2012-08-14 xHCI specification update). This patch should be backported to kernels as old as 3.2, that contain the commit 65580b4321eb36f16ae8b5987bfa1bb948fc5112 "xHCI: set USB2 hardware LPM". That was the first commit to enable USB 2.0 hardware-driven Link Power Management. Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit 6f18110227a4bd49a403a26002d762ec0802ee90 Author: Sarah Sharp Date: Mon Oct 7 17:17:20 2013 -0700 xhci: Set L1 device slot on USB2 LPM enable/disable. commit 58e21f73975ec927119370635bf68b9023831c56 upstream. To enable USB 2.0 Link Power Management (LPM), the xHCI host controller needs the device slot ID to generate the device address used in L1 entry tokens. That information is set in the L1 device slot ID field of the USB 2.0 LPM registers. Currently, the L1 device slot ID is overwritten when the xHCI driver initiates the software test of USB 2.0 Link PM in xhci_usb2_software_lpm_test. It is never cleared when USB 2.0 Link PM is disabled for the device. That should be harmless, because the Hardware LPM Enable (HLE) bit is cleared when USB 2.0 Link PM is disabled, so the host should not pay attention to the slot ID. This patch should have no effect on host behavior, but since xhci_usb2_software_lpm_test is going away in an upcoming bug fix patch, we need to move that code to the function that enables and disables USB 2.0 Link PM. This patch should be backported to kernels as old as 3.11, that contain the commit a558ccdcc71c7770c5e80c926a31cfe8a3892a09 "usb: xhci: add USB2 Link power management BESL support". The upcoming bug fix patch is also marked for that stable kernel. Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit 2fbe9566c55ddd9497292cb186b8271b64f5d37c Author: Mathias Nyman Date: Mon Sep 30 17:26:31 2013 +0300 xhci: Enable LPM support only for hardwired or BESL devices commit 890dae88672175f1d39f6105444d9bdc71c89258 upstream. Some usb3 devices falsely claim they support usb2 hardware Link PM when connected to a usb2 port. We only trust hardwired devices or devices with the later BESL LPM support to be LPM enabled as default. [Note: Sarah re-worked the original patch to move the code into the USB core, and updated it to check whether the USB device supports BESL, instead of checking if the xHCI port it's connected to supports BESL encoding.] This patch should be backported to kernels as old as 3.11, that contain the commit a558ccdcc71c7770c5e80c926a31cfe8a3892a09 "usb: xhci: add USB2 Link power management BESL support". Without this fix, some USB 3.0 devices will not enumerate or work properly under USB 2.0 ports on Haswell-ULT systems. Signed-off-by: Mathias Nyman Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit c1e847c7bc82614608007944095d30f575f1a429 Author: Sarah Sharp Date: Mon Sep 30 17:26:28 2013 +0300 usb: Don't enable USB 2.0 Link PM by default. commit de68bab4fa96014cfaa6fcbcdb9750e32969fb86 upstream. How it's supposed to work: -------------------------- USB 2.0 Link PM is a lower power state that some newer USB 2.0 devices support. USB 3.0 devices certified by the USB-IF are required to support it if they are plugged into a USB 2.0 only port, or a USB 2.0 cable is used. USB 2.0 Link PM requires both a USB device and a host controller that supports USB 2.0 hardware-enabled LPM. USB 2.0 Link PM is designed to be enabled once by software, and the host hardware handles transitions to the L1 state automatically. The premise of USB 2.0 Link PM is to be able to put the device into a lower power link state when the bus is idle or the device NAKs USB IN transfers for a specified amount of time. ...but hardware is broken: -------------------------- It turns out many USB 3.0 devices claim to support USB 2.0 Link PM (by setting the LPM bit in their USB 2.0 BOS descriptor), but they don't actually implement it correctly. This manifests as the USB device refusing to respond to transfers when it is plugged into a USB 2.0 only port under the Haswell-ULT/Lynx Point LP xHCI host. These devices pass the xHCI driver's simple test to enable USB 2.0 Link PM, wait for the port to enter L1, and then bring it back into L0. They only start to break when L1 entry is interleaved with transfers. Some devices then fail to respond to the next control transfer (usually a Set Configuration). This results in devices never enumerating. Other mass storage devices (such as a later model Western Digital My Passport USB 3.0 hard drive) respond fine to going into L1 between control transfers. They ACK the entry, come out of L1 when the host needs to send a control transfer, and respond properly to those control transfers. However, when the first READ10 SCSI command is sent, the device NAKs the data phase while it's reading from the spinning disk. Eventually, the host requests to put the link into L1, and the device ACKs that request. Then it never responds to the data phase of the READ10 command. This results in not being able to read from the drive. Some mass storage devices (like the Corsair Survivor USB 3.0 flash drive) are well behaved. They ACK the entry into L1 during control transfers, and when SCSI commands start coming in, they NAK the requests to go into L1, because they need to be at full power. Not all USB 3.0 devices advertise USB 2.0 link PM support. My Point Grey USB 3.0 webcam advertises itself as a USB 2.1 device, but doesn't have a USB 2.0 BOS descriptor, so we don't enable USB 2.0 Link PM. I suspect that means the device isn't certified. What do we do about it? ----------------------- There's really no good way for the kernel to test these devices. Therefore, the kernel needs to disable USB 2.0 Link PM by default, and distros will have to enable it by writing 1 to the sysfs file /sys/bus/usb/devices/../power/usb2_hardware_lpm. Rip out the xHCI Link PM test, since it's not sufficient to detect these buggy devices, and don't automatically enable LPM after the device is addressed. This patch should be backported to kernels as old as 3.11, that contain the commit a558ccdcc71c7770c5e80c926a31cfe8a3892a09 "usb: xhci: add USB2 Link power management BESL support". Without this fix, some USB 3.0 devices will not enumerate or work properly under USB 2.0 ports on Haswell-ULT systems. Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit a58c56c06df7d78317fb330a1677e93c46566de9 Author: Tomas Winkler Date: Mon Oct 21 22:05:38 2013 +0300 mei: nfc: fix memory leak in error path commit 4bff7208f332b2b1d7cf1338e50527441283a198 upstream. The flow may reach the err label without freeing cl and cl_info cl and cl_info weren't assigned to ndev->cl and cl_info so they weren't freed in mei_nfc_free called on error path Cc: Samuel Ortiz Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman commit 9dae4dbe6ef3f804250d3751018c5e2ea01f6f8f Author: Trond Myklebust Date: Tue Nov 12 17:24:36 2013 -0500 SUNRPC: Avoid deep recursion in rpc_release_client commit d07ba8422f1e58be94cc98a1f475946dc1b89f1b upstream. In cases where an rpc client has a parent hierarchy, then rpc_free_client may end up calling rpc_release_client() on the parent, thus recursing back into rpc_free_client. If the hierarchy is deep enough, then we can get into situations where the stack simply overflows. The fix is to have rpc_release_client() loop so that it can take care of the parent rpc client hierarchy without needing to recurse. Reported-by: Jeff Layton Reported-by: Weston Andros Adamson Reported-by: Bruce Fields Link: http://lkml.kernel.org/r/2C73011F-0939-434C-9E4D-13A1EB1403D7@netapp.com Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 2181c6aa6ae9d163415d2d6ab4ec2cfaaf6f5dcb Author: Trond Myklebust Date: Fri Nov 8 16:03:50 2013 -0500 SUNRPC: Fix a data corruption issue when retransmitting RPC calls commit a6b31d18b02ff9d7915c5898c9b5ca41a798cd73 upstream. The following scenario can cause silent data corruption when doing NFS writes. It has mainly been observed when doing database writes using O_DIRECT. 1) The RPC client uses sendpage() to do zero-copy of the page data. 2) Due to networking issues, the reply from the server is delayed, and so the RPC client times out. 3) The client issues a second sendpage of the page data as part of an RPC call retransmission. 4) The reply to the first transmission arrives from the server _before_ the client hardware has emptied the TCP socket send buffer. 5) After processing the reply, the RPC state machine rules that the call to be done, and triggers the completion callbacks. 6) The application notices the RPC call is done, and reuses the pages to store something else (e.g. a new write). 7) The client NIC drains the TCP socket send buffer. Since the page data has now changed, it reads a corrupted version of the initial RPC call, and puts it on the wire. This patch fixes the problem in the following manner: The ordering guarantees of TCP ensure that when the server sends a reply, then we know that the _first_ transmission has completed. Using zero-copy in that situation is therefore safe. If a time out occurs, we then send the retransmission using sendmsg() (i.e. no zero-copy), We then know that the socket contains a full copy of the data, and so it will retransmit a faithful reproduction even if the RPC call completes, and the application reuses the O_DIRECT buffer in the meantime. Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 1b1207b1c043687c2827dba6f5e017c698335cef Author: Trond Myklebust Date: Mon Oct 28 18:41:44 2013 -0400 SUNRPC: gss_alloc_msg - choose _either_ a v0 message or a v1 message commit 5fccc5b52ee07d07a74ce53c6f174bff81e26a16 upstream. Add the missing 'break' to ensure that we don't corrupt a legacy 'v0' type message by appending the 'v1'. Cc: Bruce Fields Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 54fc381e213ae04227c038ecab5623959b0f5849 Author: Christoph Lameter Date: Thu Nov 7 16:29:15 2013 +0000 slub: Handle NULL parameter in kmem_cache_flags commit c6f58d9b362b45c52afebe4342c9137d0dabe47f upstream. Andreas Herrmann writes: When I've used slub_debug kernel option (e.g. "slub_debug=,skbuff_fclone_cache" or similar) on a debug session I've seen a panic like: Highbank #setenv bootargs console=ttyAMA0 root=/dev/sda2 kgdboc.kgdboc=ttyAMA0,115200 slub_debug=,kmalloc-4096 earlyprintk=ttyAMA0 ... Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = c0004000 [00000000] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM Modules linked in: CPU: 0 PID: 0 Comm: swapper Tainted: G W 3.12.0-00048-gbe408cd #314 task: c0898360 ti: c088a000 task.ti: c088a000 PC is at strncmp+0x1c/0x84 LR is at kmem_cache_flags.isra.46.part.47+0x44/0x60 pc : [] lr : [] psr: 200001d3 sp : c088bea8 ip : c088beb8 fp : c088beb4 r10: 00000000 r9 : 413fc090 r8 : 00000001 r7 : 00000000 r6 : c2984a08 r5 : c0966e78 r4 : 00000000 r3 : 0000006b r2 : 0000000c r1 : 00000000 r0 : c2984a08 Flags: nzCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 0000404a DAC: 00000015 Process swapper (pid: 0, stack limit = 0xc088a248) Stack: (0xc088bea8 to 0xc088c000) bea0: c088bed4 c088beb8 c0110a3c c02c6d90 c0966e78 00000040 bec0: ef001f00 00000040 c088bf14 c088bed8 c0112070 c0110a04 00000005 c010fac8 bee0: c088bf5c c088bef0 c010fac8 ef001f00 00000040 00000000 00000040 00000001 bf00: 413fc090 00000000 c088bf34 c088bf18 c0839190 c0112040 00000000 ef001f00 bf20: 00000000 00000000 c088bf54 c088bf38 c0839200 c083914c 00000006 c0961c4c bf40: c0961c28 00000000 c088bf7c c088bf58 c08392ac c08391c0 c08a2ed8 c0966e78 bf60: c086b874 c08a3f50 c0961c28 00000001 c088bfb4 c088bf80 c083b258 c0839248 bf80: 2f800000 0f000000 c08935b4 ffffffff c08cd400 ffffffff c08cd400 c0868408 bfa0: c29849c0 00000000 c088bff4 c088bfb8 c0824974 c083b1e4 ffffffff ffffffff bfc0: c08245c0 00000000 00000000 c0868408 00000000 10c5387d c0892bcc c0868404 bfe0: c0899440 0000406a 00000000 c088bff8 00008074 c0824824 00000000 00000000 [] (strncmp+0x1c/0x84) from [] (kmem_cache_flags.isra.46.part.47+0x44/0x60) [] (kmem_cache_flags.isra.46.part.47+0x44/0x60) from [] (__kmem_cache_create+0x3c/0x410) [] (__kmem_cache_create+0x3c/0x410) from [] (create_boot_cache+0x50/0x74) [] (create_boot_cache+0x50/0x74) from [] (create_kmalloc_cache+0x4c/0x88) [] (create_kmalloc_cache+0x4c/0x88) from [] (create_kmalloc_caches+0x70/0x114) [] (create_kmalloc_caches+0x70/0x114) from [] (kmem_cache_init+0x80/0xe0) [] (kmem_cache_init+0x80/0xe0) from [] (start_kernel+0x15c/0x318) [] (start_kernel+0x15c/0x318) from [<00008074>] (0x8074) Code: e3520000 01a00002 089da800 e5d03000 (e5d1c000) ---[ end trace 1b75b31a2719ed1d ]--- Kernel panic - not syncing: Fatal exception Problem is that slub_debug option is not parsed before create_boot_cache is called. Solve this by changing slub_debug to early_param. Kernels 3.11, 3.10 are also affected. I am not sure about older kernels. Christoph Lameter explains: kmem_cache_flags may be called with NULL parameter during early boot. Skip the test in that case. Reported-by: Andreas Herrmann Signed-off-by: Christoph Lameter Signed-off-by: Pekka Enberg Signed-off-by: Greg Kroah-Hartman commit 057a7c6968c341081754ef5fe7c4d33fbfbd5465 Author: Anton Blanchard Date: Sun Nov 17 11:39:05 2013 +1100 powerpc/pseries: Duplicate dtl entries sometimes sent to userspace commit 84b073868b9d9e754ae48b828337633d1b386482 upstream. When reading from the dispatch trace log (dtl) userspace interface, I sometimes see duplicate entries. One example: # hexdump -C dtl.out 00000000 07 04 00 0c 00 00 48 44 00 00 00 00 00 00 00 00 00000010 00 0c a0 b4 16 83 6d 68 00 00 00 00 00 00 00 00 00000020 00 00 00 00 10 00 13 50 80 00 00 00 00 00 d0 32 00000030 07 04 00 0c 00 00 48 44 00 00 00 00 00 00 00 00 00000040 00 0c a0 b4 16 83 6d 68 00 00 00 00 00 00 00 00 00000050 00 00 00 00 10 00 13 50 80 00 00 00 00 00 d0 32 The problem is in scan_dispatch_log() where we call dtl_consumer() but bail out before incrementing the index. To fix this I moved dtl_consumer() after the timebase comparison. Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 80e6b610e7442644507d76a38a98e1ab68695ad6 Author: Gavin Shan Date: Tue Nov 12 14:49:21 2013 +0800 powerpc/eeh: Enable PCI_COMMAND_MASTER for PCI bridges commit bf898ec5cbd33be11147743bee27b66b10cb2f85 upstream. On PHB3, we will fail to fetch IODA tables without PCI_COMMAND_MASTER on PCI bridges. According to one experiment I had, the MSIx interrupts didn't raise from the adapter without the bit applied to all upstream PCI bridges including root port of the adapter. The patch forces to have that bit enabled accordingly. Signed-off-by: Gavin Shan Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 3f0387f7a915418bc7df3d1861d8f3536f348244 Author: Michael Neuling Date: Wed Nov 20 16:18:54 2013 +1100 powerpc/signals: Mark VSX not saved with small contexts commit c13f20ac48328b05cd3b8c19e31ed6c132b44b42 upstream. The VSX MSR bit in the user context indicates if the context contains VSX state. Currently we set this when the process has touched VSX at any stage. Unfortunately, if the user has not provided enough space to save the VSX state, we can't save it but we currently still set the MSR VSX bit. This patch changes this to clear the MSR VSX bit when the user doesn't provide enough space. This indicates that there is no valid VSX state in the user context. This is needed to support get/set/make/swapcontext for applications that use VSX but only provide a small context. For example, getcontext in glibc provides a smaller context since the VSX registers don't need to be saved over the glibc function call. But since the program calling getcontext may have used VSX, the kernel currently says the VSX state is valid when it's not. If the returned context is then used in setcontext (ie. a small context without VSX but with MSR VSX set), the kernel will refuse the context. This situation has been reported by the glibc community. Based on patch from Carlos O'Donell. Tested-by: Haren Myneni Signed-off-by: Michael Neuling Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 9e5139b7d8ffbb01fd1b3d646ea348ef929e15ad Author: Heiko Carstens Date: Thu Nov 14 15:01:43 2013 +1100 powerpc: Fix __get_user_pages_fast() irq handling commit 95f715b08fa4a953771398d20cbe35a6803ea41d upstream. __get_user_pages_fast() may be called with interrupts disabled (see e.g. get_futex_key() in kernel/futex.c) and therefore should use local_irq_save() and local_irq_restore() instead of local_irq_disable()/enable(). Signed-off-by: Heiko Carstens Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 3aad6072464530c82674f840374c726b467cfcf0 Author: Anton Blanchard Date: Mon Nov 18 14:55:28 2013 +1100 powerpc: ppc64 address space capped at 32TB, mmap randomisation disabled commit 5a049f14902982c26538250bdc8d54156d357252 upstream. Commit fba2369e6ceb (mm: use vm_unmapped_area() on powerpc architecture) has a bug in slice_scan_available() where we compare an unsigned long (high_slices) against a shifted int. As a result, comparisons against the top 32 bits of high_slices (representing the top 32TB) always returns 0 and the top of our mmap region is clamped at 32TB This also breaks mmap randomisation since the randomised address is always up near the top of the address space and it gets clamped down to 32TB. Signed-off-by: Anton Blanchard Acked-by: Michel Lespinasse Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 9a43996524dacb19f9e90484190253873748bd1f Author: Gavin Shan Date: Mon Nov 4 16:32:46 2013 +0800 powerpc/powernv: Add PE to its own PELTV commit 631ad691b5818291d89af9be607d2fe40be0886e upstream. We need add PE to its own PELTV. Otherwise, the errors originated from the PE might contribute to other PEs. In the result, we can't clear up the error successfully even we're checking and clearing errors during access to PCI config space. Reported-by: kalshett@in.ibm.com Signed-off-by: Gavin Shan Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit f457589da4d7d130e2aad8a909d13ca47e747032 Author: Prarit Bhargava Date: Thu Oct 17 08:00:11 2013 -0400 powerpc/vio: use strcpy in modalias_show commit 411cabf79e684171669ad29a0628c400b4431e95 upstream. Commit e82b89a6f19bae73fb064d1b3dd91fcefbb478f4 used strcat instead of strcpy which can result in an overflow of newlines on the buffer. Signed-off-by: Prarit Bhargava Cc: benh@kernel.crashing.org Cc: ben@decadent.org.uk Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 12fbe485d3352e07b8b9e970d18e383cbaf52f9d Author: Gerhard Sittig Date: Fri Sep 27 17:28:38 2013 +0200 powerpc/mpc512x: silence build warning upon disabled DIU commit 45d20e8348969a165c53cfb91f445e7cc599a9f0 upstream. a disabled Kconfig option results in a reference to a not implemented routine when the IS_ENABLED() macro is used for both conditional implementation of the routine as well as a C language source code test at the call site -- the "if (0) func();" construct only gets eliminated later by the optimizer, while the compiler already has emitted its warning about "func()" being undeclared provide an empty implementation for the mpc512x_setup_diu() and mpc512x_init_diu() routines in case of the disabled option, to avoid the compiler warning which is considered fatal and breaks compilation the bug appeared with commit 2abbbb63c90ab55ca3f054772c2e5ba7df810c48 "powerpc/mpc512x: move common code to shared.c file", how to reproduce: make mpc512x_defconfig echo CONFIG_FB_FSL_DIU=n >> .config && make olddefconfig make CC arch/powerpc/platforms/512x/mpc512x_shared.o .../arch/powerpc/platforms/512x/mpc512x_shared.c: In function 'mpc512x_init_early': .../arch/powerpc/platforms/512x/mpc512x_shared.c:456:3: error: implicit declaration of function 'mpc512x_init_diu' [-Werror=implicit-function-declaration] .../arch/powerpc/platforms/512x/mpc512x_shared.c: In function 'mpc512x_setup_arch': .../arch/powerpc/platforms/512x/mpc512x_shared.c:469:3: error: implicit declaration of function 'mpc512x_setup_diu' [-Werror=implicit-function-declaration] cc1: all warnings being treated as errors make[4]: *** [arch/powerpc/platforms/512x/mpc512x_shared.o] Error 1 Signed-off-by: Gerhard Sittig Signed-off-by: Anatolij Gustschin Signed-off-by: Greg Kroah-Hartman commit 5e2bc1c5f3226dd90d342447d5222c524cf602b2 Author: Anatolij Gustschin Date: Wed Oct 16 13:11:27 2013 +0200 powerpc/52xx: fix build breakage for MPC5200 LPBFIFO module commit 2bf75084f6d9f9a91ba6e30a501ff070d8a1acf6 upstream. The MPC5200 LPBFIFO driver requires the bestcomm module to be enabled, otherwise building will fail. Fix it. Reported-by: Wolfgang Denk Signed-off-by: Anatolij Gustschin Signed-off-by: Greg Kroah-Hartman commit fa9d73efe4b185ff3a9f47d68bd78a2f23b35460 Author: Mike Snitzer Date: Fri Oct 18 09:44:49 2013 -0600 block: properly stack underlying max_segment_size to DM device commit d82ae52e68892338068e7559a0c0657193341ce4 upstream. Without this patch all DM devices will default to BLK_MAX_SEGMENT_SIZE (65536) even if the underlying device(s) have a larger value -- this is due to blk_stack_limits() using min_not_zero() when stacking the max_segment_size limit. 1073741824 before patch: 65536 after patch: 1073741824 Reported-by: Lukasz Flis Signed-off-by: Mike Snitzer Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 4ceb8127d13ba24c15140b24c96145b1c317f536 Author: Mikulas Patocka Date: Mon Oct 14 12:13:24 2013 -0400 block: fix a probe argument to blk_register_region commit a207f5937630dd35bd2550620bef416937a1365e upstream. The probe function is supposed to return NULL on failure (as we can see in kobj_lookup: kobj = probe(dev, index, data); ... if (kobj) return kobj; However, in loop and brd, it returns negative error from ERR_PTR. This causes a crash if we simulate disk allocation failure and run less -f /dev/loop0 because the negative number is interpreted as a pointer: BUG: unable to handle kernel NULL pointer dereference at 00000000000002b4 IP: [] __blkdev_get+0x28/0x450 PGD 23c677067 PUD 23d6d1067 PMD 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: loop hpfs nvidia(PO) ip6table_filter ip6_tables uvesafb cfbcopyarea cfbimgblt cfbfillrect fbcon font bitblit fbcon_rotate fbcon_cw fbcon_ud fbcon_ccw softcursor fb fbdev msr ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 xt_state ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc tun ipv6 cpufreq_stats cpufreq_ondemand cpufreq_userspace cpufreq_powersave cpufreq_conservative hid_generic spadfs usbhid hid fuse raid0 snd_usb_audio snd_pcm_oss snd_mixer_oss md_mod snd_pcm snd_timer snd_page_alloc snd_hwdep snd_usbmidi_lib dmi_sysfs snd_rawmidi nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack snd soundcore lm85 hwmon_vid ohci_hcd ehci_pci ehci_hcd serverworks sata_svw libata acpi_cpufreq freq_table mperf ide_core usbcore kvm_amd kvm tg3 i2c_piix4 libphy microcode e100 usb_common ptp skge i2c_core pcspkr k10temp evdev floppy hwmon pps_core mii rtc_cmos button processor unix [last unloaded: nvidia] CPU: 1 PID: 6831 Comm: less Tainted: P W O 3.10.15-devel #18 Hardware name: empty empty/S3992-E, BIOS 'V1.06 ' 06/09/2009 task: ffff880203cc6bc0 ti: ffff88023e47c000 task.ti: ffff88023e47c000 RIP: 0010:[] [] __blkdev_get+0x28/0x450 RSP: 0018:ffff88023e47dbd8 EFLAGS: 00010286 RAX: ffffffffffffff74 RBX: ffffffffffffff74 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000001 RBP: ffff88023e47dc18 R08: 0000000000000002 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff88023f519658 R13: ffffffff8118c300 R14: 0000000000000000 R15: ffff88023f519640 FS: 00007f2070bf7700(0000) GS:ffff880247400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000002b4 CR3: 000000023da1d000 CR4: 00000000000007e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Stack: 0000000000000002 0000001d00000000 000000003e47dc50 ffff88023f519640 ffff88043d5bb668 ffffffff8118c300 ffff88023d683550 ffff88023e47de60 ffff88023e47dc98 ffffffff8118c10d 0000001d81605698 0000000000000292 Call Trace: [] ? blkdev_get_by_dev+0x60/0x60 [] blkdev_get+0x1dd/0x370 [] ? blkdev_get_by_dev+0x60/0x60 [] ? _raw_spin_unlock+0x2c/0x50 [] ? blkdev_get_by_dev+0x60/0x60 [] blkdev_open+0x65/0x80 [] do_dentry_open.isra.18+0x23e/0x2f0 [] finish_open+0x34/0x50 [] do_last.isra.62+0x2d2/0xc50 [] path_openat.isra.63+0xb8/0x4d0 [] ? might_fault+0x4e/0xa0 [] do_filp_open+0x40/0x90 [] ? _raw_spin_unlock+0x2c/0x50 [] ? __alloc_fd+0xa5/0x1f0 [] do_sys_open+0xef/0x1d0 [] SyS_open+0x19/0x20 [] system_call_fastpath+0x1a/0x1f Code: 44 00 00 55 48 89 e5 41 57 49 89 ff 41 56 41 89 d6 41 55 41 54 4c 8d 67 18 53 48 83 ec 18 89 75 cc e9 f2 00 00 00 0f 1f 44 00 00 <48> 8b 80 40 03 00 00 48 89 df 4c 8b 68 58 e8 d5 a4 07 00 44 89 RIP [] __blkdev_get+0x28/0x450 RSP CR2: 00000000000002b4 ---[ end trace bb7f32dbf02398dc ]--- The brd change should be backported to stable kernels starting with 2.6.25. The loop change should be backported to stable kernels starting with 2.6.22. Signed-off-by: Mikulas Patocka Acked-by: Tejun Heo Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 6c8a390a12e552d1545485809246aeaae7a39a9e Author: Jeff Moyer Date: Tue Oct 8 14:36:41 2013 -0400 block: fix race between request completion and timeout handling commit 4912aa6c11e6a5d910264deedbec2075c6f1bb73 upstream. crocode i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support shpchp ioatdma dca be2net sg ses enclosure ext4 mbcache jbd2 sd_mod crc_t10dif ahci megaraid_sas(U) dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan] Pid: 491, comm: scsi_eh_0 Tainted: G W ---------------- 2.6.32-220.13.1.el6.x86_64 #1 IBM -[8722PAX]-/00D1461 RIP: 0010:[] [] blk_requeue_request+0x94/0xa0 RSP: 0018:ffff881057eefd60 EFLAGS: 00010012 RAX: ffff881d99e3e8a8 RBX: ffff881d99e3e780 RCX: ffff881d99e3e8a8 RDX: ffff881d99e3e8a8 RSI: ffff881d99e3e780 RDI: ffff881d99e3e780 RBP: ffff881057eefd80 R08: ffff881057eefe90 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff881057f92338 R13: 0000000000000000 R14: ffff881057f92338 R15: ffff883058188000 FS: 0000000000000000(0000) GS:ffff880040200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 00000000006d3ec0 CR3: 000000302cd7d000 CR4: 00000000000406b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process scsi_eh_0 (pid: 491, threadinfo ffff881057eee000, task ffff881057e29540) Stack: 0000000000001057 0000000000000286 ffff8810275efdc0 ffff881057f16000 <0> ffff881057eefdd0 ffffffff81362323 ffff881057eefe20 ffffffff8135f393 <0> ffff881057e29af8 ffff8810275efdc0 ffff881057eefe78 ffff881057eefe90 Call Trace: [] __scsi_queue_insert+0xa3/0x150 [] ? scsi_eh_ready_devs+0x5e3/0x850 [] scsi_queue_insert+0x13/0x20 [] scsi_eh_flush_done_q+0x104/0x160 [] scsi_error_handler+0x35b/0x660 [] ? scsi_error_handler+0x0/0x660 [] kthread+0x96/0xa0 [] child_rip+0xa/0x20 [] ? kthread+0x0/0xa0 [] ? child_rip+0x0/0x20 Code: 00 00 eb d1 4c 8b 2d 3c 8f 97 00 4d 85 ed 74 bf 49 8b 45 00 49 83 c5 08 48 89 de 4c 89 e7 ff d0 49 8b 45 00 48 85 c0 75 eb eb a4 <0f> 0b eb fe 0f 1f 84 00 00 00 00 00 55 48 89 e5 0f 1f 44 00 00 RIP [] blk_requeue_request+0x94/0xa0 RSP The RIP is this line: BUG_ON(blk_queued_rq(rq)); After digging through the code, I think there may be a race between the request completion and the timer handler running. A timer is started for each request put on the device's queue (see blk_start_request->blk_add_timer). If the request does not complete before the timer expires, the timer handler (blk_rq_timed_out_timer) will mark the request complete atomically: static inline int blk_mark_rq_complete(struct request *rq) { return test_and_set_bit(REQ_ATOM_COMPLETE, &rq->atomic_flags); } and then call blk_rq_timed_out. The latter function will call scsi_times_out, which will return one of BLK_EH_HANDLED, BLK_EH_RESET_TIMER or BLK_EH_NOT_HANDLED. If BLK_EH_RESET_TIMER is returned, blk_clear_rq_complete is called, and blk_add_timer is again called to simply wait longer for the request to complete. Now, if the request happens to complete while this is going on, what happens? Given that we know the completion handler will bail if it finds the REQ_ATOM_COMPLETE bit set, we need to focus on the completion handler running after that bit is cleared. So, from the above paragraph, after the call to blk_clear_rq_complete. If the completion sets REQ_ATOM_COMPLETE before the BUG_ON in blk_add_timer, we go boom there (I haven't seen this in the cores). Next, if we get the completion before the call to list_add_tail, then the timer will eventually fire for an old req, which may either be freed or reallocated (there is evidence that this might be the case). Finally, if the completion comes in *after* the addition to the timeout list, I think it's harmless. The request will be removed from the timeout list, req_atom_complete will be set, and all will be well. This will only actually explain the coredumps *IF* the request structure was freed, reallocated *and* queued before the error handler thread had a chance to process it. That is possible, but it may make sense to keep digging for another race. I think that if this is what was happening, we would see other instances of this problem showing up as null pointer or garbage pointer dereferences, for example when the request structure was not re-used. It looks like we actually do run into that situation in other reports. This patch moves the BUG_ON(test_bit(REQ_ATOM_COMPLETE, &req->atomic_flags)); from blk_add_timer to the only caller that could trip over it (blk_start_request). It then inverts the calls to blk_clear_rq_complete and blk_add_timer in blk_rq_timed_out to address the race. I've boot tested this patch, but nothing more. Signed-off-by: Jeff Moyer Acked-by: Hannes Reinecke Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 74dfb60defc4debf23751a16e4b7253d10e72274 Author: Roger Tseng Date: Tue Nov 12 15:11:40 2013 -0800 drivers/memstick/core/ms_block.c: fix unreachable state in h_msb_read_page() commit a0e5a12fd18d47aa87a7a8c60ca5bc422b136564 upstream. In h_msb_read_page() in ms_block.c, flow never reaches case MSB_RP_RECIVE_STATUS_REG. This causes error when MEMSTICK_INT_ERR is encountered and status error bits are going to be examined, but the status will never be copied back. Fix it by transitioning to MSB_RP_RECIVE_STATUS_REG right after MSB_RP_SEND_READ_STATUS_REG. Signed-off-by: Roger Tseng Acked-by: Maxim Levitsky Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 425a81974e54b610d3c1ab174e3ae3a08e3aeb28 Author: Guenter Roeck Date: Fri Nov 15 10:40:38 2013 +0100 hwmon: (lm90) Fix max6696 alarm handling commit e41fae2b1ed8c78283d73651cd65be0228c0dd1c upstream. Bit 2 of status register 2 on MAX6696 (external diode 2 open) sets ALERT; the bit thus has to be listed in alert_alarms. Also display a message in the alert handler if the condition is encountered. Even though not all overtemperature conditions cause ALERT to be set, we should not ignore them in the alert handler. Display messages for all out-of-range conditions. Reported-by: Jean Delvare Signed-off-by: Guenter Roeck Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 696e67db38df4f921dd9ccfa78904a250b1b85ae Author: Christoffer Dall Date: Fri Nov 15 13:14:12 2013 -0800 arm/arm64: KVM: Fix hyp mappings of vmalloc regions commit 40c2729bab48e2832b17c1fa8af9db60e776131b upstream. Using virt_to_phys on percpu mappings is horribly wrong as it may be backed by vmalloc. Introduce kvm_kaddr_to_phys which translates both types of valid kernel addresses to the corresponding physical address. At the same time resolves a typing issue where we were storing the physical address as a 32 bit unsigned long (on arm), truncating the physical address for addresses above the 4GB limit. This caused breakage on Keystone. Reported-by: Santosh Shilimkar Tested-by: Santosh Shilimkar Signed-off-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Greg Kroah-Hartman commit 6492d85c63e0e59f8c6c42ad8cc7eee2f0bee9df Author: Greg Edwards Date: Mon Nov 4 09:08:12 2013 -0700 KVM: IOMMU: hva align mapping page size commit 27ef63c7e97d1e5dddd85051c03f8d44cc887f34 upstream. When determining the page size we could use to map with the IOMMU, the page size should also be aligned with the hva, not just the gfn. The gfn may not reflect the real alignment within the hugetlbfs file. Most of the time, this works fine. However, if the hugetlbfs file is backed by non-contiguous huge pages, a multi-huge page memslot starts at an unaligned offset within the hugetlbfs file, and the gfn is aligned with respect to the huge page size, kvm_host_page_size() will return the huge page size and we will use that to map with the IOMMU. When we later unpin that same memslot, the IOMMU returns the unmap size as the huge page size, and we happily unpin that many pfns in monotonically increasing order, not realizing we are spanning non-contiguous huge pages and partially unpin the wrong huge page. Ensure the IOMMU mapping page size is aligned with the hva corresponding to the gfn, which does reflect the alignment within the hugetlbfs file. Reviewed-by: Marcelo Tosatti Signed-off-by: Greg Edwards Signed-off-by: Gleb Natapov Signed-off-by: Greg Kroah-Hartman commit 26146207c9fc024ff6752225d271ec47ccd35dfc Author: Kevin Hao Date: Wed Oct 23 20:58:16 2013 +0800 ftrace/x86: skip over the breakpoint for ftrace caller commit ab4ead02ec235d706d0611d8741964628291237e upstream. In commit 8a4d0a687a59 "ftrace: Use breakpoint method to update ftrace caller", we choose to use breakpoint method to update the ftrace caller. But we also need to skip over the breakpoint in function ftrace_int3_handler() for them. Otherwise weird things would happen. Signed-off-by: Kevin Hao Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 94152e4a439841a2b112ae234f98625e4fe5da47 Author: Paolo Bonzini Date: Thu Oct 31 23:05:24 2013 +0100 KVM: x86: fix emulation of "movzbl %bpl, %eax" commit daf727225b8abfdfe424716abac3d15a3ac5626a upstream. When I was looking at RHEL5.9's failure to start with unrestricted_guest=0/emulate_invalid_guest_state=1, I got it working with a slightly older tree than kvm.git. I now debugged the remaining failure, which was introduced by commit 660696d1 (KVM: X86 emulator: fix source operand decoding for 8bit mov[zs]x instructions, 2013-04-24) introduced a similar mis-emulation to the one in commit 8acb4207 (KVM: fix sil/dil/bpl/spl in the mod/rm fields, 2013-05-30). The incorrect decoding occurs in 8-bit movzx/movsx instructions whose 8-bit operand is sil/dil/bpl/spl. Needless to say, "movzbl %bpl, %eax" does occur in RHEL5.9's decompression prolog, just a handful of instructions before finally giving control to the decompressed vmlinux and getting out of the invalid guest state. Because OpMem8 bypasses decode_modrm, the same handling of the REX prefix must be applied to OpMem8. Reported-by: Michele Baldessari Cc: Gleb Natapov Signed-off-by: Paolo Bonzini Signed-off-by: Gleb Natapov Signed-off-by: Greg Kroah-Hartman commit 80b0114bac7c5552aab28100545f9cf12b477de4 Author: Thomas Renninger Date: Tue Nov 12 17:39:43 2013 +0100 x86/microcode/amd: Tone down printk(), don't treat a missing firmware file as an error commit 11f918d3e2d3861b6931e97b3aa778e4984935aa upstream. Do it the same way as done in microcode_intel.c: use pr_debug() for missing firmware files. There seem to be CPUs out there for which no microcode update has been submitted to kernel-firmware repo yet resulting in scary sounding error messages in dmesg: microcode: failed to load file amd-ucode/microcode_amd_fam16h.bin Signed-off-by: Thomas Renninger Acked-by: Borislav Petkov Link: http://lkml.kernel.org/r/1384274383-43510-1-git-send-email-trenn@suse.de Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 4c6df961af41624b0a68d48ca54538359df11603 Author: Fenghua Yu Date: Wed Oct 23 18:30:12 2013 -0700 x86/apic: Disable I/O APIC before shutdown of the local APIC commit 522e66464467543c0d88d023336eec4df03ad40b upstream. In reboot and crash path, when we shut down the local APIC, the I/O APIC is still active. This may cause issues because external interrupts can still come in and disturb the local APIC during shutdown process. To quiet external interrupts, disable I/O APIC before shutdown local APIC. Signed-off-by: Fenghua Yu Link: http://lkml.kernel.org/r/1382578212-4677-1-git-send-email-fenghua.yu@intel.com [ I suppose the 'issue' is a hang during shutdown. It's a fine change nevertheless. ] Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 5ec2a1557ba618a3464b304a8ab28a883a55f0bd Author: J. Bruce Fields Date: Tue Nov 19 17:32:43 2013 -0500 nfsd4: fix xdr decoding of large non-write compounds commit 365da4adebb1c012febf81019ad3dc5bb52e2a13 upstream. This fixes a regression from 247500820ebd02ad87525db5d9b199e5b66f6636 "nfsd4: fix decoding of compounds across page boundaries". The previous code was correct: argp->pagelist is initialized in nfs4svc_deocde_compoundargs to rqstp->rq_arg.pages, and is therefore a pointer to the page *after* the page we are currently decoding. The reason that patch nevertheless fixed a problem with decoding compounds containing write was a bug in the write decoding introduced by 5a80a54d21c96590d013378d8c5f65f879451ab4 "nfsd4: reorganize write decoding", after which write decoding no longer adhered to the rule that argp->pagelist point to the next page. Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 479484f703bf1defc7ba73d7a5f37fc330e38c51 Author: Christoph Hellwig Date: Mon Nov 18 05:07:47 2013 -0800 nfsd: make sure to balance get/put_write_access commit 987da4791052fa298b7cfcde4dea9f6f2bbc786b upstream. Use a straight goto error label style in nfsd_setattr to make sure we always do the put_write_access call after we got it earlier. Note that the we have been failing to do that in the case nfsd_break_lease() returns an error, a bug introduced into 2.6.38 with 6a76bebefe15d9a08864f824d7f8d5beaf37c997 "nfsd4: break lease on nfsd setattr". Signed-off-by: Christoph Hellwig Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit fc2d834aab8bd8b318aeb3c0e2842c49a7755f0d Author: Christoph Hellwig Date: Mon Nov 18 05:07:30 2013 -0800 nfsd: split up nfsd_setattr commit 818e5a22e907fbae75e9c1fd78233baec9fa64b6 upstream. Split out two helpers to make the code more readable and easier to verify for correctness. Signed-off-by: Christoph Hellwig Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 64eed7896942ff792403b21bba981a3c3d725c52 Author: Jeff Layton Date: Wed Nov 13 09:08:21 2013 -0500 nfs: don't retry detect_trunking with RPC_AUTH_UNIX more than once commit 6d769f1e1420179d1f83cf1a9cdc585b46c28545 upstream. Currently, when we try to mount and get back NFS4ERR_CLID_IN_USE or NFS4ERR_WRONGSEC, we create a new rpc_clnt and then try the call again. There is no guarantee that doing so will work however, so we can end up retrying the call in an infinite loop. Worse yet, we create the new client using rpc_clone_client_set_auth, which creates the new client as a child of the old one. Thus, we can end up with a *very* long lineage of rpc_clnts. When we go to put all of the references to them, we can end up with a long call chain that can smash the stack as each rpc_free_client() call can recurse back into itself. This patch fixes this by simply ensuring that the SETCLIENTID call will only be retried in this situation if the last attempt did not use RPC_AUTH_UNIX. Note too that with this change, we don't need the (i > 2) check in the -EACCES case since we now have a more reliable test as to whether we should reattempt. Cc: Chuck Lever Tested-by/Acked-by: Weston Andros Adamson Signed-off-by: Jeff Layton Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit e976eb62851273adb60d2a5d0adb3ecd71c48f4f Author: J. Bruce Fields Date: Fri Nov 1 10:42:15 2013 -0400 nfsd4: fix discarded security labels on setattr commit 3378b7f40d79930f0f447a164c7e8fcbe4480e40 upstream. Security labels in setattr calls are currently ignored because we forget to set label->len. Reported-by: Jeff Layton Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 35775137cf15c3c03ce7b3e0ff2b19749a2fb0b5 Author: J. Bruce Fields Date: Fri Sep 13 11:08:45 2013 -0400 nfsd: return better errors to exportfs commit 427d6c6646d868fbd3094e7e2e1644d480cd9204 upstream. Someone noticed exportfs happily accepted exports that would later be rejected when mountd tried to give them to the kernel. Fix this. This is a regression from 4c1e1b34d5c800ad3ac9a7e2805b0bea70ad2278 "nfsd: Store ex_anon_uid and ex_anon_gid as kuids and kgids". Cc: "Eric W. Biederman" Reported-by: Yin.JianHong Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit af1fe0fe8b5706d69d211224a934cf72964eb1f8 Author: Trond Myklebust Date: Fri Nov 1 12:42:25 2013 -0400 NFS: Fix a missing initialisation when reading the SELinux label commit fcb63a9bd8427fc584229048ea14f1453dc9a2e1 upstream. Ensure that _nfs4_do_get_security_label() also initialises the SEQUENCE call correctly, by having it call into nfs4_call_sync(). Reported-by: Jeff Layton Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 31789c060834de6b159491f67d7c6bd9087acdb0 Author: Jeff Layton Date: Fri Nov 1 10:49:32 2013 -0400 nfs: fix oops when trying to set SELinux label commit 12207f69b3ef4d6eea6a5568281e49f671977ab1 upstream. Chao reported the following oops when testing labeled NFS: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [] nfs4_xdr_enc_setattr+0x43/0x110 [nfsv4] PGD 277bbd067 PUD 2777ea067 PMD 0 Oops: 0000 [#1] SMP Modules linked in: rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache sg coretemp kvm_intel kvm crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel lrw gf128mul iTCO_wdt glue_helper ablk_helper cryptd iTCO_vendor_support bnx2 pcspkr serio_raw i7core_edac cdc_ether microcode usbnet edac_core mii lpc_ich i2c_i801 mfd_core shpchp ioatdma dca acpi_cpufreq mperf nfsd auth_rpcgss nfs_acl lockd sunrpc xfs libcrc32c sr_mod sd_mod cdrom crc_t10dif mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit drm_kms_helper ata_generic ttm pata_acpi drm ata_piix libata megaraid_sas i2c_core dm_mirror dm_region_hash dm_log dm_mod CPU: 4 PID: 25657 Comm: chcon Not tainted 3.10.0-33.el7.x86_64 #1 Hardware name: IBM System x3550 M3 -[7944OEJ]-/90Y4784 , BIOS -[D6E150CUS-1.11]- 02/08/2011 task: ffff880178397220 ti: ffff8801595d2000 task.ti: ffff8801595d2000 RIP: 0010:[] [] nfs4_xdr_enc_setattr+0x43/0x110 [nfsv4] RSP: 0018:ffff8801595d3888 EFLAGS: 00010296 RAX: 0000000000000000 RBX: ffff8801595d3b30 RCX: 0000000000000b4c RDX: ffff8801595d3b30 RSI: ffff8801595d38e0 RDI: ffff880278b6ec00 RBP: ffff8801595d38c8 R08: ffff8801595d3b30 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801595d38e0 R13: ffff880277a4a780 R14: ffffffffa05686c0 R15: ffff8802765f206c FS: 00007f2c68486800(0000) GS:ffff88027fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000027651a000 CR4: 00000000000007e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Stack: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 ffff880277865800 ffff880278b6ec00 ffff880277a4a780 ffff8801595d3948 ffffffffa02ad926 ffff8801595d3b30 ffff8802765f206c Call Trace: [] rpcauth_wrap_req+0x86/0xd0 [sunrpc] [] ? call_connect+0xb0/0xb0 [sunrpc] [] ? call_connect+0xb0/0xb0 [sunrpc] [] call_transmit+0x18b/0x290 [sunrpc] [] ? call_connect+0xb0/0xb0 [sunrpc] [] __rpc_execute+0x84/0x400 [sunrpc] [] rpc_execute+0x5e/0xa0 [sunrpc] [] rpc_run_task+0x70/0x90 [sunrpc] [] rpc_call_sync+0x43/0xa0 [sunrpc] [] _nfs4_do_set_security_label+0x11d/0x170 [nfsv4] [] nfs4_set_security_label.isra.69+0xf1/0x1d0 [nfsv4] [] ? avc_alloc_node+0x24/0x125 [] ? avc_compute_av+0x1a3/0x1b5 [] nfs4_xattr_set_nfs4_label+0x3b/0x50 [nfsv4] [] generic_setxattr+0x62/0x80 [] __vfs_setxattr_noperm+0x63/0x1b0 [] vfs_setxattr+0xb5/0xc0 [] setxattr+0x12e/0x1c0 [] ? final_putname+0x22/0x50 [] ? putname+0x2b/0x40 [] ? user_path_at_empty+0x5f/0x90 [] ? __sb_start_write+0x49/0x100 [] SyS_lsetxattr+0x8f/0xd0 [] system_call_fastpath+0x16/0x1b Code: 48 8b 02 48 c7 45 c0 00 00 00 00 48 c7 45 c8 00 00 00 00 48 c7 45 d0 00 00 00 00 48 c7 45 d8 00 00 00 00 48 c7 45 e0 00 00 00 00 <48> 8b 00 48 8b 00 48 85 c0 0f 84 ae 00 00 00 48 8b 80 b8 03 00 RIP [] nfs4_xdr_enc_setattr+0x43/0x110 [nfsv4] RSP CR2: 0000000000000000 The problem is that _nfs4_do_set_security_label calls rpc_call_sync() directly which fails to do any setup of the SEQUENCE call. Have it use nfs4_call_sync() instead which does the right thing. While we're at it change the name of "args" to "arg" to better match the pattern in _nfs4_do_setattr. Reported-by: Chao Ye Cc: David Quigley Signed-off-by: Jeff Layton Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 611774299106c972d60c98d99563b8682da4381b Author: Jeff Layton Date: Thu Oct 31 13:03:04 2013 -0400 nfs: fix inverted test for delegation in nfs4_reclaim_open_state commit 1acd1c301f4faae80f4d2c7bbd9a4553b131c0e3 upstream. commit 6686390bab6a0e0 (NFS: remove incorrect "Lock reclaim failed!" warning.) added a test for a delegation before checking to see if any reclaimed locks failed. The test however is backward and is only doing that check when a delegation is held instead of when one isn't. Cc: NeilBrown Signed-off-by: Jeff Layton Fixes: 6686390bab6a: NFS: remove incorrect "Lock reclaim failed!" warning. Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit cdebf3915aa50f87f43da89415de6543cfea5f66 Author: Trond Myklebust Date: Mon Oct 28 14:57:12 2013 -0400 NFSv4: Fix state reference counting in _nfs4_opendata_reclaim_to_nfs4_state commit d49f042aeec99c5f87160bb52dd52088b1051311 upstream. Currently, if the call to nfs_refresh_inode fails, then we end up leaking a reference count, due to the call to nfs4_get_open_state. While we're at it, replace nfs4_get_open_state with a simple call to atomic_inc(); there is no need to do a full lookup of the struct nfs_state since it is passed as an argument in the struct nfs4_opendata, and is already assigned to the variable 'state'. Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 502bb2cc3514ae5e0785ea18788073835c158ddd Author: Weston Andros Adamson Date: Mon Oct 21 13:10:13 2013 -0400 NFSv4: don't reprocess cached open CLAIM_PREVIOUS commit d2bfda2e7aa036f90ccea610a657064b1e267913 upstream. Cached opens have already been handled by _nfs4_opendata_reclaim_to_nfs4_state and can safely skip being reprocessed, but must still call update_open_stateid to make sure that all active fmodes are recovered. Signed-off-by: Weston Andros Adamson Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 941e4b799c8b899c9267849c0ccba8b318dbcdc2 Author: Weston Andros Adamson Date: Mon Oct 21 13:10:11 2013 -0400 NFSv4: don't fail on missing fattr in open recover commit a43ec98b72aae3e330f0673438f58316c3769b84 upstream. This is an unneeded check that could cause the client to fail to recover opens. Signed-off-by: Weston Andros Adamson Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 63b22a1776a945f278ff9f7105472fe54b6ee2f6 Author: Weston Andros Adamson Date: Mon Oct 21 13:10:10 2013 -0400 NFSv4: fix NULL dereference in open recover commit f494a6071d31e3294a3b51ad7a3684f983953f9f upstream. _nfs4_opendata_reclaim_to_nfs4_state doesn't expect to see a cached open CLAIM_PREVIOUS, but this can happen. An example is when there are RDWR openers and RDONLY openers on a delegation stateid. The recovery path will first try an open CLAIM_PREVIOUS for the RDWR openers, this marks the delegation as not needing RECLAIM anymore, so the open CLAIM_PREVIOUS for the RDONLY openers will not actually send an rpc. The NULL dereference is due to _nfs4_opendata_reclaim_to_nfs4_state returning PTR_ERR(rpc_status) when !rpc_done. When the open is cached, rpc_done == 0 and rpc_status == 0, thus _nfs4_opendata_reclaim_to_nfs4_state returns NULL - this is unexpected by callers of nfs4_opendata_to_nfs4_state(). This can be reproduced easily by opening the same file two times on an NFSv4.0 mount with delegations enabled, once as RDWR and once as RDONLY then sleeping for a long time. While the files are held open, kick off state recovery and this NULL dereference will be hit every time. An example OOPS: [ 65.003602] BUG: unable to handle kernel NULL pointer dereference at 00000000 00000030 [ 65.005312] IP: [] __nfs4_close+0x1e/0x160 [nfsv4] [ 65.006820] PGD 7b0ea067 PUD 791ff067 PMD 0 [ 65.008075] Oops: 0000 [#1] SMP [ 65.008802] Modules linked in: rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache snd_ens1371 gameport nfsd snd_rawmidi snd_ac97_codec ac97_bus btusb snd_seq snd _seq_device snd_pcm ppdev bluetooth auth_rpcgss coretemp snd_page_alloc crc32_pc lmul crc32c_intel ghash_clmulni_intel microcode rfkill nfs_acl vmw_balloon serio _raw snd_timer lockd parport_pc e1000 snd soundcore parport i2c_piix4 shpchp vmw _vmci sunrpc ata_generic mperf pata_acpi mptspi vmwgfx ttm scsi_transport_spi dr m mptscsih mptbase i2c_core [ 65.018684] CPU: 0 PID: 473 Comm: 192.168.10.85-m Not tainted 3.11.2-201.fc19 .x86_64 #1 [ 65.020113] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013 [ 65.022012] task: ffff88003707e320 ti: ffff88007b906000 task.ti: ffff88007b906000 [ 65.023414] RIP: 0010:[] [] __nfs4_close+0x1e/0x160 [nfsv4] [ 65.025079] RSP: 0018:ffff88007b907d10 EFLAGS: 00010246 [ 65.026042] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 65.027321] RDX: 0000000000000050 RSI: 0000000000000001 RDI: 0000000000000000 [ 65.028691] RBP: ffff88007b907d38 R08: 0000000000016f60 R09: 0000000000000000 [ 65.029990] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [ 65.031295] R13: 0000000000000050 R14: 0000000000000000 R15: 0000000000000001 [ 65.032527] FS: 0000000000000000(0000) GS:ffff88007f600000(0000) knlGS:0000000000000000 [ 65.033981] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 65.035177] CR2: 0000000000000030 CR3: 000000007b27f000 CR4: 00000000000407f0 [ 65.036568] Stack: [ 65.037011] 0000000000000000 0000000000000001 ffff88007b907d90 ffff88007a880220 [ 65.038472] ffff88007b768de8 ffff88007b907d48 ffffffffa037e4a5 ffff88007b907d80 [ 65.039935] ffffffffa036a6c8 ffff880037020e40 ffff88007a880000 ffff880037020e40 [ 65.041468] Call Trace: [ 65.042050] [] nfs4_close_state+0x15/0x20 [nfsv4] [ 65.043209] [] nfs4_open_recover_helper+0x148/0x1f0 [nfsv4] [ 65.044529] [] nfs4_open_recover+0x116/0x150 [nfsv4] [ 65.045730] [] nfs4_open_reclaim+0xad/0x150 [nfsv4] [ 65.046905] [] nfs4_do_reclaim+0x149/0x5f0 [nfsv4] [ 65.048071] [] nfs4_run_state_manager+0x3bc/0x670 [nfsv4] [ 65.049436] [] ? nfs4_do_reclaim+0x5f0/0x5f0 [nfsv4] [ 65.050686] [] ? nfs4_do_reclaim+0x5f0/0x5f0 [nfsv4] [ 65.051943] [] kthread+0xc0/0xd0 [ 65.052831] [] ? insert_kthread_work+0x40/0x40 [ 65.054697] [] ret_from_fork+0x7c/0xb0 [ 65.056396] [] ? insert_kthread_work+0x40/0x40 [ 65.058208] Code: 5c 41 5d 5d c3 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 48 89 e5 41 57 41 89 f7 41 56 41 89 ce 41 55 41 89 d5 41 54 53 48 89 fb <4c> 8b 67 30 f0 41 ff 44 24 44 49 8d 7c 24 40 e8 0e 0a 2d e1 44 [ 65.065225] RIP [] __nfs4_close+0x1e/0x160 [nfsv4] [ 65.067175] RSP [ 65.068570] CR2: 0000000000000030 [ 65.070098] ---[ end trace 0d1fe4f5c7dd6f8b ]--- Signed-off-by: Weston Andros Adamson Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 2bd5435c148aa5f70ae6bbc2a5d0592f222cf359 Author: Trond Myklebust Date: Tue Oct 1 14:24:58 2013 -0400 NFSv4: Fix a use-after-free situation in _nfs4_proc_getlk() commit a6f951ddbdfb7bd87d31a44f61abe202ed6ce57f upstream. In nfs4_proc_getlk(), when some error causes a retry of the call to _nfs4_proc_getlk(), we can end up with Oopses of the form BUG: unable to handle kernel NULL pointer dereference at 0000000000000134 IP: [] _raw_spin_lock+0xe/0x30 Call Trace: [] _atomic_dec_and_lock+0x4d/0x70 [] nfs4_put_lock_state+0x32/0xb0 [nfsv4] [] nfs4_fl_release_lock+0x15/0x20 [nfsv4] [] _nfs4_proc_getlk.isra.40+0x146/0x170 [nfsv4] [] nfs4_proc_lock+0x399/0x5a0 [nfsv4] The problem is that we don't clear the request->fl_ops after the first try and so when we retry, nfs4_set_lock_state() exits early without setting the lock stateid. Regression introduced by commit 70cc6487a4e08b8698c0e2ec935fb48d10490162 (locks: make ->lock release private data before returning in GETLK case) Reported-by: Weston Andros Adamson Reported-by: Jorge Mora Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit dbb9a46b2e72985f711ab234d0e3e62d6faf3535 Author: Trond Myklebust Date: Mon Nov 4 14:38:05 2013 -0500 NFSv4.2: Fix a mismatch between Linux labeled NFS and the NFSv4.2 spec commit f3f5a0f8cc40b942f4c0ae117df82eeb65f07d4d upstream. In the spec, the security label attribute id is '80', which means that it should be bit number 80-64 == 16 in the 3rd word of the bitmap. Fixes: 4488cc96c581: NFS: Add NFSv4.2 protocol constants Cc: J. Bruce Fields Cc: Steve Dickson Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit c14049500ecb5ba0a5c3325d502928b753beaf17 Author: Takashi Iwai Date: Fri Nov 22 08:06:36 2013 +0100 ALSA: hda - Provide missing pin configs for VAIO with ALC260 commit d08c5ef2a039393eaf2ab2152db5f07790fa0f40 upstream. Some models (or maybe depending on BIOS version) of Sony VAIO with ALC260 give no proper pin configurations as default, resulting in the non-working speaker, etc. Just provide the whole pin configurations via a fixup. Reported-by: Matthew Markus Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8128fd72d47d271dac6165e7cc0b7dedbde6c5c0 Author: David Henningsson Date: Thu Nov 21 14:12:59 2013 +0100 ALSA: hda - Add headset quirk for Dell Inspiron 3135 commit b8362e70cbbb397db50939bc4c7c78dc3246c3eb upstream. BugLink: https://bugs.launchpad.net/bugs/1253636 Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a26f92e74c8abfe001910a990e013e54907a20b8 Author: Takashi Iwai Date: Thu Nov 21 09:12:52 2013 +0100 ALSA: hda - Fix the headphone jack detection on Sony VAIO TX commit 0f5a5b8515472a0219768423226b58228001e3d5 upstream. BIOS sets MISC_NO_PRESENCE bit wrongly to the pin config on NID 0x0f. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 030d2a71328b25939ec5e31c5180b5f95dc8fe54 Author: Takashi Iwai Date: Wed Nov 20 12:15:07 2013 +0100 ALSA: hda - Fix unbalanced runtime PM notification at resume commit 0fc28fc030a85aa3d6d14e9e9fca0c8237c9ffb5 upstream. When a codec is resumed, it keeps the power on while the resuming phase via hda_keep_power_on(), then turns down via snd_hda_power_down(). At that point, snd_hda_power_down() notifies the power down to the controller, and this may confuse the refcount if the codec was already powered up before the resume. In the end result, the controller goes to runtime suspend even before the codec is kicked off to the power save, and the communication stalls happens. The fix is to add the power-up notification together with hda_keep_power_on(), and clears the flag appropriately. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b2f7d06dcd2ef9bb082a7933a974fbe67f2dd842 Author: Takashi Iwai Date: Wed Nov 13 16:58:10 2013 +0100 ALSA: hda - Don't clear the power state at snd_hda_codec_reset() commit d183b4fc463489b6bbe05c99afa0257a6fe578eb upstream. snd_hda_codec_reset() is called either in resetting the whole setup at error paths or hwdep clear/reconfig sysfs triggers. But all of these don't assume that the power has to be off, rather they want to keep the power state unchanged (e.g. reconfig_codec() calls the power up/down by itself). Thus, unconditionally clearing the power state in snd_hda_codec_reset() leads to the inconsistency, confuses the further operation. This patch gets rid of the lines doing that bad thing. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a68211ac4b31c2a5c000ac467ae911d8ddd6a80b Author: Takashi Iwai Date: Wed Nov 13 09:39:08 2013 +0100 ALSA: hda - Don't turn off EAPD for headphone on Lenovo N100 commit 7a3e6107f94344e65c35bfe62de6c096a7b48965 upstream. The only EAPD on AD1986A is on NID 0x1b where usually the speaker. But this doesn't control only the speaker amp but may influence on all outputs, e.g. Lenovo N100 laptop seems to have this issue. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 08c06beb95993a5610876f81bd3eb15ec1ec448e Author: Takashi Iwai Date: Tue Nov 12 11:36:00 2013 +0100 ALSA: hda - Check keep_eapd_on before inv_eapd commit 468ac413045af1e0e4d1272291bed6878f248a69 upstream. We don't change the EAPD bit in set_pin_eapd() if keep_eapd_on flag is set by the codec driver and enable is false. But, we also apply the flipping of enable value according to inv_eapd flag in the same function, and this confused the former check, handled as if it's turned ON. The inverted EAPD check must be applied after keep_eapd_on check, instead. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 138f0e24eb928ce5a424768c05ba2aecb24068df Author: David Henningsson Date: Tue Nov 12 11:10:57 2013 +0100 ALSA: hda - Fix Line Out automute on Realtek multifunction jacks commit 5959a6bc1124211a359525d209005abc07b0197b upstream. In case there is both a multifunction headset jack and a Line Out jack, automuting was not working properly from the Line Out jack. This patch fixes that issue. BugLink: https://bugs.launchpad.net/bugs/1250377 Tested-by: Cyrus Lien Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 0841bb66703a905f31dd565d62576e815ac3c86f Author: Takashi Iwai Date: Thu Nov 7 07:29:30 2013 +0100 ALSA: hda - Add pincfg fixup for ASUS W5A commit 487a588d09db0d6508261867df208d8bdc718251 upstream. BIOS on ASUS W5A laptop with ALC880 codec doesn't provide any pin configurations, so we have to set up all pins manually. Reported-and-tested-by: nb Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 426f59d7c60bc13738cf18bdd63ffcc8dd3b43b9 Author: Takashi Iwai Date: Wed Nov 6 18:47:42 2013 +0100 ALSA: hda - Add support for CX20952 commit 8f42d7698751a45cd9f7134a5da49bc5b6206179 upstream. It's a superset of the existing CX2075x codecs, so we can reuse the existing parser code. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4e190c179a572cd41123136ea5814b889eae741b Author: David Henningsson Date: Wed Nov 6 10:50:44 2013 +0100 ALSA: hda - Make sure mute LEDs stay on during runtime suspend (Realtek) commit d5b6b65e75ce607c2734227524e11574317a1c1a upstream. Some HP machines with Realtek codecs have mute LEDs connected to VREF pins. However when these go into runtime suspend, the pin powers down and its pin control is disabled, thus disabling the LED too. This patch fixes that issue by making sure that the pin stays in D0 with correct pin control. BugLink: https://bugs.launchpad.net/bugs/1248465 Tested-by: Franz Hsieh Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit fb408e9ce79149364d74da1a128eeb4bcbe75015 Author: Takashi Iwai Date: Tue Nov 5 17:34:46 2013 +0100 ALSA: hda - Force buffer alignment for Haswell HDMI controllers commit 33499a15c2f7addc81695778753c2338b960eff7 upstream. Haswell HDMI audio controllers seem to get stuck when unaligned buffer size is used. Let's enable the buffer alignment for the corresponding entries. Since AZX_DCAPS_INTEL_PCH contains AZX_DCAPS_BUFSIZE that disables the buffer alignment forcibly, define AZX_DCAPS_INTEL_HASWELL and put the necessary AZX_DCAPS bits there. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60769 Reported-by: Alexander E. Patrakov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f6f4696d9e961214753b882d89d5d004c810ca81 Author: Takashi Iwai Date: Mon Nov 4 18:21:08 2013 +0100 ALSA: hda - Enable SPDIF for Acer TravelMate 6293 commit 24eff328f65c8ef352c90b6adb7c2f39eb94205d upstream. BIOS on Acer TravelMate 6293 doesn't set up the SPDIF output pin correctly as default, so enable it via a fixup entry. Reported-and-tested-by: Hagen Heiduck Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3dce9afa31a716edcc7012a0c4a40d18369fca82 Author: Takashi Iwai Date: Mon Nov 4 16:32:01 2013 +0100 ALSA: hda - Introduce the bitmask for excluding output volume commit a1114a8c681b0724d6ad905f53ff06aa756f5fb8 upstream. Add a bitmask to hda_gen_spec indicating NIDs to exclude from the possible volume controls. That is, when the bit is set, the NID corresponding to the bit won't be picked as an output volume control any longer. Basically this is just a band-aid for working around the issue found with CS4208 codec, where only the headphone pin has a volume AMP with different dB steps. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60811 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 204ed1297c6b91f75de720ae3ed6cb4ede61a24e Author: Kailang Yang Date: Thu Oct 24 11:35:18 2013 +0200 ALSA: hda - Add support of ALC255 codecs commit 1d04c9de5c76df113e4af7120feb53c628b5efcc upstream. It's just another variant of ALC269 & co. Signed-off-by: Kailang Yang Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f3179b8a638ddaf8366b54ce468fc85b012e1961 Author: Takashi Iwai Date: Tue Nov 12 08:06:20 2013 +0100 ALSA: msnd: Avoid duplicated driver name commit 092f9cd16aac7d054af1755c945f37c1b33399e6 upstream. msnd_pinnacle.c is used for both snd-msnd-pinnacle and snd-msnd-classic drivers, and both should have different driver names. Using the same driver name results in the sysfs warning for duplicated entries like kobject: 'msnd-pinnacle.7' (cec33408): kobject_release, parent (null) (delayed) kobject: 'msnd-pinnacle' (cecd4980): kobject_release, parent cf3ad9b0 (delayed) ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at fs/sysfs/dir.c:486 sysfs_warn_dup+0x7d/0xa0() sysfs: cannot create duplicate filename '/bus/isa/drivers/msnd-pinnacle' ...... Reported-by: Fengguang Wu Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b88839271031be0b97ad16c96455daaf35de0f34 Author: Takashi Iwai Date: Fri Nov 8 12:50:31 2013 +0100 ALSA: hda - Apply MacBook fixups for CS4208 correctly commit 885845d78551be7bf8570f6283df8b7a7797c4d1 upstream. The commit [8fe7b65ab465: ALSA: hda - Apply GPIO setup for MacBooks with CS4208] added a fixup entry matching with the vendor id 0x106b. This broke the fixups for previous MBA6,1 and 6,2, since the PCI SSID vendor id matches before evaluating the codec SSIDs. We had a similar issue on Mac with Sigmatel codecs, and solve this problem again similarly, by introducing a skeleton entry matching with the all MacBooks, then remap to the right one. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64401 Fixes: 8fe7b65ab465 ('ALSA: hda - Apply GPIO setup for MacBooks with CS4208') Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 74df56e8d21605d947ac84742de2e5cfa9f8ad6f Author: Takashi Iwai Date: Tue Nov 5 10:31:07 2013 +0100 ALSA: hda - Apply GPIO setup for MacBooks with CS4208 commit 8fe7b65ab4656e5db466a7d98b1fd48ff83b2c64 upstream. Apply the existing GPIO0 fixup as default for MacBooks with CS4208 codec. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64401 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d02c722ec36f8e107fce15e30acf4d152b15c864 Author: Takashi Iwai Date: Thu Nov 14 15:45:12 2013 +0100 ALSA: pcsp: Fix the order of input device unregistration commit 6408eac2665955343cd0e4bcd7d6237ce39611ed upstream. The current code may access to the already freed object. The input device must be accessed and unregistered before freeing the top level sound object. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8e04b5d8e4204a216a5674dc316ca9fa0800fd93 Author: Vinod Koul Date: Thu Nov 7 10:08:22 2013 +0100 ALSA: compress: fix drain calls blocking other compress functions (v6) commit f44f2a5417b2968a8724b352cc0b2545a6bcb1f4 upstream. The drain and drain_notify callback were blocked by low level driver until the draining was complete. Due to this being invoked with big fat mutex held, others ops like reading timestamp, calling pause, drop were blocked. So to fix this we add a new snd_compr_drain_notify() API. This would be required to be invoked by low level driver when drain or partial drain has been completed by the DSP. Thus we make the drain and partial_drain callback as non blocking and driver returns immediately after notifying DSP. The waiting is done while releasing the lock so that other ops can go ahead. [ The commit 917f4b5cba78 was wrongly applied from the preliminary patch. This commit corrects to the final version. Sorry for inconvenience! -- tiwai ] Signed-off-by: Vinod Koul Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7c276704b729d8d063620c836762f204e191aaf0 Author: Vinod Koul Date: Thu Oct 24 16:37:31 2013 +0530 ALSA: compress: fix drain calls blocking other compress functions commit 917f4b5cba78980a527098a910d94139d3e82c8d upstream. The drain and drain_notify callback were blocked by low level driver untill the draining was complete. Due to this being invoked with big fat mutex held, others ops like reading timestamp, calling pause, drop were blocked. So to fix this we add a new snd_compr_drain_notify() API. This would be required to be invoked by low level driver when drain or partial drain has been completed by the DSP. Thus we make the drain and partial_drain callback as non blocking and driver returns immediately after notifying DSP. The waiting is done while relasing the lock so that other ops can go ahead. Signed-off-by: Vinod Koul Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit baf1abbaada81be48054b523f9c5286b9f4ae865 Author: Takashi Iwai Date: Mon Oct 28 11:24:23 2013 +0100 ALSA: 6fire: Fix probe of multiple cards commit 9b389a8a022110b4bc055a19b888283544d9eba6 upstream. The probe code of snd-usb-6fire driver overrides the devices[] pointer wrongly without checking whether it's already occupied or not. This would screw up the device disconnection later. Spotted by coverity CID 141423. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9d4dd888b4b5799ecadfb0d8c9adda7a76779806 Author: Kees Cook Date: Tue Nov 12 15:11:17 2013 -0800 exec/ptrace: fix get_dumpable() incorrect tests commit d049f74f2dbe71354d43d393ac3a188947811348 upstream. The get_dumpable() return value is not boolean. Most users of the function actually want to be testing for non-SUID_DUMP_USER(1) rather than SUID_DUMP_DISABLE(0). The SUID_DUMP_ROOT(2) is also considered a protected state. Almost all places did this correctly, excepting the two places fixed in this patch. Wrong logic: if (dumpable == SUID_DUMP_DISABLE) { /* be protective */ } or if (dumpable == 0) { /* be protective */ } or if (!dumpable) { /* be protective */ } Correct logic: if (dumpable != SUID_DUMP_USER) { /* be protective */ } or if (dumpable != 1) { /* be protective */ } Without this patch, if the system had set the sysctl fs/suid_dumpable=2, a user was able to ptrace attach to processes that had dropped privileges to that user. (This may have been partially mitigated if Yama was enabled.) The macros have been moved into the file that declares get/set_dumpable(), which means things like the ia64 code can see them too. CVE-2013-2929 Reported-by: Vasily Kulikov Signed-off-by: Kees Cook Cc: "Luck, Tony" Cc: Oleg Nesterov Cc: "Eric W. Biederman" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 882f835f797e8912c0d927d1ba66498c76464724 Author: Mimi Zohar Date: Thu Oct 17 07:34:02 2013 -0400 Revert "ima: policy for RAMFS" commit 08de59eb144d7c41351a467442f898d720f0f15f upstream. This reverts commit 4c2c392763a682354fac65b6a569adec4e4b5387. Everything in the initramfs should be measured and appraised, but until the initramfs has extended attribute support, at least measured. Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit 4e2f1a05ed78982b300bd4c24d9be3469069a06c Author: Hans de Goede Date: Sat Sep 28 15:25:39 2013 +0200 Bluetooth: revert: "Bluetooth: Add missing reset_resume dev_pm_ops" commit b1a8014471b01dd862de9f91bbbff1296afac42d upstream. Many btusb devices have 2 modes, a hid mode and a bluetooth hci mode. These devices default to hid mode for BIOS use. This means that after having been reset they will revert to HID mode, and are no longer usable as a HCI. Therefor it is a very bad idea to just blindly make reset_resume point to the regular resume handler. Note that the btusb driver has no clue how to switch these devices from hid to hci mode, this is done in userspace through udev rules, so the proper way to deal with this is to not have a reset-resume handler and instead let the usb-system re-enumerate the device, and re-run the udev rules. I must also note, that the commit message for the commit causing this problem has a very weak motivation for the change: "Add missing reset_resume dev_pm_ops. Missing reset_resume results in the following message after power management device test. This change sets reset_resume to btusb_resume(). [ 2506.936134] btusb 1-1.5:1.0: no reset_resume for driver btusb? [ 2506.936137] btusb 1-1.5:1.1: no reset_resume for driver btusb?" Making a change solely to silence a warning while also changing important behavior (normal resume handling versus re-enumeration) requires a commit message with a proper explanation why it is safe to do so, which clearly lacks here, and unsurprisingly it turns out to not be safe to make this change. Reverting the commit in question fixes bt no longer working on my Dell E6430 after a suspend/resume, and I believe it likely also fixes the following bugs: https://bugzilla.redhat.com/show_bug.cgi?id=988481 https://bugzilla.redhat.com/show_bug.cgi?id=1010649 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1213239 This reverts commit 502f769662978a2fe99d0caed5e53e3006107381. Cc: Shuah Khan Cc: Gustavo Padovan Signed-off-by: Hans de Goede Signed-off-by: Gustavo Padovan Signed-off-by: Greg Kroah-Hartman commit 6d14a2d03eb0be6b9a5e0cbb380b1960caddc315 Author: Stanislaw Gruszka Date: Thu Oct 31 11:23:57 2013 +0100 rt2x00: fix HT TX descriptor settings regression commit 3d8bfe141be8e5c21261fc63da8e7964d44f2645 upstream. Since: commit 36323f817af0376c78612cfdab714b0feb05fea5 Author: Thomas Huehn Date: Mon Jul 23 21:33:42 2012 +0200 mac80211: move TX station pointer and restructure TX we do not pass sta pointer to rt2x00queue_create_tx_descriptor_ht(), hence we do not correctly set station WCID and AMPDU density parameters. Signed-off-by: Stanislaw Gruszka Acked-by: Gertjan van Wingerde Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 0a5ca4781d76e01b026749f9d2478eebc75db687 Author: Gabor Juhos Date: Thu Oct 3 20:00:40 2013 +0200 rt2x00: rt2800lib: fix VGC adjustment for RT5592 commit 0beb1bbf19c72f17809e42b8f33522a55c2cc18c upstream. In commit 3d81535ea5940446510a8a5cee1c6ad23c90c753 (rt2800: 5592: add chip specific vgc calculations) the rt2800_link_tuner function has been modified to adjust VGC level for the RT5592 chipset. On the RT5592 chipset, the VGC level must be adjusted only if rssi is greater than -65. However the current code adjusts the VGC value by 0x10 regardless of the actual chipset if the rssi value is between -80 and -65. Fix the broken behaviour by reordering the if-else statements. Signed-off-by: Gabor Juhos Acked-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 6394ca8c095a308a2cc76c4e9536b1b9663ddb9f Author: Stanislaw Gruszka Date: Tue Oct 15 14:31:12 2013 +0200 rt2x00: check if device is still available on rt2x00mac_flush() commit 5671ab05cf2a579218985ef56595387932d78ee4 upstream. Fix random kernel panic with below messages when remove dongle. [ 2212.355447] BUG: unable to handle kernel NULL pointer dereference at 0000000000000250 [ 2212.355527] IP: [] rt2x00usb_kick_tx_entry+0x12/0x160 [rt2x00usb] [ 2212.355599] PGD 0 [ 2212.355626] Oops: 0000 [#1] SMP [ 2212.355664] Modules linked in: rt2800usb rt2x00usb rt2800lib crc_ccitt rt2x00lib mac80211 cfg80211 tun arc4 fuse rfcomm bnep snd_hda_codec_realtek snd_hda_intel snd_hda_codec btusb uvcvideo bluetooth snd_hwdep x86_pkg_temp_thermal snd_seq coretemp aesni_intel aes_x86_64 snd_seq_device glue_helper snd_pcm ablk_helper videobuf2_vmalloc sdhci_pci videobuf2_memops videobuf2_core sdhci videodev mmc_core serio_raw snd_page_alloc microcode i2c_i801 snd_timer hid_multitouch thinkpad_acpi lpc_ich mfd_core snd tpm_tis wmi tpm tpm_bios soundcore acpi_cpufreq i915 i2c_algo_bit drm_kms_helper drm i2c_core video [last unloaded: cfg80211] [ 2212.356224] CPU: 0 PID: 34 Comm: khubd Not tainted 3.12.0-rc3-wl+ #3 [ 2212.356268] Hardware name: LENOVO 3444CUU/3444CUU, BIOS G6ET93WW (2.53 ) 02/04/2013 [ 2212.356319] task: ffff880212f687c0 ti: ffff880212f66000 task.ti: ffff880212f66000 [ 2212.356392] RIP: 0010:[] [] rt2x00usb_kick_tx_entry+0x12/0x160 [rt2x00usb] [ 2212.356481] RSP: 0018:ffff880212f67750 EFLAGS: 00010202 [ 2212.356519] RAX: 000000000000000c RBX: 000000000000000c RCX: 0000000000000293 [ 2212.356568] RDX: ffff8801f4dc219a RSI: 0000000000000000 RDI: 0000000000000240 [ 2212.356617] RBP: ffff880212f67778 R08: ffffffffa02667e0 R09: 0000000000000002 [ 2212.356665] R10: 0001f95254ab4b40 R11: ffff880212f675be R12: ffff8801f4dc2150 [ 2212.356712] R13: 0000000000000000 R14: ffffffffa02667e0 R15: 000000000000000d [ 2212.356761] FS: 0000000000000000(0000) GS:ffff88021e200000(0000) knlGS:0000000000000000 [ 2212.356813] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2212.356852] CR2: 0000000000000250 CR3: 0000000001a0c000 CR4: 00000000001407f0 [ 2212.356899] Stack: [ 2212.356917] 000000000000000c ffff8801f4dc2150 0000000000000000 ffffffffa02667e0 [ 2212.356980] 000000000000000d ffff880212f677b8 ffffffffa03a31ad ffff8801f4dc219a [ 2212.357038] ffff8801f4dc2150 0000000000000000 ffff8800b93217a0 ffff8801f49bc800 [ 2212.357099] Call Trace: [ 2212.357122] [] ? rt2x00usb_interrupt_txdone+0x90/0x90 [rt2x00usb] [ 2212.357174] [] rt2x00queue_for_each_entry+0xed/0x170 [rt2x00lib] [ 2212.357244] [] rt2x00usb_kick_queue+0x5c/0x60 [rt2x00usb] [ 2212.357314] [] rt2x00queue_flush_queue+0x62/0xa0 [rt2x00lib] [ 2212.357386] [] rt2x00mac_flush+0x30/0x70 [rt2x00lib] [ 2212.357470] [] ieee80211_flush_queues+0xbd/0x140 [mac80211] [ 2212.357555] [] ieee80211_set_disassoc+0x2d2/0x3d0 [mac80211] [ 2212.357645] [] ieee80211_mgd_deauth+0x1d3/0x240 [mac80211] [ 2212.357718] [] ? try_to_wake_up+0xec/0x290 [ 2212.357788] [] ieee80211_deauth+0x18/0x20 [mac80211] [ 2212.357872] [] cfg80211_mlme_deauth+0x9c/0x140 [cfg80211] [ 2212.357913] [] cfg80211_mlme_down+0x5c/0x60 [cfg80211] [ 2212.357962] [] cfg80211_disconnect+0x188/0x1a0 [cfg80211] [ 2212.358014] [] ? __cfg80211_stop_sched_scan+0x1c/0x130 [cfg80211] [ 2212.358067] [] cfg80211_leave+0xc4/0xe0 [cfg80211] [ 2212.358124] [] cfg80211_netdev_notifier_call+0x3ab/0x5e0 [cfg80211] [ 2212.358177] [] ? inetdev_event+0x38/0x510 [ 2212.358217] [] ? __wake_up+0x44/0x50 [ 2212.358254] [] notifier_call_chain+0x4c/0x70 [ 2212.358293] [] raw_notifier_call_chain+0x16/0x20 [ 2212.358361] [] call_netdevice_notifiers_info+0x35/0x60 [ 2212.358429] [] __dev_close_many+0x49/0xd0 [ 2212.358487] [] dev_close_many+0x88/0x100 [ 2212.358546] [] rollback_registered_many+0xb0/0x220 [ 2212.358612] [] unregister_netdevice_many+0x19/0x60 [ 2212.358694] [] ieee80211_remove_interfaces+0x112/0x190 [mac80211] [ 2212.358791] [] ieee80211_unregister_hw+0x4f/0x100 [mac80211] [ 2212.361994] [] rt2x00lib_remove_dev+0x161/0x1a0 [rt2x00lib] [ 2212.365240] [] rt2x00usb_disconnect+0x2e/0x70 [rt2x00usb] [ 2212.368470] [] usb_unbind_interface+0x64/0x1c0 [ 2212.371734] [] __device_release_driver+0x7f/0xf0 [ 2212.374999] [] device_release_driver+0x23/0x30 [ 2212.378131] [] bus_remove_device+0x108/0x180 [ 2212.381358] [] device_del+0x135/0x1d0 [ 2212.384454] [] usb_disable_device+0xb0/0x270 [ 2212.387451] [] usb_disconnect+0xad/0x1d0 [ 2212.390294] [] hub_thread+0x63d/0x1660 [ 2212.393034] [] ? wake_up_atomic_t+0x30/0x30 [ 2212.395728] [] ? hub_port_debounce+0x130/0x130 [ 2212.398412] [] kthread+0xc0/0xd0 [ 2212.401058] [] ? insert_kthread_work+0x40/0x40 [ 2212.403639] [] ret_from_fork+0x7c/0xb0 [ 2212.406193] [] ? insert_kthread_work+0x40/0x40 [ 2212.408732] Code: 24 58 08 00 00 bf 80 00 00 00 e8 3a c3 e0 e0 5b 41 5c 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 <48> 8b 47 10 48 89 fb 4c 8b 6f 28 4c 8b 20 49 8b 04 24 4c 8b 30 [ 2212.414671] RIP [] rt2x00usb_kick_tx_entry+0x12/0x160 [rt2x00usb] [ 2212.417646] RSP [ 2212.420547] CR2: 0000000000000250 [ 2212.441024] ---[ end trace 5442918f33832bce ]--- Signed-off-by: Stanislaw Gruszka Acked-by: Helmut Schaa Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit de6b1b244f4fa801a1e16a5a7fab89fcc7668b69 Author: Felix Fietkau Date: Thu Nov 14 21:33:15 2013 +0100 rt2x00: fix a crash bug in the HT descriptor handling fix commit b4089d6d8e71a7293e2192025dfa507a04f661c4 upstream. Commit "rt2x00: fix HT TX descriptor settings regression" assumes that the control parameter to rt2x00mac_tx is always non-NULL. There is an internal call in rt2x00lib_bc_buffer_iter where NULL is passed. Fix the resulting crash by adding an initialized dummy on-stack ieee80211_tx_control struct. Signed-off-by: Felix Fietkau Acked-by: Gertjan van Wingerde Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 81ac9ab7336029547174a6e091cde14ab68b24d9 Author: K. Y. Srinivasan Date: Wed Oct 16 19:27:19 2013 -0700 Drivers: hv: vmbus: Fix a bug in channel rescind code commit 565ce6422ff92f5af71e4d5a09f78215433b2695 upstream. Rescind of subchannels were not being correctly handled. Fix the bug. Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman commit 5bb21134853f6dc7bc16c7fcb24470e8676a3c54 Author: Kees Cook Date: Thu Oct 24 18:05:42 2013 -0700 lkdtm: isolate stack corruption test commit 629c66a22c21b692b6e58b9c1d8fa56a60ccb52d upstream. When tests were added to lkdtm that grew the stack frame, the stack corruption test stopped working. This isolates the test in its own function, and forces it not to be inlined. Signed-off-by: Kees Cook Fixes: cc33c537c12f ("lkdtm: add "EXEC_*" triggers") Signed-off-by: Greg Kroah-Hartman commit adf0c46683b2c5b3ba261b21b68ad6e6b7592b89 Author: Ian Abbott Date: Mon Oct 7 15:51:58 2013 +0100 staging: comedi: avoid memleak for subdevice private commit 67aa4acbc97f6a55b328e4e2305ef19cbe949d85 upstream. `comedi_alloc_spriv()` allocates private storage for a comedi subdevice and sets the `SRF_FREE_SPRIV` flag in the `runflags` member of the subdevice to allow the private storage to be automatically freed when the comedi device is being cleaned up. Unfortunately, the flag gets clobbered by `do_cmd_ioctl()` which calls `comedi_set_subdevice_runflags()` with a mask value `~0` and only the `SRF_USER` and `SRF_RUNNING` flags set, all the other SRF flags being cleared. Change the calls to `comedi_set_subdevice_runflags()` that currently use a mask value of `~0` to use a more relevant mask value. For `do_cmd_ioctl()`, the relevant SRF flags are `SRF_USER`, `SRF_ERROR` and `SRF_RUNNING`. (At one time, `SRF_RT` would be included in that set of flags, but it is no longer used.) For `comedi_alloc_spriv()` replace the call to `comedi_set_subdevice_runflags()` with a simple OR-assignment to avoid unnecessary use of a spin-lock. Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman commit 32f33da06f1b769fc7f9088bee344880cb70536a Author: Larry Finger Date: Mon Oct 21 22:15:05 2013 -0500 staging: r8188eu: Set device type to wlan commit 0d1206be229697f897f00822bc142e66da731417 upstream. The latest version of NetworkManager does not recognize the device as wireless without this change. Signed-off-by: Larry Finger Signed-off-by: Greg Kroah-Hartman commit 5cf7798500bbdf71d6587d108c48364d69331c79 Author: Rashika Kheria Date: Wed Oct 30 18:36:32 2013 +0530 Staging: zram: Fix access of NULL pointer commit 46a51c80216cb891f271ad021f59009f34677499 upstream. This patch fixes the bug in reset_store caused by accessing NULL pointer. The bdev gets its value from bdget_disk() which could fail when memory pressure is severe and hence can return NULL because allocation of inode in bdget could fail. Hence, this patch introduces a check for bdev to prevent reference to a NULL pointer in the later part of the code. It also removes unnecessary check of bdev for fsync_bdev(). Acked-by: Jerome Marchand Signed-off-by: Rashika Kheria Acked-by: Minchan Kim Signed-off-by: Greg Kroah-Hartman commit df24f94953e79dc1fb8c559f7df256861025ff49 Author: Rafael J. Wysocki Date: Thu Nov 7 01:42:17 2013 +0100 ACPI / hotplug: Do not execute "insert in progress" _OST commit 176a88d79d6b5aebabaff16734e8b3107efcaaad upstream. According to the ACPI spec (5.0, Section 6.3.5), the "Device insertion in progress (pending)" (0x80) _OST status code is reserved for the "Insertion Processing" (0x200) source event which is "a result of an OSPM action". Specifically, it is not a notification, so that status code should not be used during notification processing, which unfortunately is done by acpi_scan_bus_device_check(). For this reason, drop the ACPI_OST_SC_INSERT_IN_PROGRESS _OST status evaluation from there (it was a mistake to put it in there in the first place). Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit cf9dec04b035890995b3cb46d930f08bf5e9581d Author: Rafael J. Wysocki Date: Thu Nov 7 01:41:27 2013 +0100 ACPI / hotplug: Fix handle_root_bridge_removal() commit 2441191a19039002b2c454a261fb45986df15184 upstream. It is required to do get_device() on the struct acpi_device in question before passing it to acpi_bus_hot_remove_device() through acpi_os_hotplug_execute(), because acpi_bus_hot_remove_device() calls acpi_scan_hot_remove() that does put_device() on that object. The ACPI PCI root removal routine, handle_root_bridge_removal(), doesn't do that, which may lead to premature freeing of the device object or to executing put_device() on an object that has been freed already. Fix this problem by making handle_root_bridge_removal() use get_device() as appropriate. Signed-off-by: Rafael J. Wysocki Acked-by: Toshi Kani Signed-off-by: Greg Kroah-Hartman commit 76641adddc5dc634cb7759dfa95d3d5a545678d1 Author: Aaron Lu Date: Wed Nov 6 09:07:10 2013 +0800 ACPI / video: Quirk initial backlight level 0 commit 2c62333a408f5badd2d2ffd7177f95deeccc5ca4 upstream. Some firmware doesn't initialize initial backlight level to a proper value and _BQC will return 0 on first time evaluation. We used to be able to detect such incorrect value with our code logic, as value 0 normally isn't a valid value in _BCL. But with the introduction of Win8, firmware begins to fill _BCL with values from 0 to 100, now 0 becomes a valid value but that value will make user's screen black. This patch test initial _BQC for value 0, if such a value is returned, do not use it. References: https://bugzilla.kernel.org/show_bug.cgi?id=64031 References: https://bugzilla.kernel.org/show_bug.cgi?id=61231 References: https://bugzilla.kernel.org/show_bug.cgi?id=63111 Reported-by: Qingshuai Tian Tested-by: Aaron Lu # on "Idealpad u330p" Reported-and-tested-by: # on "Acer Aspire V5-573G" Reported-and-tested-by: Kirill Tkhai # on "HP 250 G1" Signed-off-by: Aaron Lu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 04b4bc701219792b9019cdb750c012a2ecab6357 Author: Puneet Kumar Date: Fri Nov 15 11:41:29 2013 -0800 ACPI / EC: Ensure lock is acquired before accessing ec struct members commit 36b15875a7819a2ec4cb5748ff7096ad7bd86cbb upstream. A bug was introduced by commit b76b51ba0cef ('ACPI / EC: Add more debug info and trivial code cleanup') that erroneously caused the struct member to be accessed before acquiring the required lock. This change fixes it by ensuring the lock acquisition is done first. Found by Aaron Durbin Fixes: b76b51ba0cef ('ACPI / EC: Add more debug info and trivial code cleanup') References: http://crbug.com/319019 Signed-off-by: Puneet Kumar Reviewed-by: Aaron Durbin [olof: Commit message reworded a bit] Signed-off-by: Olof Johansson Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 539ddb09c46389cc22d35543e40ccde2c2e20244 Author: Steven Rostedt Date: Tue Nov 5 12:51:11 2013 -0500 perf/ftrace: Fix paranoid level for enabling function tracer commit 12ae030d54ef250706da5642fc7697cc60ad0df7 upstream. The current default perf paranoid level is "1" which has "perf_paranoid_kernel()" return false, and giving any operations that use it, access to normal users. Unfortunately, this includes function tracing and normal users should not be allowed to enable function tracing by default. The proper level is defined at "-1" (full perf access), which "perf_paranoid_tracepoint_raw()" will only give access to. Use that check instead for enabling function tracing. Reported-by: Dave Jones Reported-by: Vince Weaver Tested-by: Vince Weaver Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Jiri Olsa Cc: Frederic Weisbecker CVE: CVE-2013-2930 Fixes: ced39002f5ea ("ftrace, perf: Add support to use function tracepoint in perf") Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit fc97fc29e0a2942e6fe72963cff235a932b91be9 Author: Peter Zijlstra Date: Wed Sep 11 12:43:13 2013 +0200 sched, idle: Fix the idle polling state logic commit ea8117478918a4734586d35ff530721b682425be upstream. Mike reported that commit 7d1a9417 ("x86: Use generic idle loop") regressed several workloads and caused excessive reschedule interrupts. The patch in question failed to notice that the x86 code had an inverted sense of the polling state versus the new generic code (x86: default polling, generic: default !polling). Fix the two prominent x86 mwait based idle drivers and introduce a few new generic polling helpers (fixing the wrong smp_mb__after_clear_bit usage). Also switch the idle routines to using tif_need_resched() which is an immediate TIF_NEED_RESCHED test as opposed to need_resched which will end up being slightly different. Reported-by: Mike Galbraith Signed-off-by: Peter Zijlstra Cc: lenb@kernel.org Cc: tglx@linutronix.de Link: http://lkml.kernel.org/n/tip-nc03imb0etuefmzybzj7sprf@git.kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 19dbd3f28ce670a6b016c595e29626d1533bba39 Author: Suman Anna Date: Tue Oct 8 23:46:49 2013 -0600 ARM: OMAP2+: hwmod: check for module address space during init commit 6423d6df1440a8acfc2f375d7cbc4cd66c2e6910 upstream. The hwmod init sequence involves initializing and idling all the hwmods during bootup. If a module class has sysconfig, the init sequence utilizes the module register base for performing any sysc configuration. The module address space is being removed from hwmod database and retrieved from the property of the corresponding DT node. If a hwmod does not have its corresponding DT node defined and the memory address space is not defined in the corresponding omap_hwmod_ocp_if, then the module register target address space would be NULL and any sysc programming would result in a NULL pointer dereference and a kernel boot hang. Handle this scenario by checking for a valid module address space during the _init of each hwmod, and leaving it in the registered state if no module register address base is defined in either of the hwmod data or the DT data. Signed-off-by: Suman Anna Acked-by: Santosh Shilimkar Tested-by: Nishanth Menon Acked-by: Tony Lindgren [paul@pwsan.com: use -ENXIO rather than -ENOMEM to indicate a missing address space error; fixed checkpatch.pl problem] Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit ce0b80a71ba1a749abaffa5e5883582d54ffe66e Author: Takashi Iwai Date: Thu Oct 24 16:06:32 2013 +0200 thinkpad_acpi: Fix build error when CONFIG_SND_MAX_CARDS > 32 commit cab6661344f14a09d7aecdf821a40f68ef9b18cc upstream. SNDRV_CARDS can be specified via Kconfig since 3.11 kernel, so this can be over 32bit integer range, which leads to a build error. Signed-off-by: Takashi Iwai Signed-off-by: Matthew Garrett Signed-off-by: Greg Kroah-Hartman commit 0bb8c8db22da5810c13974d5a8df4595a654541c Author: Ben Skeggs Date: Tue Nov 5 09:28:26 2013 +1000 drm/nvc0-/gr: fix a number of missing explicit array terminators... commit 13d2b35a065399fb447c84e80368927e5f8bf086 upstream. Signed-off-by: Ben Skeggs Cc: Ilia Mirkin Signed-off-by: Greg Kroah-Hartman commit 9d7e7af2818ec88bc6973837c67ef8cf59df7e48 Author: John Stultz Date: Mon Oct 21 09:58:07 2013 -0700 staging: ashmem: Fix ASHMEM_PURGE_ALL_CACHES return value commit 5957324045ba2c127c9401fa3ac61ac52e043ca8 upstream. Hopefully this isn't too late for 3.12. In commit 7dc19d5aff (convert shrinkers to new count/scan API) the return value to PURGE_ALL_CACHES was dropped, causing -EPERM to always be returned. This patch re-adds the ret assignment, setting it to the the ashmem_shrink_count(), which is the lru_count. (Sorry this was missed in the review!) Fixes: 7dc19d5affd7 ("convert shrinkers to new count/scan API") Cc: Colin Cross Cc: Android Kernel Team Cc: Glauber Costa Reported-by: YongQin Liu Signed-off-by: John Stultz Acked-by: Dave Chinner Signed-off-by: Greg Kroah-Hartman commit fd78668eb3b10b7bd2308142084dba07b38e359b Author: Laurent Pinchart Date: Tue Oct 29 18:20:58 2013 +0100 drm: shmobile: Add dependency on BACKLIGHT_CLASS_DEVICE commit 0a5a5499ad886dde4a032203d01e324cfe593f99 upstream. The driver registers a backlight device and thus requires BACKLIGHT_CLASS_DEVICE to be selected to avoid compilation breakages. Reported-by: Russell King Signed-off-by: Laurent Pinchart Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit dd272212175ad47ee84cf38e9d5f99502df2d930 Author: Greg Thelen Date: Thu Nov 21 14:32:00 2013 -0800 ipc,shm: fix shm_file deletion races commit a399b29dfbaaaf91162b2dc5a5875dd51bbfa2a1 upstream. When IPC_RMID races with other shm operations there's potential for use-after-free of the shm object's associated file (shm_file). Here's the race before this patch: TASK 1 TASK 2 ------ ------ shm_rmid() ipc_lock_object() shmctl() shp = shm_obtain_object_check() shm_destroy() shum_unlock() fput(shp->shm_file) ipc_lock_object() shmem_lock(shp->shm_file) The oops is caused because shm_destroy() calls fput() after dropping the ipc_lock. fput() clears the file's f_inode, f_path.dentry, and f_path.mnt, which causes various NULL pointer references in task 2. I reliably see the oops in task 2 if with shmlock, shmu This patch fixes the races by: 1) set shm_file=NULL in shm_destroy() while holding ipc_object_lock(). 2) modify at risk operations to check shm_file while holding ipc_object_lock(). Example workloads, which each trigger oops... Workload 1: while true; do id=$(shmget 1 4096) shm_rmid $id & shmlock $id & wait done The oops stack shows accessing NULL f_inode due to racing fput: _raw_spin_lock shmem_lock SyS_shmctl Workload 2: while true; do id=$(shmget 1 4096) shmat $id 4096 & shm_rmid $id & wait done The oops stack is similar to workload 1 due to NULL f_inode: touch_atime shmem_mmap shm_mmap mmap_region do_mmap_pgoff do_shmat SyS_shmat Workload 3: while true; do id=$(shmget 1 4096) shmlock $id shm_rmid $id & shmunlock $id & wait done The oops stack shows second fput tripping on an NULL f_inode. The first fput() completed via from shm_destroy(), but a racing thread did a get_file() and queued this fput(): locks_remove_flock __fput ____fput task_work_run do_notify_resume int_signal Fixes: c2c737a0461e ("ipc,shm: shorten critical region for shmat") Fixes: 2caacaa82a51 ("ipc,shm: shorten critical region for shmctl") Signed-off-by: Greg Thelen Cc: Davidlohr Bueso Cc: Rik van Riel Cc: Manfred Spraul Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bf628e80c085da4aec49792b087516160283c2fe Author: Jesper Nilsson Date: Thu Nov 21 14:32:08 2013 -0800 ipc,shm: correct error return value in shmctl (SHM_UNLOCK) commit 3a72660b07d86d60457ca32080b1ce8c2b628ee2 upstream. Commit 2caacaa82a51 ("ipc,shm: shorten critical region for shmctl") restructured the ipc shm to shorten critical region, but introduced a path where the return value could be -EPERM, even if the operation actually was performed. Before the commit, the err return value was reset by the return value from security_shm_shmctl() after the if (!ns_capable(...)) statement. Now, we still exit the if statement with err set to -EPERM, and in the case of SHM_UNLOCK, it is not reset at all, and used as the return value from shmctl. To fix this, we only set err when errors occur, leaving the fallthrough case alone. Signed-off-by: Jesper Nilsson Cc: Davidlohr Bueso Cc: Rik van Riel Cc: Michel Lespinasse Cc: Al Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bc164db77f30782171c1ed9571cb22da459a316c Author: hahnjo Date: Tue Nov 12 18:19:24 2013 +0100 alx: Reset phy speed after resume commit b54629e226d196e802abdd30c5e34f2a47cddcf2 upstream. This fixes bug 62491 (https://bugzilla.kernel.org/show_bug.cgi?id=62491). After resuming some users got the following error flooding the kernel log: alx 0000:02:00.0: invalid PHY speed/duplex: 0xffff Signed-off-by: Jonas Hahnfeld Signed-off-by: David S. Miller Cc: hahnjo Signed-off-by: Greg Kroah-Hartman commit 621c5bc9a544edf847440736f75900ecc1021c9d Author: Markus Pargmann Date: Mon Oct 28 09:54:40 2013 +0100 can: c_can: Fix RX message handling, handle lost message before EOB commit 5d0f801a2ccec3b1fdabc3392c8d99ed0413d216 upstream. If we handle end of block messages with higher priority than a lost message, we can run into an endless interrupt loop. This is reproducable with a am335x processor and "cansequence -r" at 1Mbit. As soon as we loose a packet we can't escape from an interrupt loop. This patch fixes the problem by handling lost packets before EOB packets. Signed-off-by: Markus Pargmann Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 0996972585115007edbca1dd2316185409c9c032 Author: Herbert Xu Date: Tue Nov 5 19:36:27 2013 +0800 crypto: s390 - Fix aes-cbc IV corruption commit f262f0f5cad0c9eca61d1d383e3b67b57dcbe5ea upstream. The cbc-aes-s390 algorithm incorrectly places the IV in the tfm data structure. As the tfm is shared between multiple threads, this introduces a possibility of data corruption. This patch fixes this by moving the parameter block containing the IV and key onto the stack (the block is 48 bytes long). The same bug exists elsewhere in the s390 crypto system and they will be fixed in subsequent patches. Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 8ea7fffd97835f4e3ffd5f757df152a79835f65f Author: Neil Horman Date: Tue Sep 17 08:33:11 2013 -0400 crypto: ansi_cprng - Fix off by one error in non-block size request commit 714b33d15130cbb5ab426456d4e3de842d6c5b8a upstream. Stephan Mueller reported to me recently a error in random number generation in the ansi cprng. If several small requests are made that are less than the instances block size, the remainder for loop code doesn't increment rand_data_valid in the last iteration, meaning that the last bytes in the rand_data buffer gets reused on the subsequent smaller-than-a-block request for random data. The fix is pretty easy, just re-code the for loop to make sure that rand_data_valid gets incremented appropriately Signed-off-by: Neil Horman Reported-by: Stephan Mueller CC: Stephan Mueller CC: Petr Matousek CC: Herbert Xu CC: "David S. Miller" Signed-off-by: Herbert Xu Cc: Luis Henriques Signed-off-by: Greg Kroah-Hartman commit f9bbe6ea80e700ee620ef26902eb2decec17b258 Author: Josef Bacik Date: Fri Sep 27 09:33:09 2013 -0400 Btrfs: relocate csums properly with prealloc extents commit 4577b014d1bc3db386da3246f625888fc48083a9 upstream. A user reported a problem where they were getting csum errors when running a balance and running systemd's journal. This is because systemd is awesome and fallocate()'s its log space and writes into it. Unfortunately we assume that when we read in all the csums for an extent that they are sequential starting at the bytenr we care about. This obviously isn't the case for prealloc extents, where we could have written to the middle of the prealloc extent only, which means the csum would be for the bytenr in the middle of our range and not the front of our range. Fix this by offsetting the new bytenr we are logging to based on the original bytenr the csum was for. With this patch I no longer see the csum errors I was seeing. Thanks, Reported-by: Chris Murphy Signed-off-by: Josef Bacik Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 5a9007740a12827ead4b6131782d731986831a18 Author: Olivier Sobrie Date: Sun Oct 27 22:07:53 2013 +0100 can: kvaser_usb: fix usb endpoints detection commit 896e23bd04ea50a146dffd342e2f96180f0812a5 upstream. Some devices, like the Kvaser Memorator Professional, have several bulk in endpoints. Only the first one found must be used by the driver. The same holds for the bulk out endpoint. The official Kvaser driver (leaf) was used as reference for this patch. Signed-off-by: Olivier Sobrie Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 80064f1a10da8351399d6708ad315e0abc24345d Author: Johan Hovold Date: Wed Oct 9 17:01:09 2013 +0200 USB: mos7840: fix tiocmget error handling commit a91ccd26e75235d86248d018fe3779732bcafd8d upstream. Make sure to return errors from tiocmget rather than rely on uninitialised stack data. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 31fcbef62d8142c0c173b0b8255e9b0c28a7a038 Author: Eric Sandeen Date: Mon Sep 9 15:33:29 2013 -0500 xfs: be more forgiving of a v4 secondary sb w/ junk in v5 fields commit 10e6e65dfcedff63275c3d649d329c044caa8e26 upstream. Today, if xfs_sb_read_verify encounters a v4 superblock with junk past v4 fields which includes data in sb_crc, it will be treated as a failing checksum and a significant corruption. There are known prior bugs which leave junk at the end of the V4 superblock; we don't need to actually fail the verification in this case if other checks pan out ok. So if this is a secondary superblock, and the primary superblock doesn't indicate that this is a V5 filesystem, don't treat this as an actual checksum failure. We should probably check the garbage condition as we do in xfs_repair, and possibly warn about it or self-heal, but that's a different scope of work. Stable folks: This can go back to v3.10, which is what introduced the sb CRC checking that is tripped up by old, stale, incorrect V4 superblocks w/ unzeroed bits. Signed-off-by: Eric Sandeen Acked-by: Dave Chinner Reviewed-by: Mark Tinguely Signed-off-by: Ben Myers Signed-off-by: Greg Kroah-Hartman commit 12cc2209deeda65c963c84a5e6aaf0c39aca8e6d Author: Mahesh Rajashekhara Date: Thu Oct 31 14:01:02 2013 +0530 aacraid: prevent invalid pointer dereference commit b4789b8e6be3151a955ade74872822f30e8cd914 upstream. It appears that driver runs into a problem here if fibsize is too small because we allocate user_srbcmd with fibsize size only but later we access it until user_srbcmd->sg.count to copy it over to srbcmd. It is not correct to test (fibsize < sizeof(*user_srbcmd)) because this structure already includes one sg element and this is not needed for commands without data. So, we would recommend to add the following (instead of test for fibsize == 0). Signed-off-by: Mahesh Rajashekhara Reported-by: Nico Golde Reported-by: Fabian Yamaguchi Signed-off-by: Linus Torvalds Cc: Kees Cook Signed-off-by: Greg Kroah-Hartman commit 0f6ff65ed8d3630118c3149a4fbc493dd3b8fdc4 Author: Dan Carpenter Date: Wed Oct 30 20:12:51 2013 +0300 libertas: potential oops in debugfs commit a497e47d4aec37aaf8f13509f3ef3d1f6a717d88 upstream. If we do a zero size allocation then it will oops. Also we can't be sure the user passes us a NUL terminated string so I've added a terminator. This code can only be triggered by root. Reported-by: Nico Golde Reported-by: Fabian Yamaguchi Signed-off-by: Dan Carpenter Acked-by: Dan Williams Signed-off-by: John W. Linville Cc: Kees Cook Signed-off-by: Greg Kroah-Hartman commit 9e5129ba8d3d65605683050f73f12dddbf3f8c00 Author: Al Viro Date: Wed Nov 13 07:45:40 2013 -0500 prepend_path() needs to reinitialize dentry/vfsmount/mnt on restarts commit ede4cebce16f5643c61aedd6d88d9070a1d23a68 upstream. ... and equivalent is needed in 3.12; it's broken there as well Signed-off-by: Al Viro Reported-by: Michael Marineau Tested-by: Waiman Long Signed-off-by: Greg Kroah-Hartman