commit 48eb9d081ad7594d9990454763912b4ecbcd7076 Author: Jiri Slaby Date: Mon Mar 10 11:14:40 2014 +0100 Linux 3.12.14 commit 04ea7f8d985ba915d9eebec9ae724e996d1a5404 Author: Jani Nikula Date: Tue Feb 11 11:52:05 2014 +0200 drm/i915/dp: add native aux defer retry limit commit f51a44b9a6c4982cc25bfb3727de9bb893621ebc upstream. Retrying indefinitely places too much trust on the aux implementation of the sink devices. Reported-by: Daniel Martin Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71267 Signed-off-by: Jani Nikula Tested-by: Theodore Ts'o Tested-by: Sree Harsha Totakura Signed-off-by: Daniel Vetter Signed-off-by: Jiri Slaby commit 4a036dd40a68428a35f3272a3275b3f35099dd43 Author: Jani Nikula Date: Tue Feb 11 11:52:04 2014 +0200 drm/i915/dp: increase native aux defer retry timeout commit 04eada25d1f72efdecd32d702706594f81de65d5 upstream. Give more slack to sink devices before retrying on native aux defer. AFAICT the 100 us timeout was not based on the DP spec. Signed-off-by: Jani Nikula Cc: stable@vger.kernel.org (on Jani's request) Signed-off-by: Daniel Vetter Signed-off-by: Jiri Slaby commit 8b6045d450c3accb8a1036e5d656f59bc236483e Author: Jerome Glisse Date: Wed Feb 26 19:22:47 2014 -0500 drm/radeon: free uvd ring on unload commit d965441342f3b7d63db784cad852328d17d47942 upstream. Need to free the uvd ring. Also reshuffle gart tear down to happen after uvd tear down. Signed-off-by: Jérôme Glisse Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Jiri Slaby commit 38047aec7468e244c759db806b21349552029c85 Author: Alex Deucher Date: Tue Feb 25 10:21:43 2014 -0500 drm/radeon: disable pll sharing for DP on DCE4.1 commit 9ef4e1d000a5b335fcebfcf8aef3405e59574c89 upstream. Causes display problems. We had already disabled sharing for non-DP displays. Based on a patch from: Niels Ole Salscheider bug: https://bugzilla.kernel.org/show_bug.cgi?id=58121 Signed-off-by: Alex Deucher Signed-off-by: Jiri Slaby commit 6c4fe61cdb6ddc3fd14bd916b9f42a36586d8d88 Author: Christian König Date: Thu Feb 20 18:47:14 2014 +0100 drm/radeon: fix missing bo reservation commit 5e386b574cf7e1593e1296e5b0feea4108ed6ad8 upstream. Otherwise we might get a crash here. Signed-off-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Jiri Slaby commit 0d4605e9040b0015d2e94da0572e5f47aff6c1a3 Author: Alex Deucher Date: Thu Feb 20 09:16:01 2014 -0500 drm/radeon: print the supported atpx function mask commit 9f050c7f9738ffa746c63415136645ad231b1348 upstream. Print the supported functions mask in addition to the version. This is useful in debugging PX problems since we can see what functions are available. Signed-off-by: Alex Deucher Signed-off-by: Jiri Slaby commit a3286bb5ea0f62f2c78c49c676e9611e9e499d00 Author: Alex Deucher Date: Tue Feb 18 10:25:39 2014 -0500 drm/radeon: fix audio disable on dce6+ commit d7eb0a0940618f36e5937d81c06ad7bf438a99e2 upstream. Properly clear the enable bit when audio disable is requested. Signed-off-by: Alex Deucher Reviewed-by: Christian König Signed-off-by: Jiri Slaby commit 5da2b53fd5cc451eea0a2d66bc9702724155bd66 Author: Mike Snitzer Date: Wed Feb 19 20:32:33 2014 -0500 dm thin: fix the error path for the thin device constructor commit 1acacc0784aab45627b6009e0e9224886279ac0b upstream. dm_pool_close_thin_device() must be called if dm_set_target_max_io_len() fails in thin_ctr(). Otherwise __pool_destroy() will fail because the pool will still have an open thin device: device-mapper: thin metadata: attempt to close pmd when 1 device(s) are still open device-mapper: thin: __pool_destroy: dm_pool_metadata_close() failed. Also, must establish error code if failing thin_ctr() because the pool is in fail_io mode. Signed-off-by: Mike Snitzer Acked-by: Joe Thornber Signed-off-by: Jiri Slaby commit d4c47a2b64e03a90281875b67a082a577de0ff43 Author: Mike Snitzer Date: Thu Feb 6 06:08:56 2014 -0500 dm thin: avoid metadata commit if a pool's thin devices haven't changed commit 4d1662a30dde6e545086fe0e8fd7e474c4e0b639 upstream. Commit 905e51b ("dm thin: commit outstanding data every second") introduced a periodic commit. This commit occurs regardless of whether any thin devices have made changes. Fix the periodic commit to check if any of a pool's thin devices have changed using dm_pool_changed_this_transaction(). Reported-by: Alexander Larsson Signed-off-by: Mike Snitzer Acked-by: Joe Thornber Signed-off-by: Jiri Slaby commit 9673d7e741510a68069578a775cd0c49ef8825df Author: Hannes Reinecke Date: Wed Feb 26 10:07:04 2014 +0100 dm mpath: fix stalls when handling invalid ioctls commit a1989b330093578ea5470bea0a00f940c444c466 upstream. An invalid ioctl will never be valid, irrespective of whether multipath has active paths or not. So for invalid ioctls we do not have to wait for multipath to activate any paths, but can rather return an error code immediately. This fix resolves numerous instances of: udevd[]: worker [] unexpectedly returned with status 0x0100 that have been seen during testing. Signed-off-by: Hannes Reinecke Signed-off-by: Mike Snitzer Signed-off-by: Jiri Slaby commit a5a928314b25f7b5c08629a2993807e998c90224 Author: Linus Walleij Date: Thu Feb 13 10:39:01 2014 +0100 dma: ste_dma40: don't dereference free:d descriptor commit e9baa9d9d520fb0e24cca671e430689de2d4a4b2 upstream. It appears that in the DMA40 driver the DMA tasklet will very often dereference memory for a descriptor just free:d from the DMA40 slab. Nothing happens because no other part of the driver has yet had a chance to claim this memory, but it's really nasty to dereference free:d memory, so let's check the flag before the descriptor is free and store it in a bool variable. Reported-by: Dan Carpenter Signed-off-by: Linus Walleij Signed-off-by: Vinod Koul Signed-off-by: Jiri Slaby commit 3787169fa3185aa8587972b5fdccbf700f60a4f1 Author: Sebastian Capella Date: Tue Feb 18 17:52:08 2014 -0800 PM / hibernate: Fix restore hang in freeze_processes() commit f8d5b9e9e5372f0deb7bc1ab1088a9b60b0a793d upstream. During restore, pm_notifier chain are called with PM_RESTORE_PREPARE. The firmware_class driver handler fw_pm_notify does not have a handler for this. As a result, it keeps a reader on the kmod.c umhelper_sem. During freeze_processes, the call to __usermodehelper_disable tries to take a write lock on this semaphore and hangs waiting. Signed-off-by: Sebastian Capella Acked-by: Ming Lei Signed-off-by: Rafael J. Wysocki Signed-off-by: Jiri Slaby commit 6e511735ceacf47932d0c123f786df7698a221b8 Author: Jean Delvare Date: Tue Feb 25 09:43:13 2014 +0100 i7300_edac: Fix device reference count commit 75135da0d68419ef8a925f4c1d5f63d8046e314d upstream. pci_get_device() decrements the reference count of "from" (last argument) so when we break off the loop successfully we have only one device reference - and we don't know which device we have. If we want a reference to each device, we must take them explicitly and let the pci_get_device() walk complete to avoid duplicate references. This is serious, as over-putting device references will cause the device to eventually disappear. Without this fix, the kernel crashes after a few insmod/rmmod cycles. Tested on an Intel S7000FC4UR system with a 7300 chipset. Signed-off-by: Jean Delvare Link: http://lkml.kernel.org/r/20140224111656.09bbb7ed@endymion.delvare Cc: Mauro Carvalho Chehab Cc: Doug Thompson Signed-off-by: Borislav Petkov Signed-off-by: Jiri Slaby commit 1222b6db1d6b92b995b57b41a4f1f5c8c27a67ad Author: Dr. Greg Wettstein Date: Mon Feb 24 13:59:53 2014 -0600 qla2xxx: Fix kernel panic on selective retransmission request commit 6f58c780e5a5b43a6d2121e0d43cdcba1d3cc5fc upstream. A selective retransmission request (SRR) is a fibre-channel protocol control request which provides support for requesting retransmission of a data sequence in response to an issue such as frame loss or corruption. These events are experienced infrequently in fibre-channel based networks which makes it difficult to test and assess codepaths which handle these events. We were fortunate enough, for some definition of fortunate, to have a metro-area single-mode SAN link which, at 10 GBPS sustained load levels, would consistently generate SRR's in a SCST based target implementation using our SCST/in-kernel Qlogic target interface driver. In response to an SRR the in-kernel Qlogic target driver immediately panics resulting in a catastrophic storage failure for serviced initiators. The culprit was a debug statement in the qla_target.c file which does not verify that a pointer to the SCSI CDB is not null. The unchecked pointer dereference results in the kernel panic and resultant system failure. The other two references to the SCSI CDB by the SRR handling code use a ternary operator to verify a non-null pointer is being acted on. This patch simply adds a similar test to the implicated debug statement. This patch is a candidate for any stable kernel being maintained since it addresses a potentially catastrophic event with minimal downside. Signed-off-by: Dr. Greg Wettstein Signed-off-by: Nicholas Bellinger Signed-off-by: Jiri Slaby commit b9cac36b22d4a4c4dca3a42b63931702bd4cc4c8 Author: Olof Johansson Date: Fri Feb 14 19:35:15 2014 +0000 ARM64: unwind: Fix PC calculation commit e306dfd06fcb44d21c80acb8e5a88d55f3d1cf63 upstream. The frame PC value in the unwind code used to just take the saved LR value and use that. That's incorrect as a stack trace, since it shows the return path stack, not the call path stack. In particular, it shows faulty information in case the bl is done as the very last instruction of one label, since the return point will be in the next label. That can easily be seen with tail calls to panic(), which is marked __noreturn and thus doesn't have anything useful after it. Easiest here is to just correct the unwind code and do a -4, to get the actual call site for the backtrace instead of the return site. Signed-off-by: Olof Johansson Signed-off-by: Catalin Marinas Signed-off-by: Jiri Slaby commit 23c0ac16e67d6583d4ca1fa1e1bbf4e66d019bb2 Author: James Hogan Date: Tue Feb 25 22:05:35 2014 +0000 irq-metag*: stop set_affinity vectoring to offline cpus commit f229006ec6beabf7b844653d92fa61f025fe3dcf upstream. Fix irq_set_affinity callbacks in the Meta IRQ chip drivers to AND cpu_online_mask into the cpumask when picking a CPU to vector the interrupt to. As Thomas pointed out, the /proc/irq/$N/smp_affinity interface doesn't filter out offline CPUs, so without this patch if you offline CPU0 and set an IRQ affinity to 0x3 it vectors the interrupt onto CPU0 even though it is offline. Reported-by: Thomas Gleixner Signed-off-by: James Hogan Cc: Thomas Gleixner Cc: linux-metag@vger.kernel.org Signed-off-by: Jiri Slaby commit f2dbe242a73ab88c0996e1fe53d86c460d345090 Author: Kirill A. Shutemov Date: Tue Feb 25 15:01:42 2014 -0800 mm, thp: fix infinite loop on memcg OOM commit 9845cbbd113fbb5b769a45d8e88dc47bc12df4e0 upstream. Masayoshi Mizuma reported a bug with the hang of an application under the memcg limit. It happens on write-protection fault to huge zero page If we successfully allocate a huge page to replace zero page but hit the memcg limit we need to split the zero page with split_huge_page_pmd() and fallback to small pages. The other part of the problem is that VM_FAULT_OOM has special meaning in do_huge_pmd_wp_page() context. __handle_mm_fault() expects the page to be split if it sees VM_FAULT_OOM and it will will retry page fault handling. This causes an infinite loop if the page was not split. do_huge_pmd_wp_zero_page_fallback() can return VM_FAULT_OOM if it failed to allocate one small page, so fallback to small pages will not help. The solution for this part is to replace VM_FAULT_OOM with VM_FAULT_FALLBACK is fallback required. Signed-off-by: Kirill A. Shutemov Reported-by: Masayoshi Mizuma Reviewed-by: Michal Hocko Cc: Johannes Weiner Cc: Andrea Arcangeli Cc: David Rientjes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 29e63f5f124dec97ee372cbab05611494f413adc Author: Charles Keepax Date: Tue Feb 18 15:22:12 2014 +0000 Input - arizona-haptics: Fix double lock of dapm_mutex commit c4204960e9d0ba99459dbf1db918f99a45e7a62a upstream. snd_soc_dapm_sync takes the dapm_mutex internally, but we currently take it externally as well. This patch fixes this. Signed-off-by: Charles Keepax Signed-off-by: Mark Brown Signed-off-by: Jiri Slaby commit e1f10f1dff59b1a9ed9c6a29289c95ef010b7ed2 Author: Davidlohr Bueso Date: Tue Feb 25 15:01:45 2014 -0800 ipc,mqueue: remove limits for the amount of system-wide queues commit f3713fd9cff733d9df83116422d8e4af6e86b2bb upstream. Commit 93e6f119c0ce ("ipc/mqueue: cleanup definition names and locations") added global hardcoded limits to the amount of message queues that can be created. While these limits are per-namespace, reality is that it ends up breaking userspace applications. Historically users have, at least in theory, been able to create up to INT_MAX queues, and limiting it to just 1024 is way too low and dramatic for some workloads and use cases. For instance, Madars reports: "This update imposes bad limits on our multi-process application. As our app uses approaches that each process opens its own set of queues (usually something about 3-5 queues per process). In some scenarios we might run up to 3000 processes or more (which of-course for linux is not a problem). Thus we might need up to 9000 queues or more. All processes run under one user." Other affected users can be found in launchpad bug #1155695: https://bugs.launchpad.net/ubuntu/+source/manpages/+bug/1155695 Instead of increasing this limit, revert it entirely and fallback to the original way of dealing queue limits -- where once a user's resource limit is reached, and all memory is used, new queues cannot be created. Signed-off-by: Davidlohr Bueso Reported-by: Madars Vitolins Acked-by: Doug Ledford Cc: Manfred Spraul Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit d1ea22966e9187b0b92f878a02686cbad4ab0d50 Author: Jan Kara Date: Thu Feb 20 17:02:27 2014 +0100 quota: Fix race between dqput() and dquot_scan_active() commit 1362f4ea20fa63688ba6026e586d9746ff13a846 upstream. Currently last dqput() can race with dquot_scan_active() causing it to call callback for an already deactivated dquot. The race is as follows: CPU1 CPU2 dqput() spin_lock(&dq_list_lock); if (atomic_read(&dquot->dq_count) > 1) { - not taken if (test_bit(DQ_ACTIVE_B, &dquot->dq_flags)) { spin_unlock(&dq_list_lock); ->release_dquot(dquot); if (atomic_read(&dquot->dq_count) > 1) - not taken dquot_scan_active() spin_lock(&dq_list_lock); if (!test_bit(DQ_ACTIVE_B, &dquot->dq_flags)) - not taken atomic_inc(&dquot->dq_count); spin_unlock(&dq_list_lock); - proceeds to release dquot ret = fn(dquot, priv); - called for inactive dquot Fix the problem by making sure possible ->release_dquot() is finished by the time we call the callback and new calls to it will notice reference dquot_scan_active() has taken and bail out. Signed-off-by: Jan Kara Signed-off-by: Jiri Slaby commit fea84e6b1cbfec4e124e06633a0d6febe7fad69a Author: Dan Williams Date: Wed Feb 19 16:19:35 2014 -0800 ioat: fix tasklet tear down commit da87ca4d4ca101f177fffd84f1f0a5e4c0343557 upstream. Since commit 77873803363c "net_dma: mark broken" we no longer pin dma engines active for the network-receive-offload use case. As a result the ->free_chan_resources() that occurs after the driver self test no longer has a NET_DMA induced ->alloc_chan_resources() to back it up. A late firing irq can lead to ksoftirqd spinning indefinitely due to the tasklet_disable() performed by ->free_chan_resources(). Only ->alloc_chan_resources() can clear this condition in affected kernels. This problem has been present since commit 3e037454bcfa "I/OAT: Add support for MSI and MSI-X" in 2.6.24, but is now exposed. Given the NET_DMA use case is deprecated we can revisit moving the driver to use threaded irqs. For now, just tear down the irq and tasklet properly by: 1/ Disable the irq from triggering the tasklet 2/ Disable the irq from re-arming 3/ Flush inflight interrupts 4/ Flush the timer 5/ Flush inflight tasklets References: https://lkml.org/lkml/2014/1/27/282 https://lkml.org/lkml/2014/2/19/672 Cc: Ingo Molnar Cc: Steven Rostedt Reported-by: Mike Galbraith Reported-by: Stanislav Fomichev Tested-by: Mike Galbraith Tested-by: Stanislav Fomichev Reviewed-by: Thomas Gleixner Signed-off-by: Dan Williams Signed-off-by: Jiri Slaby commit 6c46a5ba4a133fec554853cd27fb94211ccdefa1 Author: Eric Paris Date: Thu Feb 20 10:56:45 2014 -0500 SELinux: bigendian problems with filename trans rules commit 9085a6422900092886da8c404e1c5340c4ff1cbf upstream. When writing policy via /sys/fs/selinux/policy I wrote the type and class of filename trans rules in CPU endian instead of little endian. On x86_64 this works just fine, but it means that on big endian arch's like ppc64 and s390 userspace reads the policy and converts it from le32_to_cpu. So the values are all screwed up. Write the values in le format like it should have been to start. Signed-off-by: Eric Paris Acked-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Jiri Slaby commit d33ee5e7f8c3de1a6f407e3568ece84ec51db042 Author: Max Filippov Date: Wed Jan 22 08:04:43 2014 +0400 xtensa: introduce spill_registers_kernel macro commit e2fd1374c705abe4661df3fb6fadb3879c7c1846 upstream. Most in-kernel users want registers spilled on the kernel stack and don't require PS.EXCM to be set. That means that they don't need fixup routine and could reuse regular window overflow mechanism for that, which makes spill routine very simple. Suggested-by: Chris Zankel Signed-off-by: Max Filippov Signed-off-by: Jiri Slaby commit 38848e0b02a239b01e5d974a84b8a6b85bcaf48a Author: Max Filippov Date: Wed Oct 30 16:18:25 2013 +0400 xtensa: save current register frame in fast_syscall_spill_registers_fixup commit 3251f1e27a5a17f0efd436cfd1e7b9896cfab0a0 upstream. We need it saved because it contains a3 where we track which register windows we still need to spill, and fixup handler may call C exception handlers. Also fix comments. Signed-off-by: Max Filippov Signed-off-by: Jiri Slaby commit 054865c954ae9d31e5cfd1010e6e15a02d39ce96 Author: Andrew Lunn Date: Fri Feb 7 00:41:58 2014 +0100 irqchip: orion: Fix getting generic chip pointer. commit d86e9af6336c0ad586a5dbd70064253d40bbb5ff upstream. Enabling SPARSE_IRQ shows up a bug in the irq-orion bridge interrupt handler. The bridge interrupt is implemented using a single generic chip. Thus the parameter passed to irq_get_domain_generic_chip() should always be zero. Signed-off-by: Andrew Lunn Acked-by: Sebastian Hesselbarth Fixes: 9dbd90f17e4f ("irqchip: Add support for Marvell Orion SoCs") Signed-off-by: Jason Cooper Signed-off-by: Jiri Slaby commit 6b32598699db3b8f60ed3d2ffa50b880c95e1fd5 Author: Sebastian Hesselbarth Date: Fri Jan 24 00:10:32 2014 +0100 irqchip: orion: clear stale interrupts in irq_startup commit e0318ec3bf3f1502cd11b21b1eb00aa355b40b67 upstream. Bridge IRQ_CAUSE bits are asserted regardless of the corresponding bit in IRQ_MASK register. To avoid interrupt events on stale irqs, we have to clear them before unmask. This installs an .irq_startup callback to ensure stale irqs are cleared before initial unmask. Signed-off-by: Sebastian Hesselbarth Tested-by: Ezequiel Garcia Signed-off-by: Jason Cooper Signed-off-by: Jiri Slaby commit f702de8127e146a0d21be1bd532959c9ef9f4977 Author: Sebastian Hesselbarth Date: Thu Jan 23 23:38:05 2014 +0100 irqchip: orion: use handle_edge_irq on bridge irqs commit 5f40067fc86f0e49329ad4a852c278998ff4394e upstream. Bridge irqs are edge-triggered, i.e. they get asserted on low-to-high transitions and not on the level of the downstream interrupt line. This replaces handle_level_irq by the more appropriate handle_edge_irq. Signed-off-by: Sebastian Hesselbarth Tested-by: Ezequiel Garcia Signed-off-by: Jason Cooper Signed-off-by: Jiri Slaby commit dd14a330306a608820bb7eb4983443e6145483c7 Author: Sebastian Hesselbarth Date: Thu Jan 23 23:38:04 2014 +0100 irqchip: orion: clear bridge cause register on init commit 7b119fd1bdc59a8060df5b659b9f7a70e0169fd6 upstream. It is good practice to mask and clear pending irqs on init. We already mask all irqs, so also clear the bridge irq cause register. Signed-off-by: Sebastian Hesselbarth Tested-by: Ezequiel Garcia Signed-off-by: Jason Cooper Signed-off-by: Jiri Slaby commit de77ab8e1e55506d0e8759a13416935f5d0c8bc6 Author: Takashi Iwai Date: Mon Feb 24 15:23:10 2014 +0100 ALSA: hda - Add a fixup for HP Folio 13 mute LED commit 37c367ecdb9a01c9acc980e6e17913570a1788a7 upstream. HP Folio 13 may have a broken BIOS that doesn't set up the mute LED GPIO properly, and the driver guesses it wrongly, too. Add a new fixup entry for setting the GPIO pin statically for this laptop. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=70991 Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 290de678159b95d6f45f40214938c5a444eacad2 Author: Peter Zijlstra Date: Mon Feb 24 12:06:12 2014 +0100 perf: Fix hotplug splat commit e3703f8cdfcf39c25c4338c3ad8e68891cca3731 upstream. Drew Richardson reported that he could make the kernel go *boom* when hotplugging while having perf events active. It turned out that when you have a group event, the code in __perf_event_exit_context() fails to remove the group siblings from the context. We then proceed with destroying and freeing the event, and when you re-plug the CPU and try and add another event to that CPU, things go *boom* because you've still got dead entries there. Reported-by: Drew Richardson Signed-off-by: Peter Zijlstra Cc: Will Deacon Link: http://lkml.kernel.org/n/tip-k6v5wundvusvcseqj1si0oz0@git.kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Jiri Slaby commit 01ffe6154b9939874fb5d7d4cc59d66bec9ebb68 Author: Will Deacon Date: Thu Feb 6 14:59:05 2014 +0000 iommu/arm-smmu: set CBARn.BPSHCFG to NSH for s1-s2-bypass contexts commit 57ca90f6800987ac274d7ba065ae6692cdf9bcd7 upstream. Whilst trying to bring-up an SMMUv2 implementation with the table walker plumbed into a coherent interconnect, I noticed that the memory transactions targetting the CPU caches from the SMMU were marked as outer-shareable instead of inner-shareable. After a bunch of digging, it seems that we actually need to program CBARn.BPSHCFG for s1-s2-bypass contexts to act as non-shareable in order for the shareability configured in the corresponding TTBCR not to be overridden with an outer-shareable attribute. Signed-off-by: Will Deacon Signed-off-by: Jiri Slaby commit 011b7e12aeb92635e5ff3864f5ba6f388720f6ec Author: Will Deacon Date: Tue Feb 4 22:12:42 2014 +0000 iommu/arm-smmu: really fix page table locking commit c9d09e2748eaa55cac2af274574baa6368189bc1 upstream. Commit a44a9791e778 ("iommu/arm-smmu: use mutex instead of spinlock for locking page tables") replaced the page table spinlock with a mutex, to allow blocking allocations to satisfy lazy mapping requests. Unfortunately, it turns out that IOMMU mappings are created from atomic context (e.g. spinlock held during a dma_map), so this change doesn't really help us in practice. This patch is a partial revert of the offending commit, bringing back the original spinlock but replacing our page table allocations for any levels below the pgd (which is allocated during domain init) with GFP_ATOMIC instead of GFP_KERNEL. Reported-by: Andreas Herrmann Signed-off-by: Will Deacon Signed-off-by: Jiri Slaby commit d56a968ff1cebf05b44273e7698d4bdf8acb3caf Author: Yifan Zhang Date: Fri Jan 3 12:01:26 2014 +0000 iommu/arm-smmu: fix pud/pmd entry fill sequence commit 97a644208d1a08b7104d1fe2ace8cef011222711 upstream. The ARM SMMU driver's population of puds and pmds is broken, since we iterate over the next level of table repeatedly setting the current level descriptor to point at the pmd being initialised. This is clearly wrong when dealing with multiple pmds/puds. This patch fixes the problem by moving the pud/pmd population out of the loop and instead performing it when we allocate the next level (like we correctly do for ptes already). The starting address for the next level is then calculated prior to entering the loop. Signed-off-by: Yifan Zhang Signed-off-by: Will Deacon Signed-off-by: Jiri Slaby commit 4d1f2e2fa267b3196ccaa7b08419fc567391b28b Author: Denis CIOCCA Date: Fri Feb 14 14:15:00 2014 +0000 iio:gyro: bug on L3GD20H gyroscope support commit a0657716416f834ef7710a9044614d50a36c3bdc upstream. The driver was not able to manage the sensor: during probe function and wai check, the driver stops and writes: "device name and WhoAmI mismatch." The correct value of L3GD20H wai is 0xd7 instead of 0xd4. Dropped support for the sensor. Signed-off-by: Denis Ciocca Signed-off-by: Jonathan Cameron Signed-off-by: Jiri Slaby commit 4a25b0d3f0cd544c3829f50aedc4834da7f413ec Author: Manu Gupta Date: Mon Feb 24 12:12:28 2014 -0600 staging: r8188eu: Add new device ID commit 260ea9c2e2d330303163e286ab01b66dbcfe3a6f upstream. The D-Link DWA-123 REV D1 with USB ID 2001:3310 uses this driver. Signed-off-by: Manu Gupta Signed-off-by: Larry Finger Signed-off-by: Jiri Slaby commit e6608162af104fb8290e26a1c006747b0ac1ff6f Author: Arve Hjønnevåg Date: Mon Feb 17 13:58:29 2014 -0800 staging: binder: Fix death notifications commit e194fd8a5d8e0a7eeed239a8534460724b62fe2d upstream. The change (008fa749e0fe5b2fffd20b7fe4891bb80d072c6a) that moved the node release code to a separate function broke death notifications in some cases. When it encountered a reference without a death notification request, it would skip looking at the remaining references, and therefore fail to send death notifications for them. Cc: Colin Cross Cc: Android Kernel Team Signed-off-by: Arve Hjønnevåg Signed-off-by: John Stultz Signed-off-by: Jeremy Compostella Signed-off-by: Jiri Slaby Signed-off-by: Jiri Slaby commit d57db0b6149ad74940b07f8939fcdb3e578eea70 Author: Steve Twiss Date: Wed Feb 12 09:57:52 2014 +0000 regulator: da9063: Bug fix when setting max voltage on LDOs 5-11 commit ebf6dad0de89677aa58a4d8b009014ff88a23452 upstream. Bug fix to allow the setting of maximum voltage for certain LDOs. What the bug is: There is a problem caused by an invalid calculation of n_voltages in the driver. This n_voltages value has the potential to be different for each regulator. The value for linear_min_sel is set as DA9063_V##regl_name# which can be different depending upon the regulator. This is chosen according to the following definitions in the DA9063 registers.h file: DA9063_VLDO1_BIAS 0 DA9063_VLDO2_BIAS 0 DA9063_VLDO3_BIAS 0 DA9063_VLDO4_BIAS 0 DA9063_VLDO5_BIAS 2 DA9063_VLDO6_BIAS 2 DA9063_VLDO7_BIAS 2 DA9063_VLDO8_BIAS 2 DA9063_VLDO9_BIAS 3 DA9063_VLDO10_BIAS 2 DA9063_VLDO11_BIAS 2 The calculation for n_voltages is valid for LDOs whose BIAS value is zero but this is not correct for those LDOs which have a non-zero value. What the fix is: In order to take into account the non-zero linear_min_sel value which is set for the regulators LDO5, LDO6, LDO7, LDO8, LDO9, LDO10 and LDO11, the calculation for n_voltages should take into account the missing term defined by DA9063_V##regl_name#. This will in turn allow the core constraints calculation to set the maximum voltage limits correctly and therefore allow users to apply the maximum expected voltage to all of the LDOs. Signed-off-by: Steve Twiss Signed-off-by: Mark Brown Signed-off-by: Jiri Slaby commit 33328880843bac26ae1b8f62569dad13dd703bf0 Author: Lai Jiangshan Date: Sat Feb 15 22:02:28 2014 +0800 workqueue: ensure @task is valid across kthread_stop() commit 5bdfff96c69a4d5ab9c49e60abf9e070ecd2acbb upstream. When a kworker should die, the kworkre is notified through WORKER_DIE flag instead of kthread_should_stop(). This, IIRC, is primarily to keep the test synchronized inside worker_pool lock. WORKER_DIE is first set while holding pool->lock, the lock is dropped and kthread_stop() is called. Unfortunately, this means that there's a slight chance that the target kworker may see WORKER_DIE before kthread_stop() finishes and exits and frees the target task before or during kthread_stop(). Fix it by pinning the target task before setting WORKER_DIE and putting it after kthread_stop() is done. tj: Improved patch description and comment. Moved pinning above WORKER_DIE for better signify what it's protecting. Signed-off-by: Lai Jiangshan Signed-off-by: Tejun Heo Signed-off-by: Jiri Slaby commit 8a7cf765fa2a06c0e1e70dec1c68fc71c3ad27c8 Author: Guenter Roeck Date: Sat Feb 15 17:54:06 2014 -0800 hwmon: (max1668) Fix writing the minimum temperature commit 500a91571f0a5d0d3242d83802ea2fd1faccc66e upstream. When trying to set the minimum temperature, the driver was erroneously writing the maximum temperature into the chip. Signed-off-by: Guenter Roeck Reviewed-by: Jean Delvare Signed-off-by: Jiri Slaby commit e4df71a87ab45902153c799a9873758ef87040b0 Author: Chao Bi Date: Wed Feb 12 21:27:25 2014 +0200 mei: set client's read_cb to NULL when flow control fails commit accb884b32e82f943340688c9cd30290531e73e0 upstream. In mei_cl_read_start(), if it fails to send flow control request, it will release "cl->read_cb" but forget to set pointer to NULL, leaving "cl->read_cb" still pointing to random memory, next time this client is operated like mei_release(), it has chance to refer to this wrong pointer. Fixes: PANIC at kfree in mei_release() [228781.826904] Call Trace: [228781.829737] [] ? mei_cl_unlink+0x48/0xa0 [228781.835283] [] mei_io_cb_free+0x17/0x30 [228781.840733] [] mei_release+0xa8/0x180 [228781.845989] [] ? __fsnotify_parent+0xa0/0xf0 [228781.851925] [] __fput+0xd9/0x200 [228781.856696] [] ____fput+0xd/0x10 [228781.861467] [] task_work_run+0x81/0xb0 [228781.866821] [] do_exit+0x283/0xa00 [228781.871786] [] ? kprobe_flush_task+0x66/0xc0 [228781.877722] [] ? __dequeue_signal+0x18/0x1a0 [228781.883657] [] ? dequeue_signal+0x32/0x190 [228781.889397] [] do_group_exit+0x34/0xa0 [228781.894750] [] get_signal_to_deliver+0x206/0x610 [228781.901075] [] do_signal+0x38/0x100 [228781.906136] [] ? mei_read+0x42c/0x4e0 [228781.911393] [] ? wake_up_bit+0x30/0x30 [228781.916745] [] ? mei_poll+0x120/0x120 [228781.922001] [] ? vfs_read+0x89/0x160 [228781.927158] [] ? mei_poll+0x120/0x120 [228781.932414] [] ? fget_light+0x44/0xe0 [228781.937670] [] ? SyS_read+0x68/0x80 [228781.942730] [] do_notify_resume+0x55/0x70 [228781.948376] [] work_notifysig+0x29/0x30 [228781.953827] [] ? bad_area+0x5/0x3e Signed-off-by: Chao Bi Signed-off-by: Tomas Winkler Signed-off-by: Jiri Slaby commit 991b48fbe9eab5338ca1d6d35ff201314782bc90 Author: Joerg Dorchain Date: Fri Feb 21 20:29:33 2014 +0100 USB: ftdi_sio: add Cressi Leonardo PID commit 6dbd46c849e071e6afc1e0cad489b0175bca9318 upstream. Hello, the following patch adds an entry for the PID of a Cressi Leonardo diving computer interface to kernel 3.13.0. It is detected as FT232RL. Works with subsurface. Signed-off-by: Joerg Dorchain Signed-off-by: Jiri Slaby commit bdb95b2e48479c4c7bcf522e3605d1a2f8ae8438 Author: Stanislaw Gruszka Date: Wed Feb 19 10:29:01 2014 +0100 usb: ehci: fix deadlock when threadirqs option is used commit a1227f3c1030e96ebc51d677d2f636268845c5fb upstream. ehci_irq() and ehci_hrtimer_func() can deadlock on ehci->lock when threadirqs option is used. To prevent the deadlock use spin_lock_irqsave() in ehci_irq(). This change can be reverted when hrtimer callbacks become threaded. Signed-off-by: Stanislaw Gruszka Acked-by: Alan Stern Signed-off-by: Jiri Slaby commit b2f20b15e450bb7f1b7f8c67647dc3815b127ca5 Author: Alan Stern Date: Thu Feb 13 15:49:17 2014 -0500 USB: EHCI: add delay during suspend to prevent erroneous wakeups commit 3e8d6d85adedc59115a564c0a54b36e42087c4d9 upstream. High-speed USB connections revert back to full-speed signalling when the device goes into suspend. This takes several milliseconds, and during that time it's not possible to tell reliably whether the device has been disconnected. On some platforms, the Wake-On-Disconnect circuitry gets confused during this intermediate state. It generates a false wakeup signal, which can prevent the controller from going to sleep. To avoid this problem, this patch adds a 5-ms delay to the ehci_bus_suspend() routine if any ports have to switch over to full-speed signalling. (Actually, the delay was already present for devices using a particular kind of PHY power management; the patch merely causes the delay to be used more widely.) Signed-off-by: Alan Stern Reviewed-by: Peter Chen Signed-off-by: Jiri Slaby commit 1147f2e9f9227a83fa649a752590f385975b6180 Author: Aleksander Morgado Date: Wed Feb 12 16:04:45 2014 +0100 USB: serial: option: blacklist interface 4 for Cinterion PHS8 and PXS8 commit 12df84d4a80278a5b1abfec3206795291da52fc9 upstream. This interface is to be handled by the qmi_wwan driver. CC: Hans-Christoph Schemmel CC: Christian Schmiedl CC: Nicolaus Colberg CC: David McCullough Signed-off-by: Aleksander Morgado Signed-off-by: Jiri Slaby commit 4c0ef1b1273671d62dcc341664be3023e2af87ce Author: Florian Fainelli Date: Tue Jan 14 15:36:29 2014 -0800 usb: gadget: bcm63xx_udc: fix build failure on DMA channel code commit 2d1f7af3d60dd09794e0738a915d272c6c27abc5 upstream. Commit 3dc6475 ("bcm63xx_enet: add support Broadcom BCM6345 Ethernet") changed the ENETDMA[CS] macros such that they are no longer macros, but actual register offset definitions. The bcm63xx_udc driver was not updated, and as a result, causes the following build error to pop up: CC drivers/usb/gadget/u_ether.o drivers/usb/gadget/bcm63xx_udc.c: In function 'iudma_write': drivers/usb/gadget/bcm63xx_udc.c:642:24: error: called object '0' is not a function drivers/usb/gadget/bcm63xx_udc.c: In function 'iudma_reset_channel': drivers/usb/gadget/bcm63xx_udc.c:698:46: error: called object '0' is not a function drivers/usb/gadget/bcm63xx_udc.c:700:49: error: called object '0' is not a function Fix this by updating usb_dmac_{read,write}l and usb_dmas_{read,write}l to take an extra channel argument, and use the channel width (ENETDMA_CHAN_WIDTH) to offset the register we want to access, hence doing again what the macro implicitely did for us. Cc: Kevin Cernekee Cc: Jonas Gorski Signed-off-by: Florian Fainelli Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit 2e7a84eab131472ea8f413428a9bdedd54a143b5 Author: Matthieu CASTET Date: Wed Feb 19 13:46:31 2014 +0800 usb: chipidea: need to mask when writting endptflush and endptprime commit 5bf5dbeda2454296f1984adfbfc8e6f5965ac389 upstream. ENDPTFLUSH and ENDPTPRIME registers are set by software and clear by hardware. There is a bit for each endpoint. When we are setting a bit for an endpoint we should make sure we do not touch other endpoint bit. There is a race condition if the hardware clear the bit between the read and the write in hw_write. Signed-off-by: Peter Chen Signed-off-by: Matthieu CASTET Tested-by: Michael Grzeschik Signed-off-by: Jiri Slaby commit a2879c1d14a1bd066b2597d778fb9d89d05bdab0 Author: Olivier Sobrie Date: Tue Feb 11 11:01:23 2014 +0100 can: kvaser_usb: check number of channels returned by HW commit 862474f8b46f6c1e600d4934e40ba40646c696ec upstream. It is needed to check the number of channels returned by the HW because it cannot be greater than MAX_NET_DEVICES otherwise it will crash. Signed-off-by: Olivier Sobrie Signed-off-by: Marc Kleine-Budde Signed-off-by: Jiri Slaby commit 358b2ae8062c24bce75df14b1c5bce063901e96a Author: Lan Tianyu Date: Wed Feb 26 21:03:05 2014 +0800 ACPI / processor: Rework processor throttling with work_on_cpu() commit f3ca4164529b875374c410193bbbac0ee960895f upstream. acpi_processor_set_throttling() uses set_cpus_allowed_ptr() to make sure that the (struct acpi_processor)->acpi_processor_set_throttling() callback will run on the right CPU. However, the function may be called from a worker thread already bound to a different CPU in which case that won't work. Make acpi_processor_set_throttling() use work_on_cpu() as appropriate instead of abusing set_cpus_allowed_ptr(). Reported-and-tested-by: Jiri Olsa Signed-off-by: Lan Tianyu [rjw: Changelog] Signed-off-by: Rafael J. Wysocki Signed-off-by: Jiri Slaby commit c3fb946f7cabc1eb767b2c6ae42916b8fd358578 Author: Hans de Goede Date: Thu Feb 13 16:32:51 2014 +0100 ACPI / video: Filter the _BCL table for duplicate brightness values commit bd8ba20597f0cfef3ef65c3fd2aa92ab23d4c8e1 upstream. Some devices have duplicate entries in there brightness levels table, ie on my Dell Latitude E6430 the table looks like this: [ 3.686060] acpi backlight index 0, val 80 [ 3.686095] acpi backlight index 1, val 50 [ 3.686122] acpi backlight index 2, val 5 [ 3.686147] acpi backlight index 3, val 5 [ 3.686172] acpi backlight index 4, val 5 [ 3.686197] acpi backlight index 5, val 5 [ 3.686223] acpi backlight index 6, val 5 [ 3.686248] acpi backlight index 7, val 5 [ 3.686273] acpi backlight index 8, val 6 [ 3.686332] acpi backlight index 9, val 7 [ 3.686356] acpi backlight index 10, val 8 [ 3.686380] acpi backlight index 11, val 9 etc. Notice that brightness values 0-5 are all mapped to 5. This means that if userspace writes any value between 0 and 5 to the brightness sysfs attribute and then reads it, it will always return 0, which is somewhat unexpected. This is a problem for ie gnome-settings-daemon, which uses read-modify-write logic when the users presses the brightness up or down keys. This is done this way to take brightness changes from other sources into account. On this specific laptop what happens once the brightness has been set to 0, is that gsd reads 0, adds 5, writes 5, and on the next brightness up key press again reads 0, so things get stuck at the lowest brightness setting. Filtering out the duplicate table entries, makes any write to brightness read back as the written value as one would expect, fixing this. Signed-off-by: Hans de Goede Reviewed-by: Aaron Lu Signed-off-by: Rafael J. Wysocki Signed-off-by: Jiri Slaby commit ef0f10d829ab82b2a2cd8e2dca317027d2110237 Author: Jean Delvare Date: Mon Feb 24 09:39:27 2014 +0100 i7core_edac: Fix PCI device reference count commit c0f5eeed0f4cef4f05b74883a7160e7edde58b6a upstream. The reference count changes done by pci_get_device can be a little misleading when the usage diverges from the most common scheme. The reference count of the device passed as the last parameter is always decreased, even if the function returns no new device. So if we are going to try alternative device IDs, we must manually increment the device reference count before each retry. If we don't, we end up decreasing the reference count, and after a few modprobe/rmmod cycles the PCI devices will vanish. In other words and as Alan put it: without this fix the EDAC code corrupts the PCI device list. This fixes kernel bug #50491: https://bugzilla.kernel.org/show_bug.cgi?id=50491 Signed-off-by: Jean Delvare Link: http://lkml.kernel.org/r/20140224093927.7659dd9d@endymion.delvare Reviewed-by: Alan Cox Cc: Mauro Carvalho Chehab Cc: Doug Thompson Signed-off-by: Borislav Petkov Signed-off-by: Jiri Slaby commit bb0a8dd760df353a9ca6c52ddb07d959272595ca Author: Tomasz Nowicki Date: Mon Feb 10 14:00:11 2014 +0100 ACPI / PCI: Fix memory leak in acpi_pci_irq_enable() commit b685f3b1744061aa9ad822548ba9c674de5be7c6 upstream. acpi_pci_link_allocate_irq() can return negative gsi even if entry != NULL. For that case we have a memory leak, so free entry before returning from acpi_pci_irq_enable() for gsi < 0. Signed-off-by: Tomasz Nowicki [rjw: Subject and changelog] Signed-off-by: Rafael J. Wysocki Signed-off-by: Jiri Slaby commit f77706d47ac3ed59419bd61aaa2ae6d2b0fba029 Author: Bjorn Helgaas Date: Fri Feb 14 13:48:16 2014 -0700 PCI: Enable INTx if BIOS left them disabled commit 1f42db786b14a31bf807fc41ee5583a00c08fcb1 upstream. Some firmware leaves the Interrupt Disable bit set even if the device uses INTx interrupts. Clear Interrupt Disable so we get those interrupts. Based on the report mentioned below, if the user selects the "EHCI only" option in the Intel Baytrail BIOS, the EHCI device is handed off to the OS with the PCI_COMMAND_INTX_DISABLE bit set. Link: http://lkml.kernel.org/r/20140114181721.GC12126@xanatos Link: https://bugzilla.kernel.org/show_bug.cgi?id=70601 Reported-by: Chris Cheng Reported-and-tested-by: Jamie Chen Signed-off-by: Bjorn Helgaas CC: Sarah Sharp Signed-off-by: Jiri Slaby commit 32360b61a818531417b997583fda23d9675346af Author: Andrew Lunn Date: Wed Feb 5 11:55:49 2014 +0100 PCI: mvebu: Use Device ID and revision from underlying endpoint commit 322a8e91844f4ae2093e0d3d8a318d0ef2596756 upstream. Marvell SoCs place the SoC number into the PCIe endpoint device ID. The SoC stepping is placed into the PCIe revision. The old plat-orion PCIe driver allowed this information to be seen in user space with a simple lspci command. The new driver places a virtual PCI-PCI bridge on top of these endpoints. It has its own hard coded PCI device ID. Thus it is no longer possible to see what the SoC is using lspci. When initializing the PCI-PCI bridge, set its device ID and revision from the underlying endpoint, thus restoring this functionality. Debian would like to use this in order to aid installing the correct DTB file. Fixes: 45361a4fe4464 ("pci: PCIe driver for Marvell Armada 370/XP systems") Signed-off-by: Andrew Lunn Signed-off-by: Bjorn Helgaas Acked-by: Thomas Petazzoni Acked-by: Jason Cooper Signed-off-by: Jiri Slaby commit 493931434ba8f6d2b9b1ea1cc377c22787bb3bd7 Author: Srivatsa S. Bhat Date: Mon Feb 17 16:18:21 2014 +0530 cpufreq: powernow-k8: Initialize per-cpu data-structures properly commit c3274763bfc3bf1ececa269ed6e6c4d7ec1c3e5e upstream. The powernow-k8 driver maintains a per-cpu data-structure called powernow_data that is used to perform the frequency transitions. It initializes this data structure only for the policy->cpu. So, accesses to this data structure by other CPUs results in various problems because they would have been uninitialized. Specifically, if a cpu (!= policy->cpu) invokes the drivers' ->get() function, it returns 0 as the KHz value, since its per-cpu memory doesn't point to anything valid. This causes problems during suspend/resume since cpufreq_update_policy() tries to enforce this (0 KHz) as the current frequency of the CPU, and this madness gets propagated to adjust_jiffies() as well. Eventually, lots of things start breaking down, including the r8169 ethernet card, in one particularly interesting case reported by Pierre Ossman. Fix this by initializing the per-cpu data-structures of all the CPUs in the policy appropriately. References: https://bugzilla.kernel.org/show_bug.cgi?id=70311 Reported-by: Pierre Ossman Signed-off-by: Srivatsa S. Bhat Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Jiri Slaby commit bbff349264e736651e87bc6937882529b5441d47 Author: Tejun Heo Date: Mon Feb 3 10:42:07 2014 -0500 sata_sil: apply MOD15WRITE quirk to TOSHIBA MK2561GSYN commit 9f9c47f00ce99329b1a82e2ac4f70f0fe3db549c upstream. It's a bit odd to see a newer device showing mod15write; however, the reported behavior is highly consistent and other factors which could contribute seem to have been verified well enough. Also, both sata_sil itself and the drive are fairly outdated at this point making the risk of this change fairly low. It is possible, probably likely, that other drive models in the same family have the same problem; however, for now, let's just add the specific model which was tested. Signed-off-by: Tejun Heo Reported-by: matson References: http://lkml.kernel.org/g/201401211912.s0LJCk7F015058@rs103.luxsci.com Signed-off-by: Jiri Slaby commit d5772bfe2ddd46c0a59bae0f776be249f48a9db0 Author: Denis V. Lunev Date: Thu Jan 30 15:20:30 2014 +0400 ata: enable quirk from jmicron JMB350 for JMB394 commit efb9e0f4f43780f0ae0c6428d66bd03e805c7539 upstream. Without the patch the kernel generates the following error. ata11.15: SATA link up 1.5 Gbps (SStatus 113 SControl 310) ata11.15: Port Multiplier vendor mismatch '0x197b' != '0x123' ata11.15: PMP revalidation failed (errno=-19) ata11.15: failed to recover PMP after 5 tries, giving up This patch helps to bypass this error and the device becomes functional. Signed-off-by: Denis V. Lunev Signed-off-by: Tejun Heo Cc: Signed-off-by: Jiri Slaby commit 04f4e59ba8d8d7db9fad2c1cee1d4ac6dc8bd7c5 Author: Peter Zijlstra Date: Fri Feb 21 16:03:12 2014 +0100 perf/x86: Fix event scheduling commit 26e61e8939b1fe8729572dabe9a9e97d930dd4f6 upstream. Vince "Super Tester" Weaver reported a new round of syscall fuzzing (Trinity) failures, with perf WARN_ON()s triggering. He also provided traces of the failures. This is I think the relevant bit: > pec_1076_warn-2804 [000] d... 147.926153: x86_pmu_disable: x86_pmu_disable > pec_1076_warn-2804 [000] d... 147.926153: x86_pmu_state: Events: { > pec_1076_warn-2804 [000] d... 147.926156: x86_pmu_state: 0: state: .R config: ffffffffffffffff ( (null)) > pec_1076_warn-2804 [000] d... 147.926158: x86_pmu_state: 33: state: AR config: 0 (ffff88011ac99800) > pec_1076_warn-2804 [000] d... 147.926159: x86_pmu_state: } > pec_1076_warn-2804 [000] d... 147.926160: x86_pmu_state: n_events: 1, n_added: 0, n_txn: 1 > pec_1076_warn-2804 [000] d... 147.926161: x86_pmu_state: Assignment: { > pec_1076_warn-2804 [000] d... 147.926162: x86_pmu_state: 0->33 tag: 1 config: 0 (ffff88011ac99800) > pec_1076_warn-2804 [000] d... 147.926163: x86_pmu_state: } > pec_1076_warn-2804 [000] d... 147.926166: collect_events: Adding event: 1 (ffff880119ec8800) So we add the insn:p event (fd[23]). At this point we should have: n_events = 2, n_added = 1, n_txn = 1 > pec_1076_warn-2804 [000] d... 147.926170: collect_events: Adding event: 0 (ffff8800c9e01800) > pec_1076_warn-2804 [000] d... 147.926172: collect_events: Adding event: 4 (ffff8800cbab2c00) We try and add the {BP,cycles,br_insn} group (fd[3], fd[4], fd[15]). These events are 0:cycles and 4:br_insn, the BP event isn't x86_pmu so that's not visible. group_sched_in() pmu->start_txn() /* nop - BP pmu */ event_sched_in() event->pmu->add() So here we should end up with: 0: n_events = 3, n_added = 2, n_txn = 2 4: n_events = 4, n_added = 3, n_txn = 3 But seeing the below state on x86_pmu_enable(), the must have failed, because the 0 and 4 events aren't there anymore. Looking at group_sched_in(), since the BP is the leader, its event_sched_in() must have succeeded, for otherwise we would not have seen the sibling adds. But since neither 0 or 4 are in the below state; their event_sched_in() must have failed; but I don't see why, the complete state: 0,0,1:p,4 fits perfectly fine on a core2. However, since we try and schedule 4 it means the 0 event must have succeeded! Therefore the 4 event must have failed, its failure will have put group_sched_in() into the fail path, which will call: event_sched_out() event->pmu->del() on 0 and the BP event. Now x86_pmu_del() will reduce n_events; but it will not reduce n_added; giving what we see below: n_event = 2, n_added = 2, n_txn = 2 > pec_1076_warn-2804 [000] d... 147.926177: x86_pmu_enable: x86_pmu_enable > pec_1076_warn-2804 [000] d... 147.926177: x86_pmu_state: Events: { > pec_1076_warn-2804 [000] d... 147.926179: x86_pmu_state: 0: state: .R config: ffffffffffffffff ( (null)) > pec_1076_warn-2804 [000] d... 147.926181: x86_pmu_state: 33: state: AR config: 0 (ffff88011ac99800) > pec_1076_warn-2804 [000] d... 147.926182: x86_pmu_state: } > pec_1076_warn-2804 [000] d... 147.926184: x86_pmu_state: n_events: 2, n_added: 2, n_txn: 2 > pec_1076_warn-2804 [000] d... 147.926184: x86_pmu_state: Assignment: { > pec_1076_warn-2804 [000] d... 147.926186: x86_pmu_state: 0->33 tag: 1 config: 0 (ffff88011ac99800) > pec_1076_warn-2804 [000] d... 147.926188: x86_pmu_state: 1->0 tag: 1 config: 1 (ffff880119ec8800) > pec_1076_warn-2804 [000] d... 147.926188: x86_pmu_state: } > pec_1076_warn-2804 [000] d... 147.926190: x86_pmu_enable: S0: hwc->idx: 33, hwc->last_cpu: 0, hwc->last_tag: 1 hwc->state: 0 So the problem is that x86_pmu_del(), when called from a group_sched_in() that fails (for whatever reason), and without x86_pmu TXN support (because the leader is !x86_pmu), will corrupt the n_added state. Reported-and-Tested-by: Vince Weaver Signed-off-by: Peter Zijlstra Cc: Paul Mackerras Cc: Steven Rostedt Cc: Stephane Eranian Cc: Dave Jones Link: http://lkml.kernel.org/r/20140221150312.GF3104@twins.programming.kicks-ass.net Signed-off-by: Ingo Molnar Signed-off-by: Jiri Slaby commit 42458ecf9f1498ff0b227b59b23eee9890abbc12 Author: Marek Szyprowski Date: Fri Jan 24 14:49:58 2014 +0100 x86: dma-mapping: fix GFP_ATOMIC macro usage commit c091c71ad2218fc50a07b3d1dab85783f3b77efd upstream. GFP_ATOMIC is not a single gfp flag, but a macro which expands to the other flags, where meaningful is the LACK of __GFP_WAIT flag. To check if caller wants to perform an atomic allocation, the code must test for a lack of the __GFP_WAIT flag. This patch fixes the issue introduced in v3.5-rc1. Signed-off-by: Marek Szyprowski Signed-off-by: Jiri Slaby commit 7addaee35a868cd036c0d5a64388380ce47c1bc5 Author: Levente Kurusa Date: Tue Feb 18 10:22:17 2014 -0500 ahci: disable NCQ on Samsung pci-e SSDs on macbooks commit 67809f85d31eac600f6b28defa5386c9d2a13b1d upstream. Samsung's pci-e SSDs with device ID 0x1600 which are found on some macbooks time out on NCQ commands. Blacklist NCQ on the device so that the affected machines can at least boot. Original-patch-by: Levente Kurusa Signed-off-by: Tejun Heo Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60731 Signed-off-by: Jiri Slaby commit 370dd2d91350c6c6ffcff910b191dc95eb31c7a1 Author: Laurent Dufour Date: Mon Feb 24 17:30:55 2014 +0100 powerpc/crashdump : Fix page frame number check in copy_oldmem_page commit f5295bd8ea8a65dc5eac608b151386314cb978f1 upstream. In copy_oldmem_page, the current check using max_pfn and min_low_pfn to decide if the page is backed or not, is not valid when the memory layout is not continuous. This happens when running as a QEMU/KVM guest, where RTAS is mapped higher in the memory. In that case max_pfn points to the end of RTAS, and a hole between the end of the kdump kernel and RTAS is not backed by PTEs. As a consequence, the kdump kernel is crashing in copy_oldmem_page when accessing in a direct way the pages in that hole. This fix relies on the memblock's service memblock_is_region_memory to check if the read page is part or not of the directly accessible memory. Signed-off-by: Laurent Dufour Tested-by: Mahesh Salgaonkar Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Jiri Slaby commit 4fe2fdcab4dfef44f48e19c8ffabbbe7401f031f Author: Tony Breeds Date: Thu Feb 20 21:13:52 2014 +1100 powerpc/le: Ensure that the 'stop-self' RTAS token is handled correctly commit 41dd03a94c7d408d2ef32530545097f7d1befe5c upstream. Currently we're storing a host endian RTAS token in rtas_stop_self_args.token. We then pass that directly to rtas. This is fine on big endian however on little endian the token is not what we expect. This will typically result in hitting: panic("Alas, I survived.\n"); To fix this we always use the stop-self token in host order and always convert it to be32 before passing this to rtas. Signed-off-by: Tony Breeds Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Jiri Slaby commit 5a99ca7fc8b4d2c3e01f3caab239ea9e96d81efc Author: Paul Mackerras Date: Wed Feb 26 17:07:38 2014 +1100 powerpc: Increase stack redzone for 64-bit userspace to 512 bytes commit 573ebfa6601fa58b439e7f15828762839ccd306a upstream. The new ELFv2 little-endian ABI increases the stack redzone -- the area below the stack pointer that can be used for storing data -- from 288 bytes to 512 bytes. This means that we need to allow more space on the user stack when delivering a signal to a 64-bit process. To make the code a bit clearer, we define new USER_REDZONE_SIZE and KERNEL_REDZONE_SIZE symbols in ptrace.h. For now, we leave the kernel redzone size at 288 bytes, since increasing it to 512 bytes would increase the size of interrupt stack frames correspondingly. Gcc currently only makes use of 288 bytes of redzone even when compiling for the new little-endian ABI, and the kernel cannot currently be compiled with the new ABI anyway. In the future, hopefully gcc will provide an option to control the amount of redzone used, and then we could reduce it even more. This also changes the code in arch_compat_alloc_user_space() to preserve the expanded redzone. It is not clear why this function would ever be used on a 64-bit process, though. Signed-off-by: Paul Mackerras Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Jiri Slaby commit 9f93a183e6266283dce26ad92855ba7b7472c9cd Author: Trond Myklebust Date: Sun Feb 16 12:14:13 2014 -0500 SUNRPC: Ensure that gss_auth isn't freed before its upcall messages commit 9eb2ddb48ce3a7bd745c14a933112994647fa3cd upstream. Fix a race in which the RPC client is shutting down while the gss daemon is processing a downcall. If the RPC client manages to shut down before the gss daemon is done, then the struct gss_auth used in gss_release_msg() may have already been freed. Link: http://lkml.kernel.org/r/1392494917.71728.YahooMailNeo@web140002.mail.bf1.yahoo.com Reported-by: John Reported-by: Borislav Petkov Signed-off-by: Trond Myklebust Signed-off-by: Jiri Slaby commit d1c07003693c1944ef9ee8ad484c61be61829ce7 Author: Trond Myklebust Date: Tue Feb 11 09:15:54 2014 -0500 SUNRPC: Fix races in xs_nospace() commit 06ea0bfe6e6043cb56a78935a19f6f8ebc636226 upstream. When a send failure occurs due to the socket being out of buffer space, we call xs_nospace() in order to have the RPC task wait until the socket has drained enough to make it worth while trying again. The current patch fixes a race in which the socket is drained before we get round to setting up the machinery in xs_nospace(), and which is reported to cause hangs. Link: http://lkml.kernel.org/r/20140210170315.33dfc621@notabene.brown Fixes: a9a6b52ee1ba (SUNRPC: Don't start the retransmission timer...) Reported-by: Neil Brown Signed-off-by: Trond Myklebust Signed-off-by: Jiri Slaby commit a50b12e295695ad225f1fbe6aa376cf16c10a2d8 Author: Lars-Peter Clausen Date: Sat Feb 22 18:30:13 2014 +0100 ASoC: wm8958-dsp: Fix firmware block loading commit 548da08fc1e245faf9b0d7c41ecd8e07984fc332 upstream. The codec->control_data contains a pointer to the device's regmap struct. But wm8994_bulk_write() expects a pointer to the parent wm8998 device. The issue was introduced in commit d9a7666f ("ASoC: Remove ASoC-specific WM8994 I/O code"). Fixes: d9a7666f ("ASoC: Remove ASoC-specific WM8994 I/O code") Signed-off-by: Lars-Peter Clausen Signed-off-by: Mark Brown Signed-off-by: Jiri Slaby commit 75a6bf2f43f3898ee5ccdfb69e0e882c0bf77cd8 Author: Takashi Iwai Date: Tue Feb 18 09:24:12 2014 +0100 ASoC: sta32x: Fix array access overflow commit 025c3fa9256d4c54506b7a29dc3befac54f5c68d upstream. Preset EQ enum of sta32x codec driver declares too many number of items and it may lead to the access over the actual array size. Use SOC_ENUM_SINGLE_DECL() helper and it's automatically fixed. Signed-off-by: Takashi Iwai Acked-by: Liam Girdwood Acked-by: Lars-Peter Clausen Signed-off-by: Mark Brown Signed-off-by: Jiri Slaby commit b0ece0bec2fa55e50ca87bede9bb6e3852113da5 Author: Takashi Iwai Date: Thu Feb 27 07:41:32 2014 +0100 ASoC: sta32x: Fix wrong enum for limiter2 release rate commit b3619b288b621e63f66908045f48495869a996a6 upstream. There is a typo in the Limiter2 Release Rate control, a wrong enum for Limiter1 is assigned. It must point to Limiter2. Spotted by a compile warning: In file included from sound/soc/codecs/sta32x.c:34:0: sound/soc/codecs/sta32x.c:223:29: warning: ‘sta32x_limiter2_release_rate_enum’ defined but not used [-Wunused-variable] static SOC_ENUM_SINGLE_DECL(sta32x_limiter2_release_rate_enum, ^ include/sound/soc.h:275:18: note: in definition of macro ‘SOC_ENUM_DOUBLE_DECL’ struct soc_enum name = SOC_ENUM_DOUBLE(xreg, xshift_l, xshift_r, \ ^ sound/soc/codecs/sta32x.c:223:8: note: in expansion of macro ‘SOC_ENUM_SINGLE_DECL’ static SOC_ENUM_SINGLE_DECL(sta32x_limiter2_release_rate_enum, ^ Signed-off-by: Takashi Iwai Signed-off-by: Mark Brown Signed-off-by: Jiri Slaby commit 2111b6ea6352feb44c504c717d789d7405461a0c Author: Lars-Peter Clausen Date: Sat Feb 22 18:27:17 2014 +0100 ASoC: sta32x: Fix cache sync commit 70ff00f82a6af0ff68f8f7b411738634ce2f20d0 upstream. codec->control_data contains a pointer to the regmap struct of the device, not to the device private data. Use snd_soc_codec_get_drvdata() instead. The issue was introduced in commit 29fdf4fbbe ("ASoC: sta32x: Convert to regmap"). Fixes: 29fdf4fbbe (ASoC: sta32x: Convert to regmap) Signed-off-by: Lars-Peter Clausen Signed-off-by: Mark Brown Signed-off-by: Jiri Slaby commit 3e23d43ae84e765279660fe99438ae572440b49e Author: Mark Brown Date: Mon Feb 24 11:59:14 2014 +0900 ASoC: da732x: Mark DC offset control registers volatile commit 75306820248e26d15d84acf4e297b9fb27dd3bb2 upstream. The driver reads from the DC offset control registers during callibration but since the registers are marked as volatile and there is a register cache the values will not be read from the hardware after the first reading rendering the callibration ineffective. It appears that the driver was originally written for the ASoC level register I/O code but converted to regmap prior to merge and this issue was missed during the conversion as the framework level volatile register functionality was not being used. Signed-off-by: Mark Brown Acked-by: Adam Thomson Signed-off-by: Jiri Slaby commit 9ea6f4ae77698352daa516edef1d7d098d31f583 Author: Takashi Iwai Date: Tue Feb 18 09:37:30 2014 +0100 ASoC: wm8770: Fix wrong number of enum items commit 7a6c0a58dc824523966f212c76322d47c5b0e6fe upstream. wm8770 codec driver defines ain_enum with a wrong number of items. Use SOC_ENUM_DOUBLE_DECL() macro and it's automatically fixed. Signed-off-by: Takashi Iwai Acked-by: Liam Girdwood Acked-by: Charles Keepax Acked-by: Lars-Peter Clausen Signed-off-by: Mark Brown Signed-off-by: Jiri Slaby commit 2b7cd16cd2192c7aeb2c372f8955e70488fae977 Author: Dylan Reid Date: Wed Feb 12 10:24:54 2014 -0800 ASoC: max98090: sync regcache on entering STANDBY commit c42c8922c46d33ed769e99618bdfba06866a0c72 upstream. Sync regcache when entering STANDBY from OFF. ON isn't entered with OFF as the current state, so the registers were not being re-synced after suspend/resume. The 98088 and 98095 already call regcache_sync from STANDBY. Signed-off-by: Dylan Reid Signed-off-by: Mark Brown Signed-off-by: Jiri Slaby commit 2fa08dea6fc382e07829788baa35cf0a11ca9e9f Author: Alexander Shiyan Date: Sat Feb 15 23:28:29 2014 +0400 ASoC: txx9aclc_ac97: Fix kernel crash on probe commit 9febd494d15c4a351e9c9cae7184643144eea892 upstream. This patch fixes a crash caused by commit 3bed3344c826 (ASoC: txx9aclc_ac97: Convert to devm_ioremap_resource()). This is an attempt to assign "drvdata->base" while memory for "drvdata" is not already allocated. Fixes: 3bed3344c826 (ASoC: txx9aclc_ac97: Convert to devm_ioremap_resource()) Signed-off-by: Alexander Shiyan Signed-off-by: Mark Brown Signed-off-by: Jiri Slaby commit f9b501bf0525f95454ca4c7af764e1758ecefedd Author: Adam Thomson Date: Thu Feb 6 18:03:07 2014 +0000 ASoC: da9055: Fix device registration of PMIC and CODEC devices commit 07b0e5b10258b48e5edfb6c8ac156f05510eb775 upstream. Currently the I2C device Ids conflict for the MFD and CODEC so cannot be both instantiated on one platform. This patch updates the Ids and names to make them unique from each other. It should be noted that the I2C addresses for both PMIC and CODEC are modifiable so instantiation of the two are kept as separate devices, rather than instantiating the CODEC from the MFD code. Signed-off-by: Adam Thomson Acked-by: Mark Brown Signed-off-by: Mark Brown Signed-off-by: Jiri Slaby commit ee593d3a91514d37f19251daa9d57edfb27e45e7 Author: Andrew Honig Date: Thu Feb 27 19:35:14 2014 +0100 kvm: x86: fix emulator buffer overflow (CVE-2014-0049) commit a08d3b3b99efd509133946056531cdf8f3a0c09b upstream. The problem occurs when the guest performs a pusha with the stack address pointing to an mmio address (or an invalid guest physical address) to start with, but then extending into an ordinary guest physical address. When doing repeated emulated pushes emulator_read_write sets mmio_needed to 1 on the first one. On a later push when the stack points to regular memory, mmio_nr_fragments is set to 0, but mmio_is_needed is not set to 0. As a result, KVM exits to userspace, and then returns to complete_emulated_mmio. In complete_emulated_mmio vcpu->mmio_cur_fragment is incremented. The termination condition of vcpu->mmio_cur_fragment == vcpu->mmio_nr_fragments is never achieved. The code bounces back and fourth to userspace incrementing mmio_cur_fragment past it's buffer. If the guest does nothing else it eventually leads to a a crash on a memcpy from invalid memory address. However if a guest code can cause the vm to be destroyed in another vcpu with excellent timing, then kvm_clear_async_pf_completion_queue can be used by the guest to control the data that's pointed to by the call to cancel_work_item, which can be used to gain execution. Fixes: f78146b0f9230765c6315b2e14f56112513389ad Signed-off-by: Andrew Honig Signed-off-by: Paolo Bonzini Signed-off-by: Jiri Slaby commit aaecbb25d185ff59c3f8538bf4f854bd14377025 Author: Christoph Hellwig Date: Tue Nov 19 07:17:07 2013 -0800 fs: fix iversion handling commit dff6efc326a4d5f305797d4a6bba14f374fdd633 upstream. Currently notify_change directly updates i_version for size updates, which not only is counter to how all other fields are updated through struct iattr, but also breaks XFS, which need inode updates to happen under its own lock, and synchronized to the structure that gets written to the log. Remove the update in the common code, and it to btrfs and ext4, XFS already does a proper updaste internally and currently gets a double update with the existing code. IMHO this is 3.13 and -stable material and should go in through the XFS tree. Signed-off-by: Christoph Hellwig Reviewed-by: Andreas Dilger Acked-by: Jan Kara Reviewed-by: Dave Chinner Signed-off-by: Chris Mason Signed-off-by: Ben Myers Signed-off-by: Jiri Slaby commit 2c561a28bfeafc587b9d1ecc0b3c0568c2489ee7 Author: Tejun Heo Date: Thu Feb 13 13:29:31 2014 -0500 cgroup: update cgroup_enable_task_cg_lists() to grab siglock commit 532de3fc72adc2a6525c4d53c07bf81e1732083d upstream. Currently, there's nothing preventing cgroup_enable_task_cg_lists() from missing set PF_EXITING and race against cgroup_exit(). Depending on the timing, cgroup_exit() may finish with the task still linked on css_set leading to list corruption. Fix it by grabbing siglock in cgroup_enable_task_cg_lists() so that PF_EXITING is guaranteed to be visible. This whole on-demand cg_list optimization is extremely fragile and has ample possibility to lead to bugs which can cause things like once-a-year oops during boot. I'm wondering whether the better approach would be just adding "cgroup_disable=all" handling which disables the whole cgroup rather than tempting fate with this on-demand craziness. Signed-off-by: Tejun Heo Acked-by: Li Zefan Signed-off-by: Jiri Slaby commit 3e507fa19fea1d5423f4be675fd211c52f7c12c4 Author: Tejun Heo Date: Sat Feb 8 10:26:34 2014 -0500 cgroup: fix locking in cgroup_cfts_commit() commit 48573a893303986e3b0b2974d6fb11f3d1bb7064 upstream. cgroup_cfts_commit() walks the cgroup hierarchy that the target subsystem is attached to and tries to apply the file changes. Due to the convolution with inode locking, it can't keep cgroup_mutex locked while iterating. It currently holds only RCU read lock around the actual iteration and then pins the found cgroup using dget(). Unfortunately, this is incorrect. Although the iteration does check cgroup_is_dead() before invoking dget(), there's nothing which prevents the dentry from going away inbetween. Note that this is different from the usual css iterations where css_tryget() is used to pin the css - css_tryget() tests whether the css can be pinned and fails if not. The problem can be solved by simply holding cgroup_mutex instead of RCU read lock around the iteration, which actually reduces LOC. Signed-off-by: Tejun Heo Acked-by: Li Zefan Signed-off-by: Jiri Slaby commit 35fcf4dd2296b06b0ef042f203246dc73e6e3f02 Author: Tejun Heo Date: Sat Feb 8 10:26:33 2014 -0500 cgroup: fix error return from cgroup_create() commit b58c89986a77a23658682a100eb15d8edb571ebb upstream. cgroup_create() was returning 0 after allocation failures. Fix it. Signed-off-by: Tejun Heo Acked-by: Li Zefan Signed-off-by: Jiri Slaby commit 7737f595e8f566d41ef9f91246816bfbed4b7a87 Author: Tejun Heo Date: Sat Feb 8 10:26:33 2014 -0500 cgroup: fix error return value in cgroup_mount() commit eb46bf89696972b856a9adb6aebd5c7b65c266e4 upstream. When cgroup_mount() fails to allocate an id for the root, it didn't set ret before jumping to unlock_drop ending up returning 0 after a failure. Fix it. Signed-off-by: Tejun Heo Acked-by: Li Zefan Signed-off-by: Jiri Slaby commit bbfb7e7c739e477ca262ffa14dd9e4a1296e5f97 Author: Hui Wang Date: Thu Feb 20 11:47:21 2014 +0800 ALSA: hda - Enable front audio jacks on one HP desktop model commit 1de7ca5e844866f56bebb2fc47fa18e090677e88 upstream. The front headphone and mic jackes on a HP desktop model (Vendor Id: 0x111d76c7 Subsystem Id: 0x103c2b17) can not work, the codec on this machine has 8 physical ports, 6 of them are routed to rear jackes and all of them work very well, while the remaining 2 ports are routed to front headphone and mic jackes, but the corresponding pin complex node are not defined correctly. After apply this fix, the front audio jackes can work very well. [trivial fix of enum definition by tiwai] BugLink: https://bugs.launchpad.net/bugs/1282369 Cc: David Henningsson Tested-by: Gerald Yang Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit cafd89a1e68c02d95c101511bcf9bd176e7696e5 Author: Hsin-Yu Chao Date: Wed Feb 19 14:30:35 2014 +0800 ALSA: hda/ca0132 - Fix recording from mode id 0x8 commit 13c12dbe3a2ce17227f7ddef652b6a53c78fa51f upstream. Incorrect ADC is picked in ca0132_capture_pcm_prepare(), where it assumes multiple streams while there is one stream per ADC. Note that ca0132_capture_pcm_cleanup() already does the right thing. The Chromebook Pixel has a microphone under the keyboard that is attached to node id 0x8. Before this fix, recording would always go to the main internal mic (node id 0x7). Signed-off-by: Hsin-Yu Chao Reviewed-by: Dylan Reid Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 35f73ed5d4715c385a7bcbb1ca642016b2660d05 Author: Hsin-Yu Chao Date: Wed Feb 19 14:27:07 2014 +0800 ALSA: hda/ca0132 - setup/cleanup streams commit 28fba95087a7f3d107a3a6728aef7dbfaf3fd782 upstream. When a HDMI stream is opened with the same stream tag as a following opened stream to ca0132, audio will be heard from two ports simultaneously. Fix this issue by change to use snd_hda_codec_setup_stream and snd_hda_codec_cleanup_stream instead, so that an inactive stream can be marked as 'dirty' when found with a conflict stream tag, and then get purified. Signed-off-by: Hsin-Yu Chao Reviewed-by: Chih-Chung Chang Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit b68faad19e60c00ae354fe41a8e2e03dfc799cb8 Author: Clemens Ladisch Date: Sun Feb 16 17:11:10 2014 +0100 ALSA: usb-audio: work around KEF X300A firmware bug commit 624aef494f86ed0c58056361c06347ad62b26806 upstream. When the driver tries to access Function Unit 10, the KEF X300A speakers' firmware apparently locks up, making even PCM streaming impossible. Work around this by ignoring this FU. Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit f846327dad7a834b79db98e0111badb3121c441e Author: Andy Adamson Date: Tue Feb 18 10:36:05 2014 -0500 NFS fix error return in nfs4_select_rw_stateid commit 146d70caaa1b87f64597743429d7da4b8073d0c9 upstream. Do not return an error when nfs4_copy_delegation_stateid succeeds. Signed-off-by: Andy Adamson Link: http://lkml.kernel.org/r/1392737765-41942-1-git-send-email-andros@netapp.com Fixes: ef1820f9be27b (NFSv4: Don't try to recover NFSv4 locks when...) Cc: NeilBrown Signed-off-by: Trond Myklebust Signed-off-by: Jiri Slaby commit 3ca1ca4dd11f442e865a59487cf806c12d06907d Author: Olivier Langlois Date: Sat Feb 1 01:11:09 2014 -0500 rtlwifi: rtl8192ce: Fix too long disable of IRQs commit f78bccd79ba3cd9d9664981b501d57bdb81ab8a4 upstream. rtl8192ce is disabling for too long the local interrupts during hw initiatialisation when performing scans The observable symptoms in dmesg can be: - underruns from ALSA playback - clock freezes (tstamps do not change for several dmesg entries until irqs are finaly reenabled): [ 250.817669] rtlwifi:rtl_op_config():<0-0-0> 0x100 [ 250.817685] rtl8192ce:_rtl92ce_phy_set_rf_power_state():<0-1-0> IPS Set eRf nic enable [ 250.817732] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.817796] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.817910] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.818024] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.818139] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.818253] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.818367] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:98053f15:10 [ 250.818472] rtl8192ce:rtl92ce_sw_led_on():<0-1-0> LedAddr:4E ledpin=1 [ 250.818472] rtl8192c_common:rtl92c_download_fw():<0-1-0> Firmware Version(49), Signature(0x88c1),Size(32) [ 250.818472] rtl8192ce:rtl92ce_enable_hw_security_config():<0-1-0> PairwiseEncAlgorithm = 0 GroupEncAlgorithm = 0 [ 250.818472] rtl8192ce:rtl92ce_enable_hw_security_config():<0-1-0> The SECR-value cc [ 250.818472] rtl8192c_common:rtl92c_dm_check_txpower_tracking_thermal_meter():<0-1-0> Schedule TxPowerTracking direct call!! [ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> rtl92c_dm_txpower_tracking_callback_thermalmeter [ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Readback Thermal Meter = 0xe pre thermal meter 0xf eeprom_thermalmeter 0xf [ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Initial pathA ele_d reg0xc80 = 0x40000000, ofdm_index=0xc [ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Initial reg0xa24 = 0x90e1317, cck_index=0xc, ch14 0 [ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Readback Thermal Meter = 0xe pre thermal meter 0xf eeprom_thermalmeter 0xf delta 0x1 delta_lck 0x0 delta_iqk 0x0 [ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> <=== [ 250.818472] rtl8192c_common:rtl92c_dm_initialize_txpower_tracking_thermalmeter():<0-1-0> pMgntInfo->txpower_tracking = 1 [ 250.818472] rtl8192ce:rtl92ce_led_control():<0-1-0> ledaction 3 [ 250.818472] rtl8192ce:rtl92ce_sw_led_on():<0-1-0> LedAddr:4E ledpin=1 [ 250.818472] rtlwifi:rtl_ips_nic_on():<0-1-0> before spin_unlock_irqrestore [ 251.154656] PCM: Lost interrupts? [Q]-0 (stream=0, delta=15903, new_hw_ptr=293408, old_hw_ptr=277505) The exact code flow that causes that is: 1. wpa_supplicant send a start_scan request to the nl80211 driver 2. mac80211 module call rtl_op_config with IEEE80211_CONF_CHANGE_IDLE 3. rtl_ips_nic_on is called which disable local irqs 4. rtl92c_phy_set_rf_power_state() is called 5. rtl_ps_enable_nic() is called and hw_init()is executed and then the interrupts on the device are enabled A good solution could be to refactor the code to avoid calling rtl92ce_hw_init() with the irqs disabled but a quick and dirty solution that has proven to work is to reenable the irqs during the function rtl92ce_hw_init(). I think that it is safe doing so since the device interrupt will only be enabled after the init function succeed. Signed-off-by: Olivier Langlois Acked-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Jiri Slaby commit e7283f54dede376dbcdfc801f82e8659cbefa41d Author: Olivier Langlois Date: Sat Feb 1 01:11:10 2014 -0500 rtlwifi: Fix incorrect return from rtl_ps_enable_nic() commit 2e8c5e56b307271c2dab6f8bfd1d8a3822ca2390 upstream. rtl_ps_enable_nic() is called from loops that will loop until this function returns true or a maximum number of retries is performed. hw_init() returns non-zero on error. In that situation return false to restore the original design intent to retry hw init when it fails. Signed-off-by: Olivier Langlois Acked-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Jiri Slaby commit 906c44b881c18341e3afe6eb6d49a5767974ad6e Author: Stanislaw Gruszka Date: Mon Feb 10 22:38:28 2014 +0100 rtl8187: fix regression on MIPS without coherent DMA commit b6213e413a4e0c66548153516b074df14f9d08e0 upstream. This patch fixes regression caused by commit a16dad77634 "MIPS: Fix potencial corruption". That commit fixes one corruption scenario in cost of adding another one, which actually start to cause crashes on Yeeloong laptop when rtl8187 driver is used. For correct DMA read operation on machines without DMA coherence, kernel have to invalidate cache, such it will refill later with new data that device wrote to memory, when that data is needed to process. We can only invalidate full cache line. Hence when cache line includes both dma buffer and some other data (written in cache, but not yet in main memory), the other data can not hit memory due to invalidation. That happen on rtl8187 where struct rtl8187_priv fields are located just before and after small buffers that are passed to USB layer and DMA is performed on them. To fix the problem we align buffers and reserve space after them to make them match cache line. This patch does not resolve all possible MIPS problems entirely, for that we have to assure that we always map cache aligned buffers for DMA, what can be complex or even not possible. But patch fixes visible and reproducible regression and seems other possible corruptions do not happen in practice, since Yeeloong laptop works stable without rtl8187 driver. Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=54391 Reported-by: Petr Pisar Bisected-by: Tom Li Reported-and-tested-by: Tom Li Signed-off-by: Stanislaw Gruszka Acked-by: Larry Finger Acked-by: Hin-Tak Leung Signed-off-by: John W. Linville Signed-off-by: Jiri Slaby commit 18cb7c14a0a8ba6d07c18b24e4434dc31949d5f1 Author: Pavel Shilovsky Date: Fri Feb 14 13:31:02 2014 +0400 CIFS: Fix too big maxBuf size for SMB3 mounts commit 2365c4eaf077c48574ab6f143960048fc0f31518 upstream. SMB3 servers can respond with MaxTransactSize of more than 4M that can cause a memory allocation error returned from kmalloc in a lock codepath. Also the client doesn't support multicredit requests now and allows buffer sizes of 65536 bytes only. Set MaxTransactSize to this maximum supported value. Signed-off-by: Pavel Shilovsky Acked-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Jiri Slaby commit 90d369693d48ec7ffa4ca039e6fd14e861486251 Author: Jeff Layton Date: Fri Feb 14 07:20:35 2014 -0500 cifs: ensure that uncached writes handle unmapped areas correctly commit 5d81de8e8667da7135d3a32a964087c0faf5483f upstream. It's possible for userland to pass down an iovec via writev() that has a bogus user pointer in it. If that happens and we're doing an uncached write, then we can end up getting less bytes than we expect from the call to iov_iter_copy_from_user. This is CVE-2014-0069 cifs_iovec_write isn't set up to handle that situation however. It'll blindly keep chugging through the page array and not filling those pages with anything useful. Worse yet, we'll later end up with a negative number in wdata->tailsz, which will confuse the sending routines and cause an oops at the very least. Fix this by having the copy phase of cifs_iovec_write stop copying data in this situation and send the last write as a short one. At the same time, we want to avoid sending a zero-length write to the server, so break out of the loop and set rc to -EFAULT if that happens. This also allows us to handle the case where no address in the iovec is valid. [Note: Marking this for stable on v3.4+ kernels, but kernels as old as v2.6.38 may have a similar problem and may need similar fix] Reviewed-by: Pavel Shilovsky Reported-by: Al Viro Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Jiri Slaby commit 92ffeda00eeff3b33f9a41011d9ac5779d2eb131 Author: Chen Gang Date: Sat Feb 1 20:35:54 2014 +0800 avr32: Makefile: add '-D__linux__' flag for gcc-4.4.7 use commit 8d80390cfc9434d5aa4fb9e5f9768a66b30cb8a6 upstream. For avr32 cross compiler, do not define '__linux__' internally, so it will cause issue with allmodconfig. The related error: CC [M] fs/coda/psdev.o In file included from include/linux/coda.h:64, from fs/coda/psdev.c:45: include/uapi/linux/coda.h:221: error: expected specifier-qualifier-list before 'u_quad_t' The related toolchain version (which only download, not re-compile): [root@gchen linux-next]# /upstream/toolchain/download/avr32-gnu-toolchain-linux_x86/bin/avr32-gcc -v Using built-in specs. Target: avr32 Configured with: /data2/home/toolsbuild/jenkins-knuth/workspace/avr32-gnu-toolchain/src/gcc/configure --target=avr32 --host=i686-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/home/toolsbuild/jenkins-knuth/workspace/avr32-gnu-toolchain/avr32-gnu-toolchain-linux_x86 --enable-languages=c,c++ --disable-nls --disable-libssp --disable-libstdcxx-pch --with-dwarf2 --enable-version-specific-runtime-libs --disable-shared --enable-doc --with-mpfr-lib=/home/toolsbuild/jenkins-knuth/workspace/avr32-gnu-toolchain/avr32-gnu-toolchain-linux_x86/lib --with-mpfr-include=/home/toolsbuild/jenkins-knuth/workspace/avr32-gnu-toolchain/avr32-gnu-toolchain-linux_x86/include --with-gmp=/home/toolsbuild/jenkins-knuth/workspace/avr32-gnu-toolchain/avr32-gnu-toolchain-linux_x86 --with-mpc=/home/toolsbuild/jenkins-knuth/workspace/avr32-gnu-toolchain/avr32-gnu-toolchain-linux_x86 --enable-__cxa_atexit --disable-shared --with-newlib --with-pkgversion=AVR_32_bit_GNU_Toolchain_3.4.2_435 --with-bugurl=http://www .atmel.com/avr Thread model: single gcc version 4.4.7 (AVR_32_bit_GNU_Toolchain_3.4.2_435) Signed-off-by: Chen Gang Acked-by: Hans-Christian Egtvedt Signed-off-by: Jiri Slaby commit d3d36eb209abe135807704600130dad61a460900 Author: Paul Gortmaker Date: Fri Jan 10 09:29:39 2014 -0500 avr32: fix missing module.h causing build failure in mimc200/fram.c commit 5745d6a41a4f4aec29e2ccd591c6fb09ed73a955 upstream. Causing this: In file included from arch/avr32/boards/mimc200/fram.c:13: include/linux/miscdevice.h:51: error: field 'list' has incomplete type include/linux/miscdevice.h:55: error: expected specifier-qualifier-list before 'mode_t' arch/avr32/boards/mimc200/fram.c:42: error: 'THIS_MODULE' undeclared here (not in a function) Reported-by: Fengguang Wu Cc: Haavard Skinnemoen Cc: Hans-Christian Egtvedt Signed-off-by: Paul Gortmaker Signed-off-by: Sergei Trofimovich Acked-by: Hans-Christian Egtvedt Signed-off-by: Jiri Slaby commit b5d8f63d78812bd7b1fa399561d6b7943cf30b65 Author: Dan Carpenter Date: Mon Feb 17 20:33:01 2014 -0500 jbd2: fix use after free in jbd2_journal_start_reserved() commit 92e3b40537707001d17bbad800d150ab04e53bf4 upstream. If start_this_handle() fails then it leads to a use after free of "handle". Signed-off-by: Dan Carpenter Signed-off-by: "Theodore Ts'o" Signed-off-by: Jiri Slaby commit 16b360d6bc1b2fd7e97d6e7512f47d92325aa465 Author: Gavin Shan Date: Wed Feb 12 15:24:54 2014 +0800 powerpc/powernv: Rework EEH reset commit 5b2e198e50f6ba57081586b853163ea1bb95f1a8 upstream. When doing reset in order to recover the affected PE, we issue hot reset on PE primary bus if it's not root bus. Otherwise, we issue hot or fundamental reset on root port or PHB accordingly. For the later case, we didn't cover the situation where PE only includes root port and it potentially causes kernel crash upon EEH error to the PE. The patch reworks the logic of EEH reset to improve the code readability and also avoid the kernel crash. Reported-by: Thadeu Lima de Souza Cascardo Signed-off-by: Gavin Shan Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Jiri Slaby commit a0dc9944ebd01a0b279e4bed299016e7ed1115e3 Author: Kevin Hao Date: Fri Jan 17 12:25:28 2014 +0800 powerpc: Set the correct ksp_limit on ppc32 when switching to irq stack commit 1a18a66446f3f289b05b634f18012424d82aa63a upstream. Guenter Roeck has got the following call trace on a p2020 board: Kernel stack overflow in process eb3e5a00, r1=eb79df90 CPU: 0 PID: 2838 Comm: ssh Not tainted 3.13.0-rc8-juniper-00146-g19eca00 #4 task: eb3e5a00 ti: c0616000 task.ti: ef440000 NIP: c003a420 LR: c003a410 CTR: c0017518 REGS: eb79dee0 TRAP: 0901 Not tainted (3.13.0-rc8-juniper-00146-g19eca00) MSR: 00029000 CR: 24008444 XER: 00000000 GPR00: c003a410 eb79df90 eb3e5a00 00000000 eb05d900 00000001 65d87646 00000000 GPR08: 00000000 020b8000 00000000 00000000 44008442 NIP [c003a420] __do_softirq+0x94/0x1ec LR [c003a410] __do_softirq+0x84/0x1ec Call Trace: [eb79df90] [c003a410] __do_softirq+0x84/0x1ec (unreliable) [eb79dfe0] [c003a970] irq_exit+0xbc/0xc8 [eb79dff0] [c000cc1c] call_do_irq+0x24/0x3c [ef441f20] [c00046a8] do_IRQ+0x8c/0xf8 [ef441f40] [c000e7f4] ret_from_except+0x0/0x18 --- Exception: 501 at 0xfcda524 LR = 0x10024900 Instruction dump: 7c781b78 3b40000a 3a73b040 543c0024 3a800000 3b3913a0 7ef5bb78 48201bf9 5463103a 7d3b182e 7e89b92e 7c008146 <3ba00000> 7e7e9b78 48000014 57fff87f Kernel panic - not syncing: kernel stack overflow CPU: 0 PID: 2838 Comm: ssh Not tainted 3.13.0-rc8-juniper-00146-g19eca00 #4 Call Trace: The reason is that we have used the wrong register to calculate the ksp_limit in commit cbc9565ee826 (powerpc: Remove ksp_limit on ppc64). Just fix it. As suggested by Benjamin Herrenschmidt, also add the C prototype of the function in the comment in order to avoid such kind of errors in the future. Reported-by: Guenter Roeck Tested-by: Guenter Roeck Signed-off-by: Kevin Hao Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Jiri Slaby commit 46f04abf2f37c8a350202fb1335d790c976ca896 Author: Pekon Gupta Date: Tue Jan 28 11:42:41 2014 +0530 ARM: OMAP2+: gpmc: fix: DT ONENAND child nodes not probed when MTD_ONENAND is built as module commit 980386d2d6d49e0b42f48550853ef1ad6aa5d79a upstream. Fixes: commit 75d3625e0e86b2d8d77b4e9c6f685fd7ea0d5a96 ARM: OMAP2+: gpmc: add DT bindings for OneNAND OMAP SoC(s) depend on GPMC controller driver to parse GPMC DT child nodes and register them platform_device for ONENAND driver to probe later. However this does not happen if generic MTD_ONENAND framework is built as module (CONFIG_MTD_ONENAND=m). Therefore, when MTD/ONENAND and MTD/ONENAND/OMAP2 modules are loaded, they are unable to find any matching platform_device and remain un-binded. This causes on board ONENAND flash to remain un-detected. This patch causes GPMC controller to parse DT nodes when CONFIG_MTD_ONENAND=y || CONFIG_MTD_ONENAND=m Signed-off-by: Pekon Gupta Signed-off-by: Tony Lindgren Signed-off-by: Jiri Slaby commit 3b336c53793a3aab866636339f337787efb0a270 Author: Pekon Gupta Date: Tue Jan 28 11:42:40 2014 +0530 ARM: OMAP2+: gpmc: fix: DT NAND child nodes not probed when MTD_NAND is built as module commit 6b187b21c92b6e2c7e8ef0b450181c37a3f31681 upstream. Fixes: commit bc6b1e7b86f5d8e4a6fc1c0189e64bba4077efe0 ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND OMAP SoC(s) depend on GPMC controller driver to parse GPMC DT child nodes and register them platform_device for NAND driver to probe later. However this does not happen if generic MTD_NAND framework is built as module (CONFIG_MTD_NAND=m). Therefore, when MTD/NAND and MTD/NAND/OMAP2 modules are loaded, they are unable to find any matching platform_device and remain un-binded. This causes on board NAND flash to remain un-detected. This patch causes GPMC controller to parse DT nodes when CONFIG_MTD_NAND=y || CONFIG_MTD_NAND=m Signed-off-by: Pekon Gupta Signed-off-by: Tony Lindgren Signed-off-by: Jiri Slaby commit 84f94106ae5bca2d59528acebddb230db7a08a83 Author: Vinayak Kale Date: Wed Feb 12 07:30:01 2014 +0100 ARM: 7957/1: add DSB after icache flush in __flush_icache_all() commit 39544ac9df20f73e49fc6b9ac19ff533388c82c0 upstream. Add DSB after icache flush to complete the cache maintenance operation. Signed-off-by: Vinayak Kale Acked-by: Catalin Marinas Signed-off-by: Russell King Signed-off-by: Jiri Slaby commit 103a9391af1e014f6cc1c1e224a4f51bf831768f Author: Will Deacon Date: Fri Feb 7 19:12:32 2014 +0100 ARM: 7955/1: spinlock: ensure we have a compiler barrier before sev commit 7c8746a9eb287642deaad0e7c2cdf482dce5e4be upstream. When unlocking a spinlock, we require the following, strictly ordered sequence of events: /* dmb */ /* dsb */ Whilst the code does indeed reflect this in terms of the architecture, the final + have been contracted into a single inline asm without a "memory" clobber, therefore the compiler is at liberty to reorder the unlock to the end of the above sequence. In such a case, a waiting CPU may be woken up before the lock has been unlocked, leading to extremely poor performance. This patch reworks the dsb_sev() function to make use of the dsb() macro and ensure ordering against the unlock. Reported-by: Mark Rutland Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Jiri Slaby commit 160d1d210a8cc5b29722580484f5256882dc275e Author: Will Deacon Date: Fri Feb 7 19:12:20 2014 +0100 ARM: 7953/1: mm: ensure TLB invalidation is complete before enabling MMU commit bae0ca2bc550d1ec6a118fb8f2696f18c4da3d8e upstream. During __v{6,7}_setup, we invalidate the TLBs since we are about to enable the MMU on return to head.S. Unfortunately, without a subsequent dsb instruction, the invalidation is not guaranteed to have completed by the time we write to the sctlr, potentially exposing us to junk/stale translations cached in the TLB. This patch reworks the init functions so that the dsb used to ensure completion of cache/predictor maintenance is also used to ensure completion of the TLB invalidation. Reported-by: Albin Tonnerre Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Jiri Slaby commit 751d789f6490b7c08ff49dae95509b2be29bac78 Author: Marek Szyprowski Date: Thu Jan 16 15:39:17 2014 +0100 ARM: dma-mapping: fix GFP_ATOMIC macro usage commit 10c8562f932d89c030083e15f9279971ed637136 upstream. GFP_ATOMIC is not a single gfp flag, but a macro which expands to the other flags and LACK of __GFP_WAIT flag. To check if caller wanted to perform an atomic allocation, the code must test __GFP_WAIT flag presence. This patch fixes the issue introduced in v3.6-rc5 Signed-off-by: Marek Szyprowski Signed-off-by: Jiri Slaby commit 0fab4fa22023f408f6fc181b5029dcb9b8ff9fe3 Author: Theodore Ts'o Date: Sun Feb 16 19:29:32 2014 -0500 ext4: don't leave i_crtime.tv_sec uninitialized commit 19ea80603715d473600cd993b9987bc97d042e02 upstream. If the i_crtime field is not present in the inode, don't leave the field uninitialized. Fixes: ef7f38359 ("ext4: Add nanosecond timestamps") Reported-by: Vegard Nossum Tested-by: Vegard Nossum Signed-off-by: "Theodore Ts'o" Signed-off-by: Jiri Slaby commit 50e31fc3f09c418d312d4129d8f01f607087bd5a Author: Theodore Ts'o Date: Sat Feb 15 22:42:25 2014 -0500 ext4: fix online resize with a non-standard blocks per group setting commit 3d2660d0c9c2f296837078c189b68a47f6b2e3b5 upstream. The set_flexbg_block_bitmap() function assumed that the number of blocks in a blockgroup was sb->blocksize * 8, which is normally true, but not always! Use EXT4_BLOCKS_PER_GROUP(sb) instead, to fix block bitmap corruption after: mke2fs -t ext4 -g 3072 -i 4096 /dev/vdd 1G mount -t ext4 /dev/vdd /vdd resize2fs /dev/vdd 8G Signed-off-by: "Theodore Ts'o" Reported-by: Jon Bernard Signed-off-by: Jiri Slaby commit c6f75d48dffe9216edacf94205ab55aebe67e46f Author: Theodore Ts'o Date: Sat Feb 15 21:33:13 2014 -0500 ext4: fix online resize with very large inode tables commit b93c95353413041a8cebad915a8109619f66bcc6 upstream. If a file system has a large number of inodes per block group, all of the metadata blocks in a flex_bg may be larger than what can fit in a single block group. Unfortunately, ext4_alloc_group_tables() in resize.c was never tested to see if it would handle this case correctly, and there were a large number of bugs which caused the following sequence to result in a BUG_ON: kernel bug at fs/ext4/resize.c:409! ... call trace: [] ext4_flex_group_add+0x1448/0x1830 [] ext4_resize_fs+0x7b2/0xe80 [] ext4_ioctl+0xbf0/0xf00 [] do_vfs_ioctl+0x2dd/0x4b0 [] ? final_putname+0x22/0x50 [] sys_ioctl+0x81/0xa0 [] system_call_fastpath+0x16/0x1b code: c8 4c 89 df e8 41 96 f8 ff 44 89 e8 49 01 c4 44 29 6d d4 0 rip [] set_flexbg_block_bitmap+0x171/0x180 This can be reproduced with the following command sequence: mke2fs -t ext4 -i 4096 /dev/vdd 1G mount -t ext4 /dev/vdd /vdd resize2fs /dev/vdd 8G To fix this, we need to make sure the right thing happens when a block group's inode table straddles two block groups, which means the following bugs had to be fixed: 1) Not clearing the BLOCK_UNINIT flag in the second block group in ext4_alloc_group_tables --- the was proximate cause of the BUG_ON. 2) Incorrectly determining how many block groups contained contiguous free blocks in ext4_alloc_group_tables(). 3) Incorrectly setting the start of the next block range to be marked in use after a discontinuity in setup_new_flex_group_blocks(). Signed-off-by: "Theodore Ts'o" Signed-off-by: Jiri Slaby commit 793602145273c0acfe0f6390e90977b49eecedd2 Author: Theodore Ts'o Date: Wed Feb 12 12:16:04 2014 -0500 ext4: don't try to modify s_flags if the the file system is read-only commit 23301410972330c0ae9a8afc379ba2005e249cc6 upstream. If an ext4 file system is created by some tool other than mke2fs (perhaps by someone who has a pathalogical fear of the GPL) that doesn't set one or the other of the EXT2_FLAGS_{UN}SIGNED_HASH flags, and that file system is then mounted read-only, don't try to modify the s_flags field. Otherwise, if dm_verity is in use, the superblock will change, causing an dm_verity failure. Signed-off-by: "Theodore Ts'o" Signed-off-by: Jiri Slaby commit 0e2747f274ec5dbb37ef7c8a14cdd93fa2364bdf Author: Zheng Liu Date: Wed Feb 12 11:48:31 2014 -0500 ext4: fix error paths in swap_inode_boot_loader() commit 30d29b119ef01776e0a301444ab24defe8d8bef3 upstream. In swap_inode_boot_loader() we forgot to release ->i_mutex and resume unlocked dio for inode and inode_bl if there is an error starting the journal handle. This commit fixes this issue. Reported-by: Ahmed Tamrawi Cc: Andreas Dilger Cc: Dr. Tilmann Bubeck Signed-off-by: Zheng Liu Signed-off-by: "Theodore Ts'o" Signed-off-by: Jiri Slaby commit 2dcfeb29bfc13fab078b8dcba336cdbd19293ffb Author: Eric Whitney Date: Wed Feb 12 10:42:45 2014 -0500 ext4: fix xfstest generic/299 block validity failures commit 15cc17678547676c82a5da9ccf357447333fc342 upstream. Commit a115f749c1 (ext4: remove wait for unwritten extent conversion from ext4_truncate) exposed a bug in ext4_ext_handle_uninitialized_extents(). It can be triggered by xfstest generic/299 when run on a test file system created without a journal. This test continuously fallocates and truncates files to which random dio/aio writes are simultaneously performed by a separate process. The test completes successfully, but if the test filesystem is mounted with the block_validity option, a warning message stating that a logical block has been mapped to an illegal physical block is posted in the kernel log. The bug occurs when an extent is being converted to the written state by ext4_end_io_dio() and ext4_ext_handle_uninitialized_extents() discovers a mapping for an existing uninitialized extent. Although it sets EXT4_MAP_MAPPED in map->m_flags, it fails to set map->m_pblk to the discovered physical block number. Because map->m_pblk is not otherwise initialized or set by this function or its callers, its uninitialized value is returned to ext4_map_blocks(), where it is stored as a bogus mapping in the extent status tree. Since map->m_pblk can accidentally contain illegal values that are larger than the physical size of the file system, calls to check_block_validity() in ext4_map_blocks() that are enabled if the block_validity mount option is used can fail, resulting in the logged warning message. Signed-off-by: Eric Whitney Signed-off-by: "Theodore Ts'o" Signed-off-by: Jiri Slaby commit b19c399da7b857c8d9fd899a42bee0144e03465a Author: Ville Syrjälä Date: Tue Feb 11 19:52:06 2014 +0200 drm/i915: Prevent MI_DISPLAY_FLIP straddling two cachelines on IVB commit f66fab8e1cd6b3127ba4c5c0d11539fbe1de1e36 upstream. According to BSpec the entire MI_DISPLAY_FLIP packet must be contained in a single cacheline. Make sure that happens. v2: Use intel_ring_begin_cacheline_safe() v3: Use intel_ring_cacheline_align() (Chris) Cc: Bjoern C Cc: Alexandru DAMIAN Cc: Enrico Tagliavini Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74053 Signed-off-by: Ville Syrjälä Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter Signed-off-by: Jiri Slaby commit aecc29f1f791b7fc0c9fb1b689b92a63732136eb Author: Ville Syrjälä Date: Tue Feb 11 19:52:05 2014 +0200 drm/i915: Add intel_ring_cachline_align() commit 753b1ad4a281b0663329409d410243e91825c323 upstream. intel_ring_cachline_align() emits MI_NOOPs until the ring tail is aligned to a cacheline boundary. Cc: Bjoern C Cc: Alexandru DAMIAN Cc: Enrico Tagliavini Suggested-by: Chris Wilson Signed-off-by: Ville Syrjälä Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter Signed-off-by: Jiri Slaby commit 54a03e0336ed298d840feddce745b1e806b338ff Author: Ilia Mirkin Date: Thu Feb 13 21:57:15 2014 -0500 drm/nv50/disp: use correct register to determine DP display bpp commit a7f1c1e65b68e1e1ab70898528d5977ed68a0a7d upstream. Commit 0a0afd282f ("drm/nv50-/disp: move DP link training to core and train from supervisor") added code that uses the wrong register for computing the display bpp, used for bandwidth calculation. Adjust to use the same register as used by exec_clkcmp and nv50_disp_intr_unk20_2_dp. Reported-by: Torsten Wagner Reported-by: Michael Gulick Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67628 Signed-off-by: Ilia Mirkin Signed-off-by: Ben Skeggs Signed-off-by: Jiri Slaby commit 4a3817716efdbae87ce7c9a269bab707e7ea9d37 Author: Ilia Mirkin Date: Wed Jan 29 19:53:00 2014 -0500 drm/nouveau: set irq_enabled manually commit 7d3428cd4b2ad51af86fdbdf8284ca38fa95e601 upstream. Since commit 0fa9061ae8c ("drm/nouveau/mc: handle irq-related setup ourselves"), drm_device->irq_enabled remained unset. This is needed in order to properly wait for a vblank event in the generic drm code. See https://bugs.freedesktop.org/show_bug.cgi?id=74195 Reported-by: Jan Janecek Signed-off-by: Ilia Mirkin Signed-off-by: Ben Skeggs Signed-off-by: Jiri Slaby commit 85f164e1bcd9afe4deb91067f431d1419c09e13b Author: Alex Deucher Date: Tue Feb 18 10:16:28 2014 -0500 drm/radeon/ni: fix typo in dpm sq ramping setup commit 21ed4947fdfe19b60a27b84162622e56439c7937 upstream. inverted logic. Signed-off-by: Alex Deucher Signed-off-by: Jiri Slaby commit f6f27128f7b3bea1236abd88d56227e871e7dc2d Author: Nicholas Bellinger Date: Sat Mar 1 17:00:16 2014 -0800 bio-integrity: Fix bio_integrity_verify segment start bug commit 5837c80e870bc3b12ac6a98cdc9ce7a9522a8fb6 upstream. This patch addresses a bug in bio_integrity_verify() code that has been causing DIF READ verify operations to be silently skipped. The issue is that bio->bi_idx will have been incremented within bio_advance() code in the normal blk_update_request() -> req_bio_endio() completion path, and bio_integrity_verify() is using bio_for_each_segment() which starts the bio segment walk at the current bio->bi_idx. So instead use bio_for_each_segment_all() to always start the bio segment walk from zero, regardless of the current bio->bi_idx value after bio_advance() has been called. (Context change for v3.10.y -> v3.13.y code - nab) Cc: Martin K. Petersen Cc: Jens Axboe Cc: Christoph Hellwig Signed-off-by: Nicholas Bellinger Cc: stable@kernel.dk # >= v3.10 Signed-off-by: Jens Axboe commit b7b7b4554f1e0c38db6573cdd784f99aad886f37 Author: Hui Wang Date: Wed Dec 11 11:41:31 2013 +0800 ALSA: hda - One more Dell headset detection quirk commit 7dca4bc6f34829db50d9723ac3bcd1c6518ee6c3 upstream. On the Dell machines with codec whose Subsystem Id is 0x10280624, no external microphone can be detected when plugging a 3-ring headset. If we add "model=dell-headset-multi" for the snd-hda-intel.ko, the problem will disappear. BugLink: https://bugs.launchpad.net/bugs/1259790 Cc: David Henningsson Cc: stable@vger.kernel.org Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 9cd3658b7997a8bb974770929f78698816e1781e Author: Hui Wang Date: Tue Dec 10 15:57:21 2013 +0800 ALSA: hda - Another Dell headset detection quirk commit 0dfb9809e93b60946d1915b554138eb93595860c upstream. On the Dell Inspiron 3045 machine (codec Subsystem Id: 0x10280628), no external microphone can be detected when plugging a 3-ring headset. If we add "model=dell-headset-multi" for the snd-hda-intel.ko, the problem will disappear. BugLink: https://bugs.launchpad.net/hwe-somerville/+bug/1259437 CC: David Henningsson Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit df6647449d62a557b0af8c2f3976ef07e47e660b Author: Hui Wang Date: Tue Dec 10 15:57:20 2013 +0800 ALSA: hda - A Dell headset detection quirk commit 6c6eb4270c209cd3b46e4f0bb6b6480b53398111 upstream. On the Dell Optiplex 3030 machine (codec Subsystem Id: 0x10280623), no external microphone can be detected when plugging a 3-ring headset. If we add "model=dell-headset-multi" for the snd-hda-intel.ko, the problem will disappear. BugLink: https://bugs.launchpad.net/hwe-somerville/+bug/1259435 CC: David Henningsson Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit eafc38d17704cbea363ae20da414677f39aaf682 Author: Takashi Iwai Date: Thu Nov 21 08:00:20 2013 +0100 ALSA: hda - Fix missing bass speaker on ASUS N550 commit a30c9aaa900a5fda21b90d5d6a3eaa3cbf16e330 upstream. The laptop has a built-in speaker on NID 0x1a. It's an LFE only on the right channel, so we need to provide an explicit chmap, too. There might be other surround speakers, but they can fixed in addition at later point, so let's fix the easier bass speaker at first. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=65091 Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 01277f142ab06e82114506a14bc17c14e633d463 Author: David Henningsson Date: Wed Nov 20 11:43:30 2013 +0100 ALSA: hda - A casual Dell Headset quirk commit 09d2014fb0c6bcd0bf60f46e890907facd25d22c upstream. You're looking at a casual headset patch, for a specific hardware it will match, and suddenly, the headset jack will work, so please apply this simple quirk! BugLink: https://bugs.launchpad.net/bugs/1253038 Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit bac257987c921375837160f8c2f149f877dabf70 Author: Kailang Yang Date: Fri Nov 1 15:57:35 2013 +0800 ALSA: hda/realtek - Make fixup regs persist after resume commit 380702192f616df5b2ba704b85cc479a3da92c91 upstream. Upon suspend / resume, the fixup register settings are lost because sending HDA_FIXUP_ACT_PRE_PROBE is not part of the resume path. Instead, write our registers in response to the HDA_FIXUP_ACT_INIT, which happens after initial probe and upon resume. Signed-off-by: Kailang Yang Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit d3eb7ba1c7b4b2e9c50d4e646be6c0b98577c3ea Author: David Henningsson Date: Thu Nov 7 09:28:59 2013 +0100 ALSA: hda - Another Dell headset quirk commit ad8ff99e6beb8708b0bdefd9d5658324e90200f0 upstream. This machine has a multi-function headset jack. BugLink: https://bugs.launchpad.net/bugs/1248856 Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 3b7088de2cc4503d08b865e5cd66f6354aba6d6a Author: David Henningsson Date: Wed Nov 6 11:20:01 2013 +0100 ALSA: HDA - Limit mic boost and add mute LED for an HP machine commit 8e35cd4ac9967620e03f027f27db18b2e249dcd7 upstream. This machine has a mute LED as well as a noisy internal mic. Hence it needs quirks for both limiting the mic boost as well as enabling the LED. BugLink: https://bugs.launchpad.net/bugs/1248476 Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 950cefd7c57f08da6871ab51a69d398ae84ad94c Author: Takashi Iwai Date: Wed Oct 30 17:41:12 2013 +0100 ALSA: hda - Add extra chmap for 2.1 outputs on ASUS laptops commit 8e38395360844806041ea69ab9690f5f174bc40c upstream. ASUS N56VZ and N76VZ laptops have a bass speaker but its output comes only from the right channel. This patch adds the extra chmap specific to these models. Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=846531 Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 16bc2fbd8187c43a8b251a544b4c59e0cd852aef Author: Trond Myklebust Date: Thu Feb 6 14:38:53 2014 -0500 NFS: Do not set NFS_INO_INVALID_LABEL unless server supports labeled NFS commit fd1defc257e2b12ab69bc0b379105c00eca4e112 upstream. Commit aa9c2669626c (NFS: Client implementation of Labeled-NFS) introduces a performance regression. When nfs_zap_caches_locked is called, it sets the NFS_INO_INVALID_LABEL flag irrespectively of whether or not the NFS server supports security labels. Since that flag is never cleared, it means that all calls to nfs_revalidate_inode() will now trigger an on-the-wire GETATTR call. This patch ensures that we never set the NFS_INO_INVALID_LABEL unless the server advertises support for labeled NFS. It also causes nfs_setsecurity() to clear NFS_INO_INVALID_LABEL when it has successfully set the security label for the inode. Finally it gets rid of the NFS_INO_INVALID_LABEL cruft from nfs_update_inode, which has nothing to do with labeled NFS. Reported-by: Neil Brown Cc: stable@vger.kernel.org # 3.11+ Tested-by: Neil Brown Signed-off-by: Trond Myklebust Signed-off-by: Jiri Slaby commit 383728bebf1f4bb3253800a17bf3cdb28cd3312c Author: Filipe David Borba Manana Date: Sat Feb 8 15:47:46 2014 +0000 Btrfs: fix data corruption when reading/updating compressed extents commit a2aa75e18a21b21952dc6daa9bac7c9f4426f81f upstream. When using a mix of compressed file extents and prealloc extents, it is possible to fill a page of a file with random, garbage data from some unrelated previous use of the page, instead of a sequence of zeroes. A simple sequence of steps to get into such case, taken from the test case I made for xfstests, is: _scratch_mkfs _scratch_mount "-o compress-force=lzo" $XFS_IO_PROG -f -c "pwrite -S 0x06 -b 18670 266978 18670" $SCRATCH_MNT/foobar $XFS_IO_PROG -c "falloc 26450 665194" $SCRATCH_MNT/foobar $XFS_IO_PROG -c "truncate 542872" $SCRATCH_MNT/foobar $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foobar This results in the following file items in the fs tree: item 4 key (257 INODE_ITEM 0) itemoff 15879 itemsize 160 inode generation 6 transid 6 size 542872 block group 0 mode 100600 item 5 key (257 INODE_REF 256) itemoff 15863 itemsize 16 inode ref index 2 namelen 6 name: foobar item 6 key (257 EXTENT_DATA 0) itemoff 15810 itemsize 53 extent data disk byte 0 nr 0 gen 6 extent data offset 0 nr 24576 ram 266240 extent compression 0 item 7 key (257 EXTENT_DATA 24576) itemoff 15757 itemsize 53 prealloc data disk byte 12849152 nr 241664 gen 6 prealloc data offset 0 nr 241664 item 8 key (257 EXTENT_DATA 266240) itemoff 15704 itemsize 53 extent data disk byte 12845056 nr 4096 gen 6 extent data offset 0 nr 20480 ram 20480 extent compression 2 item 9 key (257 EXTENT_DATA 286720) itemoff 15651 itemsize 53 prealloc data disk byte 13090816 nr 405504 gen 6 prealloc data offset 0 nr 258048 The on disk extent at offset 266240 (which corresponds to 1 single disk block), contains 5 compressed chunks of file data. Each of the first 4 compress 4096 bytes of file data, while the last one only compresses 3024 bytes of file data. Therefore a read into the file region [285648 ; 286720[ (length = 4096 - 3024 = 1072 bytes) should always return zeroes (our next extent is a prealloc one). The solution here is the compression code path to zero the remaining (untouched) bytes of the last page it uncompressed data into, as the information about how much space the file data consumes in the last page is not known in the upper layer fs/btrfs/extent_io.c:__do_readpage(). In __do_readpage we were correctly zeroing the remainder of the page but only if it corresponds to the last page of the inode and if the inode's size is not a multiple of the page size. This would cause not only returning random data on reads, but also permanently storing random data when updating parts of the region that should be zeroed. For the example above, it means updating a single byte in the region [285648 ; 286720[ would store that byte correctly but also store random data on disk. A test case for xfstests follows soon. Signed-off-by: Filipe David Borba Manana Signed-off-by: Chris Mason Signed-off-by: Jiri Slaby commit 3939448a3adb1a157d4b01ca9082b6a19b6c4a34 Author: Filipe David Borba Manana Date: Fri Dec 20 15:17:46 2013 +0000 Btrfs: fix tree mod logging commit 5de865eebb8330eee19c37b31fb6f315a09d4273 upstream. While running the test btrfs/004 from xfstests in a loop, it failed about 1 time out of 20 runs in my desktop. The failure happened in the backref walking part of the test, and the test's error message was like this: btrfs/004 93s ... [failed, exit status 1] - output mismatch (see /home/fdmanana/git/hub/xfstests_2/results//btrfs/004.out.bad) --- tests/btrfs/004.out 2013-11-26 18:25:29.263333714 +0000 +++ /home/fdmanana/git/hub/xfstests_2/results//btrfs/004.out.bad 2013-12-10 15:25:10.327518516 +0000 @@ -1,3 +1,8 @@ QA output created by 004 *** test backref walking -*** done +unexpected output from + /home/fdmanana/git/hub/btrfs-progs/btrfs inspect-internal logical-resolve -P 141512704 /home/fdmanana/btrfs-tests/scratch_1 +expected inum: 405, expected address: 454656, file: /home/fdmanana/btrfs-tests/scratch_1/snap1/p0/d6/d3d/d156/fce, got: + ... (Run 'diff -u tests/btrfs/004.out /home/fdmanana/git/hub/xfstests_2/results//btrfs/004.out.bad' to see the entire diff) Ran: btrfs/004 Failures: btrfs/004 Failed 1 of 1 tests But immediately after the test finished, the btrfs inspect-internal command returned the expected output: $ btrfs inspect-internal logical-resolve -P 141512704 /home/fdmanana/btrfs-tests/scratch_1 inode 405 offset 454656 root 258 inode 405 offset 454656 root 5 It turned out this was because the btrfs_search_old_slot() calls performed during backref walking (backref.c:__resolve_indirect_ref) were not finding anything. The reason for this turned out to be that the tree mod logging code was not logging some node multi-step operations atomically, therefore btrfs_search_old_slot() callers iterated often over an incomplete tree that wasn't fully consistent with any tree state from the past. Besides missing items, this often (but not always) resulted in -EIO errors during old slot searches, reported in dmesg like this: [ 4299.933936] ------------[ cut here ]------------ [ 4299.933949] WARNING: CPU: 0 PID: 23190 at fs/btrfs/ctree.c:1343 btrfs_search_old_slot+0x57b/0xab0 [btrfs]() [ 4299.933950] Modules linked in: btrfs raid6_pq xor pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) bnep rfcomm bluetooth parport_pc ppdev binfmt_misc joydev snd_hda_codec_h [ 4299.933977] CPU: 0 PID: 23190 Comm: btrfs Tainted: G W O 3.12.0-fdm-btrfs-next-16+ #70 [ 4299.933978] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z77 Pro4, BIOS P1.50 09/04/2012 [ 4299.933979] 000000000000053f ffff8806f3fd98f8 ffffffff8176d284 0000000000000007 [ 4299.933982] 0000000000000000 ffff8806f3fd9938 ffffffff8104a81c ffff880659c64b70 [ 4299.933984] ffff880659c643d0 ffff8806599233d8 ffff880701e2e938 0000160000000000 [ 4299.933987] Call Trace: [ 4299.933991] [] dump_stack+0x55/0x76 [ 4299.933994] [] warn_slowpath_common+0x8c/0xc0 [ 4299.933997] [] warn_slowpath_null+0x1a/0x20 [ 4299.934003] [] btrfs_search_old_slot+0x57b/0xab0 [btrfs] [ 4299.934005] [] ? _raw_read_unlock+0x2b/0x50 [ 4299.934010] [] ? __tree_mod_log_search+0x81/0xc0 [btrfs] [ 4299.934019] [] __resolve_indirect_refs+0x130/0x5f0 [btrfs] [ 4299.934027] [] ? free_extent_buffer+0x61/0xc0 [btrfs] [ 4299.934034] [] find_parent_nodes+0x1fc/0xe40 [btrfs] [ 4299.934042] [] ? defrag_lookup_extent+0xe0/0xe0 [btrfs] [ 4299.934048] [] ? defrag_lookup_extent+0xe0/0xe0 [btrfs] [ 4299.934056] [] iterate_extent_inodes+0xe0/0x250 [btrfs] [ 4299.934058] [] ? _raw_spin_unlock+0x2b/0x50 [ 4299.934065] [] iterate_inodes_from_logical+0x92/0xb0 [btrfs] [ 4299.934071] [] ? defrag_lookup_extent+0xe0/0xe0 [btrfs] [ 4299.934078] [] btrfs_ioctl+0xf65/0x1f60 [btrfs] [ 4299.934080] [] ? handle_mm_fault+0x278/0xb00 [ 4299.934083] [] ? up_read+0x23/0x40 [ 4299.934085] [] ? __do_page_fault+0x20c/0x5a0 [ 4299.934088] [] do_vfs_ioctl+0x96/0x570 [ 4299.934090] [] ? error_sti+0x5/0x6 [ 4299.934093] [] ? trace_hardirqs_off_caller+0x28/0xd0 [ 4299.934096] [] ? retint_swapgs+0xe/0x13 [ 4299.934098] [] SyS_ioctl+0x91/0xb0 [ 4299.934100] [] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 4299.934102] [] system_call_fastpath+0x16/0x1b [ 4299.934102] [] system_call_fastpath+0x16/0x1b [ 4299.934104] ---[ end trace 48f0cfc902491414 ]--- [ 4299.934378] btrfs bad fsid on block 0 These tree mod log operations that must be performed atomically, tree_mod_log_free_eb, tree_mod_log_eb_copy, tree_mod_log_insert_root and tree_mod_log_insert_move, used to be performed atomically before the following commit: c8cc6341653721b54760480b0d0d9b5f09b46741 (Btrfs: stop using GFP_ATOMIC for the tree mod log allocations) That change removed the atomicity of such operations. This patch restores the atomicity while still not doing the GFP_ATOMIC allocations of tree_mod_elem structures, so it has to do the allocations using GFP_NOFS before acquiring the mod log lock. This issue has been experienced by several users recently, such as for example: http://www.spinics.net/lists/linux-btrfs/msg28574.html After running the btrfs/004 test for 679 consecutive iterations with this patch applied, I didn't ran into the issue anymore. Cc: stable@vger.kernel.org Signed-off-by: Filipe David Borba Manana Signed-off-by: Josef Bacik Signed-off-by: Chris Mason Signed-off-by: Jiri Slaby commit 4e6e3bd45f6fd9caac44f6fa944a78d81f2d8d1d Author: Filipe David Borba Manana Date: Thu Dec 12 19:19:52 2013 +0000 Btrfs: return immediately if tree log mod is not necessary commit 783577663507411e36e459390ef056556e93ef29 upstream. In ctree.c:tree_mod_log_set_node_key() we were calling __tree_mod_log_insert_key() even when the modification doesn't need to be logged. This would allocate a tree_mod_elem structure, fill it and pass it to __tree_mod_log_insert(), which would just acquire the tree mod log write lock and then free the tree_mod_elem structure and return (that is, a no-op). Therefore call tree_mod_log_insert() instead of __tree_mod_log_insert() which just returns immediately if the modification doesn't need to be logged (without allocating the structure, fill it, acquire write lock, free structure). Signed-off-by: Filipe David Borba Manana Signed-off-by: Josef Bacik Signed-off-by: Chris Mason Signed-off-by: Jiri Slaby commit 2b183ff24e726b97e2eeef5a54f88d4a8ac4f7d8 Author: Knut Petersen Date: Wed Sep 25 14:29:37 2013 +0200 perf: Enforce 1 as lower limit for perf_event_max_sample_rate commit 723478c8a471403c53cf144999701f6e0c4bbd11 upstream. /proc/sys/kernel/perf_event_max_sample_rate will accept negative values as well as 0. Negative values are unreasonable, and 0 causes a divide by zero exception in perf_proc_update_handler. This patch enforces a lower limit of 1. Signed-off-by: Knut Petersen Signed-off-by: Peter Zijlstra Link: http://lkml.kernel.org/r/5242DB0C.4070005@t-online.de Signed-off-by: Ingo Molnar Signed-off-by: Jiri Slaby commit 454d0fc5cdf56444ef17e7f56d6c047734c86a0e Author: Eric Dumazet Date: Thu Feb 6 10:42:42 2014 -0800 net: use __GFP_NORETRY for high order allocations [ Upstream commit ed98df3361f059db42786c830ea96e2d18b8d4db ] sock_alloc_send_pskb() & sk_page_frag_refill() have a loop trying high order allocations to prepare skb with low number of fragments as this increases performance. Problem is that under memory pressure/fragmentation, this can trigger OOM while the intent was only to try the high order allocations, then fallback to order-0 allocations. We had various reports from unexpected regressions. According to David, setting __GFP_NORETRY should be fine, as the asynchronous compaction is still enabled, and this will prevent OOM from kicking as in : CFSClientEventm invoked oom-killer: gfp_mask=0x42d0, order=3, oom_adj=0, oom_score_adj=0, oom_score_badness=2 (enabled),memcg_scoring=disabled CFSClientEventm Call Trace: [] dump_header+0xe1/0x23e [] oom_kill_process+0x6a/0x323 [] out_of_memory+0x4b3/0x50d [] __alloc_pages_may_oom+0xa2/0xc7 [] __alloc_pages_nodemask+0x1002/0x17f0 [] alloc_pages_current+0x103/0x2b0 [] sk_page_frag_refill+0x8f/0x160 [] tcp_sendmsg+0x560/0xee0 [] inet_sendmsg+0x67/0x100 [] __sock_sendmsg_nosec+0x6c/0x90 [] sock_sendmsg+0xc5/0xf0 [] __sys_sendmsg+0x136/0x430 [] sys_sendmsg+0x88/0x110 [] system_call_fastpath+0x16/0x1b Out of Memory: Kill process 2856 (bash) score 9999 or sacrifice child Signed-off-by: Eric Dumazet Acked-by: David Rientjes Acked-by: "Eric W. Biederman" Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 91e97e5763b4f0425ad90df39a23cdbd72671a7e Author: Florian Westphal Date: Sat Feb 22 10:28:31 2014 +0100 net: ip, ipv6: handle gso skbs in forwarding path commit fe6cc55f3a9a053482a76f5a6b2257cee51b4663 upstream. Marcelo Ricardo Leitner reported problems when the forwarding link path has a lower mtu than the incoming one if the inbound interface supports GRO. Given: Host R1 R2 Host sends tcp stream which is routed via R1 and R2. R1 performs GRO. In this case, the kernel will fail to send ICMP fragmentation needed messages (or pkt too big for ipv6), as GSO packets currently bypass dstmtu checks in forward path. Instead, Linux tries to send out packets exceeding the mtu. When locking route MTU on Host (i.e., no ipv4 DF bit set), R1 does not fragment the packets when forwarding, and again tries to send out packets exceeding R1-R2 link mtu. This alters the forwarding dstmtu checks to take the individual gso segment lengths into account. For ipv6, we send out pkt too big error for gso if the individual segments are too big. For ipv4, we either send icmp fragmentation needed, or, if the DF bit is not set, perform software segmentation and let the output path create fragments when the packet is leaving the machine. It is not 100% correct as the error message will contain the headers of the GRO skb instead of the original/segmented one, but it seems to work fine in my (limited) tests. Eric Dumazet suggested to simply shrink mss via ->gso_size to avoid sofware segmentation. However it turns out that skb_segment() assumes skb nr_frags is related to mss size so we would BUG there. I don't want to mess with it considering Herbert and Eric disagree on what the correct behavior should be. Hannes Frederic Sowa notes that when we would shrink gso_size skb_segment would then also need to deal with the case where SKB_MAX_FRAGS would be exceeded. This uses sofware segmentation in the forward path when we hit ipv4 non-DF packets and the outgoing link mtu is too small. Its not perfect, but given the lack of bug reports wrt. GRO fwd being broken this is a rare case anyway. Also its not like this could not be improved later once the dust settles. Acked-by: Herbert Xu Reported-by: Marcelo Ricardo Leitner Signed-off-by: Florian Westphal Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 0777d823861813723375c0e6123acc61d4ff8d56 Author: Florian Westphal Date: Sat Feb 22 10:28:30 2014 +0100 net: core: introduce netif_skb_dev_features commit d206940319c41df4299db75ed56142177bb2e5f6 upstream. Will be used by upcoming ipv4 forward path change that needs to determine feature mask using skb->dst->dev instead of skb->dev. Signed-off-by: Florian Westphal Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 449c57330908bd59b524091c0b7d12d5ab39197d Author: Florian Westphal Date: Sat Feb 22 10:28:29 2014 +0100 net: add and use skb_gso_transport_seglen() commit de960aa9ab4decc3304959f69533eef64d05d8e8 upstream. This moves part of Eric Dumazets skb_gso_seglen helper from tbf sched to skbuff core so it may be reused by upcoming ip forwarding path patch. Signed-off-by: Florian Westphal Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 515266decdb0d4b868b0dec7a70d37af48918b25 Author: Daniel Borkmann Date: Mon Feb 17 12:11:11 2014 +0100 net: sctp: fix sctp_connectx abi for ia32 emulation/compat mode [ Upstream commit ffd5939381c609056b33b7585fb05a77b4c695f3 ] SCTP's sctp_connectx() abi breaks for 64bit kernels compiled with 32bit emulation (e.g. ia32 emulation or x86_x32). Due to internal usage of 'struct sctp_getaddrs_old' which includes a struct sockaddr pointer, sizeof(param) check will always fail in kernel as the structure in 64bit kernel space is 4bytes larger than for user binaries compiled in 32bit mode. Thus, applications making use of sctp_connectx() won't be able to run under such circumstances. Introduce a compat interface in the kernel to deal with such situations by using a 'struct compat_sctp_getaddrs_old' structure where user data is copied into it, and then sucessively transformed into a 'struct sctp_getaddrs_old' structure with the help of compat_ptr(). That fixes sctp_connectx() abi without any changes needed in user space, and lets the SCTP test suite pass when compiled in 32bit and run on 64bit kernels. Fixes: f9c67811ebc0 ("sctp: Fix regression introduced by new sctp_connectx api") Signed-off-by: Daniel Borkmann Acked-by: Neil Horman Acked-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit a97a04ffa2ce28dd1b0905e29a5ba36429ff6d2b Author: Duan Jiong Date: Mon Feb 17 15:23:43 2014 +0800 ipv4: fix counter in_slow_tot [ Upstream commit a6254864c08109c66a194612585afc0439005286 ] since commit 89aef8921bf("ipv4: Delete routing cache."), the counter in_slow_tot can't work correctly. The counter in_slow_tot increase by one when fib_lookup() return successfully in ip_route_input_slow(), but actually the dst struct maybe not be created and cached, so we can increase in_slow_tot after the dst struct is created. Signed-off-by: Duan Jiong Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit c92210fdc60d7be2ece4fbdbdd82d811355583d8 Author: Jiri Bohac Date: Fri Feb 14 18:13:50 2014 +0100 bonding: 802.3ad: make aggregator_identifier bond-private [ Upstream commit 163c8ff30dbe473abfbb24a7eac5536c87f3baa9 ] aggregator_identifier is used to assign unique aggregator identifiers to aggregators of a bond during device enslaving. aggregator_identifier is currently a global variable that is zeroed in bond_3ad_initialize(). This sequence will lead to duplicate aggregator identifiers for eth1 and eth3: create bond0 change bond0 mode to 802.3ad enslave eth0 to bond0 //eth0 gets agg id 1 enslave eth1 to bond0 //eth1 gets agg id 2 create bond1 change bond1 mode to 802.3ad enslave eth2 to bond1 //aggregator_identifier is reset to 0 //eth2 gets agg id 1 enslave eth3 to bond0 //eth3 gets agg id 2 Fix this by making aggregator_identifier private to the bond. Signed-off-by: Jiri Bohac Acked-by: Veaceslav Falico Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit e8047a7d1ab917588d8dda3d6a99d570be47460e Author: Emil Goode Date: Thu Feb 13 17:50:19 2014 +0100 usbnet: remove generic hard_header_len check [ Upstream commit eb85569fe2d06c2fbf4de7b66c263ca095b397aa ] This patch removes a generic hard_header_len check from the usbnet module that is causing dropped packages under certain circumstances for devices that send rx packets that cross urb boundaries. One example is the AX88772B which occasionally send rx packets that cross urb boundaries where the remaining partial packet is sent with no hardware header. When the buffer with a partial packet is of less number of octets than the value of hard_header_len the buffer is discarded by the usbnet module. With AX88772B this can be reproduced by using ping with a packet size between 1965-1976. The bug has been reported here: https://bugzilla.kernel.org/show_bug.cgi?id=29082 This patch introduces the following changes: - Removes the generic hard_header_len check in the rx_complete function in the usbnet module. - Introduces a ETH_HLEN check for skbs that are not cloned from within a rx_fixup callback. - For safety a hard_header_len check is added to each rx_fixup callback function that could be affected by this change. These extra checks could possibly be removed by someone who has the hardware to test. - Removes a call to dev_kfree_skb_any() and instead utilizes the dev->done list to queue skbs for cleanup. The changes place full responsibility on the rx_fixup callback functions that clone skbs to only pass valid skbs to the usbnet_skb_return function. Signed-off-by: Emil Goode Reported-by: Igor Gnatenko Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 3089923511e29f755226edaa80fed0d622beb256 Author: Emil Goode Date: Thu Feb 13 19:30:39 2014 +0100 net: asix: add missing flag to struct driver_info [ Upstream commit d43ff4cd798911736fb39025ec8004284b1b0bc2 ] The struct driver_info ax88178_info is assigned the function asix_rx_fixup_common as it's rx_fixup callback. This means that FLAG_MULTI_PACKET must be set as this function is cloning the data and calling usbnet_skb_return. Not setting this flag leads to usbnet_skb_return beeing called a second time from within the rx_process function in the usbnet module. Signed-off-by: Emil Goode Reported-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 1d2e001bfa119126098310d0cb860fdc8a2c6cf8 Author: Michael S. Tsirkin Date: Thu Feb 13 11:42:05 2014 +0200 vhost: fix ref cnt checking deadlock [ Upstream commit 0ad8b480d6ee916aa84324f69acf690142aecd0e ] vhost checked the counter within the refcnt before decrementing. It really wanted to know that it is the one that has the last reference, as a way to batch freeing resources a bit more efficiently. Note: we only let refcount go to 0 on device release. This works well but we now access the ref counter twice so there's a race: all users might see a high count and decide to defer freeing resources. In the end no one initiates freeing resources until the last reference is gone (which is on VM shotdown so might happen after a looooong time). Let's do what we probably should have done straight away: switch from kref to plain atomic, documenting the semantics, return the refcount value atomically after decrement, then use that to avoid the deadlock. Reported-by: Qin Chuanyu Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 917cc7f09179ad3e0291ace1b56dd5b9788d8131 Author: Nithin Sujir Date: Thu Feb 6 14:13:05 2014 -0800 tg3: Fix deadlock in tg3_change_mtu() [ Upstream commit c6993dfd7db9b0c6b7ca7503a56fda9236a4710f ] Quoting David Vrabel - "5780 cards cannot have jumbo frames and TSO enabled together. When jumbo frames are enabled by setting the MTU, the TSO feature must be cleared. This is done indirectly by calling netdev_update_features() which will call tg3_fix_features() to actually clear the flags. netdev_update_features() will also trigger a new netlink message for the feature change event which will result in a call to tg3_get_stats64() which deadlocks on the tg3 lock." tg3_set_mtu() does not need to be under the tg3 lock since converting the flags to use set_bit(). Move it out to after tg3_netif_stop(). Reported-by: David Vrabel Tested-by: David Vrabel Signed-off-by: Michael Chan Signed-off-by: Nithin Nayak Sujir Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 6f7656e87ae2f4b916afa23c27321268f0ba80c8 Author: John Ogness Date: Sun Feb 9 18:40:11 2014 -0800 tcp: tsq: fix nonagle handling [ Upstream commit bf06200e732de613a1277984bf34d1a21c2de03d ] Commit 46d3ceabd8d9 ("tcp: TCP Small Queues") introduced a possible regression for applications using TCP_NODELAY. If TCP session is throttled because of tsq, we should consult tp->nonagle when TX completion is done and allow us to send additional segment, especially if this segment is not a full MSS. Otherwise this segment is sent after an RTO. [edumazet] : Cooked the changelog, added another fix about testing sk_wmem_alloc twice because TX completion can happen right before setting TSQ_THROTTLED bit. This problem is particularly visible with recent auto corking, but might also be triggered with low tcp_limit_output_bytes values or NIC drivers delaying TX completion by hundred of usec, and very low rtt. Thomas Glanzmann for example reported an iscsi regression, caused by tcp auto corking making this bug quite visible. Fixes: 46d3ceabd8d9 ("tcp: TCP Small Queues") Signed-off-by: John Ogness Signed-off-by: Eric Dumazet Reported-by: Thomas Glanzmann Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit dce84839274f940e533c9ae424cb2fc24a13dd0a Author: Bjørn Mork Date: Tue Feb 4 13:04:33 2014 +0100 net: qmi_wwan: add Netgear Aircard 340U [ Upstream commit fbd3a77d813f211060f86cc7a2f8416caf0e03b1 ] This device was mentioned in an OpenWRT forum. Seems to have a "standard" Sierra Wireless ifnumber to function layout: 0: qcdm 2: nmea 3: modem 8: qmi 9: storage Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 7b694760856cc5059b550724d3030e53c7cfd2d2 Author: Sabrina Dubroca Date: Thu Feb 6 18:34:12 2014 +0100 netpoll: fix netconsole IPv6 setup [ Upstream commit 00fe11b3c67dc670fe6391d22f1fe64e7c99a8ec ] Currently, to make netconsole start over IPv6, the source address needs to be specified. Without a source address, netpoll_parse_options assumes we're setting up over IPv4 and the destination IPv6 address is rejected. Check if the IP version has been forced by a source address before checking for a version mismatch when parsing the destination address. Signed-off-by: Sabrina Dubroca Acked-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 7d9c1b6b1e2730813b4d8692e5a51785fbd378db Author: Maciej Żenczykowski Date: Fri Feb 7 16:23:48 2014 -0800 net: fix 'ip rule' iif/oif device rename [ Upstream commit 946c032e5a53992ea45e062ecb08670ba39b99e3 ] ip rules with iif/oif references do not update: (detach/attach) across interface renames. Signed-off-by: Maciej Żenczykowski CC: Willem de Bruijn CC: Eric Dumazet CC: Chris Davis CC: Carlo Contavalli Google-Bug-Id: 12936021 Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 0c360776a126e0d2347ab917d1c0936683053af1 Author: Geert Uytterhoeven Date: Wed Feb 5 08:38:25 2014 +0100 ipv4: Fix runtime WARNING in rtmsg_ifa() [ Upstream commit 63b5f152eb4a5bb79b9caf7ec37b4201d12f6e66 ] On m68k/ARAnyM: WARNING: CPU: 0 PID: 407 at net/ipv4/devinet.c:1599 0x316a99() Modules linked in: CPU: 0 PID: 407 Comm: ifconfig Not tainted 3.13.0-atari-09263-g0c71d68014d1 #1378 Stack from 10c4fdf0: 10c4fdf0 002ffabb 000243e8 00000000 008ced6c 00024416 00316a99 0000063f 00316a99 00000009 00000000 002501b4 00316a99 0000063f c0a86117 00000080 c0a86117 00ad0c90 00250a5a 00000014 00ad0c90 00000000 00000000 00000001 00b02dd0 00356594 00000000 00356594 c0a86117 eff6c9e4 008ced6c 00000002 008ced60 0024f9b4 00250b52 00ad0c90 00000000 00000000 00252390 00ad0c90 eff6c9e4 0000004f 00000000 00000000 eff6c9e4 8000e25c eff6c9e4 80001020 Call Trace: [<000243e8>] warn_slowpath_common+0x52/0x6c [<00024416>] warn_slowpath_null+0x14/0x1a [<002501b4>] rtmsg_ifa+0xdc/0xf0 [<00250a5a>] __inet_insert_ifa+0xd6/0x1c2 [<0024f9b4>] inet_abc_len+0x0/0x42 [<00250b52>] inet_insert_ifa+0xc/0x12 [<00252390>] devinet_ioctl+0x2ae/0x5d6 Adding some debugging code reveals that net_fill_ifaddr() fails in put_cacheinfo(skb, ifa->ifa_cstamp, ifa->ifa_tstamp, preferred, valid)) nla_put complains: lib/nlattr.c:454: skb_tailroom(skb) = 12, nla_total_size(attrlen) = 20 Apparently commit 5c766d642bcaffd0c2a5b354db2068515b3846cf ("ipv4: introduce address lifetime") forgot to take into account the addition of struct ifa_cacheinfo in inet_nlmsg_size(). Hence add it, like is already done for ipv6. Suggested-by: Cong Wang Signed-off-by: Geert Uytterhoeven Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit b3097b176d15f0342cd3ca5c25bb03f06123ecd7 Author: Oliver Hartkopp Date: Thu Jan 30 10:11:28 2014 +0100 can: add destructor for self generated skbs [ Upstream commit 0ae89beb283a0db5980d1d4781c7d7be2f2810d6 ] Self generated skbuffs in net/can/bcm.c are setting a skb->sk reference but no explicit destructor which is enforced since Linux 3.11 with commit 376c7311bdb6 (net: add a temporary sanity check in skb_orphan()). This patch adds some helper functions to make sure that a destructor is properly defined when a sock reference is assigned to a CAN related skb. To create an unshared skb owned by the original sock a common helper function has been introduced to replace open coded functions to create CAN echo skbs. Signed-off-by: Oliver Hartkopp Tested-by: Andre Naujoks Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit d7691e10f65fd732695f1ccc60b89b712ad0bb49 Author: Cong Wang Date: Thu Feb 6 15:00:52 2014 -0800 bridge: fix netconsole setup over bridge [ Upstream commit dbe173079ab58a444e12dbebe96f5aec1e0bed1a ] Commit 93d8bf9fb8f3 ("bridge: cleanup netpoll code") introduced a check in br_netpoll_enable(), but this check is incorrect for br_netpoll_setup(). This patch moves the code after the check into __br_netpoll_enable() and calls it in br_netpoll_setup(). For br_add_if(), the check is still needed. Fixes: 93d8bf9fb8f3 ("bridge: cleanup netpoll code") Cc: Toshiaki Makita Cc: Stephen Hemminger Cc: David S. Miller Signed-off-by: Cong Wang Signed-off-by: Cong Wang Acked-by: Toshiaki Makita Tested-by: Toshiaki Makita Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit ef9daf83724b8475236c64c85c6e31aa7cd0aa9b Author: Richard Yao Date: Sat Feb 8 19:32:01 2014 -0500 9p/trans_virtio.c: Fix broken zero-copy on vmalloc() buffers [ Upstream commit b6f52ae2f0d32387bde2b89883e3b64d88b9bfe8 ] The 9p-virtio transport does zero copy on things larger than 1024 bytes in size. It accomplishes this by returning the physical addresses of pages to the virtio-pci device. At present, the translation is usually a bit shift. That approach produces an invalid page address when we read/write to vmalloc buffers, such as those used for Linux kernel modules. Any attempt to load a Linux kernel module from 9p-virtio produces the following stack. [] p9_virtio_zc_request+0x45e/0x510 [] p9_client_zc_rpc.constprop.16+0xfd/0x4f0 [] p9_client_read+0x15d/0x240 [] v9fs_fid_readn+0x50/0xa0 [] v9fs_file_readn+0x10/0x20 [] v9fs_file_read+0x37/0x70 [] vfs_read+0x9b/0x160 [] kernel_read+0x41/0x60 [] copy_module_from_fd.isra.34+0xfb/0x180 Subsequently, QEMU will die printing: qemu-system-x86_64: virtio: trying to map MMIO memory This patch enables 9p-virtio to correctly handle this case. This not only enables us to load Linux kernel modules off virtfs, but also enables ZFS file-based vdevs on virtfs to be used without killing QEMU. Special thanks to both Avi Kivity and Alexander Graf for their interpretation of QEMU backtraces. Without their guidence, tracking down this bug would have taken much longer. Also, special thanks to Linus Torvalds for his insightful explanation of why this should use is_vmalloc_addr() instead of is_vmalloc_or_module_addr(): https://lkml.org/lkml/2014/2/8/272 Signed-off-by: Richard Yao Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 9399fb6751cd485c61586cc1e1637ead4e35717e Author: Eric Dumazet Date: Mon Feb 10 11:42:35 2014 -0800 6lowpan: fix lockdep splats [ Upstream commit 20e7c4e80dcd01dad5e6c8b32455228b8fe9c619 ] When a device ndo_start_xmit() calls again dev_queue_xmit(), lockdep can complain because dev_queue_xmit() is re-entered and the spinlocks protecting tx queues share a common lockdep class. Same issue was fixed for bonding/l2tp/ppp in commits 0daa2303028a6 ("[PATCH] bonding: lockdep annotation") 49ee49202b4ac ("bonding: set qdisc_tx_busylock to avoid LOCKDEP splat") 23d3b8bfb8eb2 ("net: qdisc busylock needs lockdep annotations ") 303c07db487be ("ppp: set qdisc_tx_busylock to avoid LOCKDEP splat ") Reported-by: Alexander Aring Signed-off-by: Eric Dumazet Tested-by: Alexander Aring Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby