commit 5b31202a3604ef905d0433402aaf8aadf4660774 Author: Greg Kroah-Hartman Date: Sat Oct 5 07:00:59 2013 -0700 Linux 3.0.99 commit 2e4e7cb96933d2c9794125b038bd9ea9cba9bcfc Author: Eric Dumazet Date: Tue Jun 12 15:24:40 2012 +0200 splice: fix racy pipe->buffers uses commit 047fe3605235888f3ebcda0c728cb31937eadfe6 upstream. Dave Jones reported a kernel BUG at mm/slub.c:3474! triggered by splice_shrink_spd() called from vmsplice_to_pipe() commit 35f3d14dbbc5 (pipe: add support for shrinking and growing pipes) added capability to adjust pipe->buffers. Problem is some paths don't hold pipe mutex and assume pipe->buffers doesn't change for their duration. Fix this by adding nr_pages_max field in struct splice_pipe_desc, and use it in place of pipe->buffers where appropriate. splice_shrink_spd() loses its struct pipe_inode_info argument. Reported-by: Dave Jones Signed-off-by: Eric Dumazet Cc: Jens Axboe Cc: Alexander Viro Cc: Tom Herbert Cc: stable # 2.6.35 Tested-by: Dave Jones Signed-off-by: Jens Axboe Signed-off-by: Jiri Slaby Signed-off-by: Greg Kroah-Hartman commit 96ec909de79e2cc422126fdeb427fe8d0ffb4b95 Author: Henrik Rydberg Date: Thu Jan 26 06:08:41 2012 -0500 hwmon: (applesmc) Silence uninitialized warnings commit 0fc86eca1b338d06ec500b34ef7def79c32b602b upstream. Some error paths do not set a result, leading to the (false) assumption that the value may be used uninitialized. Set results for those paths as well. Signed-off-by: Henrik Rydberg Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 94c7268325e30ecb4767b9c080e8cec9c92d6689 Author: Henrik Rydberg Date: Thu Sep 26 08:33:16 2013 +0200 hwmon: (applesmc) Check key count before proceeding commit 5f4513864304672e6ea9eac60583eeac32e679f2 upstream. After reports from Chris and Josh Boyer of a rare crash in applesmc, Guenter pointed at the initialization problem fixed below. The patch has not been verified to fix the crash, but should be applied regardless. Reported-by: Suggested-by: Guenter Roeck Signed-off-by: Henrik Rydberg Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit d0d0e6c36f6d9fdf0df50c4d1877156b7bcff565 Author: Jani Nikula Date: Fri Sep 20 16:42:15 2013 +0300 drm/i915/dp: increase i2c-over-aux retry interval on AUX DEFER commit 8d16f258217f2f583af1fd57c5144aa4bbe73e48 upstream. There is no clear cut rules or specs for the retry interval, as there are many factors that affect overall response time. Increase the interval, and even more so on branch devices which may have limited i2c bit rates. Signed-off-by: Jani Nikula Reference: https://bugs.freedesktop.org/show_bug.cgi?id=60263 Tested-by: Nicolas Suzor Reviewed-by: Todd Previte Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 1f6014d357c7884e176c9d78c321ded23bdbd985 Author: Mikulas Patocka Date: Wed Sep 18 19:40:42 2013 -0400 dm-snapshot: fix performance degradation due to small hash size commit 60e356f381954d79088d0455e357db48cfdd6857 upstream. LVM2, since version 2.02.96, creates origin with zero size, then loads the snapshot driver and then loads the origin. Consequently, the snapshot driver sees the origin size zero and sets the hash size to the lower bound 64. Such small hash table causes performance degradation. This patch changes it so that the hash size is determined by the size of snapshot volume, not minimum of origin and snapshot size. It doesn't make sense to set the snapshot size significantly larger than the origin size, so we do not need to take origin size into account when calculating the hash size. Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 434b9ee66a512e9b91b9e1687b8183cd48a353fb Author: Mikulas Patocka Date: Wed Sep 18 19:14:22 2013 -0400 dm snapshot: workaround for a false positive lockdep warning commit 5ea330a75bd86b2b2a01d7b85c516983238306fb upstream. The kernel reports a lockdep warning if a snapshot is invalidated because it runs out of space. The lockdep warning was triggered by commit 0976dfc1d0cd80a4e9dfaf87bd87 ("workqueue: Catch more locking problems with flush_work()") in v3.5. The warning is false positive. The real cause for the warning is that the lockdep engine treats different instances of md->lock as a single lock. This patch is a workaround - we use flush_workqueue instead of flush_work. This code path is not performance sensitive (it is called only on initialization or invalidation), thus it doesn't matter that we flush the whole workqueue. The real fix for the problem would be to teach the lockdep engine to treat different instances of md->lock as separate locks. Signed-off-by: Mikulas Patocka Acked-by: Alasdair G Kergon Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 0c61d8a1d51e6f701ee17af5fa33bdeefaa02b75 Author: Kurt Garloff Date: Tue Sep 24 14:13:48 2013 +0200 usb/core/devio.c: Don't reject control message to endpoint with wrong direction bit commit 831abf76643555a99b80a3b54adfa7e4fa0a3259 upstream. Trying to read data from the Pegasus Technologies NoteTaker (0e20:0101) [1] with the Windows App (EasyNote) works natively but fails when Windows is running under KVM (and the USB device handed to KVM). The reason is a USB control message usb 4-2.2: control urb: bRequestType=22 bRequest=09 wValue=0200 wIndex=0001 wLength=0008 This goes to endpoint address 0x01 (wIndex); however, endpoint address 0x01 does not exist. There is an endpoint 0x81 though (same number, but other direction); the app may have meant that endpoint instead. The kernel thus rejects the IO and thus we see the failure. Apparently, Linux is more strict here than Windows ... we can't change the Win app easily, so that's a problem. It seems that the Win app/driver is buggy here and the driver does not behave fully according to the USB HID class spec that it claims to belong to. The device seems to happily deal with that though (and seems to not really care about this value much). So the question is whether the Linux kernel should filter here. Rejecting has the risk that somewhat non-compliant userspace apps/ drivers (most likely in a virtual machine) are prevented from working. Not rejecting has the risk of confusing an overly sensitive device with such a transfer. Given the fact that Windows does not filter it makes this risk rather small though. The patch makes the kernel more tolerant: If the endpoint address in wIndex does not exist, but an endpoint with toggled direction bit does, it will let the transfer through. (It does NOT change the message.) With attached patch, the app in Windows in KVM works. usb 4-2.2: check_ctrlrecip: process 13073 (qemu-kvm) requesting ep 01 but needs 81 I suspect this will mostly affect apps in virtual environments; as on Linux the apps would have been adapted to the stricter handling of the kernel. I have done that for mine[2]. [1] http://www.pegatech.com/ [2] https://sourceforge.net/projects/notetakerpen/ Signed-off-by: Kurt Garloff Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 314bb48ec028ae62cec4a1371cdd84b672d5a759 Author: Florian Wolter Date: Wed Aug 14 10:33:16 2013 +0200 xhci: Fix race between ep halt and URB cancellation commit 526867c3ca0caa2e3e846cb993b0f961c33c2abb upstream. The halted state of a endpoint cannot be cleared over CLEAR_HALT from a user process, because the stopped_td variable was overwritten in the handle_stopped_endpoint() function. So the xhci_endpoint_reset() function will refuse the reset and communication with device can not run over this endpoint. https://bugzilla.kernel.org/show_bug.cgi?id=60699 Signed-off-by: Florian Wolter Signed-off-by: Sarah Sharp Cc: Jonghwan Choi Signed-off-by: Greg Kroah-Hartman commit a86384dbc0bf86e10301eb8eaafb9d49c90e3183 Author: Mathias Nyman Date: Thu Sep 5 11:01:20 2013 +0300 xhci: Fix oops happening after address device timeout commit 284d20552461466b04d6bfeafeb1c47a8891b591 upstream. When a command times out, the command ring is first aborted, and then stopped. If the command ring is empty when it is stopped the stop event will point to next command which is not yet set. xHCI tries to handle this next event often causing an oops. Don't handle command completion events on stopped cmd ring if ring is empty. This patch should be backported to kernels as old as 3.7, that contain the commit b92cc66c047ff7cf587b318fe377061a353c120f "xHCI: add aborting command ring function" Signed-off-by: Mathias Nyman Reported-by: Giovanni Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit 79e1fc8a531ebe5da1078d765fadf6662edad612 Author: Malcolm Priestley Date: Sun Sep 22 19:48:54 2013 +0100 staging: vt6656: [BUG] main_usb.c oops on device_close move flag earlier. commit e3eb270fab7734427dd8171a93e4946fe28674bc upstream. The vt6656 is prone to resetting on the usb bus. It seems there is a race condition and wpa supplicant is trying to open the device via iw_handlers before its actually closed at a stage that the buffers are being removed. The device is longer considered open when the buffers are being removed. So move ~DEVICE_FLAGS_OPENED flag to before freeing the device buffers. Signed-off-by: Malcolm Priestley Signed-off-by: Greg Kroah-Hartman commit e8cf7dd6baa2ac1817ab4a8ef92f2b6791254870 Author: Josh Boyer Date: Thu Apr 18 07:51:34 2013 -0700 x86, efi: Don't map Boot Services on i386 commit 700870119f49084da004ab588ea2b799689efaf7 upstream. Add patch to fix 32bit EFI service mapping (rhbz 726701) Multiple people are reporting hitting the following WARNING on i386, WARNING: at arch/x86/mm/ioremap.c:102 __ioremap_caller+0x3d3/0x440() Modules linked in: Pid: 0, comm: swapper Not tainted 3.9.0-rc7+ #95 Call Trace: [] warn_slowpath_common+0x5f/0x80 [] ? __ioremap_caller+0x3d3/0x440 [] ? __ioremap_caller+0x3d3/0x440 [] warn_slowpath_null+0x1d/0x20 [] __ioremap_caller+0x3d3/0x440 [] ? get_usage_chars+0xfb/0x110 [] ? vprintk_emit+0x147/0x480 [] ? efi_enter_virtual_mode+0x1e4/0x3de [] ioremap_cache+0x1a/0x20 [] ? efi_enter_virtual_mode+0x1e4/0x3de [] efi_enter_virtual_mode+0x1e4/0x3de [] start_kernel+0x286/0x2f4 [] ? repair_env_string+0x51/0x51 [] i386_start_kernel+0x12c/0x12f Due to the workaround described in commit 916f676f8 ("x86, efi: Retain boot service code until after switching to virtual mode") EFI Boot Service regions are mapped for a period during boot. Unfortunately, with the limited size of the i386 direct kernel map it's possible that some of the Boot Service regions will not be directly accessible, which causes them to be ioremap()'d, triggering the above warning as the regions are marked as E820_RAM in the e820 memmap. There are currently only two situations where we need to map EFI Boot Service regions, 1. To workaround the firmware bug described in 916f676f8 2. To access the ACPI BGRT image but since we haven't seen an i386 implementation that requires either, this simple fix should suffice for now. [ Added to changelog - Matt ] Reported-by: Bryan O'Donoghue Acked-by: Tom Zanussi Acked-by: Darren Hart Cc: Josh Triplett Cc: Matthew Garrett Cc: H. Peter Anvin Cc: Ingo Molnar Cc: Thomas Gleixner Cc: Greg Kroah-Hartman Signed-off-by: Josh Boyer Signed-off-by: Matt Fleming Signed-off-by: Greg Kroah-Hartman commit 58f5bc0c124fb8338e91c8a4110ad64259632dd9 Author: Masoud Sharbiani Date: Fri Sep 20 15:59:07 2013 -0700 x86/reboot: Add quirk to make Dell C6100 use reboot=pci automatically commit 4f0acd31c31f03ba42494c8baf6c0465150e2621 upstream. Dell PowerEdge C6100 machines fail to completely reboot about 20% of the time. Signed-off-by: Masoud Sharbiani Signed-off-by: Vinson Lee Cc: Robin Holt Cc: Russell King Cc: Guan Xuetao Link: http://lkml.kernel.org/r/1379717947-18042-1-git-send-email-vlee@freedesktop.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman