commit a1bc295d7a4be9425bbeecc005d0cd013eb46cea Author: Greg Kroah-Hartman Date: Sat Jun 7 13:24:43 2014 -0700 Linux 3.14.6 commit b1f9d594668d008cacd5679cfde675dcdb9f5f8f Author: Thomas Gleixner Date: Tue Jun 3 12:27:08 2014 +0000 futex: Make lookup_pi_state more robust commit 54a217887a7b658e2650c3feff22756ab80c7339 upstream. The current implementation of lookup_pi_state has ambigous handling of the TID value 0 in the user space futex. We can get into the kernel even if the TID value is 0, because either there is a stale waiters bit or the owner died bit is set or we are called from the requeue_pi path or from user space just for fun. The current code avoids an explicit sanity check for pid = 0 in case that kernel internal state (waiters) are found for the user space address. This can lead to state leakage and worse under some circumstances. Handle the cases explicit: Waiter | pi_state | pi->owner | uTID | uODIED | ? [1] NULL | --- | --- | 0 | 0/1 | Valid [2] NULL | --- | --- | >0 | 0/1 | Valid [3] Found | NULL | -- | Any | 0/1 | Invalid [4] Found | Found | NULL | 0 | 1 | Valid [5] Found | Found | NULL | >0 | 1 | Invalid [6] Found | Found | task | 0 | 1 | Valid [7] Found | Found | NULL | Any | 0 | Invalid [8] Found | Found | task | ==taskTID | 0/1 | Valid [9] Found | Found | task | 0 | 0 | Invalid [10] Found | Found | task | !=taskTID | 0/1 | Invalid [1] Indicates that the kernel can acquire the futex atomically. We came came here due to a stale FUTEX_WAITERS/FUTEX_OWNER_DIED bit. [2] Valid, if TID does not belong to a kernel thread. If no matching thread is found then it indicates that the owner TID has died. [3] Invalid. The waiter is queued on a non PI futex [4] Valid state after exit_robust_list(), which sets the user space value to FUTEX_WAITERS | FUTEX_OWNER_DIED. [5] The user space value got manipulated between exit_robust_list() and exit_pi_state_list() [6] Valid state after exit_pi_state_list() which sets the new owner in the pi_state but cannot access the user space value. [7] pi_state->owner can only be NULL when the OWNER_DIED bit is set. [8] Owner and user space value match [9] There is no transient state which sets the user space TID to 0 except exit_robust_list(), but this is indicated by the FUTEX_OWNER_DIED bit. See [4] [10] There is no transient state which leaves owner and user space TID out of sync. Signed-off-by: Thomas Gleixner Cc: Kees Cook Cc: Will Drewry Cc: Darren Hart Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 19040c57ac6f39a6940c7c266bb80cee113d3a18 Author: Thomas Gleixner Date: Tue Jun 3 12:27:07 2014 +0000 futex: Always cleanup owner tid in unlock_pi commit 13fbca4c6ecd96ec1a1cfa2e4f2ce191fe928a5e upstream. If the owner died bit is set at futex_unlock_pi, we currently do not cleanup the user space futex. So the owner TID of the current owner (the unlocker) persists. That's observable inconsistant state, especially when the ownership of the pi state got transferred. Clean it up unconditionally. Signed-off-by: Thomas Gleixner Cc: Kees Cook Cc: Will Drewry Cc: Darren Hart Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit cae300d1bd7c591602725520aec185cc81d49547 Author: Thomas Gleixner Date: Tue Jun 3 12:27:06 2014 +0000 futex: Validate atomic acquisition in futex_lock_pi_atomic() commit b3eaa9fc5cd0a4d74b18f6b8dc617aeaf1873270 upstream. We need to protect the atomic acquisition in the kernel against rogue user space which sets the user space futex to 0, so the kernel side acquisition succeeds while there is existing state in the kernel associated to the real owner. Verify whether the futex has waiters associated with kernel state. If it has, return -EINVAL. The state is corrupted already, so no point in cleaning it up. Subsequent calls will fail as well. Not our problem. [ tglx: Use futex_top_waiter() and explain why we do not need to try restoring the already corrupted user space state. ] Signed-off-by: Darren Hart Cc: Kees Cook Cc: Will Drewry Signed-off-by: Thomas Gleixner Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 1ab0607b48fdcbac787b073f845f2ef529d4e936 Author: Thomas Gleixner Date: Tue Jun 3 12:27:06 2014 +0000 futex-prevent-requeue-pi-on-same-futex.patch futex: Forbid uaddr == uaddr2 in futex_requeue(..., requeue_pi=1) commit e9c243a5a6de0be8e584c604d353412584b592f8 upstream. If uaddr == uaddr2, then we have broken the rule of only requeueing from a non-pi futex to a pi futex with this call. If we attempt this, then dangling pointers may be left for rt_waiter resulting in an exploitable condition. This change brings futex_requeue() in line with futex_wait_requeue_pi() which performs the same check as per commit 6f7b0a2a5c0f ("futex: Forbid uaddr == uaddr2 in futex_wait_requeue_pi()") [ tglx: Compare the resulting keys as well, as uaddrs might be different depending on the mapping ] Fixes CVE-2014-3153. Reported-by: Pinkie Pie Signed-off-by: Will Drewry Signed-off-by: Kees Cook Signed-off-by: Thomas Gleixner Reviewed-by: Darren Hart Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3e32c277e17b859738f0d38a2e609ad926554ee9 Author: Sudeep Holla Date: Fri May 9 17:37:44 2014 +0100 arm64: use cpu_online_mask when using forced irq_set_affinity commit 601c942176d8ad8334118bddb747e3720bed24f8 upstream. Commit 01f8fa4f01d8("genirq: Allow forcing cpu affinity of interrupts") enabled the forced irq_set_affinity which previously refused to route an interrupt to an offline cpu. Commit ffde1de64012("irqchip: Gic: Support forced affinity setting") implements this force logic and disables the cpu online check for GIC interrupt controller. When __cpu_disable calls migrate_irqs, it disables the current cpu in cpu_online_mask and uses forced irq_set_affinity to migrate the IRQs away from the cpu but passes affinity mask with the cpu being offlined also included in it. When calling irq_set_affinity with force == true in a cpu hotplug path, the caller must ensure that the cpu being offlined is not present in the affinity mask or it may be selected as the target CPU, leading to the interrupt not being migrated. This patch uses cpu_online_mask when using forced irq_set_affinity so that the IRQs are properly migrated away. Signed-off-by: Sudeep Holla Acked-by: Mark Rutland Cc: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 3372ac6f0c1617a381f8a69ff1e7cc2e6751bdd3 Author: Guennadi Liakhovetski Date: Sat Apr 26 12:51:31 2014 -0300 media: V4L2: fix VIDIOC_CREATE_BUFS in 64- / 32-bit compatibility mode commit 97d9d23dda6f37d90aefeec4ed619d52df525382 upstream. If a struct contains 64-bit fields, it is aligned on 64-bit boundaries within containing structs in 64-bit compilations. This is the case with struct v4l2_window, which contains pointers and is embedded into struct v4l2_format, and that one is embedded into struct v4l2_create_buffers. Unlike some other structs, used as a part of the kernel ABI as ioctl() arguments, that are packed, these structs aren't packed. This isn't a problem per se, but the ioctl-compat code for VIDIOC_CREATE_BUFS contains a bug, that triggers in such 64-bit builds. That code wrongly assumes, that in struct v4l2_create_buffers, struct v4l2_format immediately follows the __u32 memory field, which in fact isn't the case. This bug wasn't visible until now, because until recently hardly any applications used this ioctl() and mostly embedded 32-bit only drivers implemented it. This is changing now with addition of this ioctl() to some USB drivers, e.g. UVC. This patch fixes the bug by copying parts of struct v4l2_create_buffers separately. Signed-off-by: Guennadi Liakhovetski Acked-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit d0c47e5d003514bef6b7be36a49a4c87058a732a Author: Guennadi Liakhovetski Date: Mon Apr 14 10:49:34 2014 -0300 media: V4L2: ov7670: fix a wrong index, potentially Oopsing the kernel from user-space commit cfece5857ca51d1dcdb157017aba226f594e9dcf upstream. Commit 75e2bdad8901a0b599e01a96229be922eef1e488 "ov7670: allow configuration of image size, clock speed, and I/O method" uses a wrong index to iterate an array. Apart from being wrong, it also uses an unchecked value from user-space, which can cause access to unmapped memory in the kernel, triggered by a normal desktop user with rights to use V4L2 devices. Signed-off-by: Guennadi Liakhovetski Acked-by: Jonathan Corbet Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit ca4a4d64a7b1c0d08067622c02ec6a276a4ebf7c Author: Eyal Shapira Date: Wed Jun 4 21:58:01 2014 +0300 iwlwifi: mvm: rs: clear per rate stats when aggregation changes commit b804eeb6649d75caeccbeae9f5623fc7b8bdfdfa upstream. The per rate stats should be cleared when aggregation state changes to avoid making rate scale decisions based on throughput figures which were collected prior to the aggregation state change and are now stale. While at it make sure any clearing of the per rate stats will get logged. Signed-off-by: Eyal Shapira Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit 424048eb3ff12c2b8da830cb8827d5bec136f515 Author: Eliad Peller Date: Wed Jun 4 21:58:00 2014 +0300 iwlwifi: add rs_rate_scale_clear_tbl_windows helper function commit 3ca71f603bb1a0f55e1ba24618ba45617bc36f70 upstream. instead of duplicating the same loop multiple times, use a new function for it. this will be later used also for clearing other windows in the table. Signed-off-by: Eliad Peller Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit f47fc3c1b48dd8fc7a0a591551454459eca0ca94 Author: Emmanuel Grumbach Date: Sun May 18 19:05:23 2014 +0300 iwlwifi: mvm: disable beacon filtering commit 7bacc782270ff7db3b9f29fa5d24ad2ee1e8e81d upstream. This feature has been causing trouble - disable it for now. Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit 24d0dd75ef19c885309cf06990267cd2cbf49fa4 Author: Antti Palosaari Date: Thu Apr 10 21:18:16 2014 -0300 media: fc2580: fix tuning failure on 32-bit arch commit 8845cc6415ec28ef8d57b3fb81c75ef9bce69c5f upstream. There was some frequency calculation overflows which caused tuning failure on 32-bit architecture. Use 64-bit numbers where needed in order to avoid calculation overflows. Thanks for the Finnish person, who asked remain anonymous, reporting, testing and suggesting the fix. Signed-off-by: Antti Palosaari Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit c1a763c431dffca42b609be822a4e1ef4231c582 Author: Alex Williamson Date: Tue Apr 22 10:08:40 2014 -0600 iommu/amd: Fix interrupt remapping for aliased devices commit e028a9e6b8a637af09ac4114083280df4a7045f1 upstream. An apparent cut and paste error prevents the correct flags from being set on the alias device resulting in MSI on conventional PCI devices failing to work. This also produces error events from the IOMMU like: AMD-Vi: Event logged [INVALID_DEVICE_REQUEST device=00:14.4 address=0x000000fdf8000000 flags=0x0a00] Where 14.4 is a PCIe-to-PCI bridge with a device behind it trying to use MSI interrupts. Signed-off-by: Alex Williamson Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit bcd5faf938fb061c4c02874a906b68c5642822f3 Author: Chunwei Chen Date: Wed Apr 23 12:35:09 2014 +0800 libceph: fix corruption when using page_count 0 page in rbd commit 178eda29ca721842f2146378e73d43e0044c4166 upstream. It has been reported that using ZFSonLinux on rbd will result in memory corruption. The bug report can be found here: https://github.com/zfsonlinux/spl/issues/241 http://tracker.ceph.com/issues/7790 The reason is that ZFS will send pages with page_count 0 into rbd, which in turns send them to tcp_sendpage. However, tcp_sendpage cannot deal with page_count 0, as it will do get_page and put_page, and erroneously free the page. This type of issue has been noted before, and handled in iscsi, drbd, etc. So, rbd should also handle this. This fix address this issue by fall back to slower sendmsg when page_count 0 detected. Cc: Sage Weil Cc: Yehuda Sadeh Signed-off-by: Chunwei Chen Reviewed-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit a03443f50794844b449d296d45557315208bec1e Author: Geert Uytterhoeven Date: Mon Apr 14 19:39:53 2014 +0200 spi: core: Ignore unsupported Dual/Quad Transfer Mode bits commit 83596fbeb5d28e8cb8878786133945d4dc7c0090 upstream. The availability of SPI Dual or Quad Transfer Mode as indicated by the "spi-tx-bus-width" and "spi-rx-bus-width" properties in the device tree is a hardware property of the SPI master, SPI slave, and board wiring. Hence the SPI core should not reject an SPI slave because an SPI master driver doesn't (yet) support Dual or Quad Transfer Mode. Change the lack of Dual or Quad Transfer Mode support in the SPI master driver from an error condition to a warning condition, and ignore the unsupported mode bits, falling back to Single Transfer Mode, to avoid breakages when running old kernels with new device trees. Fixes: f477b7fb13df (spi: DUAL and QUAD support) Signed-off-by: Geert Uytterhoeven Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 26aa7dc4730b1931dc908790944ff618d98931f5 Author: Srivatsa S. Bhat Date: Tue May 27 16:25:34 2014 +0530 powerpc, kexec: Fix "Processor X is stuck" issue during kexec from ST mode commit 011e4b02f1da156ac7fea28a9da878f3c23af739 upstream. If we try to perform a kexec when the machine is in ST (Single-Threaded) mode (ppc64_cpu --smt=off), the kexec operation doesn't succeed properly, and we get the following messages during boot: [ 0.089866] POWER8 performance monitor hardware support registered [ 0.089985] power8-pmu: PMAO restore workaround active. [ 5.095419] Processor 1 is stuck. [ 10.097933] Processor 2 is stuck. [ 15.100480] Processor 3 is stuck. [ 20.102982] Processor 4 is stuck. [ 25.105489] Processor 5 is stuck. [ 30.108005] Processor 6 is stuck. [ 35.110518] Processor 7 is stuck. [ 40.113369] Processor 9 is stuck. [ 45.115879] Processor 10 is stuck. [ 50.118389] Processor 11 is stuck. [ 55.120904] Processor 12 is stuck. [ 60.123425] Processor 13 is stuck. [ 65.125970] Processor 14 is stuck. [ 70.128495] Processor 15 is stuck. [ 75.131316] Processor 17 is stuck. Note that only the sibling threads are stuck, while the primary threads (0, 8, 16 etc) boot just fine. Looking closer at the previous step of kexec, we observe that kexec tries to wakeup (bring online) the sibling threads of all the cores, before performing kexec: [ 9464.131231] Starting new kernel [ 9464.148507] kexec: Waking offline cpu 1. [ 9464.148552] kexec: Waking offline cpu 2. [ 9464.148600] kexec: Waking offline cpu 3. [ 9464.148636] kexec: Waking offline cpu 4. [ 9464.148671] kexec: Waking offline cpu 5. [ 9464.148708] kexec: Waking offline cpu 6. [ 9464.148743] kexec: Waking offline cpu 7. [ 9464.148779] kexec: Waking offline cpu 9. [ 9464.148815] kexec: Waking offline cpu 10. [ 9464.148851] kexec: Waking offline cpu 11. [ 9464.148887] kexec: Waking offline cpu 12. [ 9464.148922] kexec: Waking offline cpu 13. [ 9464.148958] kexec: Waking offline cpu 14. [ 9464.148994] kexec: Waking offline cpu 15. [ 9464.149030] kexec: Waking offline cpu 17. Instrumenting this piece of code revealed that the cpu_up() operation actually fails with -EBUSY. Thus, only the primary threads of all the cores are online during kexec, and hence this is a sure-shot receipe for disaster, as explained in commit e8e5c2155b (powerpc/kexec: Fix orphaned offline CPUs across kexec), as well as in the comment above wake_offline_cpus(). It turns out that cpu_up() was returning -EBUSY because the variable 'cpu_hotplug_disabled' was set to 1; and this disabling of CPU hotplug was done by migrate_to_reboot_cpu() inside kernel_kexec(). Now, migrate_to_reboot_cpu() was originally written with the assumption that any further code will not need to perform CPU hotplug, since we are anyway in the reboot path. However, kexec is clearly not such a case, since we depend on onlining CPUs, atleast on powerpc. So re-enable cpu-hotplug after returning from migrate_to_reboot_cpu() in the kexec path, to fix this regression in kexec on powerpc. Also, wrap the cpu_up() in powerpc kexec code within a WARN_ON(), so that we can catch such issues more easily in the future. Fixes: c97102ba963 (kexec: migrate to reboot cpu) Signed-off-by: Srivatsa S. Bhat Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit f7fb605a0215a7646f07f6618e40c2032b174680 Author: Guenter Roeck Date: Thu May 15 09:33:42 2014 -0700 powerpc: Fix 64 bit builds with binutils 2.24 commit 7998eb3dc700aaf499f93f50b3d77da834ef9e1d upstream. With binutils 2.24, various 64 bit builds fail with relocation errors such as arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e': (.text+0x165ee): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_base_book3e' defined in .text section in arch/powerpc/kernel/built-in.o arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e': (.text+0x16602): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_end_book3e' defined in .text section in arch/powerpc/kernel/built-in.o The assembler maintainer says: I changed the ABI, something that had to be done but unfortunately happens to break the booke kernel code. When building up a 64-bit value with lis, ori, shl, oris, ori or similar sequences, you now should use @high and @higha in place of @h and @ha. @h and @ha (and their associated relocs R_PPC64_ADDR16_HI and R_PPC64_ADDR16_HA) now report overflow if the value is out of 32-bit signed range. ie. @h and @ha assume you're building a 32-bit value. This is needed to report out-of-range -mcmodel=medium toc pointer offsets in @toc@h and @toc@ha expressions, and for consistency I did the same for all other @h and @ha relocs. Replacing @h with @high in one strategic location fixes the relocation errors. This has to be done conditionally since the assembler either supports @h or @high but not both. Signed-off-by: Guenter Roeck Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 0605993990f785c882924305f5383d9cb765e736 Author: Anton Blanchard Date: Fri May 9 17:47:12 2014 +1000 powerpc: irq work racing with timer interrupt can result in timer interrupt hang commit 8050936caf125fbe54111ba5e696b68a360556ba upstream. I am seeing an issue where a CPU running perf eventually hangs. Traces show timer interrupts happening every 4 seconds even when a userspace task is running on the CPU. /proc/timer_list also shows pending hrtimers have not run in over an hour, including the scheduler. Looking closer, decrementers_next_tb is getting set to 0xffffffffffffffff, and at that point we will never take a timer interrupt again. In __timer_interrupt() we set decrementers_next_tb to 0xffffffffffffffff and rely on ->event_handler to update it: *next_tb = ~(u64)0; if (evt->event_handler) evt->event_handler(evt); In this case ->event_handler is hrtimer_interrupt. This will eventually call back through the clockevents code with the next event to be programmed: static int decrementer_set_next_event(unsigned long evt, struct clock_event_device *dev) { /* Don't adjust the decrementer if some irq work is pending */ if (test_irq_work_pending()) return 0; __get_cpu_var(decrementers_next_tb) = get_tb_or_rtc() + evt; If irq work came in between these two points, we will return before updating decrementers_next_tb and we never process a timer interrupt again. This looks to have been introduced by 0215f7d8c53f (powerpc: Fix races with irq_work). Fix it by removing the early exit and relying on code later on in the function to force an early decrementer: /* We may have raced with new irq work */ if (test_irq_work_pending()) set_dec(1); Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 6f73026dde44a785cc59697167b1f505c80377ea Author: Gavin Shan Date: Thu Apr 24 18:00:22 2014 +1000 powerpc/powernv: Reset root port in firmware commit 372cf1244d7c271806b83b32b09a1c8b1b31b353 upstream. Resetting root port has more stuff to do than that for PCIe switch ports and we should have resetting root port done in firmware instead of the kernel itself. The problem was introduced by commit 5b2e198e ("powerpc/powernv: Rework EEH reset"). Signed-off-by: Gavin Shan Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 2bf0e785c5c78bcdf1eaa7b6516240ab58cad25c Author: Stephen Boyd Date: Fri Apr 18 16:29:43 2014 -0700 clk: Fix slab corruption in clk_unregister() commit 874f224cc52d64c912087e68e3724be95ad80ee7 upstream. When a clock is unregsitered, we iterate over the list of children and reparent them to NULL (i.e. orphan list). While iterating the list, we should use the safe iterators because the children list for this clock is changing when we reparent the children to NULL. Failure to iterate safely can lead to slab corruption like this: ============================================================================= BUG kmalloc-128 (Not tainted): Poison overwritten ----------------------------------------------------------------------------- Disabling lock debugging due to kernel taint INFO: 0xed0c4900-0xed0c4903. First byte 0x0 instead of 0x6b INFO: Allocated in clk_register+0x20/0x1bc age=297 cpu=2 pid=70 __slab_alloc.isra.39.constprop.42+0x410/0x454 kmem_cache_alloc_trace+0x200/0x24c clk_register+0x20/0x1bc devm_clk_register+0x34/0x68 0xbf0000f0 platform_drv_probe+0x18/0x48 driver_probe_device+0x94/0x360 __driver_attach+0x94/0x98 bus_for_each_dev+0x54/0x88 bus_add_driver+0xe8/0x204 driver_register+0x78/0xf4 do_one_initcall+0xc4/0x17c load_module+0x19ac/0x2294 SyS_init_module+0xa4/0x110 ret_fast_syscall+0x0/0x48 INFO: Freed in clk_unregister+0xd4/0x140 age=23 cpu=2 pid=73 __slab_free+0x38/0x41c clk_unregister+0xd4/0x140 release_nodes+0x164/0x1d8 __device_release_driver+0x60/0xb0 driver_detach+0xb4/0xb8 bus_remove_driver+0x5c/0xc4 SyS_delete_module+0x148/0x1d8 ret_fast_syscall+0x0/0x48 INFO: Slab 0xeec50b90 objects=25 used=0 fp=0xed0c5400 flags=0x4080 INFO: Object 0xed0c48c0 @offset=2240 fp=0xed0c4a00 Bytes b4 ed0c48b0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ Object ed0c48c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object ed0c48d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object ed0c48e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object ed0c48f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object ed0c4900: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b ....kkkkkkkkkkkk Object ed0c4910: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object ed0c4920: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object ed0c4930: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk. Redzone ed0c4940: bb bb bb bb .... Padding ed0c49e8: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ Padding ed0c49f8: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ CPU: 3 PID: 75 Comm: mdev Tainted: G B 3.14.0-11033-g2054ba5ca781 #35 [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0x70/0xbc) [] (dump_stack) from [] (check_bytes_and_report+0xbc/0x100) [] (check_bytes_and_report) from [] (check_object+0x18c/0x218) [] (check_object) from [] (__free_slab+0x104/0x144) [] (__free_slab) from [] (__slab_free+0x3dc/0x41c) [] (__slab_free) from [] (load_elf_binary+0x88/0x12b4) [] (load_elf_binary) from [] (search_binary_handler+0x78/0x18c) [] (search_binary_handler) from [] (do_execve+0x490/0x5dc) [] (do_execve) from [] (____call_usermodehelper+0x134/0x168) [] (____call_usermodehelper) from [] (ret_from_fork+0x14/0x2c) FIX kmalloc-128: Restoring 0xed0c4900-0xed0c4903=0x6b Fixes: fcb0ee6a3d33 (clk: Implement clk_unregister) Cc: Jiada Wang Cc: Sylwester Nawrocki Cc: Kyungmin Park Signed-off-by: Stephen Boyd Signed-off-by: Mike Turquette Signed-off-by: Greg Kroah-Hartman commit 798ad2abc1b05842b7bd5292ff43055e4a767a64 Author: Stephen Boyd Date: Fri Apr 18 16:29:42 2014 -0700 clk: Fix double free due to devm_clk_register() commit 293ba3b4a4fd54891b900f2911d1a57e1ed4a843 upstream. Now that clk_unregister() frees the struct clk we're unregistering we'll free memory twice: first we'll call kfree() in __clk_release() with an address kmalloc doesn't know about and second we'll call kfree() in the devres layer. Remove the allocation of struct clk in devm_clk_register() and let clk_release() handle it. This fixes slab errors like: ============================================================================= BUG kmalloc-128 (Not tainted): Invalid object pointer 0xed08e8d0 ----------------------------------------------------------------------------- Disabling lock debugging due to kernel taint INFO: Slab 0xeec503f8 objects=25 used=15 fp=0xed08ea00 flags=0x4081 CPU: 2 PID: 73 Comm: rmmod Tainted: G B 3.14.0-11032-g526e9c764381 #34 [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0x70/0xbc) [] (dump_stack) from [] (slab_err+0x74/0x84) [] (slab_err) from [] (free_debug_processing+0x2cc/0x31c) [] (free_debug_processing) from [] (__slab_free+0x38/0x41c) [] (__slab_free) from [] (clk_unregister+0xd4/0x140) [] (clk_unregister) from [] (release_nodes+0x164/0x1d8) [] (release_nodes) from [] (__device_release_driver+0x60/0xb0) [] (__device_release_driver) from [] (driver_detach+0xb4/0xb8) [] (driver_detach) from [] (bus_remove_driver+0x5c/0xc4) [] (bus_remove_driver) from [] (SyS_delete_module+0x148/0x1d8) [] (SyS_delete_module) from [] (ret_fast_syscall+0x0/0x48) FIX kmalloc-128: Object at 0xed08e8d0 not freed Fixes: fcb0ee6a3d33 (clk: Implement clk_unregister) Cc: Jiada Wang Cc: Sylwester Nawrocki Cc: Kyungmin Park Signed-off-by: Stephen Boyd Signed-off-by: Mike Turquette Signed-off-by: Greg Kroah-Hartman commit 55494146e3d09cb6febacea484012b9dac55cb4b Author: Harald Freudenberger Date: Wed May 7 16:51:29 2014 +0200 crypto: s390 - fix aes,des ctr mode concurrency finding. commit 3901c1124ec5099254a9396085f7798153a7293f upstream. An additional testcase found an issue with the last series of patches applied: the fallback solution may not save the iv value after operation. This very small fix just makes sure the iv is copied back to the walk/desc struct. Signed-off-by: Harald Freudenberger Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit c40da129a2be0858f7e9dc8503fc878c0ebc5f6f Author: Horia Geanta Date: Fri Apr 18 13:01:42 2014 +0300 crypto: caam - add allocation failure handling in SPRINTFCAT macro commit 27c5fb7a84242b66bf1e0b2fe6bf40d19bcc5c04 upstream. GFP_ATOMIC memory allocation could fail. In this case, avoid NULL pointer dereference and notify user. Cc: Kim Phillips Signed-off-by: Horia Geanta Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 23de3167679e331f65d9aebdfb07fbf4f2167a4c Author: Dirk Brandewie Date: Thu May 8 12:57:24 2014 -0700 intel_pstate: remove setting P state to MAX on init commit d40a63c45b506b0681918d7c62a15cc9d48c8681 upstream. Setting the P state of the core to max at init time is a hold over from early implementation of intel_pstate where intel_pstate disabled cpufreq and loaded VERY early in the boot sequence. This was to ensure that intel_pstate did not affect boot time. This in not needed now that intel_pstate is a cpufreq driver. Removing this covers the case where a CPU has gone through a manual CPU offline/online cycle and the P state is set to MAX on init and the CPU immediately goes idle. Due to HW coordination the P state request on the idle CPU will drag all cores to MAX P state until the load is reevaluated when to core goes non-idle. Reported-by: Patrick Marlier Signed-off-by: Dirk Brandewie Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit dd4c4afb005de0415ea06e3586b017e193c1539e Author: Dirk Brandewie Date: Thu May 8 12:57:23 2014 -0700 intel_pstate: Set turbo VID for BayTrail commit 21855ff5bcbdd075e1c99772827a84912ab083dd upstream. A documentation update exposed that there is a separate set of VID values that must be used in the turbo/boost P state range. Add enumerating and setting the correct VID for P states in the turbo range. Signed-off-by: Dirk Brandewie Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 35493cad041359561d13dfd4c3c0df33cdd5ea4c Author: Olof Johansson Date: Fri Apr 11 15:19:41 2014 -0700 i2c: s3c2410: resume race fix commit ce78cc071f5f541480e381cc0241d37590041a9d upstream. Don't unmark the device as suspended until after it's been re-setup. The main race would be w.r.t. an i2c driver that gets resumed at the same time (asyncronously), that is allowed to do a transfer since suspended is set to 0 before reinit, but really should have seen the -EIO return instead. Signed-off-by: Olof Johansson Signed-off-by: Doug Anderson Acked-by: Kukjin Kim Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit bd811c103a08a9e35a01c0a304ba2ff87af36694 Author: Du, Wenkai Date: Thu Apr 10 23:03:19 2014 +0000 i2c: designware: Mask all interrupts during i2c controller enable commit 47bb27e78867997040a228328f2a631c3c7f2c82 upstream. There have been "i2c_designware 80860F41:00: controller timed out" errors on a number of Baytrail platforms. The issue is caused by incorrect value in Interrupt Mask Register (DW_IC_INTR_MASK) when i2c core is being enabled. This causes call to __i2c_dw_enable() to immediately start the transfer which leads to timeout. There are 3 failure modes observed: 1. Failure in S0 to S3 resume path The default value after reset for DW_IC_INTR_MASK is 0x8ff. When we start the first transaction after resuming from system sleep, TX_EMPTY interrupt is already unmasked because of the hardware default. 2. Failure in normal operational path This failure happens rarely and is hard to reproduce. Debug trace showed that DW_IC_INTR_MASK had value of 0x254 when failure occurred, which meant TX_EMPTY was unmasked. 3. Failure in S3 to S0 suspend path This failure also happens rarely and is hard to reproduce. Adding debug trace that read DW_IC_INTR_MASK made this failure not reproducible. But from ISR call trace we could conclude TX_EMPTY was unmasked when problem occurred. The patch masks all interrupts before the controller is enabled to resolve the faulty DW_IC_INTR_MASK conditions. Signed-off-by: Wenkai Du Acked-by: Mika Westerberg [wsa: improved the comment and removed typo in commit msg] Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 6a8702825dc2c66c7233c0b5d9b05a4cddec9eca Author: Wolfram Sang Date: Mon May 5 18:36:21 2014 +0200 i2c: rcar: bail out on zero length transfers commit d7653964c590ba846aa11a8f6edf409773cbc492 upstream. This hardware does not support zero length transfers. Instead, the driver does one (random) byte transfers currently with undefined results for the slaves. We now bail out. Signed-off-by: Wolfram Sang Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 6dc7b7dafd495b5234496e17abab217ac5bccb1a Author: Hans de Goede Date: Fri May 16 21:10:41 2014 +0200 ACPI / video: Revert native brightness quirk for ThinkPad T530 commit 07d1d29ee1e194b932328ad2dc1d40297062ab7f upstream. Seems it helps some users, but causes issues for other users: https://bugzilla.redhat.com/show_bug.cgi?id=1089545 So lets drop it for now until we've figured out a better fix. Fixes: 43d949024425 (ACPI / video: Add use_native_backlight quirks for more systems) References: https://bugzilla.redhat.com/show_bug.cgi?id=1089545 Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 73561c3027499aef22e68719b8f473b4ecadc23b Author: Aaron Lu Date: Tue May 13 09:51:50 2014 +0800 ACPI / video: correct DMI tag for Dell Inspiron 7520 commit 5ff365fb6aed4c7ee5aae7b0239ce0b514aefabc upstream. The DMI tag used to identify Dell Inspiron 7520 should be product name instead of product version. Fixes: 0e9f81d3b7cd (ACPI / video: Add systems that should favour native backlight interface) Reported-and-tested-by: Téo Mazars References: https://bugzilla.redhat.com/show_bug.cgi?id=909552 Signed-off-by: Aaron Lu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit fcbe7574986518eb6896c18804dc77d8dfd879ea Author: Rafael J. Wysocki Date: Mon May 12 01:13:28 2014 +0200 ACPI / TPM: Fix resume regression on Chromebooks commit f759546498d820670934c901a2fdf1ce948d2e5c upstream. Chromebooks (at least Acer C720 and Pixel) implement an ACPI object for TPM, but don't implement the _DSM method to support PPI. As a result, the TPM driver fails to load on those machines after commit 1569a4c4ceba (ACPI / TPM: detect PPI features by checking availability of _DSM functions) which causes them to fail to resume from system suspend, becuase they require the TPM hardware to be put into the right state during resume and the TPM driver is necessary for that. Fix the problem by making tpm_add_ppi() return 0 when tpm_ppi_handle is still NULL after walking the ACPI namespace in search for the PPI _DSM, which allows the TPM driver to load and operate the hardware (during system resume in particular), but avoid creating the PPI sysfs group in that case. This change is based on a prototype patch from Jiang Liu. Fixes: 1569a4c4ceba (ACPI / TPM: detect PPI features by checking availability of _DSM functions) References: https://bugzilla.kernel.org/show_bug.cgi?id=74021 Reported-by: James Duley Reported-by: Phillip Dixon Tested-by: Brandon Casey Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 10f5ccb2fdfd09f5c30ed73fb9309abec0d7d85f Author: Edward Lin Date: Wed May 7 10:47:24 2014 +0800 ACPI: blacklist win8 OSI for Dell Inspiron 7737 commit b753631b3576bf343151a82513c5d56fcda1e24f upstream. With win8 capabiltiy, the machine will boot itself immediately after shutdown command has executed. Work around this issue by disabling win8 capcability. This workaround also makes wireless hotkey work. Signed-off-by: Edward Lin Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 4f8102db05803247beb7d6013d53c13bc2e429e8 Author: Guenter Roeck Date: Tue May 6 19:18:28 2014 -0700 ACPI: Revert "ACPI / AC: convert ACPI ac driver to platform bus" commit 98012849e0cbf980326f8e34d571f4474866a88e upstream. Revert commit cc8ef5270734 (ACPI / AC: convert ACPI ac driver to platform bus) that is reported to break thermal management on MacBook Air 2013 with ArchLinux. Fixes: cc8ef5270734 (ACPI / AC: convert ACPI ac driver to platform bus) References: https://bugzilla.kernel.org/show_bug.cgi?id=71711 Cc: Zhang Rui Reported-and-tested-by: Manuel Krause Signed-off-by: Guenter Roeck Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 8c9bc41c0e97c9e176710876ca9e068b1435f409 Author: Igor Mammedov Date: Mon May 5 22:49:49 2014 +0200 ACPI / processor: do not mark present at boot but not onlined CPU as onlined commit 0b9d46dd7debf8e6dc8614106f1c1909fa8de64d upstream. acpi_processor_add() assumes that present at boot CPUs are always onlined, it is not so if a CPU failed to become onlined. As result acpi_processor_add() will mark such CPU device as onlined in sysfs and following attempts to online/offline it using /sys/device/system/cpu/cpuX/online attribute will fail. Do not poke into device internals in acpi_processor_add() and touch "struct device { .offline }" attribute, since for CPUs onlined at boot it's set by: topology_init() -> arch_register_cpu() -> register_cpu() before ACPI device tree is parsed, and for hotplugged CPUs it's set when userspace onlines CPU via sysfs. Signed-off-by: Igor Mammedov Acked-by: Toshi Kani Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 9c020b30dc3064cf0eb1be1164c38c67e3135239 Author: Hans de Goede Date: Mon May 5 11:38:09 2014 +0200 ACPI / blacklist: Add dmi_enable_osi_linux quirk for Asus EEE PC 1015PX commit f6e6e1b9fee88c90586787b71dc49bb3ce62bb89 upstream. Without this this EEE PC exports a non working WMI interface, with this it exports a working "good old" eeepc_laptop interface, fixing brightness control not working as well as rfkill being stuck in a permanent wireless blocked state. This is not an ideal way to fix this, but various attempts to fix this otherwise have failed, see: References: https://bugzilla.redhat.com/show_bug.cgi?id=1067181 Reported-and-tested-by: lou.cardone@gmail.com Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 3e873234bf01413486c9d7151dea202a7ffc6a43 Author: Hans de Goede Date: Mon May 5 11:38:08 2014 +0200 ACPI / video: Add use_native_backlight quirks for more systems commit 43d9490244254d2d6adb0f3c6275c7b8d032a2dd upstream. ThinkPad T430: extend the T430s entry to also cover the T430 (note we also have another entry for T430's with a different DMI_PRODUCT_VERSION). ThinkPad T430 Reported-and-tested-by: edm References: https://bugzilla.kernel.org/show_bug.cgi?id=51231 Thinkpad T530 Reported-and-tested-by: Balint Szigeti References: https://bugzilla.redhat.com/show_bug.cgi?id=1089545 Acer Aspire 5742G Reported-and-tested-by: AnAkkk References: https://bugzilla.kernel.org/show_bug.cgi?id=35622 Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit da33adbd92be1217c55adf3f164b35ff2238fd32 Author: Lan Tianyu Date: Sun May 4 11:07:25 2014 +0800 ACPI: Revert "ACPI / Battery: Remove battery's proc directory" commit 3a670cc79342c36d308decd5f90351830ed1685c upstream. The commit 1e2d9cd and 7d7ee95 remove ACPI Proc Battery directory and breaks some old userspace tools. This patch is to revert commit 1e2d9cd. Fixes: 1e2d9cdfb449 (ACPI / Battery: Remove battery's proc directory) Signed-off-by: Lan Tianyu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit ef0dcd4fd05a21b411a345f88acf4d841b8e34c4 Author: Lan Tianyu Date: Sun May 4 11:07:24 2014 +0800 ACPI: Revert "ACPI: Remove CONFIG_ACPI_PROCFS_POWER and cm_sbsc.c" commit e2a7c3d7812369daae56f069eab2e8f3e548d231 upstream. The commit 1e2d9cd and 7d7ee95 remove ACPI Proc Battery directory and breaks some old userspace tools. This patch is to revert 7d7ee95. Fixes: 7d7ee958867a (ACPI: Remove CONFIG_ACPI_PROCFS_POWER and cm_sbsc.c) Signed-off-by: Lan Tianyu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 0ed09dccba02daca9afa960d160a74a6f72c4398 Author: Lv Zheng Date: Tue May 13 16:50:30 2014 +0800 ACPICA: Tables: Restore old behavor to favor 32-bit FADT addresses. commit 85dbd5801f62b66e2aa7826aaefcaebead44c8a6 upstream. We need to find a smarter way to switch to 64-bit FADT addresses according to the bug report. This patch reverts Linux to the original behavior. Fixes: 0249ed2444d6 (ACPICA: Add option to favor 32-bit FADT addresses.) References: https://bugzilla.kernel.org/show_bug.cgi?id=74021 Reported-and-tested-by: Oswald Buddenhagen Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 226ae56a2f6043d841c654c6e47e38ca16fa8957 Author: Lv Zheng Date: Wed Apr 30 10:05:40 2014 +0800 ACPICA: Tables: Fix invalid pointer accesses in acpi_tb_parse_root_table(). commit d48dc067450d84324067f4472dc0b169e9af4454 upstream. Linux XSDT validation mechanism backport has introduced a regreession: Commit: 671cc68dc61f029d44b43a681356078e02d8dab8 Subject: ACPICA: Back port and refine validation of the XSDT root table. There is a pointer still accessed after unmapping. This patch fixes this issue. Lv Zheng. Fixes: 671cc68dc61f (ACPICA: Back port and refine validation of the XSDT root table.) References: https://bugzilla.kernel.org/show_bug.cgi?id=73911 References: https://bugs.archlinux.org/task/39811 Signed-off-by: Lv Zheng Reported-and-tested-by: Bruce Chiarelli Reported-and-tested-by: Spyros Stathopoulos Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 2ba7d5e2dcc58167017c404bd1fd2756d814e75c Author: Levente Kurusa Date: Tue May 6 15:57:48 2014 +0200 libata: clean up ZPODD when a port is detached commit a6f9bf4d2f965b862b95213303d154e02957eed8 upstream. When a ZPODD device is unbound via sysfs, the ACPI notify handler is not removed. This causes panics as observed in Bug #74601. The panic only happens when the wake happens from outside the kernel (i.e. inserting a media or pressing a button). Add a loop to ata_port_detach which loops through the port's devices and checks if zpodd is enabled, if so call zpodd_exit. Reviewed-by: Aaron Lu Signed-off-by: Levente Kurusa Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 17edcf1972526501acd31bfb8c689eb18d597b91 Author: Nicholas Bellinger Date: Mon May 12 12:18:32 2014 -0700 tcm_fc: Fix free-after-use regression in ft_free_cmd commit ed8ec8f707ed4760c124d47b27c93df8ec5b1eba upstream. This patch fixes a free-after-use regression in ft_free_cmd(), where ft_sess_put() is called with cmd->sess after percpu_ida_free() has already released the tag. Fix this bug by saving the ft_sess pointer ahead of percpu_ida_free(), and pass it directly to ft_sess_put(). The regression was originally introduced in v3.13-rc1 commit: commit 5f544cfac956971099e906f94568bc3fd1a7108a Author: Nicholas Bellinger Date: Mon Sep 23 12:12:42 2013 -0700 tcm_fc: Convert to per-cpu command map pre-allocation of ft_cmd Reported-by: Jun Wu Cc: Mark Rustad Cc: Robert Love Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 8b9df249dd60380b2347585038e643677715f591 Author: Andy Shevchenko Date: Wed May 7 10:56:24 2014 +0300 dmaengine: dw: went back to plain {request,free}_irq() calls commit 97977f7576a89cb9436c000ae703c0d515e748ac upstream. The commit dbde5c29 "dw_dmac: use devm_* functions to simplify code" turns probe function to use devm_* helpers and simultaneously brings a regression. We need to ensure irq is disabled, followed by ensuring that don't schedule any more tasklets and then its safe to use tasklet_kill(). The free_irq() will ensure that the irq is disabled and also wait till all scheduled interrupts are executed by invoking synchronize_irq(). So we need to only do tasklet_kill() after invoking free_irq(). Signed-off-by: Andy Shevchenko Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 2591d624cdfe6e24b0cb4f1da4845ba6a1dbe473 Author: Ezequiel Garcia Date: Wed May 21 14:02:35 2014 -0700 dma: mv_xor: Flush descriptors before activating a channel commit 5a9a55bf9157d3490b0c8c4c81d4708602c26e07 upstream. We need to use writel() instead of writel_relaxed() when starting a channel, to ensure all the descriptors have been flushed before the activation. While at it, remove the unneeded read-modify-write and make the code simpler. Signed-off-by: Lior Amsalem Signed-off-by: Ezequiel Garcia Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit e411566e7dc68df11b817d154fb06e3fd761bc77 Author: Xuelin Shi Date: Wed May 21 14:02:37 2014 -0700 dmaengine: fix dmaengine_unmap failure commit c1f43dd9c20d85e66c4d77e284f64ac114abe3f8 upstream. The count which is used to get_unmap_data maybe not the same as the count computed in dmaengine_unmap which causes to free data in a wrong pool. This patch fixes this issue by keeping the map count with unmap_data structure and use this count to get the pool. Signed-off-by: Xuelin Shi Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 6a1170d673278d51c8ceee2cb091d4baf4ef1ba2 Author: Joe Thornber Date: Fri May 9 15:59:38 2014 +0100 dm thin: add timeout to stop out-of-data-space mode holding IO forever commit 85ad643b7e7e52d37620fb272a9fd577a8095647 upstream. If the pool runs out of data space, dm-thin can be configured to either error IOs that would trigger provisioning, or hold those IOs until the pool is resized. Unfortunately, holding IOs until the pool is resized can result in a cascade of tasks hitting the hung_task_timeout, which may render the system unavailable. Add a fixed timeout so IOs can only be held for a maximum of 60 seconds. If LVM is going to resize a thin-pool that is out of data space it needs to be prompt about it. Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 36f7757dadcd45c0ecce396662f923c0841e12ff Author: Joe Thornber Date: Tue May 6 16:28:14 2014 +0100 dm thin: allow metadata commit if pool is in PM_OUT_OF_DATA_SPACE mode commit 8d07e8a5f5bc7b90f755d9b427ea930024f4c986 upstream. Commit 3e1a0699 ("dm thin: fix out of data space handling") introduced a regression in the metadata commit() method by returning an error if the pool is in PM_OUT_OF_DATA_SPACE mode. This oversight caused a thin device to return errors even if the default queue_if_no_space ENOSPC handling mode is used. Fix commit() to only fail if pool is in PM_READ_ONLY or PM_FAIL mode. Reported-by: qindehua@163.com Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 4cf3d5e62ea1868a963f6430eb7e40e46ac7295b Author: Mikulas Patocka Date: Thu Feb 20 18:01:01 2014 -0500 dm crypt: fix cpu hotplug crash by removing per-cpu structure commit 610f2de3559c383caf8fbbf91e9968102dff7ca0 upstream. The DM crypt target used per-cpu structures to hold pointers to a ablkcipher_request structure. The code assumed that the work item keeps executing on a single CPU, so it didn't use synchronization when accessing this structure. If a CPU is disabled by writing 0 to /sys/devices/system/cpu/cpu*/online, the work item could be moved to another CPU. This causes dm-crypt crashes, like the following, because the code starts using an incorrect ablkcipher_request: smpboot: CPU 7 is now offline BUG: unable to handle kernel NULL pointer dereference at 0000000000000130 IP: [] crypt_convert+0x12d/0x3c0 [dm_crypt] ... Call Trace: [] ? kcryptd_crypt+0x305/0x470 [dm_crypt] [] ? finish_task_switch+0x40/0xc0 [] ? process_one_work+0x168/0x470 [] ? worker_thread+0x10b/0x390 [] ? manage_workers.isra.26+0x290/0x290 [] ? kthread+0xaf/0xc0 [] ? kthread_create_on_node+0x120/0x120 [] ? ret_from_fork+0x7c/0xb0 [] ? kthread_create_on_node+0x120/0x120 Fix this bug by removing the per-cpu definition. The structure ablkcipher_request is accessed via a pointer from convert_context. Consequently, if the work item is rescheduled to a different CPU, the thread still uses the same ablkcipher_request. This change may undermine performance improvements intended by commit c0297721 ("dm crypt: scale to multiple cpus") on select hardware. In practice no performance difference was observed on recent hardware. But regardless, correctness is more important than performance. Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit c8b177eab863291fc70efabfc649fbfba0da9442 Author: Gavin Shan Date: Mon May 19 13:06:46 2014 +1000 PCI: Wrong register used to check pending traffic commit d0b4cc4e32705ff00d90d32da7783c266c702c04 upstream. The incorrect register offset is passed to pci_wait_for_pending(), which is caused by commit 157e876ffe ("PCI: Add pci_wait_for_pending() (refactor pci_wait_for_pending_transaction())"). Fixes: 157e876ffe ("PCI: Add pci_wait_for_pending() (refactor pci_wait_for_pending_transaction()) Signed-off-by: Gavin Shan Signed-off-by: Bjorn Helgaas Acked-by: Alex Williamson Signed-off-by: Greg Kroah-Hartman commit b2fe79d69507a4f8140089c0458b1a31211ebf67 Author: Emmanuel Grumbach Date: Sun Apr 13 15:51:41 2014 +0300 iwlwifi: mvm: BT Coex - fix Look Up Table commit a6bc92803e7f765e02c923cf37c8e280e729642a upstream. A few entries were wrong and this caused throughput issues. Fixes: dac94da8dba3 ("iwlwifi: mvm: new BT Coex API") Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit 6b88559e343570c67468dc4cf1eeeebe6f24ec3d Author: Jani Nikula Date: Wed May 21 11:07:25 2014 +0200 drm/i915: quirk invert brightness for Acer Aspire 5336 This is commit 0f540c3a7cfb91c9d7a19eb0c95c24 upstream. Since commit ee1452d7458451a7508e0663553ce88d63958157 Author: Jani Nikula Date: Fri Sep 20 15:05:30 2013 +0300 drm/i915: assume all GM45 Acer laptops use inverted backlight PWM failed and was later reverted in commit be505f643925e257087247b996cd8ece787c12af Author: Alexander van Heukelum Date: Sat Dec 28 21:00:39 2013 +0100 Revert "drm/i915: assume all GM45 Acer laptops use inverted backlight PWM" fix the individual broken machine instead. Note to backporters: http://patchwork.freedesktop.org/patch/17837/ is the patch you want for 3.13 and older. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=54171 Reference: http://mid.gmane.org/DUB115-W7628C7C710EA51AA110CD4A5000@phx.gbl Signed-off-by: Jani Nikula Reviewed-by: Ville Syrjälä [danvet: Patch mangling for 3.14 plus adding the link to the original for 3.13.] Signed-off-by: Daniel Vetter commit 01fdf4cb75be9337949bb6b8668e3a84747cf057 Author: Chris Wilson Date: Wed May 21 11:07:24 2014 +0200 drm/i915: Fix unsafe loop iteration over vma whilst unbinding them This is commit df6f783a4ef6790780a67c491897ac upstream. On non-LLC platforms, when changing the cache level of an object, we may need to unbind it so that prefetching across page boundaries does not cross into a different memory domain. This requires us to unbind conflicting vma, but we did so iterating over the objects vma in an unsafe manner (as the list was being modified as we iterated). The regression was introduced in commit 3089c6f239d7d2c4cb2dd5c353e8984cf79af1d7 Author: Ben Widawsky Date: Wed Jul 31 17:00:03 2013 -0700 drm/i915: make caching operate on all address spaces apparently as far back as v3.12-rc1, but it has only just begun to trigger real world bug reports. Reported-and-tested-by: Nikolay Martynov Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76384 Signed-off-by: Chris Wilson Cc: Ben Widawsky Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 68f914e32934bfa570ec9feff6a85896d376f8de Author: Imre Deak Date: Wed May 21 11:07:23 2014 +0200 drm/i915: move power domain init earlier during system resume This is commit 76c4b250080fff6e4befaa36199424 upstream. During resume the intel hda audio driver depends on the i915 driver reinitializing the audio power domain. Since the order of calling the i915 resume handler wrt. that of the audio driver is not guaranteed, move the power domain reinitialization step to the resume_early handler. This is guaranteed to run before the resume handler of any other driver. The power domain initialization in turn requires us to enable the i915 pci device first, so move that part earlier too. Accordingly disabling of the i915 pci device should happen after the audio suspend handler ran. So move the disabling later from the i915 resume handler to the resume_late handler. v2: - move intel_uncore_sanitize/early_sanitize earlier too, so they don't get reordered wrt. intel_power_domains_init_hw() Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76152 Signed-off-by: Imre Deak Reviewed-by: Takashi Iwai [danvet: Add cc: stable and loud comments that this is just a hack.] [danvet: Fix "Should it be static?" sparse warning reported by Wu Fengguang's kbuilder.] Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 32c6d0e4f0bf5be3604dbb9b6ac9df713a93f683 Author: Daniel Vetter Date: Wed May 21 11:07:22 2014 +0200 drm/i915: Disable self-refresh for untiled fbs on i915gm This is commit 2ab1bc9df01dbc19b55b2271100db7 upstream. Apparently it doesn't work. X-tiled self-refresh works flawlessly otoh. Apparently X still works correctly with linear framebuffers, so might just be an issue with the initial modeset. It's unclear whether this just borked wm setup from our side or a hw restriction, but just disabling gets things going. Note that this regression was only brought to light with commit 3f2dc5ac05714711fc14f2bf0ee5e42d5c08c581 Author: Ville Syrjälä Date: Fri Jan 10 14:06:47 2014 +0200 drm/i915: Fix 915GM self-refresh enable/disable before that self-refresh for i915GM didn't work at all. Kudos to Ville for spotting a little bug in the original patch I've attached to the bug. Cc: Ville Syrjälä Cc: Chris Wilson Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76103 Tested-by: Krzysztof Mazur Cc: Krzysztof Mazur Reviewed-by: Ville Syrjälä Signed-off-by: Daniel Vetter [Jani: rebase on top of drm-next with primary plane support.] Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 91afab3c0c9251e87ad786f49006d987d8baf90c Author: Mikulas Patocka Date: Sat May 17 06:49:22 2014 -0400 target: fix memory leak on XCOPY commit 1e1110c43b1cda9fe77fc4a04835e460550e6b3c upstream. On each processed XCOPY command, two "kmalloc-512" memory objects are leaked. These represent two allocations of struct xcopy_pt_cmd in target_core_xcopy.c. The reason for the memory leak is that the cmd_kref field is not initialized (thus, it is zero because the allocations were done with kzalloc). When we decrement zero kref in target_put_sess_cmd, the result is not zero, thus target_release_cmd_kref is not called. This patch fixes the bug by moving kref initialization from target_get_sess_cmd to transport_init_se_cmd (this function is called from target_core_xcopy.c, so it will correctly initialize cmd_kref). It can be easily verified that all code that calls target_get_sess_cmd also calls transport_init_se_cmd earlier, thus moving kref_init shouldn't introduce any new problems. Signed-off-by: Mikulas Patocka Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit e1ff900f3b048d488c81c21b18ae9da022a293a8 Author: Andy Grover Date: Wed May 14 15:48:06 2014 -0700 target: Don't allow setting WC emulation if device doesn't support commit 07b8dae38b09bcfede7e726f172e39b5ce8390d9 upstream. Just like for pSCSI, if the transport sets get_write_cache, then it is not valid to enable write cache emulation for it. Return an error. see https://bugzilla.redhat.com/show_bug.cgi?id=1082675 Reviewed-by: Chris Leech Signed-off-by: Andy Grover Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit d2e2fd98e0b0cbb233481822301c1757ddd69be2 Author: Nicholas Bellinger Date: Thu May 1 13:44:56 2014 -0700 iscsi-target: Change BUG_ON to REJECT in iscsit_process_nop_out commit 7cbfcc953789ff864c2bf8365a82a3fba4869649 upstream. This patch changes an incorrect use of BUG_ON to instead generate a REJECT + PROTOCOL_ERROR in iscsit_process_nop_out() code. This case can occur with traditional TCP where a flood of zeros in the data stream can reach this block for what is presumed to be a NOP-OUT with a solicited reply, but without a valid iscsi_cmd pointer. This incorrect BUG_ON was introduced during the v3.11-rc timeframe with the following commit: commit 778de368964c5b7e8100cde9f549992d521e9c89 Author: Nicholas Bellinger Date: Fri Jun 14 16:07:47 2013 -0700 iscsi/isert-target: Refactor ISCSI_OP_NOOP RX handling Reported-by: Arshad Hussain Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 3e0b286f942157529c4498295cfa9dade24bfdba Author: Sagi Grimberg Date: Tue Apr 29 13:13:45 2014 +0300 Target/iser: Fix iscsit_accept_np and rdma_cm racy flow commit 531b7bf4bd795d9a09eac92504322a472c010bc8 upstream. RDMA CM and iSCSI target flows are asynchronous and completely uncorrelated. Relying on the fact that iscsi_accept_np will be called after CM connection request event and will wait for it is a mistake. When attempting to login to a few targets this flow is racy and unpredictable, but for parallel login to dozens of targets will race and hang every time. The correct synchronizing mechanism in this case is pending on a semaphore rather than a wait_for_event. We keep the pending interruptible for iscsi_np cleanup stage. (Squash patch to remove dead code into parent - nab) Reported-by: Slava Shwartsman Signed-off-by: Sagi Grimberg Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit c4ee9c7a44d386c9bb88589a39c0cc30fd5526b0 Author: Sagi Grimberg Date: Tue Apr 29 13:13:44 2014 +0300 Target/iser: Fix wrong connection requests list addition commit 9fe63c88b1d59f1ce054d6948ccd3096496ecedb upstream. Should be adding list_add_tail($new, $head) and not the other way around. Signed-off-by: Sagi Grimberg Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit de162a48287592f93d3cc3a3af5a130d1fd648c7 Author: Andy Grover Date: Tue Apr 15 14:13:12 2014 -0700 target: Allow non-supporting backends to set pi_prot_type to 0 commit 448ba904160f9d8f69217c28a1692cee5afbff88 upstream. Userspace tools assume if a value is read from configfs, it is valid and will not cause an error if the same value is written back. The only valid value for pi_prot_type for backends not supporting DIF is 0, so allow this particular value to be set without returning an error. Reported-by: Krzysztof Chojnowski Signed-off-by: Andy Grover Reviewed-by: Sagi Grimberg Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 4d1a31078295f5aacb92bb313c6cd989f9d6742f Author: Marcel Apfelbaum Date: Thu May 15 12:42:49 2014 -0600 PCI: shpchp: Check bridge's secondary (not primary) bus speed commit 93fa9d32670f5592c8e56abc9928fc194e1e72fc upstream. When a new device is added below a hotplug bridge, the bridge's secondary bus speed and the device's bus speed must match. The shpchp driver previously checked the bridge's *primary* bus speed, not the secondary bus speed. This caused hot-add errors like: shpchp 0000:00:03.0: Speed of bus ff and adapter 0 mismatch Check the secondary bus speed instead. [bhelgaas: changelog] Link: https://bugzilla.kernel.org/show_bug.cgi?id=75251 Fixes: 3749c51ac6c1 ("PCI: Make current and maximum bus speeds part of the PCI core") Signed-off-by: Marcel Apfelbaum Signed-off-by: Bjorn Helgaas Acked-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit 43d3b56b2e8c6c6ffdd988187a096e5c24cb5a8b Author: Tejun Heo Date: Mon May 19 15:52:10 2014 -0400 sysfs: make sure read buffer is zeroed commit f5c16f29bf5e57ba4051fc7785ba7f035f798c71 upstream. 13c589d5b0ac ("sysfs: use seq_file when reading regular files") switched sysfs from custom read implementation to seq_file to enable later transition to kernfs. After the change, the buffer passed to ->show() is acquired through seq_get_buf(); unfortunately, this introduces a subtle behavior change. Before the commit, the buffer passed to ->show() was always zero as it was allocated using get_zeroed_page(). Because seq_file doesn't clear buffers on allocation and neither does seq_get_buf(), after the commit, depending on the behavior of ->show(), we may end up exposing uninitialized data to userland thus possibly altering userland visible behavior and leaking information. Fix it by explicitly clearing the buffer. Signed-off-by: Tejun Heo Reported-by: Ron Fixes: 13c589d5b0ac ("sysfs: use seq_file when reading regular files") Signed-off-by: Greg Kroah-Hartman commit bae3622bb8afd02343c79949635b8d84c2cf3485 Author: Arnd Bergmann Date: Wed Apr 23 14:49:17 2014 +0200 genirq: Provide irq_force_affinity fallback for non-SMP commit 4c88d7f9b0d5fb0588c3386be62115cc2eaa8f9f upstream. Patch 01f8fa4f01d "genirq: Allow forcing cpu affinity of interrupts" added an irq_force_affinity() function, and 30ccf03b4a6 "clocksource: Exynos_mct: Use irq_force_affinity() in cpu bringup" subsequently uses it. However, the driver can be used with CONFIG_SMP disabled, but the function declaration is only available for CONFIG_SMP, leading to this build error: drivers/clocksource/exynos_mct.c:431:3: error: implicit declaration of function 'irq_force_affinity' [-Werror=implicit-function-declaration] irq_force_affinity(mct_irqs[MCT_L0_IRQ + cpu], cpumask_of(cpu)); This patch introduces a dummy helper function for the non-SMP case that always returns success, to get rid of the build error. Since the patches causing the problem are marked for stable backports, this one should be as well. Signed-off-by: Arnd Bergmann Cc: Krzysztof Kozlowski Acked-by: Kukjin Kim Link: http://lkml.kernel.org/r/5619084.0zmrrIUZLV@wuerfel Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 461a8fe47232a42c5ba9e2ac57eed37df331a2e3 Author: Linus Torvalds Date: Wed May 14 16:33:54 2014 -0700 x86-64, modify_ldt: Make support for 16-bit segments a runtime option commit fa81511bb0bbb2b1aace3695ce869da9762624ff upstream. Checkin: b3b42ac2cbae x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels disabled 16-bit segments on 64-bit kernels due to an information leak. However, it does seem that people are genuinely using Wine to run old 16-bit Windows programs on Linux. A proper fix for this ("espfix64") is coming in the upcoming merge window, but as a temporary fix, create a sysctl to allow the administrator to re-enable support for 16-bit segments. It adds a "/proc/sys/abi/ldt16" sysctl that defaults to zero (off). If you hit this issue and care about your old Windows program more than you care about a kernel stack address information leak, you can do echo 1 > /proc/sys/abi/ldt16 as root (add it to your startup scripts), and you should be ok. The sysctl table is only added if you have COMPAT support enabled on x86-64, but I assume anybody who runs old windows binaries very much does that ;) Signed-off-by: H. Peter Anvin Link: http://lkml.kernel.org/r/CA%2B55aFw9BPoD10U1LfHbOMpHWZkvJTkMcfCs9s3urPr1YyWBxw@mail.gmail.com Signed-off-by: Greg Kroah-Hartman commit db5f7d04fd718b94f428220b2ba4d4c87f55a3a5 Author: James Hogan Date: Tue May 13 23:58:24 2014 +0100 metag: Reduce maximum stack size to 256MB commit d71f290b4e98a39f49f2595a13be3b4d5ce8e1f1 upstream. Specify the maximum stack size for arches where the stack grows upward (parisc and metag) in asm/processor.h rather than hard coding in fs/exec.c so that metag can specify a smaller value of 256MB rather than 1GB. This fixes a BUG on metag if the RLIMIT_STACK hard limit is increased beyond a safe value by root. E.g. when starting a process after running "ulimit -H -s unlimited" it will then attempt to use a stack size of the maximum 1GB which is far too big for metag's limited user virtual address space (stack_top is usually 0x3ffff000): BUG: failure at fs/exec.c:589/shift_arg_pages()! Signed-off-by: James Hogan Cc: Helge Deller Cc: "James E.J. Bottomley" Cc: linux-parisc@vger.kernel.org Cc: linux-metag@vger.kernel.org Cc: John David Anglin Signed-off-by: Greg Kroah-Hartman commit 43f0630e513566750fb51df14b54f5b4b4f3f65f Author: Mikulas Patocka Date: Thu May 8 15:51:37 2014 -0400 metag: fix memory barriers commit 2425ce84026c385b73ae72039f90d042d49e0394 upstream. Volatile access doesn't really imply the compiler barrier. Volatile access is only ordered with respect to other volatile accesses, it isn't ordered with respect to general memory accesses. Gcc may reorder memory accesses around volatile access, as we can see in this simple example (if we compile it with optimization, both increments of *b will be collapsed to just one): void fn(volatile int *a, long *b) { (*b)++; *a = 10; (*b)++; } Consequently, we need the compiler barrier after a write to the volatile variable, to make sure that the compiler doesn't reorder the volatile write with something else. Signed-off-by: Mikulas Patocka Acked-by: Peter Zijlstra Signed-off-by: James Hogan Signed-off-by: Greg Kroah-Hartman commit 1ed85d074da980973dfd184ffe22bd83aef98901 Author: John David Anglin Date: Sun May 11 18:40:50 2014 -0400 parisc: Improve LWS-CAS performance commit c776cd89fc705fc8b5c2e5ad906bf5d791620fed upstream. The attached change significantly improves the performance of the LWS-CAS code in syscall.S. This allows a number of packages to build (e.g., zeromq3, gtest and libxs) that previously failed because slow LWS-CAS performance under contention. In particular, interrupts taken while the lock was taken degraded performance significantly. The change does the following: 1) Disables interrupts around the CAS operation, and 2) Changes the loads and stores to use the ordered completer, "o", on PA 2.0. "o" and "ma" with a zero offset are equivalent. The latter is accepted on both PA 1.X and 2.0. The use of ordered loads and stores probably makes no difference on all existing hardware, but it seemed pedantically correct. In particular, the CAS operation must complete before LDCW lock is released. As written before, a processor could reorder the operations. I don't believe the period interrupts are disabled is long enough to significantly increase interrupt latency. For example, the TLB insert code is longer. Worst case is a memory fault in the CAS operation. Signed-off-by: John David Anglin Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 7278cee18cdcaca8cad7e453382f3ffd2a1949ab Author: Helge Deller Date: Mon May 5 18:07:12 2014 +0200 parisc: ratelimit userspace segfault printing commit fef47e2a2e1e75fe50a10f634a80f16808348cc6 upstream. Ratelimit printing of userspace segfaults and make it runtime configurable via the /proc/sys/debug/exception-trace variable. This should resolve syslog from growing way too fast and thus prevents possible system service attacks. Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 5e1367f31dab0cc508e795f66d34267eab1cff09 Author: Charles Keepax Date: Tue May 13 13:45:15 2014 +0100 ASoC: wm8962: Update register CLASS_D_CONTROL_1 to be non-volatile commit 44330ab516c15dda8a1e660eeaf0003f84e43e3f upstream. The register CLASS_D_CONTROL_1 is marked as volatile because it contains a bit, DAC_MUTE, which is also mirrored in the ADC_DAC_CONTROL_1 register. This causes problems for the "Speaker Switch" control, which will report an error if the CODEC is suspended because it relies on a volatile register. To resolve this issue mark CLASS_D_CONTROL_1 as non-volatile and manually keep the register cache in sync by updating both bits when changing the mute status. Reported-by: Shawn Guo Signed-off-by: Charles Keepax Tested-by: Shawn Guo Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit c33bed1fff471f165bd53943ba43ee0c506cac2b Author: Lars-Peter Clausen Date: Wed May 7 16:20:24 2014 +0200 ASoC: dapm: Skip CODEC<->CODEC links in connect_dai_link_widgets() commit ca5106ae3da0179dcee3ae21f3ea94f62e9fdb0c upstream. For CODEC to CODEC DAI links the paths are created in snd_soc_dapm_new_pcm(). Also for CODEC to CODEC links the widgets are connected cross-over via a DAI link widget, meaning that the capture widget of one CODEC will be connected to the playback widget of the other and vice versa. Whereas snd_soc_dapm_connect_dai_link_widgets() directly connects the playback widget of the CPU DAI to the playback widget of the CODEC DAI and the capture widget of the CPU DAI to the capture widget of the CODEC DAI. So not skipping CODEC<->CODEC links in snd_soc_dapm_connect_dai_link_widgets() will create incorrect connections between the two CODECs which will cause DAPM to detect active paths where there are none and unnecessarily power up widgets. Fixes: b893ea5 ("ASoC: sapm: Automatically connect DAI link widgets in DAPM graph.") Signed-off-by: Lars-Peter Clausen Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b0e75f5df3df6a79218711775505ae4625255044 Author: Emmanuel Grumbach Date: Thu May 8 09:48:10 2014 +0300 iwlwifi: mvm: fix setting channel in monitor mode commit 1c4abec0baf25ffb92a28cc99d4231feeaa4d3f3 upstream. There was a deadlock in monitor mode when we were setting the channel if the channel was not 1. ====================================================== [ INFO: possible circular locking dependency detected ] 3.14.3 #4 Not tainted ------------------------------------------------------- iw/3323 is trying to acquire lock: (&local->chanctx_mtx){+.+.+.}, at: [] ieee80211_vif_release_channel+0x42/0xb0 [mac80211] but task is already holding lock: (&local->iflist_mtx){+.+...}, at: [] ieee80211_set_monitor_channel+0x5a/0x1b0 [mac80211] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&local->iflist_mtx){+.+...}: [] __lock_acquire+0xb3b/0x13b0 [] lock_acquire+0xb0/0x1f0 [] mutex_lock_nested+0x78/0x4f0 [] ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211] [] iwl_mvm_recalc_multicast+0x49/0xa0 [iwlmvm] [] iwl_mvm_configure_filter+0x4e/0x70 [iwlmvm] [] ieee80211_configure_filter+0x153/0x5f0 [mac80211] [] ieee80211_reconfig_filter+0x15/0x20 [mac80211] [snip] -> #1 (&mvm->mutex){+.+.+.}: [] __lock_acquire+0xb3b/0x13b0 [] lock_acquire+0xb0/0x1f0 [] mutex_lock_nested+0x78/0x4f0 [] iwl_mvm_add_chanctx+0x56/0xe0 [iwlmvm] [] ieee80211_new_chanctx+0x13e/0x410 [mac80211] [] ieee80211_vif_use_channel+0x1c3/0x5a0 [mac80211] [] ieee80211_add_virtual_monitor+0x1ab/0x6b0 [mac80211] [] ieee80211_do_open+0xe6a/0x15a0 [mac80211] [] ieee80211_open+0x59/0x60 [mac80211] [snip] -> #0 (&local->chanctx_mtx){+.+.+.}: [] check_prevs_add+0x977/0x980 [] __lock_acquire+0xb3b/0x13b0 [] lock_acquire+0xb0/0x1f0 [] mutex_lock_nested+0x78/0x4f0 [] ieee80211_vif_release_channel+0x42/0xb0 [mac80211] [] ieee80211_set_monitor_channel+0x113/0x1b0 [mac80211] [] cfg80211_set_monitor_channel+0x77/0x2b0 [cfg80211] [] __nl80211_set_channel+0x122/0x140 [cfg80211] [] nl80211_set_wiphy+0x284/0xaf0 [cfg80211] [snip] other info that might help us debug this: Chain exists of: &local->chanctx_mtx --> &mvm->mutex --> &local->iflist_mtx Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&local->iflist_mtx); lock(&mvm->mutex); lock(&local->iflist_mtx); lock(&local->chanctx_mtx); *** DEADLOCK *** This deadlock actually occurs: INFO: task iw:3323 blocked for more than 120 seconds. Not tainted 3.14.3 #4 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. iw D ffff8800c8afcd80 4192 3323 3322 0x00000000 ffff880078fdb7e0 0000000000000046 ffff8800c8afcd80 ffff880078fdbfd8 00000000001d5540 00000000001d5540 ffff8801141b0000 ffff8800c8afcd80 ffff880078ff9e38 ffff880078ff9e38 ffff880078ff9e40 0000000000000246 Call Trace: [] schedule_preempt_disabled+0x31/0x80 [] mutex_lock_nested+0x19d/0x4f0 [] ? ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211] [] ? ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211] [] ? iwl_mvm_power_mac_update_mode+0xc0/0xc0 [iwlmvm] [] ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211] [] _iwl_mvm_power_update_binding+0x27/0x80 [iwlmvm] [] iwl_mvm_unassign_vif_chanctx+0x81/0xc0 [iwlmvm] [] __ieee80211_vif_release_channel+0xdf/0x470 [mac80211] [] ieee80211_vif_release_channel+0x4a/0xb0 [mac80211] [] ieee80211_set_monitor_channel+0x113/0x1b0 [mac80211] [] cfg80211_set_monitor_channel+0x77/0x2b0 [cfg80211] [] __nl80211_set_channel+0x122/0x140 [cfg80211] [] nl80211_set_wiphy+0x284/0xaf0 [cfg80211] This fixes https://bugzilla.kernel.org/show_bug.cgi?id=75541 Reviewed-by: Johannes Berg Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit 83134b6448d894e1842bbd765a87a456b5c67a1e Author: Emmanuel Grumbach Date: Sun Apr 13 16:03:11 2014 +0300 iwlwifi: pcie: disable interrupts upon PCIe alloc commit 83f7a85f1134c6e914453f5747435415a23d516b upstream. In case RFKILL is in KILL position, the NIC will issue an interrupt straight away. This interrupt won't be sent because it is masked in the hardware. But if our interrupt service routine is called for another reason (SHARED_IRQ), then we'll look at the interrupt cause and service it. This can cause bad things if we are not ready yet. Explicitly clean the interrupt cause register to make sure we won't service anything before we are ready to. Reported-and-tested-by: Alexander Monakov Reviewed-by: Johannes Berg Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit 753f4d8c21fee8d6c10943fc509f5a293208b14e Author: Jianyu Zhan Date: Mon Apr 14 13:47:40 2014 +0800 percpu: make pcpu_alloc_chunk() use pcpu_mem_free() instead of kfree() commit 5a838c3b60e3a36ade764cf7751b8f17d7c9c2da upstream. pcpu_chunk_struct_size = sizeof(struct pcpu_chunk) + BITS_TO_LONGS(pcpu_unit_pages) * sizeof(unsigned long) It hardly could be ever bigger than PAGE_SIZE even for large-scale machine, but for consistency with its couterpart pcpu_mem_zalloc(), use pcpu_mem_free() instead. Commit b4916cb17c26 ("percpu: make pcpu_free_chunk() use pcpu_mem_free() instead of kfree()") addressed this problem, but missed this one. tj: commit message updated Signed-off-by: Jianyu Zhan Signed-off-by: Tejun Heo Fixes: 099a19d91ca4 ("percpu: allow limited allocation before slab is online) Signed-off-by: Greg Kroah-Hartman commit 53284d37ccc9d8fe19d14a2bf8766740ef060ca3 Author: Thomas Petazzoni Date: Mon May 12 16:11:40 2014 +0200 ARM: mvebu: mvebu-soc-id: keep clock enabled if PCIe unit is enabled commit b25bcf1bcaf6687991ae08dd76cd784bf9fe3d05 upstream. Since the mvebu-soc-id code in mach-mvebu/ was introduced, several users have noticed a regression: the PCIe card connected in the first PCIe interface is not detected properly. This is due to the fact that the mvebu-soc-id code enables the PCIe clock of the first PCIe interface, reads the SoC device ID and revision number (yes this information is made available as part of PCIe registers), and then disables the clock. However, by doing this, we gate the clock and therefore loose the complex PCIe configuration that was done by the bootloader. Unfortunately, as of today, the kernel is not capable of doing this complex configuration by itself, so we really need to keep the PCIe clock enabled. However, we don't want to keep it enabled unconditionally: if the PCIe interface is not enabled or PCI support is not compiled into the kernel, there is no reason to keep the PCIe clock running. This issue was discussed with Kevin Hilman, and the suggested solution was to make the mvebu-soc-id code keep the clock enabled in case it will be needed for PCIe. This is therefore the solution implemented in this patch. Long term, we hope to make the kernel more capable in terms of PCIe configuration for this platform, which will anyway be needed to support the compilation of the PCIe host controller driver as a module. In the mean time however, we don't have much other choice than to implement the currently proposed solution. Reported-by: Neil Greatorex Cc: Neil Greatorex Cc: Jason Gunthorpe Cc: Kevin Hilman Signed-off-by: Thomas Petazzoni Link: https://lkml.kernel.org/r/1399903900-29977-3-git-send-email-thomas.petazzoni@free-electrons.com Fixes: af8d1c63afcb ("ARM: mvebu: Add support to get the ID and the revision of a SoC") Acked-by: Gregory CLEMENT Tested-by: Gregory CLEMENT Tested-by: Andrew Lunn Tested-by: Willy Tarreau Signed-off-by: Jason Cooper Signed-off-by: Greg Kroah-Hartman commit 34ab79184f4c1cc86b469dadf5b0a449d27822de Author: Thomas Petazzoni Date: Mon May 12 16:11:39 2014 +0200 ARM: mvebu: mvebu-soc-id: add missing clk_put() call commit 42a18d1cf484d02e23afadfa5dc09356e6bef9fa upstream. The mvebu-soc-id code in mach-mvebu/ needs to enable a clock to read the SoC device ID and revision number. To do so, it does a clk_get(), then a clk_prepare_enable(), reads the value, and disables the clock with clk_disable_unprepare(). However, it forgets to clk_put() the clock. This commit fixes this issue. Signed-off-by: Thomas Petazzoni Link: https://lkml.kernel.org/r/1399903900-29977-2-git-send-email-thomas.petazzoni@free-electrons.com Fixes: af8d1c63afcb ("ARM: mvebu: Add support to get the ID and the revision of a SoC") Acked-by: Gregory CLEMENT Tested-by: Gregory CLEMENT Tested-by: Andrew Lunn Tested-by: Willy Tarreau Signed-off-by: Jason Cooper Signed-off-by: Greg Kroah-Hartman commit e1373f319a61c13a1a8f89ff0e3d8966ca4c47fc Author: Thomas Petazzoni Date: Fri Apr 18 14:19:53 2014 +0200 PCI: mvebu: split PCIe BARs into multiple MBus windows when needed commit 398f5d5e10b6b917cd9d35ef21d545b0afbada22 upstream. MBus windows are used on Marvell platforms to map certain peripherals in the physical address space. In the PCIe context, MBus windows are needed to map PCIe I/O and memory regions in the physical address. However, those MBus windows can only have power of two sizes, while PCIe BAR do not necessarily guarantee this. For this reason, the current pci-mvebu breaks on platforms where PCIe devices have BARs that don't sum up to a power of two size at the emulated bridge level. This commit fixes this by allowing the pci-mvebu driver to create multiple contiguous MBus windows (each having a power of two size) to cover a given PCIe BAR. To achieve this, two functions are added: mvebu_pcie_add_windows() and mvebu_pcie_del_windows() to respectively add and remove all the MBus windows that are needed to map the provided PCIe region base and size. The emulated PCI bridge code now calls those functions, instead of directly calling the mvebu-mbus driver functions. Fixes: 45361a4fe446 ('pci: PCIe driver for Marvell Armada 370/XP systems') Signed-off-by: Thomas Petazzoni Link: https://lkml.kernel.org/r/1397823593-1932-8-git-send-email-thomas.petazzoni@free-electrons.com Tested-by: Neil Greatorex Acked-by: Bjorn Helgaas Signed-off-by: Jason Cooper Signed-off-by: Greg Kroah-Hartman commit 4db1788ac444bb3e1b0162c0495dc2e9e8056700 Author: Thomas Petazzoni Date: Fri Apr 18 14:19:52 2014 +0200 bus: mvebu-mbus: allow several windows with the same target/attribute commit b566e782be32145664d96ada3e389f17d32742e5 upstream. Having multiple windows with the same target and attribute is actually legal, and can be useful for PCIe windows, when PCIe BARs have a size that isn't a power of two, and we therefore need to create several MBus windows to cover the PCIe BAR for a given PCIe interface. Fixes: fddddb52a6c4 ('bus: introduce an Marvell EBU MBus driver') Signed-off-by: Thomas Petazzoni Link: https://lkml.kernel.org/r/1397823593-1932-7-git-send-email-thomas.petazzoni@free-electrons.com Tested-by: Neil Greatorex Signed-off-by: Jason Cooper Signed-off-by: Greg Kroah-Hartman commit ebb332ca3d9b355cabc2c220c9b74114a26ece03 Author: Willy Tarreau Date: Fri Apr 18 14:19:50 2014 +0200 PCI: mvebu: fix off-by-one in the computed size of the mbus windows commit b6d07e0273d3296cfbdc88145b8a00ddbefb310a upstream. mvebu_pcie_handle_membase_change() and mvebu_pcie_handle_iobase_change() do not correctly compute the window size. PCI uses an inclusive start/end address pair, which requires a +1 when converting to size. This only worked because a bug in the mbus driver allowed it to silently accept and round up bogus sizes. Fix this by adding one to the computed size. Fixes: 45361a4fe446 ('PCIe driver for Marvell Armada 370/XP systems') Signed-off-by: Willy Tarreau Reviewed-By: Jason Gunthorpe Signed-off-by: Thomas Petazzoni Link: https://lkml.kernel.org/r/1397823593-1932-5-git-send-email-thomas.petazzoni@free-electrons.com Tested-by: Neil Greatorex Acked-by: Bjorn Helgaas Signed-off-by: Jason Cooper Signed-off-by: Greg Kroah-Hartman commit fc94eff9a98437a6ca42b2cb27aa13bf4389c295 Author: Thomas Petazzoni Date: Mon Apr 14 17:29:18 2014 +0200 memory: mvebu-devbus: fix the conversion of the bus width commit ce965c3d2e68c5325dd5624eb101d70423022fef upstream. According to the Armada 370 and Armada XP datasheets, the part of the Device Bus register that configure the bus width should contain 0 for a 8 bits bus width, and 1 for a 16 bits bus width (other values are unsupported/reserved). However, the current conversion done in the driver to convert from a bus width in bits to the value expected by the register leads to setting the register to 1 for a 8 bits bus, and 2 for a 16 bits bus. This mistake was compensated by a mistake in the existing Device Tree files for Armada 370/XP platforms: they were declaring a 8 bits bus width, while the hardware in fact uses a 16 bits bus width. This commit fixes that by adjusting the conversion logic. This patch fixes a bug that was introduced in 3edad321b1bd2e6c8b5f38146c115c8982438f06 ('drivers: memory: Introduce Marvell EBU Device Bus driver'), which was merged in v3.11. Signed-off-by: Thomas Petazzoni Link: https://lkml.kernel.org/r/1397489361-5833-2-git-send-email-thomas.petazzoni@free-electrons.com Fixes: 3edad321b1bd ('drivers: memory: Introduce Marvell EBU Device Bus driver') Acked-by: Ezequiel Garcia Acked-by: Gregory CLEMENT Signed-off-by: Jason Cooper Signed-off-by: Greg Kroah-Hartman commit efa2a039afc3eac43e529e02bb47df62042a504c Author: Lai Jiangshan Date: Fri Apr 18 11:04:16 2014 -0400 workqueue: make rescuer_thread() empty wq->maydays list before exiting commit 4d595b866d2c653dc90a492b9973a834eabfa354 upstream. After a @pwq is scheduled for emergency execution, other workers may consume the affectd work items before the rescuer gets to them. This means that a workqueue many have pwqs queued on @wq->maydays list while not having any work item pending or in-flight. If destroy_workqueue() executes in such condition, the rescuer may exit without emptying @wq->maydays. This currently doesn't cause any actual harm. destroy_workqueue() can safely destroy all the involved data structures whether @wq->maydays is populated or not as nobody access the list once the rescuer exits. However, this is nasty and makes future development difficult. Let's update rescuer_thread() so that it empties @wq->maydays after seeing should_stop to guarantee that the list is empty on rescuer exit. tj: Updated comment and patch description. Signed-off-by: Lai Jiangshan Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 7b21cacc8bf8fda9822d63496fb38bc6def34046 Author: Lai Jiangshan Date: Fri Apr 18 11:04:16 2014 -0400 workqueue: fix a possible race condition between rescuer and pwq-release commit 77668c8b559e4fe2acf2a0749c7c83cde49a5025 upstream. There is a race condition between rescuer_thread() and pwq_unbound_release_workfn(). Even after a pwq is scheduled for rescue, the associated work items may be consumed by any worker. If all of them are consumed before the rescuer gets to them and the pwq's base ref was put due to attribute change, the pwq may be released while still being linked on @wq->maydays list making the rescuer dereference already freed pwq later. Make send_mayday() pin the target pwq until the rescuer is done with it. tj: Updated comment and patch description. Signed-off-by: Lai Jiangshan Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 65eefbee64455cb2f18a77be616ca1df10c95d6d Author: Daeseok Youn Date: Wed Apr 16 14:32:29 2014 +0900 workqueue: fix bugs in wq_update_unbound_numa() failure path commit 77f300b198f93328c26191b52655ce1b62e202cf upstream. wq_update_unbound_numa() failure path has the following two bugs. - alloc_unbound_pwq() is called without holding wq->mutex; however, if the allocation fails, it jumps to out_unlock which tries to unlock wq->mutex. - The function should switch to dfl_pwq on failure but didn't do so after alloc_unbound_pwq() failure. Fix it by regrabbing wq->mutex and jumping to use_dfl_pwq on alloc_unbound_pwq() failure. Signed-off-by: Daeseok Youn Acked-by: Lai Jiangshan Signed-off-by: Tejun Heo Fixes: 4c16bd327c74 ("workqueue: implement NUMA affinity for unbound workqueues") Signed-off-by: Greg Kroah-Hartman commit 91c372b12c4a6dca1663338aed088e4c19d14f17 Author: J. Bruce Fields Date: Tue May 20 15:55:21 2014 -0400 nfsd4: remove lockowner when removing lock stateid commit a1b8ff4c97b4375d21b6d6c45d75877303f61b3b upstream. The nfsv4 state code has always assumed a one-to-one correspondance between lock stateid's and lockowners even if it appears not to in some places. We may actually change that, but for now when FREE_STATEID releases a lock stateid it also needs to release the parent lockowner. Symptoms were a subsequent LOCK crashing in find_lockowner_str when it calls same_lockowner_ino on a lockowner that unexpectedly has an empty so_stateids list. Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit befdf0a5cec2ca490bca178b1baf2dba1e7ec261 Author: J. Bruce Fields Date: Thu May 8 11:19:41 2014 -0400 nfsd4: warn on finding lockowner without stateid's commit 27b11428b7de097c42f205beabb1764f4365443b upstream. The current code assumes a one-to-one lockowner<->lock stateid correspondance. Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 930cf0edb2938e26799ea000d96b77bbab9cb98e Author: Kinglong Mee Date: Fri Apr 18 20:49:04 2014 +0800 NFSD: Call ->set_acl with a NULL ACL structure if no entries commit aa07c713ecfc0522916f3cd57ac628ea6127c0ec upstream. After setting ACL for directory, I got two problems that caused by the cached zero-length default posix acl. This patch make sure nfsd4_set_nfs4_acl calls ->set_acl with a NULL ACL structure if there are no entries. Thanks for Christoph Hellwig's advice. First problem: ............ hang ........... Second problem: [ 1610.167668] ------------[ cut here ]------------ [ 1610.168320] kernel BUG at /root/nfs/linux/fs/nfsd/nfs4acl.c:239! [ 1610.168320] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC [ 1610.168320] Modules linked in: nfsv4(OE) nfs(OE) nfsd(OE) rpcsec_gss_krb5 fscache ip6t_rpfilter ip6t_REJECT cfg80211 xt_conntrack rfkill ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw auth_rpcgss nfs_acl snd_intel8x0 ppdev lockd snd_ac97_codec ac97_bus snd_pcm snd_timer e1000 pcspkr parport_pc snd parport serio_raw joydev i2c_piix4 sunrpc(OE) microcode soundcore i2c_core ata_generic pata_acpi [last unloaded: nfsd] [ 1610.168320] CPU: 0 PID: 27397 Comm: nfsd Tainted: G OE 3.15.0-rc1+ #15 [ 1610.168320] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 1610.168320] task: ffff88005ab653d0 ti: ffff88005a944000 task.ti: ffff88005a944000 [ 1610.168320] RIP: 0010:[] [] _posix_to_nfsv4_one+0x3cd/0x3d0 [nfsd] [ 1610.168320] RSP: 0018:ffff88005a945b00 EFLAGS: 00010293 [ 1610.168320] RAX: 0000000000000001 RBX: ffff88006700bac0 RCX: 0000000000000000 [ 1610.168320] RDX: 0000000000000000 RSI: ffff880067c83f00 RDI: ffff880068233300 [ 1610.168320] RBP: ffff88005a945b48 R08: ffffffff81c64830 R09: 0000000000000000 [ 1610.168320] R10: ffff88004ea85be0 R11: 000000000000f475 R12: ffff880068233300 [ 1610.168320] R13: 0000000000000003 R14: 0000000000000002 R15: ffff880068233300 [ 1610.168320] FS: 0000000000000000(0000) GS:ffff880077800000(0000) knlGS:0000000000000000 [ 1610.168320] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 1610.168320] CR2: 00007f5bcbd3b0b9 CR3: 0000000001c0f000 CR4: 00000000000006f0 [ 1610.168320] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1610.168320] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 1610.168320] Stack: [ 1610.168320] ffffffff00000000 0000000b67c83500 000000076700bac0 0000000000000000 [ 1610.168320] ffff88006700bac0 ffff880068233300 ffff88005a945c08 0000000000000002 [ 1610.168320] 0000000000000000 ffff88005a945b88 ffffffffa034e2d5 000000065a945b68 [ 1610.168320] Call Trace: [ 1610.168320] [] nfsd4_get_nfs4_acl+0x95/0x150 [nfsd] [ 1610.168320] [] nfsd4_encode_fattr+0x646/0x1e70 [nfsd] [ 1610.168320] [] ? kmemleak_alloc+0x4e/0xb0 [ 1610.168320] [] ? nfsd_setuser_and_check_port+0x52/0x80 [nfsd] [ 1610.168320] [] ? selinux_cred_prepare+0x1b/0x30 [ 1610.168320] [] nfsd4_encode_getattr+0x5a/0x60 [nfsd] [ 1610.168320] [] nfsd4_encode_operation+0x67/0x110 [nfsd] [ 1610.168320] [] nfsd4_proc_compound+0x21d/0x810 [nfsd] [ 1610.168320] [] nfsd_dispatch+0xbb/0x200 [nfsd] [ 1610.168320] [] svc_process_common+0x46d/0x6d0 [sunrpc] [ 1610.168320] [] svc_process+0x103/0x170 [sunrpc] [ 1610.168320] [] nfsd+0xbf/0x130 [nfsd] [ 1610.168320] [] ? nfsd_destroy+0x80/0x80 [nfsd] [ 1610.168320] [] kthread+0xd2/0xf0 [ 1610.168320] [] ? insert_kthread_work+0x40/0x40 [ 1610.168320] [] ret_from_fork+0x7c/0xb0 [ 1610.168320] [] ? insert_kthread_work+0x40/0x40 [ 1610.168320] Code: 78 02 e9 e7 fc ff ff 31 c0 31 d2 31 c9 66 89 45 ce 41 8b 04 24 66 89 55 d0 66 89 4d d2 48 8d 04 80 49 8d 5c 84 04 e9 37 fd ff ff <0f> 0b 90 0f 1f 44 00 00 55 8b 56 08 c7 07 00 00 00 00 8b 46 0c [ 1610.168320] RIP [] _posix_to_nfsv4_one+0x3cd/0x3d0 [nfsd] [ 1610.168320] RSP [ 1610.257313] ---[ end trace 838254e3e352285b ]--- Signed-off-by: Kinglong Mee Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit eac32428fe7e6f4337d23682ee9c56530bbf3790 Author: Trond Myklebust Date: Fri Apr 18 14:43:57 2014 -0400 NFSd: call rpc_destroy_wait_queue() from free_client() commit 4cb57e3032d4e4bf5e97780e9907da7282b02b0c upstream. Mainly to ensure that we don't leave any hanging timers. Signed-off-by: Trond Myklebust Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 25bd4bc3d6f8825ce64646fa6751288ba59d597a Author: Trond Myklebust Date: Fri Apr 18 14:43:56 2014 -0400 NFSd: Move default initialisers from create_client() to alloc_client() commit 5694c93e6c4954fa9424c215f75eeb919bddad64 upstream. Aside from making it clearer what is non-trivial in create_client(), it also fixes a bug whereby we can call free_client() before idr_init() has been called. Signed-off-by: Trond Myklebust Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit d970de72f3c225e61487e67d0fa6e1842fcd0162 Author: Takashi Iwai Date: Fri May 23 09:02:44 2014 +0200 ALSA: hda - Fix onboard audio on Intel H97/Z97 chipsets commit 77f07800cb456bed6e5c345e6e4e83e8eda62437 upstream. The recent Intel H97/Z97 chipsets need the similar setups like other Intel chipsets for snooping, etc. Especially without snooping, the audio playback stutters or gets corrupted. This fix patch just adds the corresponding PCI ID entry with the proper flags. Reported-and-tested-by: Arthur Borsboom Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b2a89593b10d1f939253bdd952c782f01dbca7a0 Author: Anssi Hannula Date: Mon May 5 02:38:43 2014 +0300 ALSA: hda - hdmi: Set converter channel count even without sink commit f06ab794af7055d0949b09885f79f8b493deec64 upstream. Since commit 1df5a06a ("ALSA: hda - hdmi: Fix programmed active channel count") channel count is no longer being set if monitor_present is 0. This is because setting the count was moved after the CA value is determined, which is only after the monitor_present check in hdmi_setup_audio_infoframe(). Unfortunately, in some cases, such as with a non-spec-compliant codec or with a problematic video driver, monitor_present is always 0. As a specific example, this seems to happen with gen1 ATV (SiI1390 codec), causing left-channel-only stereo playback (multi-channel playback has apparently never worked with this codec despite it reporting 8 channels, reason unknown). Simply setting converter channel count without setting the pin infoframe and channel mapping as well does not theoretically make much sense as this will just mean they are out-of-sync and multichannel playback will have a wrong channel mapping. However, adding back just setting the converter channel count even in no-monitor case is the safest change which at least fixes the stereo playback regression on SiI1390 codec. Do that. Signed-off-by: Anssi Hannula Reported-by: Stephan Raue Tested-by: Stephan Raue Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d5aa7c8942d1bda9d77423b6bb00756b43eb1f88 Author: Hans de Goede Date: Mon May 19 22:54:09 2014 -0700 Input: synaptics - change min/max quirk table to pnp-id matching commit 0f68f39c393bc06ac5ccc8794f0e2ed841e41c3e upstream. Most of the affected models share pnp-ids for the touchpad. So switching to pnp-ids give us 2 advantages: 1) It shrinks the quirk list 2) It will lower the new quirk addition frequency, ie the recently added W540 quirk would not have been necessary since it uses the same LEN0034 pnp ids as other models already added before it As an added bonus it actually puts the quirk on the actual psmouse, rather then on the machine, which is technically more correct. Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 9cffb0d9a3781be5233f768eba98e24e842401da Author: Hans de Goede Date: Mon May 19 22:53:23 2014 -0700 Input: synaptics - add a matches_pnp_id helper function commit e2f611029b370bb7a04236215ad4b36aa8cb98cd upstream. This is a preparation patch for simplifying the min/max quirk table. Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 3f437926516b1689898011378c4aa88daee87d6b Author: Hans de Goede Date: Mon May 19 22:52:30 2014 -0700 Input: synaptics - T540p - unify with other LEN0034 models commit 6d396ede224dc596d92d7cab433713536e68916c upstream. The T540p has a touchpad with pnp-id LEN0034, all the models with this pnp-id have the same min/max values, except the T540p where the values are slightly off. Fix them to be identical. This is a preparation patch for simplifying the quirk table. Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 58cd56a83d858b33f4c8945216bad2223eb29a9a Author: Hans de Goede Date: Wed May 14 11:10:40 2014 -0700 Input: synaptics - add min/max quirk for the ThinkPad W540 commit 0b5fe736fe923f1f5e05413878d5990e92ffbdf5 upstream. https://bugzilla.redhat.com/show_bug.cgi?id=1096436 Tested-and-reported-by: ajayr@bigfoot.com Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 5a543920cdae8d847461d60d4817667c31db93d4 Author: Hans de Goede Date: Mon May 5 09:36:43 2014 -0700 Input: elantech - fix touchpad initialization on Gigabyte U2442 commit 36189cc3cd57ab0f1cd75241f93fe01de928ac06 upstream. The hw_version 3 Elantech touchpad on the Gigabyte U2442 does not accept 0x0b as initialization value for r10, this stand-alone version of the driver: http://planet76.com/drivers/elantech/psmouse-elantech-v6.tar.bz2 Uses 0x03 which does work, so this means not setting bit 3 of r10 which sets: "Enable Real H/W Resolution In Absolute mode" Which will result in half the x and y resolution we get with that bit set, so simply not setting it everywhere is not a solution. We've been unable to find a way to identify touchpads where setting the bit will fail, so this patch uses a dmi based blacklist for this. https://bugzilla.kernel.org/show_bug.cgi?id=61151 Reported-by: Philipp Wolfer Tested-by: Philipp Wolfer Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 512a588518fefae5dab75b89b734cfb64e53177b Author: Sheng-Liang Song Date: Thu Apr 24 16:28:29 2014 -0700 Input: atkbd - fix keyboard not working on some LG laptops commit 3d725caa9dcc78c3dc9e7ea0c04f626468edd9c9 upstream. After issuing ATKBD_CMD_RESET_DIS, keyboard on some LG laptops stops working. The workaround is to stop issuing ATKBD_CMD_RESET_DIS commands. In order to keep changes in atkbd driver to the minimum we check DMI signature and only skip ATKBD_CMD_RESET_DIS if we are running on LG LW25-B7HV or P1-J273B. Signed-off-by: Sheng-Liang Song Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit df02df0a9269f9d27c0d3738e330b2c166445f76 Author: Romain Izard Date: Tue Mar 4 10:09:39 2014 +0100 trace: module: Maintain a valid user count commit 098507ae3ec2331476fb52e85d4040c1cc6d0ef4 upstream. The replacement of the 'count' variable by two variables 'incs' and 'decs' to resolve some race conditions during module unloading was done in parallel with some cleanup in the trace subsystem, and was integrated as a merge. Unfortunately, the formula for this replacement was wrong in the tracing code, and the refcount in the traces was not usable as a result. Use 'count = incs - decs' to compute the user count. Link: http://lkml.kernel.org/p/1393924179-9147-1-git-send-email-romain.izard.pro@gmail.com Acked-by: Ingo Molnar Cc: Rusty Russell Cc: Frederic Weisbecker Fixes: c1ab9cab7509 "merge conflict resolution" Signed-off-by: Romain Izard Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit f0754e5903c14a1f36da90275b1c17becddc581c Author: Al Viro Date: Sat Apr 19 12:30:58 2014 -0400 fix races between __d_instantiate() and checks of dentry flags commit 22213318af7ae265bc6cd8aef2febbc2d69a2440 upstream. in non-lazy walk we need to be careful about dentry switching from negative to positive - both ->d_flags and ->d_inode are updated, and in some places we might see only one store. The cases where dentry has been obtained by dcache lookup with ->i_mutex held on parent are safe - ->d_lock and ->i_mutex provide all the barriers we need. However, there are several places where we run into trouble: * do_last() fetches ->d_inode, then checks ->d_flags and assumes that inode won't be NULL unless d_is_negative() is true. Race with e.g. creat() - we might have fetched the old value of ->d_inode (still NULL) and new value of ->d_flags (already not DCACHE_MISS_TYPE). Lin Ming has observed and reported the resulting oops. * a bunch of places checks ->d_inode for being non-NULL, then checks ->d_flags for "is it a symlink". Race with symlink(2) in case if our CPU sees ->d_inode update first - we see non-NULL there, but ->d_flags still contains DCACHE_MISS_TYPE instead of DCACHE_SYMLINK_TYPE. Result: false negative on "should we follow link here?", with subsequent unpleasantness. Reported-and-tested-by: Lin Ming Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 36eca0cf9c5f995fd0b7933a11d58fa5f640f3ae Author: Ian Kent Date: Tue May 6 12:50:06 2014 -0700 autofs: fix lockref lookup commit 6b6751f7feba68d8f5c72b72cc69a1c5a625529c upstream. autofs needs to be able to see private data dentry flags for its dentrys that are being created but not yet hashed and for its dentrys that have been rmdir()ed but not yet freed. It needs to do this so it can block processes in these states until a status has been returned to indicate the given operation is complete. It does this by keeping two lists, active and expring, of dentrys in this state and uses ->d_release() to keep them stable while it checks the reference count to determine if they should be used. But with the recent lockref changes dentrys being freed sometimes don't transition to a reference count of 0 before being freed so autofs can occassionally use a dentry that is invalid which can lead to a panic. Signed-off-by: Ian Kent Cc: Al Viro Cc: Linus Torvalds Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 600d8cbcd0f10b6535429a21bfb6cf2369155759 Author: Yan, Zheng Date: Mon Apr 14 13:13:02 2014 +0800 ceph: clear directory's completeness when creating file commit 0a8a70f96fe1bd3e07c15bb86fd247e76102398a upstream. When creating a file, ceph_set_dentry_offset() puts the new dentry at the end of directory's d_subdirs, then set the dentry's offset based on directory's max offset. The offset does not reflect the real postion of the dentry in directory. Later readdir reply from MDS may change the dentry's position/offset. This inconsistency can cause missing/duplicate entries in readdir result if readdir is partly satisfied by dcache_readdir(). The fix is clear directory's completeness after creating/renaming file. It prevents later readdir from using dcache_readdir(). Fixes: http://tracker.ceph.com/issues/8025 Signed-off-by: Yan, Zheng Reviewed-by: Sage Weil Signed-off-by: Greg Kroah-Hartman commit a23e2fa7ab52dfec62dc40de5cea10aec7cacdda Author: David Ertman Date: Tue Mar 25 04:27:55 2014 +0000 e1000e: Fix no connectivity when driver loaded with cable out commit b20a774495671f037e7160ea2ce8789af6b61533 upstream. In commit da1e2046e5, the flow for enabling/disabling an Si errata workaround (e1000_lv_jumbo_workaround_ich8lan) was changed to fix a problem with iAMT connections dropping on interface down with jumbo frames set. Part of this change was to move the function call disabling the workaround to e1000e_down() from the e1000_setup_rctl() function. The mechanic for disabling of this workaround involves writing several MAC and PHY registers back to hardware defaults. After this commit, when the driver is loaded with the cable out, the PHY registers are not programmed with the correct default values. This causes the device to be capable of transmitting packets, but is unable to recieve them until this workaround is called. The flow of e1000e's open code relies upon calling the above workaround to expicitly program these registers either with jumbo frame appropriate settings or h/w defaults on 82579 and newer hardware. Fix this issue by adding logic to e1000_setup_rctl() that not only calls e1000_lv_jumbo_workaround_ich8lan() when jumbo frames are set, to enable the workaround, but also calls this function to explicitly disable the workaround in the case that jumbo frames are not set. Signed-off-by: Dave Ertman Tested-by: Jeff Pieper Signed-off-by: Jeff Kirsher Cc: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 4305a2a568662fec9b05f4887cf1e0e37d02c127 Author: Hans de Goede Date: Sat Apr 19 22:26:41 2014 -0700 Input: synaptics - report INPUT_PROP_TOPBUTTONPAD property commit 43e19888b1fe2a3e8a5543030c5b286cde38b3f5 upstream. Check PNP ID of the PS/2 AUX port and report INPUT_PROP_TOPBUTTONPAD property for for touchpads with top button areas. Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 46ce727cb672b6dbf26aa8d79681ade18fcaa3e7 Author: Hans de Goede Date: Sat Apr 19 22:25:45 2014 -0700 Input: Add INPUT_PROP_TOPBUTTONPAD device property commit f37c013409bb78ebb958821aa10d069e707cabac upstream. On some newer laptops with a trackpoint the physical buttons for the trackpoint have been removed to allow for a larger touchpad. On these laptops the buttonpad has clearly marked areas on the top which are to be used as trackpad buttons. Users of the event device-node need to know about this, so that they can properly interpret BTN_LEFT events as being a left / right / middle click depending on where on the button pad the clicking finger is. This commits adds a INPUT_PROP_TOPBUTTONPAD device property which drivers for such buttonpads will use to signal to the user that this buttonpad not only has the normal bottom button area, but also a top button area. Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit d1d5f913ffad1020726988f8570d8befc3228615 Author: Hans de Goede Date: Sat Apr 19 20:47:35 2014 -0700 Input: i8042 - add firmware_id support commit a7c5868c3482127cb308c779b8a6460a3353c17f upstream. Fill in the new serio firmware_id sysfs attribute for pnp instantiated 8042 serio ports. Signed-off-by: Hans de Goede Acked-by: Peter Hutterer Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit bca4529f141352f6de2f66a2772c86b30b6cfaea Author: Hans de Goede Date: Sat Apr 19 20:39:35 2014 -0700 Input: serio - add firmware_id sysfs attribute commit 0456c66f4e905e1ca839318219c770988b47975c upstream. serio devices exposed via platform firmware interfaces such as ACPI may provide additional identifying information of use to userspace. We don't associate the serio devices with the firmware device (we don't set it as parent), so there's no way for userspace to make use of this information. We cannot change the parent for serio devices instantiated though a firmware interface as that would break suspend / resume ordering. Therefore this patch adds a new firmware_id sysfs attribute so that userspace can get a string from there with any additional identifying information the firmware interface may provide. Signed-off-by: Hans de Goede Acked-by: Peter Hutterer Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 3b13d52c662b61444fe5c5b6f5bb9e549017054e Author: Chew, Kean ho Date: Sat Mar 1 00:03:56 2014 +0800 i2c: i801: enable Intel BayTrail SMBUS commit 1b31e9b76ef8c62291e698dfdb973499986a7f68 upstream. Add Device ID of Intel BayTrail SMBus Controller. Signed-off-by: Chew, Kean ho Signed-off-by: Chew, Chiau Ee Reviewed-by: Jean Delvare Signed-off-by: Wolfram Sang Cc: "Chang, Rebecca Swee Fun" Signed-off-by: Greg Kroah-Hartman commit 429f444ee6aea8146c115dded7b8b0214cea5e2d Author: Salva Peiró Date: Wed Apr 30 19:48:02 2014 +0200 media: media-device: fix infoleak in ioctl media_enum_entities() commit e6a623460e5fc960ac3ee9f946d3106233fd28d8 upstream. This fixes CVE-2014-1739. Signed-off-by: Salva Peiró Acked-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 479ffa4481d1a6ab94acfdef021687c8129b4205 Author: Dan Carpenter Date: Thu Nov 7 08:08:44 2013 +0000 clk: vexpress: NULL dereference on error path commit 6b4ed8b00e93bd31f24a25f59ed8d1b808d0cc00 upstream. If the allocation fails then we dereference the NULL in the error path. Just return directly. Fixes: ed27ff1db869 ('clk: Versatile Express clock generators ("osc") driver') Signed-off-by: Dan Carpenter Signed-off-by: Pawel Moll Signed-off-by: Greg Kroah-Hartman commit 0253b3bff10fb9e5464efdc47e27272b47ad40b7 Author: Tim Chen Date: Mon Mar 17 16:52:26 2014 -0700 crypto: crypto_wq - Fix late crypto work queue initialization commit 130fa5bc81b44b6cc1fbdea3abf6db0da22964e0 upstream. The crypto algorithm modules utilizing the crypto daemon could be used early when the system start up. Using module_init does not guarantee that the daemon's work queue is initialized when the cypto alorithm depending on crypto_wq starts. It is necessary to initialize the crypto work queue earlier at the subsystem init time to make sure that it is initialized when used. Signed-off-by: Tim Chen Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 7ce60f41fa20ab7b08eef3d972804f7efe7938c3 Author: Aristeu Rozanski Date: Mon May 5 11:18:59 2014 -0400 device_cgroup: check if exception removal is allowed commit d2c2b11cfa134f4fbdcc34088824da26a084d8de upstream. [PATCH v3 1/2] device_cgroup: check if exception removal is allowed When the device cgroup hierarchy was introduced in bd2953ebbb53 - devcg: propagate local changes down the hierarchy a specific case was overlooked. Consider the hierarchy bellow: A default policy: ALLOW, exceptions will deny access \ B default policy: ALLOW, exceptions will deny access There's no need to verify when an new exception is added to B because in this case exceptions will deny access to further devices, which is always fine. Hierarchy in device cgroup only makes sure B won't have more access than A. But when an exception is removed (by writing devices.allow), it isn't checked if the user is in fact removing an inherited exception from A, thus giving more access to B. Example: # echo 'a' >A/devices.allow # echo 'c 1:3 rw' >A/devices.deny # echo $$ >A/B/tasks # echo >/dev/null -bash: /dev/null: Operation not permitted # echo 'c 1:3 w' >A/B/devices.allow # echo >/dev/null # This shouldn't be allowed and this patch fixes it by making sure to never allow exceptions in this case to be removed if the exception is partially or fully present on the parent. v3: missing '*' in function description v2: improved log message and formatting fixes Cc: cgroups@vger.kernel.org Cc: Li Zefan Signed-off-by: Aristeu Rozanski Acked-by: Serge Hallyn Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 6d838324fa8a4a328fa760066beba3a7dcb24832 Author: Aristeu Rozanski Date: Mon Apr 21 12:13:03 2014 -0400 device_cgroup: rework device access check and exception checking commit 79d719749d23234e9b725098aa49133f3ef7299d upstream. Whenever a device file is opened and checked against current device cgroup rules, it uses the same function (may_access()) as when a new exception rule is added by writing devices.{allow,deny}. And in both cases, the algorithm is the same, doesn't matter the behavior. First problem is having device access to be considered the same as rule checking. Consider the following structure: A (default behavior: allow, exceptions disallow access) \ B (default behavior: allow, exceptions disallow access) A new exception is added to B by writing devices.deny: c 12:34 rw When checking if that exception is allowed in may_access(): if (dev_cgroup->behavior == DEVCG_DEFAULT_ALLOW) { if (behavior == DEVCG_DEFAULT_ALLOW) { /* the exception will deny access to certain devices */ return true; Which is ok, since B is not getting more privileges than A, it doesn't matter and the rule is accepted Now, consider it's a device file open check and the process belongs to cgroup B. The access will be generated as: behavior: allow exception: c 12:34 rw The very same chunk of code will allow it, even if there's an explicit exception telling to do otherwise. A simple test case: # mkdir new_group # cd new_group # echo $$ >tasks # echo "c 1:3 w" >devices.deny # echo >/dev/null # echo $? 0 This is a serious bug and was introduced on c39a2a3018f8 devcg: prepare may_access() for hierarchy support To solve this problem, the device file open function was split from the new exception check. Second problem is how exceptions are processed by may_access(). The first part of the said function tries to match fully with an existing exception: list_for_each_entry_rcu(ex, &dev_cgroup->exceptions, list) { if ((refex->type & DEV_BLOCK) && !(ex->type & DEV_BLOCK)) continue; if ((refex->type & DEV_CHAR) && !(ex->type & DEV_CHAR)) continue; if (ex->major != ~0 && ex->major != refex->major) continue; if (ex->minor != ~0 && ex->minor != refex->minor) continue; if (refex->access & (~ex->access)) continue; match = true; break; } That means the new exception should be contained into an existing one to be considered a match: New exception Existing match? notes b 12:34 rwm b 12:34 rwm yes b 12:34 r b *:34 rw yes b 12:34 rw b 12:34 w no extra "r" b *:34 rw b 12:34 rw no too broad "*" b *:34 rw b *:34 rwm yes Which is fine in some cases. Consider: A (default behavior: deny, exceptions allow access) \ B (default behavior: deny, exceptions allow access) In this case the full match makes sense, the new exception cannot add more access than the parent allows But this doesn't always work, consider: A (default behavior: allow, exceptions disallow access) \ B (default behavior: deny, exceptions allow access) In this case, a new exception in B shouldn't match any of the exceptions in A, after all you can't allow something that was forbidden by A. But consider this scenario: New exception Existing in A match? outcome b 12:34 rw b 12:34 r no exception is accepted Because the new exception has "w" as extra, it doesn't match, so it'll be added to B's exception list. The same problem can happen during a file access check. Consider a cgroup with allow as default behavior: Access Exception match? b 12:34 rw b 12:34 r no In this case, the access didn't match any of the exceptions in the cgroup, which is required since exceptions will disallow access. To solve this problem, two new functions were created to match an exception either fully or partially. In the example above, a partial check will be performed and it'll produce a match since at least "b 12:34 r" from "b 12:34 rw" access matches. Cc: cgroups@vger.kernel.org Cc: Tejun Heo Cc: Serge Hallyn Cc: Li Zefan Signed-off-by: Aristeu Rozanski Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit c0a6fd1b45d9fd5ee34bb7884e4af79002893d28 Author: Geert Uytterhoeven Date: Mon Apr 14 18:52:14 2014 +0200 Documentation: Update stable address in Chinese and Japanese translations commit 98b0f811aade1b7c6e7806c86aa0befd5919d65f upstream. The English and Korean translations were updated, the Chinese and Japanese weren't. Signed-off-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 9f531ef39d2a3dcfb50e66faabf66a6376f324e5 Author: Emil Goode Date: Sun Mar 9 21:06:51 2014 +0100 brcmsmac: fix deadlock on missing firmware commit 8fc1e8c240aab968db658b2d8d079b4391207a36 upstream. When brcm80211 firmware is not installed networking hangs. A deadlock happens because we call ieee80211_unregister_hw() from the .start callback of struct ieee80211_ops. When .start is called we are under rtnl lock and ieee80211_unregister_hw() tries to take it again. Function call stack: dev_change_flags() __dev_change_flags() __dev_open() ASSERT_RTNL() <-- Assert rtnl lock ops->ndo_open() .ndo_open = ieee80211_open, ieee80211_open() ieee80211_do_open() drv_start() local->ops->start() .start = brcms_ops_start, brcms_ops_start() brcms_remove() ieee80211_unregister_hw() rtnl_lock() <-- Here we deadlock Introduced by: commit 25b5632fb35ca61b8ae3eee235edcdc2883f7a5e ("brcmsmac: request firmware in .start() callback") This patch fixes the bug by removing the call to brcms_remove() and moves the brcms_request_fw() call to the top of the .start callback to not initiate anything unless firmware is installed. Signed-off-by: Emil Goode Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 7a5db34ad2ea9a97448904a8a9e6e49d82e9d133 Author: Russell King Date: Sun Apr 6 15:20:03 2014 -0700 leds: leds-pwm: properly clean up after probe failure commit 392369019eb96e914234ea21eda806cb51a1073e upstream. When probing with DT, we add each LED one at a time. If we find a LED without a PWM device (because it is not available yet) we fail the initialisation, unregister previous LEDs, and then by way of managed resources, we free the structure. The problem with this is we may have a scheduled and active work_struct in this structure, and this results in a nasty kernel oops. We need to cancel this work_struct properly upon cleanup - and the cleanup we require is the same cleanup as we do when the LED platform device is removed. Rather than writing this same code three times, move it into a separate function and use it in all three places. Fixes: c971ff185f64 ("leds: leds-pwm: Defer led_pwm_set() if PWM can sleep") Signed-off-by: Russell King Signed-off-by: Bryan Wu Signed-off-by: Greg Kroah-Hartman commit 92840945e295889bde76fb38531f11dafb34b506 Author: Martin Peres Date: Fri Mar 14 00:26:52 2014 +0100 drm/nouveau/pm/fan: drop the fan lock in fan_update() before rescheduling commit 61679fe153b2b9ea5b5e2ab93305419e85e99a9d upstream. This should fix a deadlock that has been reported to us where fan_update() would hold the fan lock and try to grab the alarm_program_lock to reschedule an update. On an other CPU, the alarm_program_lock would have been taken before calling fan_update(), leading to a deadlock. We should Cc: # 3.9+ Reported-by: Marcin Slusarz Tested-by: Timothée Ravier Tested-by: Boris Fersing (IRC nick fersingb, no public email address) Signed-off-by: Martin Peres Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 4fe6be724f7045fd6ecf59941b4f94fdd50f82b8 Author: Christoph Paasch Date: Fri Mar 21 04:02:09 2014 -0700 igb: Unset IGB_FLAG_HAS_MSIX-flag when falling back to msi-only commit b709323d2477614823a38c2f2a9a206e087e28fc upstream. Prior to cd14ef54d25 (igb: Change to use statically allocated array for MSIx entries), having msix_entries different from NULL was an indicator that MSIX is enabled. In igb_set_interrupt_capabiliy we may fall back to MSI-only. Prior to the above patch msix_entries was set to NULL by igb_reset_interrupt_capability. However, now we are checking the flag for IGB_FLAG_HAS_MSIX and so the stack gets completly confused: [ 42.659791] ------------[ cut here ]------------ [ 42.715032] WARNING: CPU: 7 PID: 0 at net/sched/sch_generic.c:264 dev_watchdog+0x15c/0x1fb() [ 42.848263] NETDEV WATCHDOG: eth0 (igb): transmit queue 0 timed out [ 42.923253] Modules linked in: [ 42.959875] CPU: 7 PID: 0 Comm: swapper/7 Not tainted 3.14.0-rc2-mptcp #437 [ 43.043184] Hardware name: HP ProLiant DL165 G7, BIOS O37 01/26/2011 [ 43.119215] 0000000000000108 ffff88023fdc3da8 ffffffff81487847 0000000000000108 [ 43.208165] ffff88023fdc3df8 ffff88023fdc3de8 ffffffff81034e7d ffff88023fdc3dd8 [ 43.297120] ffffffff813fff10 ffff880236018000 ffff880236b178c0 0000000000000008 [ 43.386071] Call Trace: [ 43.415303] [] dump_stack+0x49/0x62 [ 43.484174] [] warn_slowpath_common+0x77/0x91 [ 43.556049] [] ? dev_watchdog+0x15c/0x1fb [ 43.623759] [] warn_slowpath_fmt+0x41/0x43 [ 43.692511] [] dev_watchdog+0x15c/0x1fb [ 43.758141] [] ? __netdev_watchdog_up+0x64/0x64 [ 43.832091] [] call_timer_fn+0x17/0x6f [ 43.896682] [] run_timer_softirq+0x162/0x1a2 [ 43.967511] [] __do_softirq+0xcd/0x1cc [ 44.032104] [] irq_exit+0x3a/0x48 [ 44.091492] [] smp_apic_timer_interrupt+0x43/0x50 [ 44.167525] [] apic_timer_interrupt+0x6a/0x70 [ 44.239392] [] ? default_idle+0x6/0x8 [ 44.310343] [] arch_cpu_idle+0x13/0x18 [ 44.374934] [] cpu_startup_entry+0xa7/0x101 [ 44.444724] [] start_secondary+0x1b2/0x1b7 [ 44.513472] ---[ end trace a5a075fd4e7f854f ]--- [ 44.568753] igb 0000:04:00.0 eth0: Reset adapter [ 46.206945] random: nonblocking pool is initialized [ 46.465670] irq 44: nobody cared (try booting with the "irqpoll" option) [ 46.545862] CPU: 7 PID: 0 Comm: swapper/7 Tainted: G W 3.14.0-rc2-mptcp #437 [ 46.640610] Hardware name: HP ProLiant DL165 G7, BIOS O37 01/26/2011 [ 46.716641] ffff8802363f8c84 ffff88023fdc3e38 ffffffff81487847 00000000a03cdb6d [ 46.805598] ffff8802363f8c00 ffff88023fdc3e68 ffffffff81068489 0000007f81825400 [ 46.894539] ffff8802363f8c00 0000000000000000 0000000000000000 ffff88023fdc3ea8 [ 46.983484] Call Trace: [ 47.012714] [] dump_stack+0x49/0x62 [ 47.081585] [] __report_bad_irq+0x35/0xc1 [ 47.149295] [] note_interrupt+0x16e/0x1ea [ 47.217006] [] handle_irq_event_percpu+0x116/0x12e [ 47.294075] [] handle_irq_event+0x33/0x4f [ 47.361787] [] handle_fasteoi_irq+0x83/0xd1 [ 47.431577] [] handle_irq+0x1f/0x28 [ 47.493047] [] do_IRQ+0x4e/0xd4 [ 47.550358] [] common_interrupt+0x6a/0x6a [ 47.618066] [] ? default_idle+0x6/0x8 [ 47.689016] [] arch_cpu_idle+0x13/0x18 [ 47.753605] [] cpu_startup_entry+0xa7/0x101 [ 47.823397] [] start_secondary+0x1b2/0x1b7 [ 47.892146] handlers: [ 47.919301] [] igb_intr So, this patch unsets the flag to indicate that we are not using MSIX. This patch does exactly this: Unsetting the flag when falling back to MSI. Fixes: cd14ef54d25b (igb: Change to use statically allocated array for MSIx entries) Cc: Carolyn Wyborny Signed-off-by: Christoph Paasch Tested-by: Jeff Pieper Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman commit 5c0f1fdbaebb742c0903bba402772f0db7760aa1 Author: Christoph Paasch Date: Fri Mar 21 03:48:19 2014 -0700 igb: Fix Null-pointer dereference in igb_reset_q_vector commit cb06d102327eadcd1bdc480bfd9f8876251d1007 upstream. When igb_set_interrupt_capability() calls igb_reset_interrupt_capability() (e.g., because CONFIG_PCI_MSI is unset), num_q_vectors has been set but no vector has yet been allocated. igb_reset_interrupt_capability() will then call igb_reset_q_vector, which assumes that the vector is allocated. As this is not the case, we are accessing a NULL-pointer. This patch fixes it by checking that q_vector is indeed different from NULL. Fixes: 02ef6e1d0b0023 (igb: Fix queue allocation method to accommodate changing during runtime) Cc: Carolyn Wyborny Signed-off-by: Christoph Paasch Tested-by: Jeff Pieper Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman commit 8a255ad5da168d12278f6a59bb2727ca07416c9d Author: Dan Carpenter Date: Wed Jan 15 06:43:39 2014 +0000 i40e: potential array underflow in i40e_vc_process_vf_msg() commit c243e96335c56e56dcf6a00593104554fb06b689 upstream. If "vf_id" is smaller than hw->func_caps.vf_base_id then it leads to an array underflow of the pf->vf[] array. This is unlikely to happen unless the hardware is bad, but it's a small change and it silences a static checker warning. Fixes: 7efa84b7abc1 ('i40e: support VFs on PFs other than 0') Signed-off-by: Dan Carpenter Tested-by: Sibai Li Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman commit cd3750a8e7a512616c64c729a8de4d4d0bd69b7e Author: Aaron Lu Date: Mon May 12 16:55:45 2014 +0800 drm/i915: restore backlight precision when converting from ACPI commit 721e82c08c1afd6b47367b0e0c4a62140b0667f3 upstream. When we set backlight on behalf of ACPI opregion, we will convert the backlight value in the 0-255 range defined in opregion to the actual hardware level. Commit 22505b82a2 (drm/i915: avoid brightness overflow when doing scale) is meant to fix the overflow problem when doing the conversion, but it also caused a problem that the converted hardware level doesn't quite represent the intended value: say user wants maximum backlight level(255 in opregion's range), then we will calculate the actual hardware level to be: level = freq / max * level, where freq is the hardware's max backlight level(937 on an user's box), and max and level are all 255. The converted value should be 937 but the above calculation will yield 765. To fix this issue, just use 64 bits to do the calculation to keep the precision and avoid overflow at the same time. Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=72491 Reported-by: Nico Schottelius Reviewed-by: Chris Wilson Signed-off-by: Aaron Lu Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit e3fe5945d5fff076366e852440c7c2e9c7b7d17c Author: Jani Nikula Date: Fri May 9 14:52:34 2014 +0300 drm/i915/vlv: reset VLV media force wake request register commit 05adaf1f101f25f40f12c29403e6488f0e45f6b6 upstream. Media force wake get hangs the machine when the system is booted without displays attached. The assumption is that (at least some versions of) the firmware has skipped some initialization in that case. Empirical evidence suggests we need to reset the media force wake request register in addition to the render one to avoid hangs. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75895 Reported-by: Imre Deak Reported-by: Darren Hart Tested-by: Darren Hart Reviewed-by: Mika Kuoppala Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 57a2e10dbc72c327a02dda55c4685beac7fdd79c Author: Maarten Lankhorst Date: Thu May 1 13:58:05 2014 +0200 drm/nouveau: fix another lock unbalance in nouveau_crtc_page_flip commit 806cbc5026933a781b66adecf6d1658fde9138e6 upstream. Fixes a regression introduced by 060810d7abaabca "drm/nouveau: fix locking issues in page flipping paths". chan->cli->mutex is unlocked a second time in the fail_unreserve path, fix this by moving mutex_unlock down. Signed-off-by: Maarten Lankhorst Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 939837d48a1a31304938f10ee1a454ef4aa838b2 Author: Ilia Mirkin Date: Wed Mar 26 19:37:21 2014 -0400 drm/nouveau/acpi: allow non-optimus setups to load vbios from acpi commit a3d0b1218d351c6e6f3cea36abe22236a08cb246 upstream. There appear to be a crop of new hardware where the vbios is not available from PROM/PRAMIN, but there is a valid _ROM method in ACPI. The data read from PCIROM almost invariably contains invalid instructions (still has the x86 opcodes), which makes this a low-risk way to try to obtain a valid vbios image. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76475 Signed-off-by: Ilia Mirkin Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit e9582f152369e8e183e9c5cd5e42900ff87a7f24 Author: Ben Hutchings Date: Sat Apr 26 21:59:04 2014 +0100 rtl8192cu: Fix unbalanced irq enable in error path of rtl92cu_hw_init() commit 3234f5b06fc3094176a86772cc64baf3decc98fc upstream. Fixes: a53268be0cb9 ('rtlwifi: rtl8192cu: Fix too long disable of IRQs') Signed-off-by: Ben Hutchings Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit b4c97e6c9c17a32267a78f5661c5a07dd5a53e02 Author: Liu Hua Date: Thu Mar 27 06:56:18 2014 +0100 ARM: 8012/1: kdump: Avoid overflow when converting pfn to physaddr commit 8fad87bca7ac9737e413ba5f1656f1114a8c314d upstream. When we configure CONFIG_ARM_LPAE=y, pfn << PAGE_SHIFT will overflow if pfn >= 0x100000 in copy_oldmem_page. So use __pfn_to_phys for converting. Signed-off-by: Liu Hua Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 542e7f333e12cb600e6a2a59356cae5ca8f0dea5 Author: Leif Lindholm Date: Thu Apr 17 18:41:59 2014 +0100 arm: dts: Fix missing device_type="memory" for ste-ccu8540 commit bfaed5abad998bfc88a66e6e71c7b08dcf82f04e upstream. The current .dts for ste-ccu8540 lacks a 'device_type = "memory"' for its memory node, relying on an old ppc quirk in order to discover its memory. Fix the data so that all parsing code can handle it correctly. Signed-off-by: Leif Lindholm Acked-by: Lee Jones Acked-by: Linus Walleij Cc: linux-arm-kernel@lists.infradead.org Cc: devicetree@vger.kernel.org Cc: Mark Rutland Signed-off-by: Grant Likely Signed-off-by: Greg Kroah-Hartman commit c5a7378aa0114f09e3c7c89489b2a9aadfda1469 Author: Thomas Petazzoni Date: Mon Apr 14 17:29:21 2014 +0200 ARM: mvebu: fix NOR bus-width in Armada XP OpenBlocks AX3 Device Tree commit 6e20bae8a39c40d4e03698e4160bad2d2629062b upstream. The mvebu-devbus driver had a serious bug, which lead to a 8 bits bus width declared in the Device Tree being considered as a 16 bits bus width when configuring the hardware. This bug in mvebu-devbus driver was compensated by a symetric mistake in the Armada XP OpenBlocks AX3 Device Tree: a 8 bits bus width was declared, even though the hardware actually has a 16 bits bus width connection with the NOR flash. Now that we have fixed the mvebu-devbus driver to behave according to its Device Tree binding, this commit fixes the problematic Device Tree files as well. This bug was introduced in commit a7d4f81821f7eec3175f8e23dd6949c71ab2da43 ('ARM: mvebu: Add support for NOR flash device on Openblocks AX3 board') which was merged in v3.10. Signed-off-by: Thomas Petazzoni Link: https://lkml.kernel.org/r/1397489361-5833-5-git-send-email-thomas.petazzoni@free-electrons.com Fixes: a7d4f81821f7 ('ARM: mvebu: Add support for NOR flash device on Openblocks AX3 board') Acked-by: Ezequiel Garcia Acked-by: Gregory CLEMENT Signed-off-by: Jason Cooper Signed-off-by: Greg Kroah-Hartman commit dc68b6a6c724a43404ded6fb5227bca536c1209e Author: Thomas Petazzoni Date: Mon Apr 14 17:29:20 2014 +0200 ARM: mvebu: fix NOR bus-width in Armada XP DB Device Tree commit f3aec8f3f05025e7b450102dae0759375346706e upstream. The mvebu-devbus driver had a serious bug, which lead to a 8 bits bus width declared in the Device Tree being considered as a 16 bits bus width when configuring the hardware. This bug in mvebu-devbus driver was compensated by a symetric mistake in the Armada XP DB Device Tree: a 8 bits bus width was declared, even though the hardware actually has a 16 bits bus width connection with the NOR flash. Now that we have fixed the mvebu-devbus driver to behave according to its Device Tree binding, this commit fixes the problematic Device Tree files as well. This bug was introduced in commit b484ff42df475c5087d614c4d477273e1906bcb9 ('ARM: mvebu: Add support for NOR flash device on Armada XP-DB board') which was merged in v3.11. Signed-off-by: Thomas Petazzoni Link: https://lkml.kernel.org/r/1397489361-5833-4-git-send-email-thomas.petazzoni@free-electrons.com Fixes: b484ff42df47 ('ARM: mvebu: Add support for NOR flash device on Armada XP-DB board') Acked-by: Ezequiel Garcia Acked-by: Gregory CLEMENT Signed-off-by: Jason Cooper Signed-off-by: Greg Kroah-Hartman commit f05b2f5730bdaa4f80864fb5a906e246b54a303d Author: Thomas Petazzoni Date: Mon Apr 14 17:29:19 2014 +0200 ARM: mvebu: fix NOR bus-width in Armada XP GP Device Tree commit 1a88f809ccb5db1509a7514b187c00b3a995fc82 upstream. The mvebu-devbus driver had a serious bug, which lead to a 8 bits bus width declared in the Device Tree being considered as a 16 bits bus width when configuring the hardware. This bug in mvebu-devbus driver was compensated by a symetric mistake in the Armada XP GP Device Tree: a 8 bits bus width was declared, even though the hardware actually has a 16 bits bus width connection with the NOR flash. Now that we have fixed the mvebu-devbus driver to behave according to its Device Tree binding, this commit fixes the problematic Device Tree files as well. This bug was introduced in commit da8d1b38356853c37116f9afa29f15648d7fb159 ('ARM: mvebu: Add support for NOR flash device on Armada XP-GP board') which was merged in v3.10. Signed-off-by: Thomas Petazzoni Link: https://lkml.kernel.org/r/1397489361-5833-3-git-send-email-thomas.petazzoni@free-electrons.com Fixes: da8d1b383568 ('ARM: mvebu: Add support for NOR flash device on Armada XP-GP board') Acked-by: Ezequiel Garcia Acked-by: Gregory CLEMENT Signed-off-by: Jason Cooper Signed-off-by: Greg Kroah-Hartman commit 0387a6a201d9a28032cd9882e440aaa9fed34aec Author: Thomas Gleixner Date: Sun Apr 13 20:44:46 2014 +0200 ARM: common: edma: Fix xbar mapping commit cf7eb979116c2568e8bc3b6a7269c7a359864ace upstream. This is another great example of trainwreck engineering: commit 2646a0e529 (ARM: edma: Add EDMA crossbar event mux support) added support for using EDMA on peripherals which have no direct EDMA event mapping. The code compiles and does not explode in your face, but that's it. 1) Reading an u16 array from an u32 device tree array simply does not work. Even if the function is named "edma_of_read_u32_to_s16_array". It merily calls of_property_read_u16_array. So the resulting 16bit array will have every other entry = 0. 2) The DT entry for the xbar registers related to xbar has length 0x10 instead of the real length: 0xfd0 - 0xf90 = 0x40. Not a real problem as it does not cross a page boundary, but wrong nevertheless. 3) But none of this matters as the mapping never happens: After reading nonsense edma_of_read_u32_to_s16_array() invalidates the first array entry pair, so nobody can ever notice the braindamage by immediate explosion. Seems the QA criteria for this code was solely not to explode when someone adds edma-xbar-event-map entries to the DT. Goal achieved, congratulations! Not really helpful if someone wants to use edma on a device which requires a xbar mapping. Fix the issues by: - annotating the device tree entry with "/bits/ 16" as documented in the of_property_read_u16_array kernel doc - make the size of the xbar register mapping correct - invalidating the end of the array and not the start This convoluted mess wants to be completely rewritten as there is no point to keep the xbar_chan array memory and the iomapping of the xbar regs around forever. Marking the xbar mapped channels as used should be done right there. But that's a different issue and this patch is small enough to make it work and allows a simple backport for stable. Signed-off-by: Thomas Gleixner Signed-off-by: Sekhar Nori Signed-off-by: Greg Kroah-Hartman commit 12800a2e16f3f4c2a28bb43feda1d56b566a1746 Author: Sascha Hauer Date: Tue May 6 13:01:34 2014 +0200 ARM: dts: i.MX53: Fix ipu register space size commit 6d66da89bf4422c0a0693627fb3e25f74af50f92 upstream. The IPU register space is 128MB, not 2GB. Fixes: abed9a6bf2bb 'ARM i.MX53: Add IPU support' Signed-off-by: Sascha Hauer Acked-by: Shawn Guo Signed-off-by: Olof Johansson Signed-off-by: Greg Kroah-Hartman commit 6f5d63343a96cfadaa16fd4bcc06c0c7b0b26c7f Author: Sebastian Hesselbarth Date: Wed Apr 30 14:56:28 2014 +0200 ARM: dts: kirkwood: fix mislocated pcie-controller nodes commit 788296b2d19d16ec33aba0a5ad1544d50bb58601 upstream. Commit 54397d85349f ("ARM: kirkwood: Relocate PCIe device tree nodes") moved the pcie-controller nodes for the Kirkwood SoCs to the mbus bus node. For some reason, two boards were not properly converted and have their pci-controller nodes still in the ocp bus node. As the corresponding SoC pcie-controller does not exist anymore, it is likely that pcie is broken on those boards since above commit. Fix it by moving the pcie related nodes to the correct location. Signed-off-by: Sebastian Hesselbarth Fixes: 54397d85349f ("ARM: kirkwood: Relocate PCIe device tree nodes") Acked-by: Andrew Lunn Link: https://lkml.kernel.org/r/1398862602-29595-2-git-send-email-sebastian.hesselbarth@gmail.com Signed-off-by: Jason Cooper Signed-off-by: Greg Kroah-Hartman commit 0da911cf4d976e59599586f04fc2cbfc871fb4cd Author: Thomas Petazzoni Date: Sun Apr 13 16:39:38 2014 +0200 ARM: orion5x: fix target ID for crypto SRAM window commit 1cc9d48145b81e307fab94a5cf6ee66ec2f0de60 upstream. In commit 4ca2c04085a1caa903e92a5fc0da25362150aac2 ('ARM: orion5x: Move to ID based window creation'), the mach-orion5x code was changed to use the new mvebu-mbus API. However, in the process, a mistake was made on the crypto SRAM window target ID: it should have been 0x9 (verified in the datasheet) and not 0x0. Signed-off-by: Thomas Petazzoni Acked-by: Sebastian Hesselbarth Link: https://lkml.kernel.org/r/1397400006-4315-2-git-send-email-thomas.petazzoni@free-electrons.com Fixes: 4ca2c04085a1 ('ARM: orion5x: Move to ID based window creation') Signed-off-by: Jason Cooper Signed-off-by: Greg Kroah-Hartman commit 876d8a6f0b960cc4cdc0a6cc193d846f124a80b5 Author: Johannes Weiner Date: Tue May 6 12:50:07 2014 -0700 revert "mm: vmscan: do not swap anon pages just because free+file is low" commit 623762517e2370be3b3f95f4fe08d6c063a49b06 upstream. This reverts commit 0bf1457f0cfc ("mm: vmscan: do not swap anon pages just because free+file is low") because it introduced a regression in mostly-anonymous workloads, where reclaim would become ineffective and trap every allocating task in direct reclaim. The problem is that there is a runaway feedback loop in the scan balance between file and anon, where the balance tips heavily towards a tiny thrashing file LRU and anonymous pages are no longer being looked at. The commit in question removed the safe guard that would detect such situations and respond with forced anonymous reclaim. This commit was part of a series to fix premature swapping in loads with relatively little cache, and while it made a small difference, the cure is obviously worse than the disease. Revert it. Signed-off-by: Johannes Weiner Reported-by: Christian Borntraeger Acked-by: Christian Borntraeger Acked-by: Rafael Aquini Cc: Rik van Riel Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e9c26d89734fd98fe3ef9dda6a5056d01900b463 Author: Vlastimil Babka Date: Tue May 6 12:50:03 2014 -0700 mm/compaction: make isolate_freepages start at pageblock boundary commit 49e068f0b73dd042c186ffa9b420a9943e90389a upstream. The compaction freepage scanner implementation in isolate_freepages() starts by taking the current cc->free_pfn value as the first pfn. In a for loop, it scans from this first pfn to the end of the pageblock, and then subtracts pageblock_nr_pages from the first pfn to obtain the first pfn for the next for loop iteration. This means that when cc->free_pfn starts at offset X rather than being aligned on pageblock boundary, the scanner will start at offset X in all scanned pageblock, ignoring potentially many free pages. Currently this can happen when a) zone's end pfn is not pageblock aligned, or b) through zone->compact_cached_free_pfn with CONFIG_HOLES_IN_ZONE enabled and a hole spanning the beginning of a pageblock This patch fixes the problem by aligning the initial pfn in isolate_freepages() to pageblock boundary. This also permits replacing the end-of-pageblock alignment within the for loop with a simple pageblock_nr_pages increment. Signed-off-by: Vlastimil Babka Reported-by: Heesub Shin Acked-by: Minchan Kim Cc: Mel Gorman Acked-by: Joonsoo Kim Cc: Bartlomiej Zolnierkiewicz Cc: Michal Nazarewicz Cc: Naoya Horiguchi Cc: Christoph Lameter Acked-by: Rik van Riel Cc: Dongjun Shin Cc: Sunghwan Yun Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 55023920439daa2631aad56e51b7983f74d76556 Author: Rik van Riel Date: Tue May 6 12:50:01 2014 -0700 mm/page-writeback.c: fix divide by zero in pos_ratio_polynom commit d5c9fde3dae750889168807038243ff36431d276 upstream. It is possible for "limit - setpoint + 1" to equal zero, after getting truncated to a 32 bit variable, and resulting in a divide by zero error. Using the fully 64 bit divide functions avoids this problem. It also will cause pos_ratio_polynom() to return the correct value when (setpoint - limit) exceeds 2^32. Also uninline pos_ratio_polynom, at Andrew's request. Signed-off-by: Rik van Riel Reviewed-by: Michal Hocko Cc: Aneesh Kumar K.V Cc: Mel Gorman Cc: Nishanth Aravamudan Cc: Luiz Capitulino Cc: Masayoshi Mizuma Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 94d3803b8b5aff8b0a8b47116c1f1d37f75c8819 Author: Fabian Frederick Date: Tue May 6 12:50:11 2014 -0700 fs/affs/super.c: bugfix / double free commit d353efd02357a74753cd45f367a2d3d357fd6904 upstream. Commit 842a859db26b ("affs: use ->kill_sb() to simplify ->put_super() and failure exits of ->mount()") adds .kill_sb which frees sbi but doesn't remove sbi free in case of parse_options error causing double free+random crash. Signed-off-by: Fabian Frederick Cc: Alexander Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 54c2a0ca8378bb0cbfbb56179c883d1bd9258cf9 Author: Christoph Hellwig Date: Sun May 4 13:03:32 2014 +0200 posix_acl: handle NULL ACL in posix_acl_equiv_mode commit 50c6e282bdf5e8dabf8d7cf7b162545a55645fd9 upstream. Various filesystems don't bother checking for a NULL ACL in posix_acl_equiv_mode, and thus can dereference a NULL pointer when it gets passed one. This usually happens from the NFS server, as the ACL tools never pass a NULL ACL, but instead of one representing the mode bits. Instead of adding boilerplat to all filesystems put this check into one place, which will allow us to remove the check from other filesystems as well later on. Signed-off-by: Christoph Hellwig Reported-by: Ben Greear Reported-by: Marco Munderloh , Cc: Chuck Lever Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 1304ba7cd0d5936fc1e837a9692e621666e638cc Author: Marcel Holtmann Date: Tue Apr 22 14:04:16 2014 -0700 Revert "Bluetooth: Enable autosuspend for Intel Bluetooth device" commit 3c49aa852e00978ba2f1a4d1e4598a0c669a5347 upstream. This reverts commit d2bee8fb6e18f6116aada39851918473761f7ab1. Enabling autosuspend for Intel Bluetooth devices has been shown to not work reliable. It does work for some people with certain combinations of USB host controllers, but for others it puts the device to sleep and it will not wake up for any event. These events can be important ones like HCI Inquiry Complete or HCI Connection Request. The events will arrive as soon as you poke the device with a new command, but that is not something we can do in these cases. Initially there were patches to the xHCI USB controller that fixed this for some people, but not for all. This could be well a problem somewhere in the USB subsystem or in the USB host controllers or just plain a hardware issue somewhere. At this moment we just do not know and the only safe action is to revert this patch. Signed-off-by: Marcel Holtmann Cc: Tedd Ho-Jeong An Signed-off-by: Gustavo Padovan Signed-off-by: Greg Kroah-Hartman commit 7dbf1b3b9dfc2c2c1f92243d024a5c718e76d74d Author: Mohammed Habibulla Date: Thu Apr 17 11:37:13 2014 -0700 Bluetooth: Add support for Lite-on [04ca:3007] commit 1fb4e09a7e780b915dbd172592ae7e2a4c071065 upstream. Add support for the AR9462 chip T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=03 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=3007 Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Mohammed Habibulla Signed-off-by: Gustavo Padovan Signed-off-by: Greg Kroah-Hartman commit fe8578f3e20633647165faf324f283e67deff7e5 Author: Johan Hedberg Date: Fri Apr 11 12:02:32 2014 -0700 Bluetooth: Fix redundant encryption request for reauthentication commit 09da1f3463eb81d59685df723b1c5950b7570340 upstream. When we're performing reauthentication (in order to elevate the security level from an unauthenticated key to an authenticated one) we do not need to issue any encryption command once authentication completes. Since the trigger for the encryption HCI command is the ENCRYPT_PEND flag this flag should not be set in this scenario. Instead, the REAUTH_PEND flag takes care of all necessary steps for reauthentication. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 5e3ccae03cc3a26f535067c26e8f65d46679302f Author: Johan Hedberg Date: Fri Apr 11 12:02:31 2014 -0700 Bluetooth: Fix triggering BR/EDR L2CAP Connect too early commit 9eb1fbfa0a737fd4d3a6d12d71c5ea9af622b887 upstream. Commit 1c2e004183178 introduced an event handler for the encryption key refresh complete event with the intent of fixing some LE/SMP cases. However, this event is shared with BR/EDR and there we actually want to act only on the auth_complete event (which comes after the key refresh). If we do not do this we may trigger an L2CAP Connect Request too early and cause the remote side to return a security block error. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit f5ad14928afcc5c2b1c2722c7e935842ad512b0d Author: Clemens Ladisch Date: Thu May 1 12:20:22 2014 +0200 ALSA: usb-audio: work around corrupted TEAC UD-H01 feedback data commit 7040b6d1febfdbd9c1595efb751d492cd2503f96 upstream. The TEAC UD-H01 firmware sends wrong feedback frequency values, thus causing the PC to send the samples at a wrong rate, which results in clicks and crackles in the output. Add a workaround to detect and fix the corruption. Signed-off-by: Clemens Ladisch [mick37@gmx.de: use sender->udh01_fb_quirk rather than ep->udh01_fb_quirk in snd_usb_handle_sync_urb()] Reported-and-tested-by: Mick Reported-and-tested-by: Andrea Messa Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c2965f4fee71bb2432a2d06989247cbc526b9e55 Author: Stanislaw Gruszka Date: Thu Apr 17 11:08:47 2014 +0200 rt2x00: fix beaconing on USB commit 8834d3608cc516f13e2e510f4057c263f3d2ce42 upstream. When disable beaconing we clear register with beacon and newer set it back, what make we stop send beacons infinitely. Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit fb2b50456d3361cc81ce9d9161e886fe3d3b7779 Author: Daniele Forsi Date: Mon Apr 28 17:09:11 2014 +0200 USB: Nokia 5300 should be treated as unusual dev commit 6ed07d45d09bc2aa60e27b845543db9972e22a38 upstream. Signed-off-by: Daniele Forsi Signed-off-by: Greg Kroah-Hartman commit 2f0200ad379e0908dd386c11f98311dc5e772cb5 Author: Victor A. Santos Date: Sat Apr 26 23:20:14 2014 -0300 USB: Nokia 305 should be treated as unusual dev commit f0ef5d41792a46a1085dead9dfb0bdb2c574638e upstream. Signed-off-by: Victor A. Santos Signed-off-by: Greg Kroah-Hartman commit 6212307c6babf64d8a857df892a70c618f332eb3 Author: Daniele Forsi Date: Tue Apr 29 11:44:03 2014 +0200 usb: storage: shuttle_usbat: fix discs being detected twice commit df602c2d2358f02c6e49cffc5b49b9daa16db033 upstream. Even if the USB-to-ATAPI converter supported multiple LUNs, this driver would always detect the same physical device or media because it doesn't use srb->device->lun in any way. Tested with an Hewlett-Packard CD-Writer Plus 8200e. Signed-off-by: Daniele Forsi Signed-off-by: Greg Kroah-Hartman commit 9917280e2277d0b6b1f209c5753c67b673da3ba2 Author: Bjørn Mork Date: Sun Apr 27 16:47:42 2014 +0200 usb: qcserial: add a number of Dell devices commit 4d7c0136a54f62501f8a34c4d08a5e0258d3d3ca upstream. Dan writes: "The Dell drivers use the same configuration for PIDs: 81A2: Dell Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card 81A3: Dell Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card 81A4: Dell Wireless 5570e HSPA+ (42Mbps) Mobile Broadband Card 81A8: Dell Wireless 5808 Gobi(TM) 4G LTE Mobile Broadband Card 81A9: Dell Wireless 5808e Gobi(TM) 4G LTE Mobile Broadband Card These devices are all clearly Sierra devices, but are also definitely Gobi-based. The A8 might be the MC7700/7710 and A9 is likely a MC7750. >From DellGobi5kSetup.exe from the Dell drivers: usbif0: serial/firmware loader? usbif2: nmea usbif3: modem/ppp usbif8: net/QMI" Reported-by: AceLan Kao Reported-by: Dan Williams Signed-off-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman commit a9c3ff5b68b302b81ff5240643a2be5b8461a26c Author: Alan Stern Date: Thu May 1 15:21:42 2014 -0400 USB: OHCI: fix problem with global suspend on ATI controllers commit c1db30a2a79eb59997b13b8cabf2a50bea9f04e1 upstream. Some OHCI controllers from ATI/AMD seem to have difficulty with "global" USB suspend, that is, suspending an entire USB bus without setting the suspend feature for each port connected to a device. When we try to resume the child devices, the controller gives timeout errors on the unsuspended ports, requiring resets, and can even cause ohci-hcd to hang; see http://marc.info/?l=linux-usb&m=139514332820398&w=2 and the following messages. This patch fixes the problem by adding a new quirk flag to ohci-hcd. The flag causes the ohci_rh_suspend() routine to suspend each unsuspended, enabled port before suspending the root hub. This effectively converts the "global" suspend to an ordinary root-hub suspend. There is no need to unsuspend these ports when the root hub is resumed, because the child devices will be resumed anyway in the course of a normal system resume ("global" suspend is never used for runtime PM). This patch should be applied to all stable kernels which include commit 0aa2832dd0d9 (USB: use "global suspend" for system sleep on USB-2 buses) or a backported version thereof. Signed-off-by: Alan Stern Reported-by: Peter Münster Tested-by: Peter Münster Signed-off-by: Greg Kroah-Hartman commit 3866f7f4c5371d71c38809ec23e1142a52e934f1 Author: Jean-Jacques Hiblot Date: Wed Mar 12 17:30:08 2014 +0100 usb: gadget: at91-udc: fix irq and iomem resource retrieval commit 886c7c426d465732ec9d1b2bbdda5642fc2e7e05 upstream. When using dt resources retrieval (interrupts and reg properties) there is no predefined order for these resources in the platform dev resource table. Also don't expect the number of resource to be always 2. Signed-off-by: Jean-Jacques Hiblot Acked-by: Boris BREZILLON Acked-by: Nicolas Ferre Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 6cb00d58ad0724088646dc1fec20de4e7bbaaf72 Author: Nikita Yushchenko Date: Mon Apr 28 19:23:44 2014 +0400 fsl-usb: do not test for PHY_CLK_VALID bit on controller version 1.6 commit d183c81929beeba842b74422f754446ef2b8b49c upstream. Per reference manuals of Freescale P1020 and P2020 SoCs, USB controller present in these SoCs has bit 17 of USBx_CONTROL register marked as Reserved - there is no PHY_CLK_VALID bit there. Testing for this bit in ehci_fsl_setup_phy() behaves differently on two P1020RDB boards available here - on one board test passes and fsl-usb init succeeds, but on other board test fails, causing fsl-usb init to fail. This patch changes ehci_fsl_setup_phy() not to test PHY_CLK_VALID on controller version 1.6 that (per manual) does not have this bit. Signed-off-by: Nikita Yushchenko Signed-off-by: Greg Kroah-Hartman commit edbfad5ceee721db176f03fb56070ff651b7f2e6 Author: Atilla Filiz Date: Fri Apr 11 16:51:23 2014 +0200 iio:imu:mpu6050: Fixed segfault in Invensens MPU driver due to null dereference commit b9b3a41893c3f1be67b5aacfa525969914bea0e9 upstream. The driver segfaults when the kernel boots with device tree as the platform data is then not present and the pointer is deferenced without checking it is not null. This patch introduces such a check avoiding the crash. Signed-off-by: Atilla Filiz Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit c6229d9e33fe849bf6f7f16a7813550a1936806a Author: Tuomas Tynkkynen Date: Fri May 16 16:50:20 2014 +0300 clk: tegra: Fix wrong value written to PLLE_AUX commit d2c834abe2b39a2d5a6c38ef44de87c97cbb34b4 upstream. The value written to PLLE_AUX was incorrect due to a wrong variable being used. Without this fix SATA does not work. Signed-off-by: Tuomas Tynkkynen Tested-by: Mikko Perttunen Reviewed-by: Thierry Reding Tested-by: Thierry Reding Acked-by: Thierry Reding Signed-off-by: Mike Turquette [mturquette@linaro.org: improved changelog] Signed-off-by: Greg Kroah-Hartman commit ab1948555192941e6725e459775a47c432ce3679 Author: Thierry Reding Date: Wed Apr 9 14:26:59 2014 +0200 drm/tegra: Remove gratuitous pad field commit cbfbbabb89b37f6bad05f478d906a385149f288d upstream. The version of the drm_tegra_submit structure that was merged all the way back in 3.10 contains a pad field that was originally intended to properly pad the following __u64 field. Unfortunately it seems like a different field was dropped during review that caused this padding to become unnecessary, but the pad field wasn't removed at that time. One possible side-effect of this is that since the __u64 following the pad is now no longer properly aligned, the compiler may (or may not) introduce padding itself, which results in no predictable ABI. Rectify this by removing the pad field so that all fields are again naturally aligned. Technically this is breaking existing userspace ABI, but given that there aren't any (released) userspace drivers that make use of this yet, the fallout should be minimal. Fixes: d43f81cbaf43 ("drm/tegra: Add gr2d device") Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit d293313f492702284f33beaacc06d168f3a9b000 Author: Leo Liu Date: Mon Apr 28 09:40:22 2014 -0400 drm/radeon: check buffer relocation offset commit 695daf1a8e731a4b5b89de89a61f32a4d7ad7094 upstream. Signed-off-by: Leo Liu Signed-off-by: Christian König Signed-off-by: Greg Kroah-Hartman commit 19aef29eea6e5b42e4097c2ccdd80e944e9f9f6f Author: Christian König Date: Wed Apr 23 20:46:06 2014 +0200 drm/radeon: use pflip irq on R600+ v2 commit f5d636d2a74b755879feec35e14a259de52ccc07 upstream. Testing the update pending bit directly after issuing an update is nonsense cause depending on the pixel clock the CRTC needs a bit of time to execute the flip even when we are in the VBLANK period. This is just a non invasive patch to solve the problem at hand, a more complete and cleaner solution should follow in the next merge window. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=76564 v2: fix source IDs for CRTC2-6 Signed-off-by: Christian König Signed-off-by: Greg Kroah-Hartman commit f5cb8a665138985118920de132db115c74dcf7ec Author: Christian König Date: Thu Apr 10 16:11:36 2014 +0200 drm/radeon/uvd: use lower clocks on old UVD to boot v2 commit e45187620f9fc103edf68fa5ea78e73033e1668c upstream. Some RV7xx generation hardware crashes after you raise the UVD clocks for the first time. Try to avoid this by using the lower clocks to boot these. Workaround for: https://bugzilla.kernel.org/show_bug.cgi?id=71891 v2: lower clocks on IB test as well Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit c4a92098086a52c9520d4e7cbc22000408c6160a Author: Alex Deucher Date: Tue Apr 22 08:17:18 2014 -0400 drm/radeon: fix count in cik_sdma_ring_test() commit 7e95cfb0b797678cd3493ca0322ef2675547a0bc upstream. Should be 5 rather than 4. Noticed-by: Mathias Fröhlich Signed-off-by: Alex Deucher Signed-off-by: Christian König Signed-off-by: Greg Kroah-Hartman commit c37a57cce4fe8affcf3f589232fd006be967f11c Author: Alex Deucher Date: Fri Apr 18 09:08:11 2014 -0400 drm/radeon: disable dpm on rv770 by default commit 76e6dcece841faebbee78895780e8209ff40d922 upstream. There seem to be stability issues on a number of cards. bugs: https://bugs.freedesktop.org/show_bug.cgi?id=76286 https://bugzilla.redhat.com/show_bug.cgi?id=1085785 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741619 Signed-off-by: Alex Deucher Cc: matthias.graf@st.ovqu.de Cc: bp@alien8.de Signed-off-by: Greg Kroah-Hartman commit 58ae7e523bd6bfb185518ad4171225ef8c1cb930 Author: Alex Deucher Date: Tue Apr 15 12:44:35 2014 -0400 drm/radeon: don't allow runpm=1 on systems with out ATPX commit 73acacc7397fe854ed2ab75f1c940fa00faaf15e upstream. vgaswitcheroo and the ATPX ACPI methods are required to power down the dGPU. bug: https://bugzilla.kernel.org/show_bug.cgi?id=73901 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit c530d3e43f61db68b29e9c2e6d5aa8fd073ca79d Author: Alex Deucher Date: Tue Apr 15 12:44:33 2014 -0400 drm/radeon/pm: don't walk the crtc list before it has been initialized (v2) commit 3ed9a335cfc64b2c83545f341cdddf2347b12b97 upstream. Avoids a crash in certain cases when thermal irqs are generated before the display structures have been initialized. v2: fix the vblank and vrefresh helpers as well bug: https://bugzilla.kernel.org/show_bug.cgi?id=73931 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit f9822c158e4a573cff2eeaa39c7054716bf6c375 Author: Alex Deucher Date: Tue Apr 15 12:44:34 2014 -0400 drm/radeon: fix ATPX detection on non-VGA GPUs commit e9a4099a59cc598a44006059dd775c25e422b772 upstream. Some newer PX laptops have the pci device class set to DISPLAY_OTHER rather than DISPLAY_VGA. This properly detects ATPX on those laptops. Based on a patch from: Pali Rohár Signed-off-by: Alex Deucher Cc: airlied@gmail.com Signed-off-by: Greg Kroah-Hartman commit d110f9e2766eb8df5a5b2832d7ab39c566d92721 Author: Alex Deucher Date: Tue Apr 15 12:44:32 2014 -0400 drm/radeon: properly unregister hwmon interface (v2) commit cb3e4e7c59e4b43ac378631f6101f5c8de3a27a5 upstream. Need to properly unregister the hwmon device on driver unload. v2: minor clean up bug: https://bugzilla.kernel.org/show_bug.cgi?id=73931 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 5f198faeb27a9ec9f7a253f3e1aaa6c16b88a227 Author: Alex Deucher Date: Wed Apr 16 09:42:23 2014 -0400 drm/radeon/ci: make sure mc ucode is loaded before checking the size commit bcddee29b0b87af3aeda953840f97b356b24dc5e upstream. Avoid a possible segfault. Noticed-by: Dan Carpenter Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 078e8e804177a7ce50f51ecc636f7d33e924b72d Author: Alex Deucher Date: Wed Apr 16 09:42:22 2014 -0400 drm/radeon/si: make sure mc ucode is loaded before checking the size commit 8c79bae6a30f606b7a4e17c994bc5f72f8fdaf11 upstream. Avoid a possible segfault. Noticed-by: Dan Carpenter Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 3302087d6669a36c71ae57643ac36ecc8345c6ee Author: Alex Deucher Date: Fri Apr 11 11:21:51 2014 -0400 drm/radeon: re-enable mclk dpm on R7 260X asics commit 7e1858f9aff7d608b3d0abad4bda0130de887b89 upstream. If the new mc ucode is available. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 4740d5c1c89c152ef847e4a479a87a25e763b286 Author: Alex Deucher Date: Fri Apr 11 11:21:50 2014 -0400 drm/radeon: add support for newer mc ucode on CI (v2) commit 277babc374f6ecab6af182554f5d9f35a7768755 upstream. Fixes mclk stability on certain asics. v2: print out mc firmware version used and size bug: https://bugs.freedesktop.org/show_bug.cgi?id=75992 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 970e611a336ec91041087577eeb3f35b7644c6e7 Author: Alex Deucher Date: Fri Apr 11 11:21:49 2014 -0400 drm/radeon: add support for newer mc ucode on SI (v2) commit 1ebe92802eaf0569784dce843bc28a78842d236c upstream. May fix stability issues with some newer cards. v2: print out mc firmware version used and size Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 5fe20c529d02c53e1924e8e50f5601f9f276b1d9 Author: Alex Deucher Date: Thu Apr 10 22:29:03 2014 -0400 drm/radeon: disable mclk dpm on R7 260X commit 57700ad1f2f21d5d7ab7ee0e58d11b5954852434 upstream. Setting higher mclks seems to cause stability issues on some R7 260X boards. Disable it for now for stability until we find a proper fix. bug: https://bugs.freedesktop.org/show_bug.cgi?id=75992 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 89a06bf8ac495148fd4f33f1080802409df6a3d0 Author: Alex Deucher Date: Thu Apr 10 22:29:01 2014 -0400 drm/radeon: fix runpm handling on APUs (v4) commit 90c4cde9d5a2bb6239cb3e253bb3832ed89dc75c upstream. Don't try and runtime suspend the APU in PX systems. We only want to power down the dGPU. v2: fix harder v3: fix stupid typo v4: consolidate runpm enablement to a single flag bugs: https://bugs.freedesktop.org/show_bug.cgi?id=75127 https://bugzilla.kernel.org/show_bug.cgi?id=72701 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 3c86e8d191e090fda325c782d8b0700164b91065 Author: Alex Deucher Date: Tue Apr 8 11:28:54 2014 -0400 drm/radeon: fix audio pin counts for DCE6+ (v2) commit be0949f5eb9c8133a05cf25f108f09e85e79cd32 upstream. There is actually quite a bit of variance based on the asic. v2: fix typo noticed by Jerome. Signed-off-by: Alex Deucher Signed-off-by: Christian König Signed-off-by: Greg Kroah-Hartman commit c871d49c4034d8e3fe23699bae4780fb83a7cb27 Author: Egbert Eich Date: Fri Apr 25 10:56:22 2014 +0200 drm/i915: Break encoder->crtc link separately in intel_sanitize_crtc() commit 7f1950fbb989e8fc5463b307e062b4529d51c862 upstream. Depending on the SDVO output_flags SDVO may have multiple connectors linking to the same encoder (in intel_connector->encoder->base). Only one of those connectors should be active (ie link to the encoder thru drm_connector->encoder). If intel_connector_break_all_links() is called from intel_sanitize_crtc() we may break the crtc connection of an encoder thru an inactive connector in which case intel_connector_break_all_links() will not be called again for the active connector if this happens to come later in the list due to: if (connector->encoder->base.crtc != &crtc->base) continue; in intel_sanitize_crtc(). This will however leave the drm_connector->encoder linkage for this active connector in place. Subsequently this will cause multiple warnings in intel_connector_check_state() to trigger and the driver will eventually die in drm_encoder_crtc_ok() (because of crtc == NULL). To avoid this remove intel_connector_break_all_links() and move its code to its two calling functions: intel_sanitize_crtc() and intel_sanitize_encoder(). This allows to implement the link breaking more flexibly matching the surrounding code: ie. in intel_sanitize_crtc() we can break the crtc link separatly after the links to the encoders have been broken which avoids above problem. This regression has been introduced in: commit 24929352481f085c5f85d4d4cbc919ddf106d381 Author: Daniel Vetter Date: Mon Jul 2 20:28:59 2012 +0200 drm/i915: read out the modeset hw state at load and resume time so goes back to the very beginning of the modeset rework. v2: This patch takes care of the concernes voiced by Chris Wilson and Daniel Vetter that only breaking links if the drm_connector is linked to an encoder may miss some links. v3: move all encoder handling to encoder loop as suggested by Daniel Vetter. Signed-off-by: Egbert Eich Reviewed-by: Daniel Vetter Cc: Jani Nikula Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 0779b0c8d8a87b1f8a3bdee9a7c3b14e90c197ce Author: Daniel Vetter Date: Thu Apr 24 12:03:17 2014 +0200 drm/i915: Don't WARN nor handle unexpected hpd interrupts on gmch platforms commit 3ff04a160a891e56cdcee5c198d4c764d1c8c78b upstream. The status bits are unconditionally set, the control bits only enable the actual interrupt generation. Which means if we get some random other interrupts we'll bogusly complain about them. So restrict the WARN to platforms with a sane hotplug interrupt handling scheme. And even more important also don't attempt to process the hpd bit since we've detected a storm already. Instead just clear the bit silently. This WARN has been introduced in commit b8f102e8bf71cacf33326360fdf9dcfd1a63925b Author: Egbert Eich Date: Fri Jul 26 14:14:24 2013 +0200 drm/i915: Add messages useful for HPD storm detection debugging (v2) before that we silently handled the hpd event and so partially defeated the storm detection. v2: Pimp commit message (Jani) Cc: Jani Nikula Cc: Egbert Eich Cc: bitlord Reported-by: bitlord Signed-off-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 3991cd6eb52b67ff57b9531dcf48f496bad28146 Author: Daniel Vetter Date: Sun Apr 13 12:00:33 2014 +0200 drm/i915: Don't check gmch state on inherited configs commit 9953599bc02dbc1d3330e6a0bfc6c50e9dffcac6 upstream. ... our current modeset code isn't good enough yet to handle this. The scenario is: 1. BIOS sets up a cloned config with lvds+external screen on the same pipe, e.g. pipe B. 2. We read out that state for pipe B and assign the gmch_pfit state to it. 3. The initial modeset switches the lvds to pipe A but due to lack of atomic modeset we don't recompute the config of pipe B. -> both pipes now claim (in the sw pipe config structure) to use the gmch_pfit, which just won't work. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74081 Tested-by: max Cc: Alan Stern Signed-off-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 79f09e67094e00a31f43b9f177350a88ada1dc98 Author: Ville Syrjälä Date: Thu Mar 27 11:08:45 2014 +0200 drm/i915: Allow user modes to exceed DVI 165MHz limit commit 40478455fefdc0bde24ae872c3f88d58a1b0e435 upstream. In commit commit 6375b768a9850b6154478993e5fb566fa4614a9c Author: Ville Syrjälä Date: Mon Mar 3 11:33:36 2014 +0200 drm/i915: Reject >165MHz modes w/ DVI monitors the driver started to filter out display modes which exceed the single-link DVI 165Mz dotclock limits when the monitor doesn't report itself as being HDMI compliant. The intent was to filter out all EDID derived modes that require dual-link DVI to operate since we don't support dual-link. However the patch went a bit too far and also causes the driver to reject such modes even when specified by the user. Normally we don't check the sink limitations when setting a mode from the user. This allows the user to specify any mode whether the sink reports to support it or not. This can be useful since often the sinks support more modes than they report in the EDID. So relax the checks a bit, and apply the single-link DVI dotclock limit only when filtering the mode list, and ignore the limit when setting a user specified mode. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=72961 Tested-by: Nicholas Vinson Reviewed-by: Daniel Vetter Signed-off-by: Ville Syrjälä Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit ecf253254253bebd4ee5456f9cf038ac647002c8 Author: Neil Greatorex Date: Fri Apr 18 14:19:49 2014 +0200 irqchip: armada-370-xp: Fix releasing of MSIs commit ff3c664505bf8a8334bca5045e87b85cfe4d2277 upstream. Store the value of d->hwirq in a local variable as the real value is wiped out by calling irq_dispose_mapping. Without this patch, the armada_370_xp_free_msi function would always free MSI#0, no matter what was passed to it. Fixes: 31f614edb726fcc4d5aa0f2895fbdec9b04a3ca4 ('irqchip: armada-370-xp: implement MSI support') Signed-off-by: Neil Greatorex Link: https://lkml.kernel.org/r/1397823593-1932-4-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Thomas Petazzoni Link: https://lkml.kernel.org/r/1397823593-1932-4-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper Signed-off-by: Greg Kroah-Hartman commit 12a4de881cd646f8c594e0b70df8ce4c9117969c Author: Thomas Petazzoni Date: Fri Apr 18 14:19:48 2014 +0200 irqchip: armada-370-xp: implement the ->check_device() msi_chip operation commit 830cbe4b7a918613276aa3d3b28d24410623f92c upstream. Until now, we were leaving the ->check_device() msi_chip operation empty, which leads the PCI core to believe that we support both MSI and MSI-X. In fact, we do not support MSI-X, so we have to tell this to the PCI core by providing an implementation of this operation. Fixes: 31f614edb726fcc4d5aa0f2895fbdec9b04a3ca4 ('irqchip: armada-370-xp: implement MSI support') Signed-off-by: Thomas Petazzoni Link: https://lkml.kernel.org/r/1397823593-1932-3-git-send-email-thomas.petazzoni@free-electrons.com Tested-by: Neil Greatorex Signed-off-by: Jason Cooper Signed-off-by: Greg Kroah-Hartman commit 338187da0dbc36fa9bbe955694413befdda863d5 Author: Thomas Petazzoni Date: Fri Apr 18 14:19:47 2014 +0200 irqchip: armada-370-xp: fix invalid cast of signed value into unsigned variable commit da343fc776e0bcb238b65d9d24610819b95d0ef4 upstream. The armada_370_xp_alloc_msi() function returns a signed int, which is negative on error. However, we store the return value into an irq_hw_number_t, which is unsigned. Therefore, we actually never test if armada_370_xp_alloc_msi() returns an error or not, which may lead us to use hwirq numbers of as 0xffffffe4 (when armada_370_xp_alloc_msi() returns -ENOSPC). This commit fixes that by storing the return value of armada_370_xp_alloc_msi() in a signed variable. Fixes: 31f614edb726fcc4d5aa0f2895fbdec9b04a3ca4 ('irqchip: armada-370-xp: implement MSI support') Signed-off-by: Thomas Petazzoni Link: https://lkml.kernel.org/r/1397823593-1932-2-git-send-email-thomas.petazzoni@free-electrons.com Tested-by: Neil Greatorex Signed-off-by: Jason Cooper Signed-off-by: Greg Kroah-Hartman commit 92c2df53a32daea0cc2c98d377bf4a5be8c7d934 Author: Kieran Clancy Date: Wed Apr 30 00:21:20 2014 +0930 ACPI / EC: Process rather than discard events in acpi_ec_clear commit 3eba563e280101209bad27d40bfc83ddf1489234 upstream. Address a regression caused by commit ad332c8a4533: (ACPI / EC: Clear stale EC events on Samsung systems) After the earlier patch, there was found to be a race condition on some earlier Samsung systems (N150/N210/N220). The function acpi_ec_clear was sometimes discarding a new EC event before its GPE was triggered by the system. In the case of these systems, this meant that the "lid open" event was not registered on resume if that was the cause of the wake, leading to problems when attempting to close the lid to suspend again. After testing on a number of Samsung systems, both those affected by the previous EC bug and those affected by the race condition, it seemed that the best course of action was to process rather than discard the events. On Samsung systems which accumulate stale EC events, there does not seem to be any adverse side-effects of running the associated _Q methods. This patch adds an argument to the static function acpi_ec_sync_query so that it may be used within the acpi_ec_clear loop in place of acpi_ec_query_unlocked which was used previously. With thanks to Stefan Biereigel for reporting the issue, and for all the people who helped test the new patch on affected systems. Fixes: ad332c8a4533 (ACPI / EC: Clear stale EC events on Samsung systems) References: https://lkml.kernel.org/r/532FE3B2.9060808@biereigel-wb.de References: https://bugzilla.kernel.org/show_bug.cgi?id=44161#c173 Reported-by: Stefan Biereigel Signed-off-by: Kieran Clancy Tested-by: Stefan Biereigel Tested-by: Dennis Jansen Tested-by: Nicolas Porcel Tested-by: Maurizio D'Addona Tested-by: Juan Manuel Cabo Tested-by: Giannis Koutsou Tested-by: Kieran Clancy Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit b4f4e365642929fe45616bf2d3c79baf81dbf8b4 Author: Rafael J. Wysocki Date: Wed Apr 30 22:36:33 2014 +0200 PNP / ACPI: Do not return errors if _DIS or _SRS are not present commit a8d22396302b7e4e5f0a594c1c1594388c29edaf upstream. The ACPI PNP subsystem returns errors from pnpacpi_set_resources() and pnpacpi_disable_resources() if the _SRS or _DIS methods are not present, respectively, but it should not do that, because those methods are optional. For this reason, modify pnpacpi_set_resources() and pnpacpi_disable_resources(), respectively, to ignore missing _SRS or _DIS. This problem has been uncovered by commit 202317a573b2 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace) and manifested itself by causing serial port suspend to fail on some systems. Fixes: 202317a573b2 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace) References: https://bugzilla.kernel.org/show_bug.cgi?id=74371 Reported-by: wxg4net Reported-and-tested-by: Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 0bc4091108e8f2e65faef3082e5261f2c35cd2b4 Author: NeilBrown Date: Tue May 6 09:36:08 2014 +1000 md: avoid possible spinning md thread at shutdown. commit 0f62fb220aa4ebabe8547d3a9ce4a16d3c045f21 upstream. If an md array with externally managed metadata (e.g. DDF or IMSM) is in use, then we should not set safemode==2 at shutdown because: 1/ this is ineffective: user-space need to be involved in any 'safemode' handling, 2/ The safemode management code doesn't cope with safemode==2 on external metadata and md_check_recover enters an infinite loop. Even at shutdown, an infinite-looping process can be problematic, so this could cause shutdown to hang. Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 8c7311a1c4a8d804bde91b00a2f2c1a22a954c30 Author: NeilBrown Date: Mon May 5 13:34:37 2014 +1000 md/raid10: call wait_barrier() for each request submitted. commit cc13b1d1500656a20e41960668f3392dda9fa6e2 upstream. wait_barrier() includes a counter, so we must call it precisely once (unless balanced by allow_barrier()) for each request submitted. Since commit 20d0189b1012a37d2533a87fb451f7852f2418d1 block: Introduce new bio_split() in 3.14-rc1, we don't call it for the extra requests generated when we need to split a bio. When this happens the counter goes negative, any resync/recovery will never start, and "mdadm --stop" will hang. Reported-by: Chris Murphy Fixes: 20d0189b1012a37d2533a87fb451f7852f2418d1 Cc: Kent Overstreet Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit f9556c35b5b7ce5b50a0490c2b93c88af92df648 Author: Mike Snitzer Date: Thu May 1 16:14:24 2014 -0400 dm cache: fix writethrough mode quiescing in cache_map commit 131cd131a9ff63d4b84f3fe15073a2984ac30066 upstream. Commit 2ee57d58735 ("dm cache: add passthrough mode") inadvertently removed the deferred set reference that was taken in cache_map()'s writethrough mode support. Restore taking this reference. This issue was found with code inspection. Signed-off-by: Mike Snitzer Acked-by: Joe Thornber Signed-off-by: Greg Kroah-Hartman commit c80498a9f6b91d35bc6b6dfd185886d8d4346d43 Author: Milan Broz Date: Mon Apr 14 22:02:30 2014 +0200 dm verity: fix biovecs hash calculation regression commit 3a7745215e7f73a5c7d9bcdc50661a55b39052a3 upstream. Commit 003b5c5719f159f4f4bf97511c4702a0638313dd ("block: Convert drivers to immutable biovecs") incorrectly converted biovec iteration in dm-verity to always calculate the hash from a full biovec, but the function only needs to calculate the hash from part of the biovec (up to the calculated "todo" value). Fix this issue by limiting hash input to only the requested data size. This problem was identified using the cryptsetup regression test for veritysetup (verity-compat-test). Signed-off-by: Milan Broz Acked-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 14f7702f692048e1426d763457a34cb02e5c4267 Author: Viresh Kumar Date: Mon May 12 13:42:29 2014 +0530 hrtimer: Set expiry time before switch_hrtimer_base() commit 84ea7fe37908254c3bd90910921f6e1045c1747a upstream. switch_hrtimer_base() calls hrtimer_check_target() which ensures that we do not migrate a timer to a remote cpu if the timer expires before the current programmed expiry time on that remote cpu. But __hrtimer_start_range_ns() calls switch_hrtimer_base() before the new expiry time is set. So the sanity check in hrtimer_check_target() is operating on stale or even uninitialized data. Update expiry time before calling switch_hrtimer_base(). [ tglx: Rewrote changelog once again ] Signed-off-by: Viresh Kumar Cc: linaro-kernel@lists.linaro.org Cc: linaro-networking@linaro.org Cc: fweisbec@gmail.com Cc: arvind.chauhan@arm.com Link: http://lkml.kernel.org/r/81999e148745fc51bbcd0615823fbab9b2e87e23.1399882253.git.viresh.kumar@linaro.org Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit a975e06b60d48007642a622ca17883003cc3a90f Author: Leon Ma Date: Wed Apr 30 16:43:10 2014 +0800 hrtimer: Prevent remote enqueue of leftmost timers commit 012a45e3f4af68e86d85cce060c6c2fed56498b2 upstream. If a cpu is idle and starts an hrtimer which is not pinned on that same cpu, the nohz code might target the timer to a different cpu. In the case that we switch the cpu base of the timer we already have a sanity check in place, which determines whether the timer is earlier than the current leftmost timer on the target cpu. In that case we enqueue the timer on the current cpu because we cannot reprogram the clock event device on the target. If the timers base is already the target CPU we do not have this sanity check in place so we enqueue the timer as the leftmost timer in the target cpus rb tree, but we cannot reprogram the clock event device on the target cpu. So the timer expires late and subsequently prevents the reprogramming of the target cpu clock event device until the previously programmed event fires or a timer with an earlier expiry time gets enqueued on the target cpu itself. Add the same target check as we have for the switch base case and start the timer on the current cpu if it would become the leftmost timer on the target. [ tglx: Rewrote subject and changelog ] Signed-off-by: Leon Ma Link: http://lkml.kernel.org/r/1398847391-5994-1-git-send-email-xindong.ma@intel.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 149c874163b1e5f13e46f8a87b1e69fa7b613b92 Author: Stuart Hayes Date: Tue Apr 29 17:55:02 2014 -0500 hrtimer: Prevent all reprogramming if hang detected commit 6c6c0d5a1c949d2e084706f9e5fb1fccc175b265 upstream. If the last hrtimer interrupt detected a hang it sets hang_detected=1 and programs the clock event device with a delay to let the system make progress. If hang_detected == 1, we prevent reprogramming of the clock event device in hrtimer_reprogram() but not in hrtimer_force_reprogram(). This can lead to the following situation: hrtimer_interrupt() hang_detected = 1; program ce device to Xms from now (hang delay) We have two timers pending: T1 expires 50ms from now T2 expires 5s from now Now T1 gets canceled, which causes hrtimer_force_reprogram() to be invoked, which in turn programs the clock event device to T2 (5 seconds from now). Any hrtimer_start after that will not reprogram the hardware due to hang_detected still being set. So we effectivly block all timers until the T2 event fires and cleans up the hang situation. Add a check for hang_detected to hrtimer_force_reprogram() which prevents the reprogramming of the hang delay in the hardware timer. The subsequent hrtimer_interrupt will resolve all outstanding issues. [ tglx: Rewrote subject and changelog and fixed up the comment in hrtimer_force_reprogram() ] Signed-off-by: Stuart Hayes Link: http://lkml.kernel.org/r/53602DC6.2060101@gmail.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 1636737609d52bc1560bf8189f4d897c9c8c03f4 Author: Grant Likely Date: Tue Apr 29 12:05:22 2014 +0100 drivercore: deferral race condition fix commit 58b116bce13612e5aa6fcd49ecbd4cf8bb59e835 upstream. When the kernel is built with CONFIG_PREEMPT it is possible to reach a state when all modules loaded but some driver still stuck in the deferred list and there is a need for external event to kick the deferred queue to probe these drivers. The issue has been observed on embedded systems with CONFIG_PREEMPT enabled, audio support built as modules and using nfsroot for root filesystem. The following log fragment shows such sequence when all audio modules were loaded but the sound card is not present since the machine driver has failed to probe due to missing dependency during it's probe. The board is am335x-evmsk (McASP<->tlv320aic3106 codec) with davinci-evm machine driver: ... [ 12.615118] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: ENTER [ 12.719969] davinci_evm sound.3: davinci_evm_probe: ENTER [ 12.725753] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card [ 12.753846] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component [ 12.922051] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component DONE [ 12.950839] davinci_evm sound.3: ASoC: platform (null) not registered [ 12.957898] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card DONE (-517) [ 13.099026] davinci-mcasp 4803c000.mcasp: Kicking the deferred list [ 13.177838] davinci-mcasp 4803c000.mcasp: really_probe: probe_count = 2 [ 13.194130] davinci_evm sound.3: snd_soc_register_card failed (-517) [ 13.346755] davinci_mcasp_driver_init: LEAVE [ 13.377446] platform sound.3: Driver davinci_evm requests probe deferral [ 13.592527] platform sound.3: really_probe: probe_count = 0 In the log the machine driver enters it's probe at 12.719969 (this point it has been removed from the deferred lists). McASP driver already executing it's probing (since 12.615118). The machine driver tries to construct the sound card (12.950839) but did not found one of the components so it fails. After this McASP driver registers all the ASoC components (the machine driver still in it's probe function after it failed to construct the card) and the deferred work is prepared at 13.099026 (note that this time the machine driver is not in the lists so it is not going to be handled when the work is executing). Lastly the machine driver exit from it's probe and the core places it to the deferred list but there will be no other driver going to load and the deferred queue is not going to be kicked again - till we have external event like connecting USB stick, etc. The proposed solution is to try the deferred queue once more when the last driver is asking for deferring and we had drivers loaded while this last driver was probing. This way we can avoid drivers stuck in the deferred queue. Signed-off-by: Grant Likely Reviewed-by: Peter Ujfalusi Tested-by: Peter Ujfalusi Acked-by: Greg Kroah-Hartman Cc: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 0bdedaf41a797458aa4ed3c73004f0658af760fa Author: Josef Gajdusek Date: Mon May 12 13:48:26 2014 +0200 hwmon: (emc1403) Support full range of known chip revision numbers commit 3a18e1398fc2dc9c32bbdc50664da3a77959a8d1 upstream. The datasheet for EMC1413/EMC1414, which is fully compatible to EMC1403/1404 and uses the same chip identification, references revision numbers 0x01, 0x03, and 0x04. Accept the full range of revision numbers from 0x01 to 0x04 to make sure none are missed. Signed-off-by: Josef Gajdusek [Guenter Roeck: Updated headline and description] Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 5b532284ae769ee07b5f9592b1888da9336fca18 Author: Jean Delvare Date: Mon May 12 11:44:51 2014 +0200 hwmon: (emc1403) Fix resource leak on module unload commit 8759f9046550f463098148bf577ccd32cdb895e3 upstream. Commit 454aee17f claims to convert driver emc1403 to use devm_hwmon_device_register_with_groups, however the patch itself makes use of hwmon_device_register_with_groups instead. As the driver remove function was still dropped, the hwmon device is no longer unregistered on driver removal, leading to a resource leak. Signed-off-by: Jean Delvare Fixes: 454aee17f hwmon: (emc1403) Convert to use devm_hwmon_device_register_with_groups Cc: Guenter Roeck Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 0b86a50c92e0118117224d57a9b4aa79d33d98b0 Author: Josef Gajdusek Date: Sun May 11 14:40:44 2014 +0200 hwmon: (emc1403) fix inverted store_hyst() commit 17c048fc4bd95efea208a1920f169547d8588f1f upstream. Attempts to set the hysteresis value to a temperature below the target limit fails with "write error: Numerical result out of range" due to an inverted comparison. Signed-off-by: Josef Gajdusek Reviewed-by: Jean Delvare [Guenter Roeck: Updated headline and description] Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit f35f0047951663702d21e430c9e986a22c4ddd69 Author: Guenter Roeck Date: Wed Apr 30 14:08:14 2014 -0700 Revert "hwmon: (coretemp) Refine TjMax detection" commit c0940e95f7a78be0525c8d31df0b1f71e149e57e upstream. This reverts commit 9fb6c9c73b11bef65ba80a362547fd116c1e1c9d. Tjmax on some Intel CPUs is below 85 degrees C. One known example is L5630 with Tjmax of 71 degrees C. There are other Xeon processors with Tjmax of 70 or 80 degrees C. Also, the Intel IA32 System Programming document states that the temperature target is in bits 23:16 of MSR 0x1a2 (MSR_TEMPERATURE_TARGET), which is 8 bits, not 7. So even if turbostat uses similar checks to validate Tjmax, there is no evidence that the checks are actually required. On the contrary, the checks are known to cause problems and therefore need to be removed. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=75071. Fixes: 9fb6c9c hwmon: (coretemp) Refine TjMax detection Reviewed-by: Jean Delvare Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 43cbcb5be20cb6f61833bd596c0f74f6c8cc048c Author: Rusty Russell Date: Mon Apr 28 11:05:43 2014 +0930 module: remove warning about waiting module removal. commit 79465d2fd48e68940c2bdecddbdecd45bbba06fe upstream. We remove the waiting module removal in commit 3f2b9c9cdf38 (September 2013), but it turns out that modprobe in kmod (< version 16) was asking for waiting module removal. No one noticed since modprobe would check for 0 usage immediately before trying to remove the module, and the race is unlikely. However, it means that anyone running old (but not ancient) kmod versions is hitting the printk designed to see if anyone was running "rmmod -w". All reports so far have been false positives, so remove the warning. Fixes: 3f2b9c9cdf389e303b2273679af08aab5f153517 Reported-by: Valerio Vanni Cc: Elliott, Robert (Server Storage) Acked-by: Lucas De Marchi Signed-off-by: Rusty Russell Signed-off-by: Greg Kroah-Hartman commit 991d867488c63cf76138596a96147839f9975989 Author: Leon Yu Date: Thu May 1 03:31:28 2014 +0000 aio: fix potential leak in aio_run_iocb(). commit 754320d6e166d3a12cb4810a452bde00afbd4e9a upstream. iovec should be reclaimed whenever caller of rw_copy_check_uvector() returns, but it doesn't hold when failure happens right after aio_setup_vectored_rw(). Fix that in a such way to avoid hairy goto. Signed-off-by: Leon Yu Signed-off-by: Benjamin LaHaise Signed-off-by: Greg Kroah-Hartman commit 53937890848b0e9552be2119ad49823cfb9c5eb9 Author: Johannes Berg Date: Wed Mar 19 18:36:39 2014 +0100 iwlwifi: mvm: delay enabling smart FIFO until after beacon RX commit 0229cdafb6f67064a217591d48b0f6abf14e8385 upstream. If we have no beacon data before association, delay smart FIFO enablement until after we have this data. Not doing so can cause association failures in extremely silent environments (usually only a shielded box/room) as beacon RX is not sent to the host immediately, and then the association time event ends without the host receiving any beacon even though it was on the air - it's just stuck on the FIFO. Fixes: 1f3b0ff8ecce ("iwlwifi: mvm: Add Smart FIFO support") Signed-off-by: Johannes Berg Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit 54a2ab1efaf5d35d68143a9c0f652955ad16eb82 Author: Chen Yucong Date: Thu May 22 11:54:15 2014 -0700 hwpoison, hugetlb: lock_page/unlock_page does not match for handling a free hugepage commit b985194c8c0a130ed155b71662e39f7eaea4876f upstream. For handling a free hugepage in memory failure, the race will happen if another thread hwpoisoned this hugepage concurrently. So we need to check PageHWPoison instead of !PageHWPoison. If hwpoison_filter(p) returns true or a race happens, then we need to unlock_page(hpage). Signed-off-by: Chen Yucong Reviewed-by: Naoya Horiguchi Tested-by: Naoya Horiguchi Reviewed-by: Andi Kleen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7c5a5a8a48bc22f7df51c1d78f595b411a447a0f Author: Mark Salter Date: Thu May 15 15:19:22 2014 +0100 arm64: fix pud_huge() for 2-level pagetables commit 4797ec2dc83a43be35bad56037d1b53db9e2b5d5 upstream. The following happens when trying to run a kvm guest on a kernel configured for 64k pages. This doesn't happen with 4k pages: BUG: failure at include/linux/mm.h:297/put_page_testzero()! Kernel panic - not syncing: BUG! CPU: 2 PID: 4228 Comm: qemu-system-aar Tainted: GF 3.13.0-0.rc7.31.sa2.k32v1.aarch64.debug #1 Call trace: [] dump_backtrace+0x0/0x16c [] show_stack+0x14/0x1c [] dump_stack+0x84/0xb0 [] panic+0xf4/0x220 [] free_reserved_area+0x0/0x110 [] free_pages+0x50/0x88 [] kvm_free_stage2_pgd+0x30/0x40 [] kvm_arch_destroy_vm+0x18/0x44 [] kvm_put_kvm+0xf0/0x184 [] kvm_vm_release+0x10/0x1c [] __fput+0xb0/0x288 [] ____fput+0xc/0x14 [] task_work_run+0xa8/0x11c [] do_notify_resume+0x54/0x58 In arch/arm/kvm/mmu.c:unmap_range(), we end up doing an extra put_page() on the stage2 pgd which leads to the BUG in put_page_testzero(). This happens because a pud_huge() test in unmap_range() returns true when it should always be false with 2-level pages tables used by 64k pages. This patch removes support for huge puds if 2-level pagetables are being used. Signed-off-by: Mark Salter [catalin.marinas@arm.com: removed #ifndef around PUD_SIZE check] Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit d0cdfb253ea2c82d650ce656160ffd233bf736f5 Author: Anthony Iliopoulos Date: Wed May 14 11:29:48 2014 +0200 x86, mm, hugetlb: Add missing TLB page invalidation for hugetlb_cow() commit 9844f5462392b53824e8b86726e7c33b5ecbb676 upstream. The invalidation is required in order to maintain proper semantics under CoW conditions. In scenarios where a process clones several threads, a thread operating on a core whose DTLB entry for a particular hugepage has not been invalidated, will be reading from the hugepage that belongs to the forked child process, even after hugetlb_cow(). The thread will not see the updated page as long as the stale DTLB entry remains cached, the thread attempts to write into the page, the child process exits, or the thread gets migrated to a different processor. Signed-off-by: Anthony Iliopoulos Link: http://lkml.kernel.org/r/20140514092948.GA17391@server-36.huawei.corp Suggested-by: Shay Goikhman Acked-by: Dave Hansen Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 57a0cd815351438f7ed67a6923b33eb6cdde4986 Author: Heiko Stuebner Date: Fri May 9 15:36:57 2014 -0700 drivers/rtc/rtc-hym8563.c: set uie_unsupported commit 282cba6b00a95f0277ed71551e3f6b0477e8836b upstream. The alarm of the hym8563 only supports a minute accuracy, while the uie wants an alarm one second in the future. Therefore things like the select() syscall will fail with a timeout, because the next alarm will happen in a worst case of 60 seconds. Signed-off-by: Heiko Stuebner Cc: Alessandro Zummo Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 2bcd64e5aaa27654473ba5fbda7e6e057aa75cc8 Author: Kirill A. Shutemov Date: Fri May 9 15:37:00 2014 -0700 mm, thp: close race between mremap() and split_huge_page() commit dd18dbc2d42af75fffa60c77e0f02220bc329829 upstream. It's critical for split_huge_page() (and migration) to catch and freeze all PMDs on rmap walk. It gets tricky if there's concurrent fork() or mremap() since usually we copy/move page table entries on dup_mm() or move_page_tables() without rmap lock taken. To get it work we rely on rmap walk order to not miss any entry. We expect to see destination VMA after source one to work correctly. But after switching rmap implementation to interval tree it's not always possible to preserve expected walk order. It works fine for dup_mm() since new VMA has the same vma_start_pgoff() / vma_last_pgoff() and explicitly insert dst VMA after src one with vma_interval_tree_insert_after(). But on move_vma() destination VMA can be merged into adjacent one and as result shifted left in interval tree. Fortunately, we can detect the situation and prevent race with rmap walk by moving page table entries under rmap lock. See commit 38a76013ad80. Problem is that we miss the lock when we move transhuge PMD. Most likely this bug caused the crash[1]. [1] http://thread.gmane.org/gmane.linux.kernel.mm/96473 Fixes: 108d6642ad81 ("mm anon rmap: remove anon_vma_moveto_tail") Signed-off-by: Kirill A. Shutemov Reviewed-by: Andrea Arcangeli Cc: Rik van Riel Acked-by: Michel Lespinasse Cc: Dave Jones Cc: David Miller Acked-by: Johannes Weiner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6a12f896ce0aa2e88af62b5282b2a40488a5283e Author: Johannes Berg Date: Wed May 14 15:34:41 2014 +0200 mac80211: fix on-channel remain-on-channel commit b4b177a5556a686909e643f1e9b6434c10de079f upstream. Jouni reported that if a remain-on-channel was active on the same channel as the current operating channel, then the ROC would start, but any frames transmitted using mgmt-tx on the same channel would get delayed until after the ROC. The reason for this is that the ROC starts, but doesn't have any handling for "remain on the same channel", so it stops the interface queues. The later mgmt-tx then puts the frame on the interface queues (since it's on the current operating channel) and thus they get delayed until after the ROC. To fix this, add some logic to handle remaining on the same channel specially and not stop the queues etc. in this case. This not only fixes the bug but also improves behaviour in this case as data frames etc. can continue to flow. Reported-by: Jouni Malinen Tested-by: Jouni Malinen Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 802cb37dbc7b07bb557ca7a9817c1566e28c8d26 Author: Emmanuel Grumbach Date: Tue May 13 12:54:09 2014 +0300 mac80211: fix suspend vs. association race commit c52666aef9f2dff39276eb53f15d99e2e229870f upstream. If the association is in progress while we suspend, the stack will be in a messed up state. Clean it before we suspend. This patch completes Johannes's patch: 1a1cb744de160ee70086a77afff605bbc275d291 Author: Johannes Berg mac80211: fix suspend vs. authentication race Fixes: 12e7f517029d ("mac80211: cleanup generic suspend/resume procedures") Signed-off-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 8faa53c451ac66d604253105b2041356d723d4c1 Author: Eliad Peller Date: Wed Apr 30 16:14:24 2014 +0300 mac80211: fix nested rtnl locking on ieee80211_reconfig commit e669ba2d06c6195662601956454ac959892f0762 upstream. ieee80211_reconfig already holds rtnl, so calling cfg80211_sched_scan_stopped results in deadlock. Use the rtnl-version of this function instead. Fixes: d43c6b6 ("mac80211: reschedule sched scan after HW restart") Signed-off-by: Eliad Peller Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 853487c377bee8175103a85bb00b8d9385bd4359 Author: Eliad Peller Date: Wed Apr 30 16:14:23 2014 +0300 cfg80211: add cfg80211_sched_scan_stopped_rtnl commit 792e6aa7a15ea0fb16f8687e93caede1ea9118c7 upstream. Add locked-version for cfg80211_sched_scan_stopped. This is used for some users that might want to call it when rtnl is already locked. Fixes: d43c6b6 ("mac80211: reschedule sched scan after HW restart") Signed-off-by: Eliad Peller Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 9b36bd2727bac870fa3a4cba856af3a85af55410 Author: Eliad Peller Date: Wed Apr 30 15:58:13 2014 +0300 cfg80211: free sme on connection failures commit c1fbb258846dfc425507a093922d2d001e54c3ea upstream. cfg80211 is notified about connection failures by __cfg80211_connect_result() call. However, this function currently does not free cfg80211 sme. This results in hanging connection attempts in some cases e.g. when mac80211 authentication attempt is denied, we have this function call: ieee80211_rx_mgmt_auth() -> cfg80211_rx_mlme_mgmt() -> cfg80211_process_auth() -> cfg80211_sme_rx_auth() -> __cfg80211_connect_result() but cfg80211_sme_free() is never get called. Fixes: ceca7b712 ("cfg80211: separate internal SME implementation") Signed-off-by: Eliad Peller Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 01a6e699b573ca7b72de3339121e9872f80b49f3 Author: Ilan Peer Date: Tue Jan 14 15:17:23 2014 +0200 cfg80211: fix few minor issues in reg_process_hint() commit 772f0389338cfcf96da1c178046dc7e1649ab554 upstream. Fix the following issues in reg_process_hint(): 1. Add verification that wiphy is valid before processing NL80211_REGDOMAIN_SET_BY_COUNTRY_IE. 2. Free the request in case of invalid initiator. 3. Remove WARN_ON check on reg_request->alpha2 as it is not a pointer. Signed-off-by: Ilan Peer Signed-off-by: Johannes Berg Signed-off-by: Luis R. Rodriguez Signed-off-by: Greg Kroah-Hartman commit 87e837b6dd8f7756ac55325900ff885f1689dc71 Author: Corey Minyard Date: Mon Apr 14 09:46:52 2014 -0500 ipmi: Reset the KCS timeout when starting error recovery commit eb6d78ec213e6938559b801421d64714dafcf4b2 upstream. The OBF timer in KCS was not reset in one situation when error recovery was started, resulting in an immediate timeout. Reported-by: Bodo Stroesser Signed-off-by: Corey Minyard Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 2915ea2cf89b86347689ac2ec73922620528c3e0 Author: Bodo Stroesser Date: Mon Apr 14 09:46:51 2014 -0500 ipmi: Fix a race restarting the timer commit 48e8ac2979920ffa39117e2d725afa3a749bfe8d upstream. With recent changes it is possible for the timer handler to detect an idle interface and not start the timer, but the thread to start an operation at the same time. The thread will not start the timer in that instance, resulting in the timer not running. Instead, move all timer operations under the lock and start the timer in the thread if it detect non-idle and the timer is not already running. Moving under locks allows the last timeout to be set in both the thread and the timer. 'Timer is not running' means that the timer is not pending and smi_timeout() is not running. So we need a flag to detect this correctly. Also fix a few other timeout bugs: setting the last timeout when the interrupt has to be disabled and the timer started, and setting the last timeout in check_start_timer_thread possibly racing with the timer Signed-off-by: Corey Minyard Signed-off-by: Bodo Stroesser Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 58773757360a8e94c60ed2f04f2a12a55cb6aa51 Author: Jiri Bohac Date: Fri Apr 18 17:23:11 2014 +0200 timer: Prevent overflow in apply_slack commit 98a01e779f3c66b0b11cd7e64d531c0e41c95762 upstream. On architectures with sizeof(int) < sizeof (long), the computation of mask inside apply_slack() can be undefined if the computed bit is > 32. E.g. with: expires = 0xffffe6f5 and slack = 25, we get: expires_limit = 0x20000000e bit = 33 mask = (1 << 33) - 1 /* undefined */ On x86, mask becomes 1 and and the slack is not applied properly. On s390, mask is -1, expires is set to 0 and the timer fires immediately. Use 1UL << bit to solve that issue. Suggested-by: Deborah Townsend Signed-off-by: Jiri Bohac Link: http://lkml.kernel.org/r/20140418152310.GA13654@midget.suse.cz Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 1782fdcfcabe123bce44acdf662d92f3bb059df5 Author: Stephen Warren Date: Fri Apr 4 16:31:05 2014 -0600 gpu: host1x: handle the correct # of syncpt regs commit 22bbd5d949dc7fdd72a4e78e767fa09d8e54b446 upstream. BIT_WORD() truncates rather than rounds, so the loops in syncpt_thresh_isr() and _host1x_intr_disable_all_syncpt_intrs() use <= rather than < in an attempt to process the correct number of registers when rounding of the conversion of count of bits to count of words is necessary. However, when rounding isn't necessary because the value is already a multiple of the divisor (as is the case for all values of nb_pts the code actually sees), this causes one too many registers to be processed. Solve this by using and explicit DIV_ROUND_UP() call, rather than BIT_WORD(), and comparing with < rather than <=. Fixes: 7ede0b0bf3e2 ("gpu: host1x: Add syncpoint wait and interrupts") Signed-off-by: Stephen Warren Acked-By: Terje Bergstrom Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit f5c8ff84d9c249f28a26bb24f35ea946f754b791 Author: Emmanuel Grumbach Date: Wed Apr 9 19:27:25 2014 +0300 iwlwifi: 7000: bump API to 9 commit 431031851ea72a25abb9ad4df56a0f3b997e3026 upstream. This will allow to load the new firmware. Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit 8d9d04e946c2b4b3742fb20c98610e3109bdb478 Author: Eyal Shapira Date: Sun Apr 6 18:13:22 2014 +0300 iwlwifi: mvm: rs: reinit rs if no tx for a long time commit 87d5e4155c0088e6766b4f0193b63fa0eab71220 upstream. After being idle for a long time (>5sec) the rs statistics will be stale so we prefer to reset rs and start from legacy rates again. This gives better results when the attenuation increased signficantly (e.g. we got further from the AP) and after a while we start Tx Note that the first Tx after the idle period will still go out in the old modulation and rate but this seemed a simpler approach compared to adding a timer or modifying mac80211 for this. The negative impact is negligble as we'll recover quickly. Signed-off-by: Eyal Shapira Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit 0046274a882836ade933319d179a7e436cf5c971 Author: Eyal Shapira Date: Sun Apr 6 02:42:18 2014 +0300 iwlwifi: mvm: rs: fix and cleanup rs_get_rate_action commit e53839eb9882c99d3781eab0fe1b2d4369a6a2cc upstream. Change the down/upscale decision logic a bit to be based on different success ratio thresholds. This fixes the implementation compared to the rate scale algorithm which was planned to yield optimal results. Also fix a case where a lower rate wasn't explored despite being a potential for better throughput. While at it rewrite rs_get_rate_action to be more clear and clean. Signed-off-by: Eyal Shapira Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit bb6259d93e88d2ae7b177f2d999a51a2c4033eb9 Author: Eyal Shapira Date: Sun Apr 6 05:27:36 2014 +0300 iwlwifi: mvm: avoid searching unnecessary columns commit d8fff919ecd7820084675c2814913445e95640ac upstream. Don't search columns which are unlikely to succeed as previous columns searched with less aggressive modulation failed. Signed-off-by: Eyal Shapira Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit ee4fc7fe8684705b32414c276be038b432c3c2dc Author: Eyal Shapira Date: Sun Apr 6 04:39:23 2014 +0300 iwlwifi: mvm: rs: fallback to legacy Tx columns commit fd7dbee51b3d98402edb11fec0c93d96476e0ae1 upstream. Allow switching back to legacy Tx columns so we'll stop doing HT/VHT in case we're far from the AP. Stop active aggregation when making a deciding to stay in a legacy column. Despite having low legacy rates in the LQ table lower entries it doesn't help much in case we're doing aggregations as the aggregation was being transmitted in the initial rate of the table. This should help traffic stalls when far from the AP. Signed-off-by: Eyal Shapira Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit ce1c4e8c013a957983910fccaff8704f636e1cb0 Author: Oren Givon Date: Wed Apr 2 14:04:20 2014 +0300 iwlwifi: add new 7265 HW IDs commit 80f2679e589503bd6cbaaa1f9c1cd9dd7dfae032 upstream. Add 2 new HW IDs for the 7265 series. Signed-off-by: Oren Givon Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit 3891094e863a9238c705186ca3b082c6ee920b57 Author: Eyal Shapira Date: Tue Mar 25 10:25:44 2014 +0200 iwlwifi: mvm: rs: fix mimo delimiter in LQ cmd commit d9088f60425e0acd8a8f05fdfcfdd288d3258641 upstream. mimo_delim was always set to 0 instead of pointing to the first SISO entry after MIMO rates. This can cause keep transmitting in MIMO even when we shouldn't. For example when the peer is requesting static SMPS. Signed-off-by: Eyal Shapira Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit fcc4e85dd282735261636c17d0fac91d83c4fa57 Author: Emmanuel Grumbach Date: Mon Mar 24 22:17:15 2014 +0200 iwlwifi: add MODULE_FIRMWARE for 7265 commit 08a732f4e4a842f0101e5ea03d79e9d613ffadbe upstream. It was missing. Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman commit 6b8279034082d4b6a066041ab5889ff711227160 Author: Loic Poulain Date: Thu Apr 24 11:38:56 2014 +0200 8250_core: Fix unwanted TX chars write commit b08c9c317e3f7764a91d522cd031639ba42b98cc upstream. On transmit-hold-register empty, serial8250_tx_chars should be called only if we don't use DMA. DMA has its own tx cycle. Signed-off-by: Loic Poulain Reviewed-by: Heikki Krogerus Signed-off-by: Greg Kroah-Hartman commit 7d056f1066bd1d677273e3db285e00f0fd80674d Author: Loic Poulain Date: Thu Apr 24 11:34:48 2014 +0200 serial: 8250: Fix thread unsafe __dma_tx_complete function commit f8fd1b0350d3a4581125f5eda6528f5a2c5f9183 upstream. __dma_tx_complete is not protected against concurrent call of serial8250_tx_dma. it can lead to circular tail index corruption or parallel call of serial_tx_dma on the same data portion. This patch fixes this issue by holding the port lock. Signed-off-by: Loic Poulain Reviewed-by: Heikki Krogerus Signed-off-by: Greg Kroah-Hartman commit e83c667a1f451b1ae47a27d5e2ef0acb5f2c5b3d Author: Linus Torvalds Date: Tue Apr 22 13:49:40 2014 -0700 mm: make fixup_user_fault() check the vma access rights too commit 1b17844b29ae042576bea588164f2f1e9590a8bc upstream. fixup_user_fault() is used by the futex code when the direct user access fails, and the futex code wants it to either map in the page in a usable form or return an error. It relied on handle_mm_fault() to map the page, and correctly checked the error return from that, but while that does map the page, it doesn't actually guarantee that the page will be mapped with sufficient permissions to be then accessed. So do the appropriate tests of the vma access rights by hand. [ Side note: arguably handle_mm_fault() could just do that itself, but we have traditionally done it in the caller, because some callers - notably get_user_pages() - have been able to access pages even when they are mapped with PROT_NONE. Maybe we should re-visit that design decision, but in the meantime this is the minimal patch. ] Found by Dave Jones running his trinity tool. Reported-by: Dave Jones Acked-by: Hugh Dickins Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ef4c3729e2561dd90c2faaa05309f3419d271a99 Author: Vincent Stehlé Date: Fri Apr 4 08:43:18 2014 +0200 topology: Fix compilation warning when not in SMP commit 53974e06603977f348ed978d75c426b0532daa67 upstream. The topology_##name() macro does not use its argument when CONFIG_SMP is not set, as it ultimately calls the cpu_data() macro. So we avoid maintaining a possibly unused `cpu' variable, to avoid the following compilation warning: drivers/base/topology.c: In function ‘show_physical_package_id’: drivers/base/topology.c:103:118: warning: unused variable ‘cpu’ [-Wunused-variable] define_id_show_func(physical_package_id); drivers/base/topology.c: In function ‘show_core_id’: drivers/base/topology.c:106:106: warning: unused variable ‘cpu’ [-Wunused-variable] define_id_show_func(core_id); This can be seen with e.g. x86 defconfig and CONFIG_SMP not set. Signed-off-by: Vincent Stehlé Signed-off-by: Greg Kroah-Hartman commit e616309ecae3499d452bcd1e83801063ccefccc8 Author: Eric Dumazet Date: Sat Apr 19 10:15:07 2014 -0700 coredump: fix va_list corruption commit 404ca80eb5c2727d78cd517d12108b040c522e12 upstream. A va_list needs to be copied in case it needs to be used twice. Thanks to Hugh for debugging this issue, leading to various panics. Tested: lpq84:~# echo "|/foobar12345 %h %h %h %h %h %h %h %h %h %h %h %h %h %h %h %h %h %h %h %h" >/proc/sys/kernel/core_pattern 'produce_core' is simply : main() { *(int *)0 = 1;} lpq84:~# ./produce_core Segmentation fault (core dumped) lpq84:~# dmesg | tail -1 [ 614.352947] Core dump to |/foobar12345 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 (null) pipe failed Notice the last argument was replaced by a NULL (we were lucky enough to not crash, but do not try this on your production machine !) After fix : lpq83:~# echo "|/foobar12345 %h %h %h %h %h %h %h %h %h %h %h %h %h %h %h %h %h %h %h %h" >/proc/sys/kernel/core_pattern lpq83:~# ./produce_core Segmentation fault lpq83:~# dmesg | tail -1 [ 740.800441] Core dump to |/foobar12345 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 pipe failed Fixes: 5fe9d8ca21cc ("coredump: cn_vprintf() has no reason to call vsnprintf() twice") Signed-off-by: Eric Dumazet Diagnosed-by: Hugh Dickins Acked-by: Oleg Nesterov Cc: Neil Horman Cc: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 73f13bc7127d93951d776821589c5108fc285842 Author: Bartlomiej Zolnierkiewicz Date: Mon Mar 31 19:51:14 2014 +0200 pata_at91: fix ata_host_activate() failure handling commit 27aa64b9d1bd0d23fd692c91763a48309b694311 upstream. Add missing clk_put() call to ata_host_activate() failure path. Sergei says, "Hm, I have once fixed that (see that *if* (!ret)) but looks like a later commit 477c87e90853d136b188c50c0e4a93d01cad872e (ARM: at91/pata: use gpio_is_valid to check the gpio) broke it again. :-( Would be good if the changelog did mention that..." Cc: Andrew Victor Cc: Nicolas Ferre Cc: Jean-Christophe Plagniol-Villard Cc: Sergei Shtylyov Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 59516f324f324b6b392b94833da3972e346c5f0c Author: Tejun Heo Date: Sun Apr 20 08:29:21 2014 -0400 kernfs: add back missing error check in kernfs_fop_mmap() commit b44b2140265ddfde03acbe809336111d31adb0d1 upstream. While updating how mmap enabled kernfs files are handled by lockdep, 9b2db6e18945 ("sysfs: bail early from kernfs_file_mmap() to avoid spurious lockdep warning") inadvertently dropped error return check from kernfs_file_mmap(). The intention was just dropping "if (ops->mmap)" check as the control won't reach the point if the mmap callback isn't implemented, but I mistakenly removed the error return check together with it. This led to Xorg crash on i810 which was reported and bisected to the commit and then to the specific change by Tobias. Signed-off-by: Tejun Heo Reported-and-bisected-by: Tobias Powalowski Tested-by: Tobias Powalowski References: http://lkml.kernel.org/g/533D01BD.1010200@googlemail.com Signed-off-by: Greg Kroah-Hartman commit ce5e2b32090d5564d4393b36b5be3b226f4ded4e Author: Krzysztof Kozlowski Date: Wed Apr 16 14:36:45 2014 +0000 clocksource: Exynos_mct: Register clock event after request_irq() commit 8db6e5104b77de5d0b7002b95069da0992a34be9 upstream. After hotplugging CPU1 the first call of interrupt handler for CPU1 oneshot timer was called on CPU0 because it fired before setting IRQ affinity. Affected are SoCs where Multi Core Timer interrupts are shared (SPI), e.g. Exynos 4210. During setup of the MCT timers the clock event device should be registered after setting the affinity for interrupt. This will prevent starting the timer too early. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Thomas Gleixner Cc: Kyungmin Park Cc: Marek Szyprowski Cc: Bartlomiej Zolnierkiewicz Cc: Tomasz Figa , Cc: Daniel Lezcano , Cc: Kukjin Kim Cc: linux-arm-kernel@lists.infradead.org, Link: http://lkml.kernel.org/r/20140416143316.299247848@linutronix.de Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 35c726c15087376c8c50b726df5b60b786e07741 Author: Thomas Gleixner Date: Wed Apr 16 14:36:45 2014 +0000 clocksource: Exynos_mct: Use irq_force_affinity() in cpu bringup commit 30ccf03b4a6a2102a2219058bdc6d779dc637dd7 upstream. The starting cpu is not yet in the online mask so irq_set_affinity() fails which results in per cpu timers for this cpu ending up on some other online cpu, ususally cpu 0. Use irq_force_affinity() which disables the online mask check and makes things work. Signed-off-by: Thomas Gleixner Tested-by: Krzysztof Kozlowski Cc: Kyungmin Park Cc: Marek Szyprowski Cc: Bartlomiej Zolnierkiewicz Cc: Tomasz Figa , Cc: Daniel Lezcano , Cc: Kukjin Kim Cc: linux-arm-kernel@lists.infradead.org, Link: http://lkml.kernel.org/r/20140416143316.106665251@linutronix.de Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 8f141082814e9f03bda4233849ae42af7504fad0 Author: Thomas Gleixner Date: Wed Apr 16 14:36:44 2014 +0000 genirq: Allow forcing cpu affinity of interrupts commit 01f8fa4f01d8362358eb90e412bd7ae18a3ec1ad upstream. The current implementation of irq_set_affinity() refuses rightfully to route an interrupt to an offline cpu. But there is a special case, where this is actually desired. Some of the ARM SoCs have per cpu timers which require setting the affinity during cpu startup where the cpu is not yet in the online mask. If we can't do that, then the local timer interrupt for the about to become online cpu is routed to some random online cpu. The developers of the affected machines tried to work around that issue, but that results in a massive mess in that timer code. We have a yet unused argument in the set_affinity callbacks of the irq chips, which I added back then for a similar reason. It was never required so it got not used. But I'm happy that I never removed it. That allows us to implement a sane handling of the above scenario. So the affected SoC drivers can add the required force handling to their interrupt chip, switch the timer code to irq_force_affinity() and things just work. This does not affect any existing user of irq_set_affinity(). Tagged for stable to allow a simple fix of the affected SoC clock event drivers. Reported-and-tested-by: Krzysztof Kozlowski Signed-off-by: Thomas Gleixner Cc: Kyungmin Park Cc: Marek Szyprowski Cc: Bartlomiej Zolnierkiewicz Cc: Tomasz Figa , Cc: Daniel Lezcano , Cc: Kukjin Kim Cc: linux-arm-kernel@lists.infradead.org, Link: http://lkml.kernel.org/r/20140416143315.717251504@linutronix.de Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit ddd07396fcb9ac740aa21794221ef6f9e3cdc31f Author: Thomas Gleixner Date: Wed Apr 16 14:36:44 2014 +0000 irqchip: Gic: Support forced affinity setting commit ffde1de64012c406dfdda8690918248b472f24e4 upstream. To support the affinity setting of per cpu timers in the early startup of a not yet online cpu, implement the force logic, which disables the cpu online check. Tagged for stable to allow a simple fix of the affected SoC clock event drivers. Signed-off-by: Thomas Gleixner Tested-by: Krzysztof Kozlowski Cc: Kyungmin Park Cc: Marek Szyprowski Cc: Bartlomiej Zolnierkiewicz Cc: Tomasz Figa , Cc: Daniel Lezcano , Cc: Kukjin Kim Cc: linux-arm-kernel@lists.infradead.org, Link: http://lkml.kernel.org/r/20140416143315.916984416@linutronix.de Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 274eb7bf1dce97dac496d7b9ded91f9de5719cf0 Author: Rob Herring Date: Wed Apr 23 17:57:41 2014 -0500 of/irq: do irq resolution in platform_get_irq commit 9ec36cafe43bf835f8f29273597a5b0cbc8267ef upstream. Currently we get the following kind of errors if we try to use interrupt phandles to irqchips that have not yet initialized: irq: no irq domain found for /ocp/pinmux@48002030 ! ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184() Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012 (show_stack+0x14/0x1c) (dump_stack+0x6c/0xa0) (warn_slowpath_common+0x64/0x84) (warn_slowpath_null+0x1c/0x24) (of_device_alloc+0x144/0x184) (of_platform_device_create_pdata+0x44/0x9c) (of_platform_bus_create+0xd0/0x170) (of_platform_bus_create+0x12c/0x170) (of_platform_populate+0x60/0x98) This is because we're wrongly trying to populate resources that are not yet available. It's perfectly valid to create irqchips dynamically, so let's fix up the issue by resolving the interrupt resources when platform_get_irq is called. And then we also need to accept the fact that some irqdomains do not exist that early on, and only get initialized later on. So we can make the current WARN_ON into just into a pr_debug(). We still attempt to populate irq resources when we create the devices. This allows current drivers which don't use platform_get_irq to continue to function. Once all drivers are fixed, this code can be removed. Suggested-by: Russell King Signed-off-by: Rob Herring Signed-off-by: Tony Lindgren Tested-by: Tony Lindgren Signed-off-by: Grant Likely Signed-off-by: Greg Kroah-Hartman commit d9550cf732c439447abe24655c23fcc27915ff7d Author: Steven Rostedt (Red Hat) Date: Thu Apr 24 10:40:12 2014 -0400 ftrace/module: Hardcode ftrace_module_init() call into load_module() commit a949ae560a511fe4e3adf48fa44fefded93e5c2b upstream. A race exists between module loading and enabling of function tracer. CPU 1 CPU 2 ----- ----- load_module() module->state = MODULE_STATE_COMING register_ftrace_function() mutex_lock(&ftrace_lock); ftrace_startup() update_ftrace_function(); ftrace_arch_code_modify_prepare() set_all_module_text_rw(); ftrace_arch_code_modify_post_process() set_all_module_text_ro(); [ here all module text is set to RO, including the module that is loading!! ] blocking_notifier_call_chain(MODULE_STATE_COMING); ftrace_init_module() [ tries to modify code, but it's RO, and fails! ftrace_bug() is called] When this race happens, ftrace_bug() will produces a nasty warning and all of the function tracing features will be disabled until reboot. The simple solution is to treate module load the same way the core kernel is treated at boot. To hardcode the ftrace function modification of converting calls to mcount into nops. This is done in init/main.c there's no reason it could not be done in load_module(). This gives a better control of the changes and doesn't tie the state of the module to its notifiers as much. Ftrace is special, it needs to be treated as such. The reason this would work, is that the ftrace_module_init() would be called while the module is in MODULE_STATE_UNFORMED, which is ignored by the set_all_module_text_ro() call. Link: http://lkml.kernel.org/r/1395637826-3312-1-git-send-email-indou.takao@jp.fujitsu.com Reported-by: Takao Indoh Acked-by: Rusty Russell Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit bb4d8694e07076c8f905d475adb5b68feef06649 Author: Thomas Gleixner Date: Thu May 22 03:25:39 2014 +0000 rtmutex: Fix deadlock detector for real commit 397335f004f41e5fcf7a795e94eb3ab83411a17c upstream. The current deadlock detection logic does not work reliably due to the following early exit path: /* * Drop out, when the task has no waiters. Note, * top_waiter can be NULL, when we are in the deboosting * mode! */ if (top_waiter && (!task_has_pi_waiters(task) || top_waiter != task_top_pi_waiter(task))) goto out_unlock_pi; So this not only exits when the task has no waiters, it also exits unconditionally when the current waiter is not the top priority waiter of the task. So in a nested locking scenario, it might abort the lock chain walk and therefor miss a potential deadlock. Simple fix: Continue the chain walk, when deadlock detection is enabled. We also avoid the whole enqueue, if we detect the deadlock right away (A-A). It's an optimization, but also prevents that another waiter who comes in after the detection and before the task has undone the damage observes the situation and detects the deadlock and returns -EDEADLOCK, which is wrong as the other task is not in a deadlock situation. Signed-off-by: Thomas Gleixner Cc: Peter Zijlstra Reviewed-by: Steven Rostedt Cc: Lai Jiangshan Link: http://lkml.kernel.org/r/20140522031949.725272460@linutronix.de Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit d2790a6a61111f956dc9cea2c1450508b583e38f Author: Leif Lindholm Date: Thu Apr 17 18:42:00 2014 +0100 mips: dts: Fix missing device_type="memory" property in memory nodes commit dfc44f8030653b345fc6fb337558c3a07536823f upstream. A few platforms lack a 'device_type = "memory"' for their memory nodes, relying on an old ppc quirk in order to discover its memory. Add the missing data so that all parsing code can find memory nodes correctly. Signed-off-by: Leif Lindholm Cc: linux-mips@linux-mips.org Cc: devicetree@vger.kernel.org Cc: Mark Rutland Acked-by: John Crispin Signed-off-by: Grant Likely Signed-off-by: Greg Kroah-Hartman commit 4236d29b5fc3e32a6c00ddf7ccf53ce5786730a8 Author: Aaro Koskinen Date: Thu Apr 3 22:24:01 2014 +0300 MIPS/loongson2_cpufreq: Fix CPU clock rate setting commit 8e8acb32960f42c81b1d50deac56a2c07bb6a18a upstream. Loongson2 has been using (incorrectly) kHz for cpu_clk rate. This has been unnoticed, as loongson2_cpufreq was the only place where the rate was set/get. After commit 652ed95d5fa6074b3c4ea245deb0691f1acb6656 (cpufreq: introduce cpufreq_generic_get() routine) things however broke, and now loops_per_jiffy adjustments are incorrect (1000 times too long). The patch fixes this by changing cpu_clk rate to Hz. Signed-off-by: Aaro Koskinen Cc: Rafael J. Wysocki Cc: Viresh Kumar Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: cpufreq@vger.kernel.org Cc: Aaro Koskinen Patchwork: https://patchwork.linux-mips.org/patch/6678/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 7c3b5654c06c68470c446f96c6ba9b939c67771e Author: Thomas Gleixner Date: Mon May 12 20:45:35 2014 +0000 futex: Prevent attaching to kernel threads commit f0d71b3dcb8332f7971b5f2363632573e6d9486a upstream. We happily allow userspace to declare a random kernel thread to be the owner of a user space PI futex. Found while analysing the fallout of Dave Jones syscall fuzzer. We also should validate the thread group for private futexes and find some fast way to validate whether the "alleged" owner has RW access on the file which backs the SHM, but that's a separate issue. Signed-off-by: Thomas Gleixner Cc: Dave Jones Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Darren Hart Cc: Davidlohr Bueso Cc: Steven Rostedt Cc: Clark Williams Cc: Paul McKenney Cc: Lai Jiangshan Cc: Roland McGrath Cc: Carlos ODonell Cc: Jakub Jelinek Cc: Michael Kerrisk Cc: Sebastian Andrzej Siewior Link: http://lkml.kernel.org/r/20140512201701.194824402@linutronix.de Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit efcd089d4786faba8753d625419fff13b84cd0be Author: Thomas Gleixner Date: Mon May 12 20:45:34 2014 +0000 futex: Add another early deadlock detection check commit 866293ee54227584ffcb4a42f69c1f365974ba7f upstream. Dave Jones trinity syscall fuzzer exposed an issue in the deadlock detection code of rtmutex: http://lkml.kernel.org/r/20140429151655.GA14277@redhat.com That underlying issue has been fixed with a patch to the rtmutex code, but the futex code must not call into rtmutex in that case because - it can detect that issue early - it avoids a different and more complex fixup for backing out If the user space variable got manipulated to 0x80000000 which means no lock holder, but the waiters bit set and an active pi_state in the kernel is found we can figure out the recursive locking issue by looking at the pi_state owner. If that is the current task, then we can safely return -EDEADLK. The check should have been added in commit 59fa62451 (futex: Handle futex_pi OWNER_DIED take over correctly) already, but I did not see the above issue caused by user space manipulation back then. Signed-off-by: Thomas Gleixner Cc: Dave Jones Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Darren Hart Cc: Davidlohr Bueso Cc: Steven Rostedt Cc: Clark Williams Cc: Paul McKenney Cc: Lai Jiangshan Cc: Roland McGrath Cc: Carlos ODonell Cc: Jakub Jelinek Cc: Michael Kerrisk Cc: Sebastian Andrzej Siewior Link: http://lkml.kernel.org/r/20140512201701.097349971@linutronix.de Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman