commit 058fbb1d2ef932b4b59faa79701d2a7a702acd1b Author: Ben Hutchings Date: Fri Aug 7 00:32:21 2015 +0100 Linux 3.2.70 commit 18a1b31042032ef9907da1622be8ee45efc177ea Author: Lv Zheng Date: Mon Apr 13 11:48:52 2015 +0800 ACPICA: Utilities: Cleanup to remove useless ACPI_PRINTF/FORMAT_xxx helpers. commit 1d0a0b2f6df2bf2643fadc990eb143361eca6ada upstream. ACPICA commit b60612373a4ef63b64a57c124576d7ddb6d8efb6 For physical addresses, since the address may exceed 32-bit address range after calculation, we should use 0x%8.8X%8.8X instead of ACPI_PRINTF_UINT and ACPI_FORMAT_UINT64() instead of ACPI_FORMAT_NATIVE_UINT()/ACPI_FORMAT_TO_UINT(). This patch also removes above replaced macros as there are no users. This is a preparation to switch acpi_physical_address to 64-bit on 32-bit kernel builds. Link: https://github.com/acpica/acpica/commit/b6061237 Signed-off-by: Lv Zheng Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki Signed-off-by: Dirk Behme [gdavis: Move tbprint.c changes to tbutils.c due to lack of commit "42f4786 ACPICA: Split table print utilities to a new a separate file" in linux-3.10.y] Signed-off-by: George G. Davis Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 4eba3fcab979dbb061c0e03b75ded2ff1fac0af6 Author: Lv Zheng Date: Mon Apr 13 11:48:46 2015 +0800 ACPICA: Utilities: Cleanup to convert physical address printing formats. commit cc2080b0e5a7c6c33ef5e9ffccbc2b8f6f861393 upstream. ACPICA commit 7f06739db43a85083a70371c14141008f20b2198 For physical addresses, since the address may exceed 32-bit address range after calculation, we should use %8.8X%8.8X (see ACPI_FORMAT_UINT64()) to convert the %p formats. This is a preparation to switch acpi_physical_address to 64-bit on 32-bit kernel builds. Link: https://github.com/acpica/acpica/commit/7f06739d Signed-off-by: Lv Zheng Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki Signed-off-by: Dirk Behme [gdavis: Move tbinstall.c changes to tbutils.c due to lack of commit "42f4786 ACPICA: Split table print utilities to a new a separate file" in linux-3.10.y] Signed-off-by: George G. Davis Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: - Drop inapplicable changes to drivers/acpi/acpica/utaddress.c and acpi_tb_install_table() - Fix similar format issues in acpi_tb_add_table() and acpi_tb_install_table() that aren't present upstream] Signed-off-by: Ben Hutchings commit 0e3c5ec24ca3d7c830482d38c1bc9620041a6bed Author: Bob Moore Date: Fri Aug 17 10:55:32 2012 +0800 ACPICA: Debug output: Update output for Processor object. commit 0b232fcad225c35513c9d5719613ae552abccd82 upstream. Cleanup output for Processor(). Length is a byte, not a word. Signed-off-by: Bob Moore Signed-off-by: Feng Tang Signed-off-by: Len Brown Signed-off-by: Ben Hutchings commit 405909c2d89bc29bc4b55ccbdde4a25227562e33 Author: Lv Zheng Date: Mon Apr 13 11:48:18 2015 +0800 ACPICA: Tables: Change acpi_find_root_pointer() to use acpi_physical_address. commit 85e014b4304626972bff42249556748ad3fcf812 upstream. commit f254e3c57b9d952e987502aefa0804c177dd2503 upstream. ACPICA commit 7d9fd64397d7c38899d3dc497525f6e6b044e0e3 OSPMs like Linux expect an acpi_physical_address returning value from acpi_find_root_pointer(). This triggers warnings if sizeof (acpi_size) doesn't equal to sizeof (acpi_physical_address): drivers/acpi/osl.c:275:3: warning: passing argument 1 of 'acpi_find_root_pointer' from incompatible pointer type [enabled by default] In file included from include/acpi/acpi.h:64:0, from include/linux/acpi.h:36, from drivers/acpi/osl.c:41: include/acpi/acpixf.h:433:1: note: expected 'acpi_size *' but argument is of type 'acpi_physical_address *' This patch corrects acpi_find_root_pointer(). Link: https://github.com/acpica/acpica/commit/7d9fd643 Signed-off-by: Lv Zheng Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki Signed-off-by: Dirk Behme Signed-off-by: George G. Davis Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 7402a5fe1e502c7ce5b8adc670b4dbe601ee56fa Author: Sam Ravnborg Date: Wed Apr 4 21:20:01 2012 +0200 sparc32,leon: fix leon build commit d657784b70ef653350d7aa49da90a8484c29da7d upstream. Minimal fix to allow leon to be built. Signed-off-by: Sam Ravnborg Cc: Konrad Eisele Cc: Daniel Hellstrom Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit cee9e1e861382df144a3a880f8e2c89285197a3e Author: Arnd Bergmann Date: Fri Jun 21 21:55:35 2013 +0200 staging: line6: avoid __sync_fetch_and_{and,or} commit 9f613601482c56e05884f21565e3d218fac427ae upstream. __sync_fetch_and_and and __sync_fetch_and_or are functions that are provided by gcc and depending on the target architecture may be implemented in libgcc, which is not always available in the kernel. This leads to a build failure on ARMv5: drivers/built-in.o: In function `line6_pcm_release': :(.text+0x3bfe80): undefined reference to `__sync_fetch_and_and_4' drivers/built-in.o: In function `line6_pcm_acquire': :(.text+0x3bff30): undefined reference to `__sync_fetch_and_or_4' To work around this, we can use the kernel-provided cmpxchg macro. Build-tested only. Signed-off-by: Arnd Bergmann Cc: Markus Grabner Acked-by: Randy Dunlap Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: - Adjust context - Fix up two more instances of __sync_fetch_and_and() that were removed separately upstream] Signed-off-by: Ben Hutchings commit 53774d1d22885f5bf14645baf551a3c4b6a6efba Author: John David Anglin Date: Sat Apr 20 19:41:06 2013 +0000 parisc: Provide __ucmpdi2 to resolve undefined references in 32 bit builds. commit ca0ad83da17b6ba07f9eb5902e69daac90c4fa61 upstream. The Debian experimental linux source package (3.8.5-1) build fails with the following errors: ... MODPOST 2016 modules ERROR: "__ucmpdi2" [fs/btrfs/btrfs.ko] undefined! ERROR: "__ucmpdi2" [drivers/md/dm-verity.ko] undefined! The attached patch resolves this problem. It is based on the s390 implementation of ucmpdi2.c. Signed-off-by: John David Anglin Cc: "James E.J. Bottomley" Signed-off-by: Helge Deller Signed-off-by: Ben Hutchings commit 6876b78ee008e416e3802e376cf9392e14b9c92a Author: hujianyang Date: Tue Dec 30 11:56:09 2014 +0800 UBI: fix soft lockup in ubi_check_volume() commit 9aa272b492e7551a9ee0e2c83c720ea013698485 upstream. Running mtd-utils/tests/ubi-tests/io_basic.c could cause soft lockup or watchdog reset. It is because *updatevol* will perform ubi_check_volume() after updating finish and this function will full scan the updated lebs if the volume is initialized as STATIC_VOLUME. This patch adds *cond_resched()* in the loop of lebs scan to avoid soft lockup. Helped by Richard Weinberger [ 2158.067096] INFO: rcu_sched self-detected stall on CPU { 1} (t=2101 jiffies g=1606 c=1605 q=56) [ 2158.172867] CPU: 1 PID: 2073 Comm: io_basic Tainted: G O 3.10.53 #21 [ 2158.172898] [] (unwind_backtrace+0x0/0x120) from [] (show_stack+0x10/0x14) [ 2158.172918] [] (show_stack+0x10/0x14) from [] (rcu_check_callbacks+0x1c0/0x660) [ 2158.172936] [] (rcu_check_callbacks+0x1c0/0x660) from [] (update_process_times+0x38/0x64) [ 2158.172953] [] (update_process_times+0x38/0x64) from [] (tick_sched_handle+0x54/0x60) [ 2158.172966] [] (tick_sched_handle+0x54/0x60) from [] (tick_sched_timer+0x44/0x74) [ 2158.172978] [] (tick_sched_timer+0x44/0x74) from [] (__run_hrtimer+0xc8/0x1b8) [ 2158.172992] [] (__run_hrtimer+0xc8/0x1b8) from [] (hrtimer_interrupt+0x128/0x2a4) [ 2158.173007] [] (hrtimer_interrupt+0x128/0x2a4) from [] (arch_timer_handler_virt+0x28/0x30) [ 2158.173022] [] (arch_timer_handler_virt+0x28/0x30) from [] (handle_percpu_devid_irq+0x9c/0x124) [ 2158.173036] [] (handle_percpu_devid_irq+0x9c/0x124) from [] (generic_handle_irq+0x20/0x30) [ 2158.173049] [] (generic_handle_irq+0x20/0x30) from [] (handle_IRQ+0x64/0x8c) [ 2158.173060] [] (handle_IRQ+0x64/0x8c) from [] (gic_handle_irq+0x3c/0x60) [ 2158.173074] [] (gic_handle_irq+0x3c/0x60) from [] (__irq_svc+0x40/0x50) [ 2158.173083] Exception stack(0xc4043c98 to 0xc4043ce0) [ 2158.173092] 3c80: c4043ce4 00000019 [ 2158.173102] 3ca0: 1f8a865f c050ad10 1f8a864c 00000031 c04b5970 0003ebce 00000000 f3550000 [ 2158.173113] 3cc0: bf00bc68 00000800 0003ebce c4043ce0 c0186d14 c0186cb8 80000013 ffffffff [ 2158.173130] [] (__irq_svc+0x40/0x50) from [] (read_current_timer+0x4/0x38) [ 2158.173145] [] (read_current_timer+0x4/0x38) from [<1f8a865f>] (0x1f8a865f) [ 2183.927097] BUG: soft lockup - CPU#1 stuck for 22s! [io_basic:2073] [ 2184.002229] Modules linked in: nandflash(O) [last unloaded: nandflash] Signed-off-by: Wang Kai Signed-off-by: hujianyang Signed-off-by: Richard Weinberger Signed-off-by: Ben Hutchings commit af2b0e8019d23d6db0ec339821aec23f6c19e367 Author: Ralf Baechle Date: Wed Mar 25 13:21:51 2015 +0100 MIPS: Octeon: Delete override of cpu_has_mips_r2_exec_hazard. commit f05ff43355e6997c18f82ddcee370a6e5f8643ce upstream. This is no longer needed with the fixed, new and improved definition of cpu_has_mips_r2_exec_hazard in . For a discussion, see http://patchwork.linux-mips.org/patch/9539/. Signed-off-by: Ralf Baechle Signed-off-by: Ben Hutchings commit 8feb2a714b3478b2cde5c576fd9f47ef44b60e8d Author: Ralf Baechle Date: Wed Mar 25 13:14:16 2015 +0100 MIPS: Fix cpu_has_mips_r2_exec_hazard. commit 9cdf30bd3bac697fc533988f44a117434a858f69 upstream. Returns a non-zero value if the current processor implementation requires an IHB instruction to deal with an instruction hazard as per MIPS R2 architecture specification, zero otherwise. For a discussion, see http://patchwork.linux-mips.org/patch/9539/. Signed-off-by: Ralf Baechle [bwh: Backported to 3.2: trim the CPU type list] Signed-off-by: Ben Hutchings commit 53493d44a771a3155ee12b6ac668fb2543d21a7a Author: Alexander Sverdlin Date: Wed Mar 18 14:05:21 2015 +0100 MIPS: Octeon: Remove udelay() causing huge IRQ latency commit 73bf3c2a500b2db8ac966469591196bf55afb409 upstream. udelay() in PCI/PCIe read/write callbacks cause 30ms IRQ latency on Octeon platforms because these operations are called from PCI_OP_READ() and PCI_OP_WRITE() under raw_spin_lock_irqsave(). Signed-off-by: Alexander Sverdlin Cc: linux-mips@linux-mips.org Cc: David Daney Cc: Rob Herring Cc: Jiri Kosina Cc: Randy Dunlap Cc: Masanari Iida Cc: Bjorn Helgaas Cc: Mathias Patchwork: https://patchwork.linux-mips.org/patch/9576/ Signed-off-by: Ralf Baechle [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 6bde6a3df0b4c8680d51c987d446b0ff2d6df0a6 Author: Lars Persson Date: Thu Feb 26 14:16:03 2015 +0100 MIPS: Fix race condition in lazy cache flushing. commit 4d46a67a3eb827ccf1125959936fd51ba318dabc upstream. The lazy cache flushing implemented in the MIPS kernel suffers from a race condition that is exposed by do_set_pte() in mm/memory.c. A pre-condition is a file-system that writes to the page from the CPU in its readpage method and then calls flush_dcache_page(). One example is ubifs. Another pre-condition is that the dcache flush is postponed in __flush_dcache_page(). Upon a page fault for an executable mapping not existing in the page-cache, the following will happen: 1. Write to the page 2. flush_dcache_page 3. flush_icache_page 4. set_pte_at 5. update_mmu_cache (commits the flush of a dcache-dirty page) Between steps 4 and 5 another thread can hit the same page and it will encounter a valid pte. Because the data still is in the L1 dcache the CPU will fetch stale data from L2 into the icache and execute garbage. This fix moves the commit of the cache flush to step 3 to close the race window. It also reduces the amount of flushes on non-executable mappings because we never enter __flush_dcache_page() for non-aliasing CPUs. Regressions can occur in drivers that mistakenly relies on the flush_dcache_page() in get_user_pages() for DMA operations. [ralf@linux-mips.org: Folded in patch 9346 to fix highmem issue.] Signed-off-by: Lars Persson Cc: linux-mips@linux-mips.org Cc: paul.burton@imgtec.com Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/9346/ Patchwork: https://patchwork.linux-mips.org/patch/9738/ Signed-off-by: Ralf Baechle Signed-off-by: Ben Hutchings commit 383253cfed2018d4422c6251170107823594309d Author: Ben Greear Date: Thu Jun 6 14:29:49 2013 -0700 Fix lockup related to stop_machine being stuck in __do_softirq. commit 34376a50fb1fa095b9d0636fa41ed2e73125f214 upstream. The stop machine logic can lock up if all but one of the migration threads make it through the disable-irq step and the one remaining thread gets stuck in __do_softirq. The reason __do_softirq can hang is that it has a bail-out based on jiffies timeout, but in the lockup case, jiffies itself is not incremented. To work around this, re-add the max_restart counter in __do_irq and stop processing irqs after 10 restarts. Thanks to Tejun Heo and Rusty Russell and others for helping me track this down. This was introduced in 3.9 by commit c10d73671ad3 ("softirq: reduce latencies"). It may be worth looking into ath9k to see if it has issues with its irq handler at a later date. The hang stack traces look something like this: ------------[ cut here ]------------ WARNING: at kernel/watchdog.c:245 watchdog_overflow_callback+0x9c/0xa7() Watchdog detected hard LOCKUP on cpu 2 Modules linked in: ath9k ath9k_common ath9k_hw ath mac80211 cfg80211 nfsv4 auth_rpcgss nfs fscache nf_nat_ipv4 nf_nat veth 8021q garp stp mrp llc pktgen lockd sunrpc] Pid: 23, comm: migration/2 Tainted: G C 3.9.4+ #11 Call Trace: warn_slowpath_common+0x85/0x9f warn_slowpath_fmt+0x46/0x48 watchdog_overflow_callback+0x9c/0xa7 __perf_event_overflow+0x137/0x1cb perf_event_overflow+0x14/0x16 intel_pmu_handle_irq+0x2dc/0x359 perf_event_nmi_handler+0x19/0x1b nmi_handle+0x7f/0xc2 do_nmi+0xbc/0x304 end_repeat_nmi+0x1e/0x2e <> cpu_stopper_thread+0xae/0x162 smpboot_thread_fn+0x258/0x260 kthread+0xc7/0xcf ret_from_fork+0x7c/0xb0 ---[ end trace 4947dfa9b0a4cec3 ]--- BUG: soft lockup - CPU#1 stuck for 22s! [migration/1:17] Modules linked in: ath9k ath9k_common ath9k_hw ath mac80211 cfg80211 nfsv4 auth_rpcgss nfs fscache nf_nat_ipv4 nf_nat veth 8021q garp stp mrp llc pktgen lockd sunrpc] irq event stamp: 835637905 hardirqs last enabled at (835637904): __do_softirq+0x9f/0x257 hardirqs last disabled at (835637905): apic_timer_interrupt+0x6d/0x80 softirqs last enabled at (5654720): __do_softirq+0x1ff/0x257 softirqs last disabled at (5654725): irq_exit+0x5f/0xbb CPU 1 Pid: 17, comm: migration/1 Tainted: G WC 3.9.4+ #11 To be filled by O.E.M. To be filled by O.E.M./To be filled by O.E.M. RIP: tasklet_hi_action+0xf0/0xf0 Process migration/1 Call Trace: __do_softirq+0x117/0x257 irq_exit+0x5f/0xbb smp_apic_timer_interrupt+0x8a/0x98 apic_timer_interrupt+0x72/0x80 printk+0x4d/0x4f stop_machine_cpu_stop+0x22c/0x274 cpu_stopper_thread+0xae/0x162 smpboot_thread_fn+0x258/0x260 kthread+0xc7/0xcf ret_from_fork+0x7c/0xb0 Signed-off-by: Ben Greear Acked-by: Tejun Heo Acked-by: Pekka Riikonen Cc: Eric Dumazet Signed-off-by: Linus Torvalds [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings Cc: Rui Xiang commit 29a07c1eb1ddd861fbf501df25bbc154999d06cb Author: Eric Dumazet Date: Thu Jan 10 15:26:34 2013 -0800 softirq: reduce latencies commit c10d73671ad30f54692f7f69f0e09e75d3a8926a upstream. In various network workloads, __do_softirq() latencies can be up to 20 ms if HZ=1000, and 200 ms if HZ=100. This is because we iterate 10 times in the softirq dispatcher, and some actions can consume a lot of cycles. This patch changes the fallback to ksoftirqd condition to : - A time limit of 2 ms. - need_resched() being set on current task When one of this condition is met, we wakeup ksoftirqd for further softirq processing if we still have pending softirqs. Using need_resched() as the only condition can trigger RCU stalls, as we can keep BH disabled for too long. I ran several benchmarks and got no significant difference in throughput, but a very significant reduction of latencies (one order of magnitude) : In following bench, 200 antagonist "netperf -t TCP_RR" are started in background, using all available cpus. Then we start one "netperf -t TCP_RR", bound to the cpu handling the NIC IRQ (hard+soft) Before patch : # netperf -H 7.7.7.84 -t TCP_RR -T2,2 -- -k RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 7.7.7.84 () port 0 AF_INET : first burst 0 : cpu bind RT_LATENCY=550110.424 MIN_LATENCY=146858 MAX_LATENCY=997109 P50_LATENCY=305000 P90_LATENCY=550000 P99_LATENCY=710000 MEAN_LATENCY=376989.12 STDDEV_LATENCY=184046.92 After patch : # netperf -H 7.7.7.84 -t TCP_RR -T2,2 -- -k RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 7.7.7.84 () port 0 AF_INET : first burst 0 : cpu bind RT_LATENCY=40545.492 MIN_LATENCY=9834 MAX_LATENCY=78366 P50_LATENCY=33583 P90_LATENCY=59000 P99_LATENCY=69000 MEAN_LATENCY=38364.67 STDDEV_LATENCY=12865.26 Signed-off-by: Eric Dumazet Cc: David Miller Cc: Tom Herbert Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings Cc: Rui Xiang commit f9cedbf0a8b63a10442c2fbf6286b9fa65b68d26 Author: Dan McGee Date: Mon Oct 17 13:05:23 2011 +0000 powerpc+sparc64/mm: Remove hack in mmap randomize layout commit fa8cbaaf5a68f62db3f9a8444ecbb940b47984cb upstream. Since commit 8a0a9bd4db63bc45e301, this comment in mmap_rnd() does not hold true as the value returned by get_random_int() will in fact be different every single call. Remove the comment and simplify the code back to its original desired form. This reverts commit a5adc91a4b44b5d1 which is no longer necessary and also fixes the sparc code that copied this same adjustment. Signed-off-by: Dan McGee Acked-by: David S. Miller Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Ben Hutchings Cc: Moritz Mühlenhoff commit f062bd6e420a064a19563b80c26d746b0262e404 Author: Mark Grondona Date: Wed Sep 11 14:24:31 2013 -0700 __ptrace_may_access() should not deny sub-threads commit 73af963f9f3036dffed55c3a2898598186db1045 upstream. __ptrace_may_access() checks get_dumpable/ptrace_has_cap/etc if task != current, this can can lead to surprising results. For example, a sub-thread can't readlink("/proc/self/exe") if the executable is not readable. setup_new_exec()->would_dump() notices that inode_permission(MAY_READ) fails and then it does set_dumpable(suid_dumpable). After that get_dumpable() fails. (It is not clear why proc_pid_readlink() checks get_dumpable(), perhaps we could add PTRACE_MODE_NODUMPABLE) Change __ptrace_may_access() to use same_thread_group() instead of "task == current". Any security check is pointless when the tasks share the same ->mm. Signed-off-by: Mark Grondona Signed-off-by: Ben Woodard Signed-off-by: Oleg Nesterov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings Cc: Sheng Yong commit a7b4d51399316329b6a3d9eaeab224d83eeebe67 Author: Oleg Nesterov Date: Wed Sep 11 14:20:06 2013 -0700 include/linux/sched.h: don't use task->pid/tgid in same_thread_group/has_group_leader_pid commit e1403b8edf669ff49bbdf602cc97fefa2760cb15 upstream. task_struct->pid/tgid should go away. 1. Change same_thread_group() to use task->signal for comparison. 2. Change has_group_leader_pid(task) to compare task_pid(task) with signal->leader_pid. Signed-off-by: Oleg Nesterov Cc: Michal Hocko Cc: Sergey Dyasly Reviewed-by: "Eric W. Biederman" Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Peter Zijlstra Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings Cc: Sheng Yong commit ea475029e76a0b7fc6e96baf4d414079dec8a90a Author: Feng Tang Date: Wed May 30 23:15:41 2012 +0800 x86/reboot: Fix a warning message triggered by stop_other_cpus() commit 55c844a4dd16a4d1fdc0cf2a283ec631a02ec448 upstream. When rebooting our 24 CPU Westmere servers with 3.4-rc6, we always see this warning msg: Restarting system. machine restart ------------[ cut here ]------------ WARNING: at arch/x86/kernel/smp.c:125 native_smp_send_reschedule+0x74/0xa7() Hardware name: X8DTN Modules linked in: igb [last unloaded: scsi_wait_scan] Pid: 1, comm: systemd-shutdow Not tainted 3.4.0-rc6+ #22 Call Trace: [] warn_slowpath_common+0x7e/0x96 [] warn_slowpath_null+0x15/0x17 [] native_smp_send_reschedule+0x74/0xa7 [] trigger_load_balance+0x279/0x2a6 [] scheduler_tick+0xe0/0xe9 [] update_process_times+0x60/0x70 [] tick_sched_timer+0x68/0x92 [] __run_hrtimer+0xb3/0x13c [] ? tick_nohz_handler+0xd0/0xd0 [] hrtimer_interrupt+0xdb/0x198 [] smp_apic_timer_interrupt+0x81/0x94 [] apic_timer_interrupt+0x67/0x70 [] ? default_send_IPI_mask_allbutself_phys+0xb4/0xc4 [] physflat_send_IPI_allbutself+0x12/0x14 [] native_nmi_stop_other_cpus+0x8a/0xd6 [] native_machine_shutdown+0x50/0x67 [] machine_shutdown+0xa/0xc [] native_machine_restart+0x20/0x32 [] machine_restart+0xa/0xc [] kernel_restart+0x47/0x4c [] sys_reboot+0x13e/0x17c [] ? _raw_spin_unlock_bh+0x10/0x12 [] ? bdi_queue_work+0xcf/0xd8 [] ? __bdi_start_writeback+0xae/0xb7 [] ? iterate_supers+0xa3/0xb7 [] system_call_fastpath+0x16/0x1b ---[ end trace 320af5cb1cb60c5b ]--- The root cause seems to be the default_send_IPI_mask_allbutself_phys() takes quite some time (I measured it could be several ms) to complete sending NMIs to all the other 23 CPUs, and for HZ=250/1000 system, the time is long enough for a timer interrupt to happen, which will in turn trigger to kick load balance to a stopped CPU and cause this warning in native_smp_send_reschedule(). So disabling the local irq before stop_other_cpu() can fix this problem (tested 25 times reboot ok), and it is fine as there should be nobody caring the timer interrupt in such reboot stage. The latest 3.4 kernel slightly changes this behavior by sending REBOOT_VECTOR first and only send NMI_VECTOR if the REBOOT_VCTOR fails, and this patch is still needed to prevent the problem. Signed-off-by: Feng Tang Acked-by: Don Zickus Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20120530231541.4c13433a@feng-i7 Signed-off-by: Ingo Molnar [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings Cc: Vinson Lee commit 4e2b03643331b745dbbcda3d1bf196e3e3929341 Author: Jim Snow Date: Tue Nov 18 14:51:09 2014 +0100 sb_edac: Fix erroneous bytes->gigabytes conversion commit 8c009100295597f23978c224aec5751a365bc965 upstream. Signed-off-by: Jim Snow Signed-off-by: Lukasz Anaczkowski Signed-off-by: Mauro Carvalho Chehab Cc: Vinson Lee [lizf: Backported to 3.4: - adjust context - use debugf0() instead of edac_dbg()] Signed-off-by: Zefan Li Signed-off-by: Ben Hutchings commit f4782e326ffabea060c545ba5dc4275f0de2f7d1 Author: Mauro Carvalho Chehab Date: Mon Nov 7 18:26:53 2011 -0300 Fix sb_edac compilation with 32 bits kernels commit 5b889e379f340f43b1252abde5d37a7084c846b9 upstream. As reported by Josh Boyer : > drivers/edac/sb_edac.c: In function 'get_memory_error_data': > drivers/edac/sb_edac.c:861:2: warning: left shift count >= width of type > [enabled by default] > > ERROR: "__udivdi3" [drivers/edac/sb_edac.ko] undefined! > make[1]: *** [__modpost] Error 1 > make: *** [modules] Error 2 PS.: compile-tested only Reported-by: Josh Boyer Signed-off-by: Mauro Carvalho Chehab [bwh: Prerequisite for "sb_edac: Fix erroneous bytes->gigabytes conversion"] Signed-off-by: Ben Hutchings commit 38e4433dfdc1e90e878c48c8fa954250de542111 Author: Konrad Rzeszutek Wilk Date: Fri Apr 17 15:04:48 2015 -0400 config: Enable NEED_DMA_MAP_STATE by default when SWIOTLB is selected commit a6dfa128ce5c414ab46b1d690f7a1b8decb8526d upstream. A huge amount of NIC drivers use the DMA API, however if compiled under 32-bit an very important part of the DMA API can be ommitted leading to the drivers not working at all (especially if used with 'swiotlb=force iommu=soft'). As Prashant Sreedharan explains it: "the driver [tg3] uses DEFINE_DMA_UNMAP_ADDR(), dma_unmap_addr_set() to keep a copy of the dma "mapping" and dma_unmap_addr() to get the "mapping" value. On most of the platforms this is a no-op, but ... with "iommu=soft and swiotlb=force" this house keeping is required, ... otherwise we pass 0 while calling pci_unmap_/pci_dma_sync_ instead of the DMA address." As such enable this even when using 32-bit kernels. Reported-by: Ian Jackson Signed-off-by: Konrad Rzeszutek Wilk Acked-by: David S. Miller Acked-by: Prashant Sreedharan Cc: Borislav Petkov Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Michael Chan Cc: Thomas Gleixner Cc: boris.ostrovsky@oracle.com Cc: cascardo@linux.vnet.ibm.com Cc: david.vrabel@citrix.com Cc: sanjeevb@broadcom.com Cc: siva.kallam@broadcom.com Cc: vyasevich@gmail.com Cc: xen-devel@lists.xensource.com Link: http://lkml.kernel.org/r/20150417190448.GA9462@l.oracle.com Signed-off-by: Ingo Molnar [bwh: Backported to 3.2: also change the def_bool (cond) to def_bool y + depends] Signed-off-by: Ben Hutchings commit f09662ea912a4b11372e5a709960fcfdc125011a Author: Junling Zheng Date: Mon Jun 1 09:28:00 2015 +0000 net: socket: Fix the wrong returns for recvmsg and sendmsg Based on 08adb7dabd4874cc5666b4490653b26534702ce0 upstream. We found that after v3.10.73, recvmsg might return -EFAULT while -EINVAL was expected. We tested it through the recvmsg01 testcase come from LTP testsuit. It set msg->msg_namelen to -1 and the recvmsg syscall returned errno 14, which is unexpected (errno 22 is expected): recvmsg01 4 TFAIL : invalid socket length ; returned -1 (expected -1), errno 14 (expected 22) Linux mainline has no this bug for commit 08adb7dab fixes it accidentally. However, it is too large and complex to be backported to LTS 3.10. Commit 281c9c36 (net: compat: Update get_compat_msghdr() to match copy_msghdr_from_user() behaviour) made get_compat_msghdr() return error if msg_sys->msg_namelen was negative, which changed the behaviors of recvmsg and sendmsg syscall in a lib32 system: Before commit 281c9c36, get_compat_msghdr() wouldn't fail and it would return -EINVAL in move_addr_to_user() or somewhere if msg_sys->msg_namelen was invalid and then syscall returned -EINVAL, which is correct. And now, when msg_sys->msg_namelen is negative, get_compat_msghdr() will fail and wants to return -EINVAL, however, the outer syscall will return -EFAULT directly, which is unexpected. This patch gets the return value of get_compat_msghdr() as well as copy_msghdr_from_user(), then returns this expected value if get_compat_msghdr() fails. Fixes: 281c9c36 (net: compat: Update get_compat_msghdr() to match copy_msghdr_from_user() behaviour) Signed-off-by: Junling Zheng Signed-off-by: Hanbing Xu Cc: Li Zefan Cc: Al Viro Cc: David Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 3ecadd2fbea4f06a31b62e9832fedbc16d9dbb18 Author: Joonsoo Kim Date: Sat Jun 9 02:23:16 2012 +0900 slub: refactoring unfreeze_partials() commit 43d77867a4f333de4e4189114c480dd365133c09 upstream. Current implementation of unfreeze_partials() is so complicated, but benefit from it is insignificant. In addition many code in do {} while loop have a bad influence to a fail rate of cmpxchg_double_slab. Under current implementation which test status of cpu partial slab and acquire list_lock in do {} while loop, we don't need to acquire a list_lock and gain a little benefit when front of the cpu partial slab is to be discarded, but this is a rare case. In case that add_partial is performed and cmpxchg_double_slab is failed, remove_partial should be called case by case. I think that these are disadvantages of current implementation, so I do refactoring unfreeze_partials(). Minimizing code in do {} while loop introduce a reduced fail rate of cmpxchg_double_slab. Below is output of 'slabinfo -r kmalloc-256' when './perf stat -r 33 hackbench 50 process 4000 > /dev/null' is done. ** before ** Cmpxchg_double Looping ------------------------ Locked Cmpxchg Double redos 182685 Unlocked Cmpxchg Double redos 0 ** after ** Cmpxchg_double Looping ------------------------ Locked Cmpxchg Double redos 177995 Unlocked Cmpxchg Double redos 1 We can see cmpxchg_double_slab fail rate is improved slightly. Bolow is output of './perf stat -r 30 hackbench 50 process 4000 > /dev/null'. ** before ** Performance counter stats for './hackbench 50 process 4000' (30 runs): 108517.190463 task-clock # 7.926 CPUs utilized ( +- 0.24% ) 2,919,550 context-switches # 0.027 M/sec ( +- 3.07% ) 100,774 CPU-migrations # 0.929 K/sec ( +- 4.72% ) 124,201 page-faults # 0.001 M/sec ( +- 0.15% ) 401,500,234,387 cycles # 3.700 GHz ( +- 0.24% ) stalled-cycles-frontend stalled-cycles-backend 250,576,913,354 instructions # 0.62 insns per cycle ( +- 0.13% ) 45,934,956,860 branches # 423.297 M/sec ( +- 0.14% ) 188,219,787 branch-misses # 0.41% of all branches ( +- 0.56% ) 13.691837307 seconds time elapsed ( +- 0.24% ) ** after ** Performance counter stats for './hackbench 50 process 4000' (30 runs): 107784.479767 task-clock # 7.928 CPUs utilized ( +- 0.22% ) 2,834,781 context-switches # 0.026 M/sec ( +- 2.33% ) 93,083 CPU-migrations # 0.864 K/sec ( +- 3.45% ) 123,967 page-faults # 0.001 M/sec ( +- 0.15% ) 398,781,421,836 cycles # 3.700 GHz ( +- 0.22% ) stalled-cycles-frontend stalled-cycles-backend 250,189,160,419 instructions # 0.63 insns per cycle ( +- 0.09% ) 45,855,370,128 branches # 425.436 M/sec ( +- 0.10% ) 169,881,248 branch-misses # 0.37% of all branches ( +- 0.43% ) 13.596272341 seconds time elapsed ( +- 0.22% ) No regression is found, but rather we can see slightly better result. Acked-by: Christoph Lameter Signed-off-by: Joonsoo Kim Signed-off-by: Pekka Enberg [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings Cc: Zefan Li commit 20a5d5d4ed1518f9e74163b1d8ebc1ca7b2e6aa0 Author: Ben Hutchings Date: Sat Aug 1 19:55:11 2015 +0100 debugfs: Fix statfs() regression in 3.2.69 Commit 915f4f86ddc4 ("debugfs: leave freeing a symlink body until inode eviction", commit 0db59e59299f upstream) changed debugfs to define its own super_operations and implement the evict_inode operation. Luis Henriques pointed out that it needs to define the statfs operation, as in simple_super_operations which it was using before. Reported-by: Luis Henriques Signed-off-by: Ben Hutchings commit 117b8a10fe0c434d9043267efd51f3ba3f3d359a Author: Alexander Sverdlin Date: Mon Jun 29 10:41:03 2015 +0200 sctp: Fix race between OOTB responce and route removal [ Upstream commit 29c4afc4e98f4dc0ea9df22c631841f9c220b944 ] There is NULL pointer dereference possible during statistics update if the route used for OOTB responce is removed at unfortunate time. If the route exists when we receive OOTB packet and we finally jump into sctp_packet_transmit() to send ABORT, but in the meantime route is removed under our feet, we take "no_route" path and try to update stats with IP_INC_STATS(sock_net(asoc->base.sk), ...). But sctp_ootb_pkt_new() used to prepare responce packet doesn't call sctp_transport_set_owner() and therefore there is no asoc associated with this packet. Probably temporary asoc just for OOTB responces is overkill, so just introduce a check like in all other places in sctp_packet_transmit(), where "asoc" is dereferenced. To reproduce this, one needs to 0. ensure that sctp module is loaded (otherwise ABORT is not generated) 1. remove default route on the machine 2. while true; do ip route del [interface-specific route] ip route add [interface-specific route] done 3. send enough OOTB packets (i.e. HB REQs) from another host to trigger ABORT responce On x86_64 the crash looks like this: BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 IP: [] sctp_packet_transmit+0x63c/0x730 [sctp] PGD 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: ... CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 4.0.5-1-ARCH #1 Hardware name: ... task: ffffffff818124c0 ti: ffffffff81800000 task.ti: ffffffff81800000 RIP: 0010:[] [] sctp_packet_transmit+0x63c/0x730 [sctp] RSP: 0018:ffff880127c037b8 EFLAGS: 00010296 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000015ff66b480 RDX: 00000015ff66b400 RSI: ffff880127c17200 RDI: ffff880123403700 RBP: ffff880127c03888 R08: 0000000000017200 R09: ffffffff814625af R10: ffffea00047e4680 R11: 00000000ffffff80 R12: ffff8800b0d38a28 R13: ffff8800b0d38a28 R14: ffff8800b3e88000 R15: ffffffffa05f24e0 FS: 0000000000000000(0000) GS:ffff880127c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000020 CR3: 00000000c855b000 CR4: 00000000000007f0 Stack: ffff880127c03910 ffff8800b0d38a28 ffffffff8189d240 ffff88011f91b400 ffff880127c03828 ffffffffa05c94c5 0000000000000000 ffff8800baa1c520 0000000000000000 0000000000000001 0000000000000000 0000000000000000 Call Trace: [] ? sctp_sf_tabort_8_4_8.isra.20+0x85/0x140 [sctp] [] ? sctp_transport_put+0x52/0x80 [sctp] [] sctp_do_sm+0xb8c/0x19a0 [sctp] [] ? trigger_load_balance+0x90/0x210 [] ? update_process_times+0x59/0x60 [] ? timerqueue_add+0x60/0xb0 [] ? enqueue_hrtimer+0x29/0xa0 [] ? read_tsc+0x9/0x10 [] ? put_page+0x55/0x60 [] ? clockevents_program_event+0x6d/0x100 [] ? skb_free_head+0x58/0x80 [] ? chksum_update+0x1b/0x27 [crc32c_generic] [] ? crypto_shash_update+0xce/0xf0 [] sctp_endpoint_bh_rcv+0x113/0x280 [sctp] [] sctp_inq_push+0x46/0x60 [sctp] [] sctp_rcv+0x880/0x910 [sctp] [] ? sctp_packet_transmit_chunk+0xb0/0xb0 [sctp] [] ? sctp_csum_update+0x20/0x20 [sctp] [] ? ip_route_input_noref+0x235/0xd30 [] ? ack_ioapic_level+0x7b/0x150 [] ip_local_deliver_finish+0xae/0x210 [] ip_local_deliver+0x35/0x90 [] ip_rcv_finish+0xf5/0x370 [] ip_rcv+0x2b8/0x3a0 [] __netif_receive_skb_core+0x763/0xa50 [] __netif_receive_skb+0x18/0x60 [] netif_receive_skb_internal+0x40/0xd0 [] napi_gro_receive+0xe8/0x120 [] rtl8169_poll+0x2da/0x660 [r8169] [] net_rx_action+0x21a/0x360 [] __do_softirq+0xe1/0x2d0 [] irq_exit+0xad/0xb0 [] do_IRQ+0x58/0xf0 [] common_interrupt+0x6d/0x6d [] ? hrtimer_start+0x18/0x20 [] ? sctp_transport_destroy_rcu+0x29/0x30 [sctp] [] ? mwait_idle+0x60/0xa0 [] arch_cpu_idle+0xf/0x20 [] cpu_startup_entry+0x3ec/0x480 [] rest_init+0x85/0x90 [] start_kernel+0x48b/0x4ac [] ? early_idt_handlers+0x120/0x120 [] x86_64_start_reservations+0x2a/0x2c [] x86_64_start_kernel+0x161/0x184 Code: 90 48 8b 80 b8 00 00 00 48 89 85 70 ff ff ff 48 83 bd 70 ff ff ff 00 0f 85 cd fa ff ff 48 89 df 31 db e8 18 63 e7 e0 48 8b 45 80 <48> 8b 40 20 48 8b 40 30 48 8b 80 68 01 00 00 65 48 ff 40 78 e9 RIP [] sctp_packet_transmit+0x63c/0x730 [sctp] RSP CR2: 0000000000000020 ---[ end trace 5aec7fd2dc983574 ]--- Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff) drm_kms_helper: panic occurred, switching back to text console ---[ end Kernel panic - not syncing: Fatal exception in interrupt Signed-off-by: Alexander Sverdlin Acked-by: Neil Horman Acked-by: Marcelo Ricardo Leitner Acked-by: Vlad Yasevich Signed-off-by: David S. Miller [bwh: Backported to 3.2: sctp alway uses init_net] Signed-off-by: Ben Hutchings commit 818ffedfbdf96e1d1ca2f1a4b39ad58cb07e2cfc Author: Julian Anastasov Date: Tue Jun 16 22:56:39 2015 +0300 neigh: do not modify unlinked entries [ Upstream commit 2c51a97f76d20ebf1f50fef908b986cb051fdff9 ] The lockless lookups can return entry that is unlinked. Sometimes they get reference before last neigh_cleanup_and_release, sometimes they do not need reference. Later, any modification attempts may result in the following problems: 1. entry is not destroyed immediately because neigh_update can start the timer for dead entry, eg. on change to NUD_REACHABLE state. As result, entry lives for some time but is invisible and out of control. 2. __neigh_event_send can run in parallel with neigh_destroy while refcnt=0 but if timer is started and expired refcnt can reach 0 for second time leading to second neigh_destroy and possible crash. Thanks to Eric Dumazet and Ying Xue for their work and analyze on the __neigh_event_send change. Fixes: 767e97e1e0db ("neigh: RCU conversion of struct neighbour") Fixes: a263b3093641 ("ipv4: Make neigh lookups directly in output packet path.") Fixes: 6fd6ce2056de ("ipv6: Do not depend on rt->n in ip6_finish_output2().") Cc: Eric Dumazet Cc: Ying Xue Signed-off-by: Julian Anastasov Acked-by: Eric Dumazet Signed-off-by: David S. Miller [bwh: Backported to 3.2: drop change to __neigh_set_probe_once() which we don't have] Signed-off-by: Ben Hutchings commit d77456d7361a00d6a4989f8230570e46e53b19eb Author: Willem de Bruijn Date: Wed Jun 17 15:59:34 2015 -0400 packet: avoid out of bounds read in round robin fanout [ Upstream commit 468479e6043c84f5a65299cc07cb08a22a28c2b1 ] PACKET_FANOUT_LB computes f->rr_cur such that it is modulo f->num_members. It returns the old value unconditionally, but f->num_members may have changed since the last store. Ensure that the return value is always < num. When modifying the logic, simplify it further by replacing the loop with an unconditional atomic increment. Fixes: dc99f600698d ("packet: Add fanout support.") Suggested-by: Eric Dumazet Signed-off-by: Willem de Bruijn Acked-by: Eric Dumazet Signed-off-by: David S. Miller [bwh: Backported to 3.2: - Adjust context - Demux functions return a sock pointer, not an index] Signed-off-by: Ben Hutchings commit f5a27902fd01ffc4b379101c64ac3a8cb69495bd Author: Eric Dumazet Date: Tue Jun 16 07:59:11 2015 -0700 packet: read num_members once in packet_rcv_fanout() [ Upstream commit f98f4514d07871da7a113dd9e3e330743fd70ae4 ] We need to tell compiler it must not read f->num_members multiple times. Otherwise testing if num is not zero is flaky, and we could attempt an invalid divide by 0 in fanout_demux_cpu() Note bug was present in packet_rcv_fanout_hash() and packet_rcv_fanout_lb() but final 3.1 had a simple location after commit 95ec3eb417115fb ("packet: Add 'cpu' fanout policy.") Fixes: dc99f600698dc ("packet: Add fanout support.") Signed-off-by: Eric Dumazet Cc: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 41431e402fc405dcef9a468a815c68b322ad0e62 Author: Nikolay Aleksandrov Date: Mon Jun 15 20:28:51 2015 +0300 bridge: fix br_stp_set_bridge_priority race conditions [ Upstream commit 2dab80a8b486f02222a69daca6859519e05781d9 ] After the ->set() spinlocks were removed br_stp_set_bridge_priority was left running without any protection when used via sysfs. It can race with port add/del and could result in use-after-free cases and corrupted lists. Tested by running port add/del in a loop with stp enabled while setting priority in a loop, crashes are easily reproducible. The spinlocks around sysfs ->set() were removed in commit: 14f98f258f19 ("bridge: range check STP parameters") There's also a race condition in the netlink priority support that is fixed by this change, but it was introduced recently and the fixes tag covers it, just in case it's needed the commit is: af615762e972 ("bridge: add ageing_time, stp_state, priority over netlink") Signed-off-by: Nikolay Aleksandrov Fixes: 14f98f258f19 ("bridge: range check STP parameters") Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit f563f5e04ac9f65a9f08b5d04c44f96f6a00ff72 Author: Ian Campbell Date: Mon Jun 1 11:30:24 2015 +0100 xen: netback: read hotplug script once at start of day. [ Upstream commit 31a418986a5852034d520a5bab546821ff1ccf3d ] When we come to tear things down in netback_remove() and generate the uevent it is possible that the xenstore directory has already been removed (details below). In such cases netback_uevent() won't be able to read the hotplug script and will write a xenstore error node. A recent change to the hypervisor exposed this race such that we now sometimes lose it (where apparently we didn't ever before). Instead read the hotplug script configuration during setup and use it for the lifetime of the backend device. The apparently more obvious fix of moving the transition to state=Closed in netback_remove() to after the uevent does not work because it is possible that we are already in state=Closed (in reaction to the guest having disconnected as it shutdown). Being already in Closed means the toolstack is at liberty to start tearing down the xenstore directories. In principal it might be possible to arrange to unregister the device sooner (e.g on transition to Closing) such that xenstore would still be there but this state machine is fragile and prone to anger... A modern Xen system only relies on the hotplug uevent for driver domains, when the backend is in the same domain as the toolstack it will run the necessary setup/teardown directly in the correct sequence wrt xenstore changes. Signed-off-by: Ian Campbell Acked-by: Wei Liu Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit f25e48cb938644c632f140c8bc92e0c4210ce20b Author: Mark Salyzyn Date: Tue May 26 08:22:19 2015 -0700 unix/caif: sk_socket can disappear when state is unlocked [ Upstream commit b48732e4a48d80ed4a14812f0bab09560846514e ] got a rare NULL pointer dereference in clear_bit Signed-off-by: Mark Salyzyn Acked-by: Hannes Frederic Sowa ---- v2: switch to sock_flag(sk, SOCK_DEAD) and added net/caif/caif_socket.c v3: return -ECONNRESET in upstream caller of wait function for SOCK_DEAD Signed-off-by: David S. Miller [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit dbd061fc4f55c9759b2e59f13080e1735095bbce Author: Richard Cochran Date: Mon May 25 11:55:43 2015 +0200 net: dp83640: fix broken calibration routine. [ Upstream commit 397a253af5031de4a4612210055935309af4472c ] Currently, the calibration function that corrects the initial offsets among multiple devices only works the first time. If the function is called more than once, the calibration fails and bogus offsets will be programmed into the devices. In a well hidden spot, the device documentation tells that trigger indexes 0 and 1 are special in allowing the TRIG_IF_LATE flag to actually work. This patch fixes the issue by using one of the special triggers during the recalibration method. Signed-off-by: Richard Cochran Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit dfbbd2eeb55b42e1e32a113c3cde01a6114391d3 Author: Scott Wood Date: Tue Jun 24 20:15:51 2014 -0500 powerpc: Don't skip ePAPR spin-table CPUs commit 6663a4fa6711050036562ddfd2086edf735fae21 upstream. Commit 59a53afe70fd530040bdc69581f03d880157f15a "powerpc: Don't setup CPUs with bad status" broke ePAPR SMP booting. ePAPR says that CPUs that aren't presently running shall have status of disabled, with enable-method being used to determine whether the CPU can be enabled. Fix by checking for spin-table, which is currently the only supported enable-method. Signed-off-by: Scott Wood Cc: Michael Neuling Cc: Emil Medve Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Ben Hutchings Cc: Jonathan Toppins commit 86e059f8367c5fc34bbe2350cc6a8c78335f4c58 Author: Anton Blanchard Date: Wed Aug 7 02:01:32 2013 +1000 powerpc: Make logical to real cpu mapping code endian safe commit ac13282dff13cd0f4da0f0ccb134bc29bfa10255 upstream. Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt [jt: fixed up context due to commit 59a53afe70fd530040bdc69581f03d880157f15a already being backported.] Signed-off-by: Jonathan Toppins Reviewed-by: Andy Gospodarek Acked-by: Curt Brune Acked-by: Roopa Prabhu Signed-off-by: Ben Hutchings commit e658cbfdf7032cab063e4c9a918bd49daed1cddc Author: Thierry Reding Date: Fri Apr 13 16:18:34 2012 +0200 dt: Add empty of_property_match_string() function commit bd3d5500f0c41a30149cb184362716096a17bc75 upstream. This commit adds an empty of_property_match_string() function for !CONFIG_OF builds. Acked-by: Rob Herring Signed-off-by: Thierry Reding Signed-off-by: Ben Hutchings Cc: Jonathan Toppins commit 64e195f6c6da1be9771afd672a452e5c3414a01a Author: Grant Likely Date: Mon Dec 12 09:25:58 2011 -0700 of: Add of_property_match_string() to find index into a string list commit 7aff0fe33033fc75b61446ba29d38b1b1354af9f upstream. Add a helper function for finding the index of a string in a string list property. This helper is useful for bindings that use a separate *-name property for attaching names to tuples in another property such as 'reg' or 'gpios'. Signed-off-by: Grant Likely [jt: dropped changes to files not existing in the 3.2 tree] Signed-off-by: Jonathan Toppins Reviewed-by: Andy Gospodarek Acked-by: Curt Brune Acked-by: Roopa Prabhu Signed-off-by: Ben Hutchings commit 29f163de8d5660ab388f97e47b9b1c75c87f9c6b Author: Hans Schillstrom Date: Thu Apr 26 07:47:44 2012 +0200 ipvs: kernel oops - do_ip_vs_get_ctl commit 8537de8a7ab6681cc72fb0411ab1ba7fdba62dd0 upstream. Change order of init so netns init is ready when register ioctl and netlink. Ver2 Whitespace fixes and __init added. Reported-by: "Ryan O'Hara" Signed-off-by: Hans Schillstrom Acked-by: Julian Anastasov Signed-off-by: Jesper Dangaard Brouer Signed-off-by: Simon Horman Signed-off-by: Ben Hutchings Cc: Andreas Unterkircher commit 001b7cc921ce608997f2796ecf95fe05b7288457 Author: Marcelo Ricardo Leitner Date: Fri Jun 12 10:16:41 2015 -0300 sctp: fix ASCONF list handling commit 2d45a02d0166caf2627fe91897c6ffc3b19514c4 upstream. ->auto_asconf_splist is per namespace and mangled by functions like sctp_setsockopt_auto_asconf() which doesn't guarantee any serialization. Also, the call to inet_sk_copy_descendant() was backuping ->auto_asconf_list through the copy but was not honoring ->do_auto_asconf, which could lead to list corruption if it was different between both sockets. This commit thus fixes the list handling by using ->addr_wq_lock spinlock to protect the list. A special handling is done upon socket creation and destruction for that. Error handlig on sctp_init_sock() will never return an error after having initialized asconf, so sctp_destroy_sock() can be called without addrq_wq_lock. The lock now will be take on sctp_close_sock(), before locking the socket, so we don't do it in inverse order compared to sctp_addr_wq_timeout_handler(). Instead of taking the lock on sctp_sock_migrate() for copying and restoring the list values, it's preferred to avoid rewritting it by implementing sctp_copy_descendant(). Issue was found with a test application that kept flipping sysctl default_auto_asconf on and off, but one could trigger it by issuing simultaneous setsockopt() calls on multiple sockets or by creating/destroying sockets fast enough. This is only triggerable locally. Fixes: 9f7d653b67ae ("sctp: Add Auto-ASCONF support (core).") Reported-by: Ji Jianwen Suggested-by: Neil Horman Suggested-by: Hannes Frederic Sowa Acked-by: Hannes Frederic Sowa Signed-off-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller [bwh: Backported to 3.2: - Adjust filename, context - Most per-netns state is global] Signed-off-by: Ben Hutchings commit 556574d97b6e0c2970b7e5ab693bcf35f73195fa Author: Eric Dumazet Date: Sat May 30 09:16:53 2015 -0700 udp: fix behavior of wrong checksums commit beb39db59d14990e401e235faf66a6b9b31240b0 upstream. We have two problems in UDP stack related to bogus checksums : 1) We return -EAGAIN to application even if receive queue is not empty. This breaks applications using edge trigger epoll() 2) Under UDP flood, we can loop forever without yielding to other processes, potentially hanging the host, especially on non SMP. This patch is an attempt to make things better. We might in the future add extra support for rt applications wanting to better control time spent doing a recv() in a hostile environment. For example we could validate checksums before queuing packets in socket receive queue. Signed-off-by: Eric Dumazet Cc: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 75cf667b7fac08a7b21694adca7dff07361be68a Author: Ben Hutchings Date: Mon Jun 15 03:51:55 2015 +0100 pipe: iovec: Fix memory corruption when retrying atomic copy as non-atomic pipe_iov_copy_{from,to}_user() may be tried twice with the same iovec, the first time atomically and the second time not. The second attempt needs to continue from the iovec position, pipe buffer offset and remaining length where the first attempt failed, but currently the pipe buffer offset and remaining length are reset. This will corrupt the piped data (possibly also leading to an information leak between processes) and may also corrupt kernel memory. This was fixed upstream by commits f0d1bec9d58d ("new helper: copy_page_from_iter()") and 637b58c2887e ("switch pipe_read() to copy_page_to_iter()"), but those aren't suitable for stable. This fix for older kernel versions was made by Seth Jennings for RHEL and I have extracted it from their update. CVE-2015-1805 References: https://bugzilla.redhat.com/show_bug.cgi?id=1202855 Signed-off-by: Ben Hutchings commit 9fa3f3e6f2a4f4797df5550a33ec5ac1088647e7 Author: Steven Rostedt Date: Mon Jun 15 17:50:25 2015 -0400 tracing: Have filter check for balanced ops commit 2cf30dc180cea808077f003c5116388183e54f9e upstream. When the following filter is used it causes a warning to trigger: # cd /sys/kernel/debug/tracing # echo "((dev==1)blocks==2)" > events/ext4/ext4_truncate_exit/filter -bash: echo: write error: Invalid argument # cat events/ext4/ext4_truncate_exit/filter ((dev==1)blocks==2) ^ parse_error: No error ------------[ cut here ]------------ WARNING: CPU: 2 PID: 1223 at kernel/trace/trace_events_filter.c:1640 replace_preds+0x3c5/0x990() Modules linked in: bnep lockd grace bluetooth ... CPU: 3 PID: 1223 Comm: bash Tainted: G W 4.1.0-rc3-test+ #450 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05 05/07/2012 0000000000000668 ffff8800c106bc98 ffffffff816ed4f9 ffff88011ead0cf0 0000000000000000 ffff8800c106bcd8 ffffffff8107fb07 ffffffff8136b46c ffff8800c7d81d48 ffff8800d4c2bc00 ffff8800d4d4f920 00000000ffffffea Call Trace: [] dump_stack+0x4c/0x6e [] warn_slowpath_common+0x97/0xe0 [] ? _kstrtoull+0x2c/0x80 [] warn_slowpath_null+0x1a/0x20 [] replace_preds+0x3c5/0x990 [] create_filter+0x82/0xb0 [] apply_event_filter+0xd4/0x180 [] event_filter_write+0x8f/0x120 [] __vfs_write+0x28/0xe0 [] ? __sb_start_write+0x53/0xf0 [] ? security_file_permission+0x30/0xc0 [] vfs_write+0xb8/0x1b0 [] SyS_write+0x4f/0xb0 [] system_call_fastpath+0x12/0x6a ---[ end trace e11028bd95818dcd ]--- Worse yet, reading the error message (the filter again) it says that there was no error, when there clearly was. The issue is that the code that checks the input does not check for balanced ops. That is, having an op between a closed parenthesis and the next token. This would only cause a warning, and fail out before doing any real harm, but it should still not caues a warning, and the error reported should work: # cd /sys/kernel/debug/tracing # echo "((dev==1)blocks==2)" > events/ext4/ext4_truncate_exit/filter -bash: echo: write error: Invalid argument # cat events/ext4/ext4_truncate_exit/filter ((dev==1)blocks==2) ^ parse_error: Meaningless filter expression And give no kernel warning. Link: http://lkml.kernel.org/r/20150615175025.7e809215@gandalf.local.home Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Arnaldo Carvalho de Melo Reported-by: Vince Weaver Tested-by: Vince Weaver Signed-off-by: Steven Rostedt [bwh: Backported to 3.2: drop the check for OP_NOT, which we don't have] Signed-off-by: Ben Hutchings commit 67766970d59d88c721c31387a9d3df4e4fb9bb37 Author: Wang Long Date: Wed Jun 10 08:12:37 2015 +0000 ring-buffer-benchmark: Fix the wrong sched_priority of producer commit 108029323910c5dd1ef8fa2d10da1ce5fbce6e12 upstream. The producer should be used producer_fifo as its sched_priority, so correct it. Link: http://lkml.kernel.org/r/1433923957-67842-1-git-send-email-long.wanglong@huawei.com Signed-off-by: Wang Long Signed-off-by: Steven Rostedt Signed-off-by: Ben Hutchings commit a01afa11c96910ffe327a53ce0a7fbc04e7a2e44 Author: Nikolay Aleksandrov Date: Tue Jun 9 10:23:57 2015 -0700 bridge: fix multicast router rlist endless loop commit 1a040eaca1a22f8da8285ceda6b5e4a2cb704867 upstream. Since the addition of sysfs multicast router support if one set multicast_router to "2" more than once, then the port would be added to the hlist every time and could end up linking to itself and thus causing an endless loop for rlist walkers. So to reproduce just do: echo 2 > multicast_router; echo 2 > multicast_router; in a bridge port and let some igmp traffic flow, for me it hangs up in br_multicast_flood(). Fix this by adding a check in br_multicast_add_router() if the port is already linked. The reason this didn't happen before the addition of multicast_router sysfs entries is because there's a !hlist_unhashed check that prevents it. Signed-off-by: Nikolay Aleksandrov Fixes: 0909e11758bd ("bridge: Add multicast_router sysfs entries") Acked-by: Herbert Xu Signed-off-by: David S. Miller [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit b9cc09945dcaebcafd8d20bf0445630820a0b40d Author: James Hogan Date: Thu Jun 4 13:25:27 2015 +0100 MIPS: Fix enabling of DEBUG_STACKOVERFLOW commit 5f35b9cd553fd64415b563497d05a563c988dbd6 upstream. Commit 334c86c494b9 ("MIPS: IRQ: Add stackoverflow detection") added kernel stack overflow detection, however it only enabled it conditional upon the preprocessor definition DEBUG_STACKOVERFLOW, which is never actually defined. The Kconfig option is called DEBUG_STACKOVERFLOW, which manifests to the preprocessor as CONFIG_DEBUG_STACKOVERFLOW, so switch it to using that definition instead. Fixes: 334c86c494b9 ("MIPS: IRQ: Add stackoverflow detection") Signed-off-by: James Hogan Cc: Ralf Baechle Cc: Adam Jiang Cc: linux-mips@linux-mips.org Patchwork: http://patchwork.linux-mips.org/patch/10531/ Signed-off-by: Ralf Baechle Signed-off-by: Ben Hutchings commit 309f124498078d09735b4e6b83c463b5564551df Author: 洪一竹 Date: Thu Jun 4 22:00:24 2015 -0700 Input: elantech - add new icbody type commit 692dd1916436164e228608803dfb6cb768d6355a upstream. This adds new icbody type to the list recognized by Elantech PS/2 driver. Signed-off-by: Sam Hung Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings commit fc499f972747dbe98d93647b971cffc949e07a04 Author: Sam hung Date: Thu Jan 8 13:22:43 2015 -0800 Input: elantech - support new ICs types for version 4 commit 810aa0918b2b032684c8cad13f73d6ba37ad11c0 upstream. This change allows the driver to recognize newer Elantech touchpads. Signed-off-by: Yi ju Hong Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings commit 5a0df908a3c8dbd7244d06ee8598bfe9b6dc721f Author: Jordan Rife Date: Tue Apr 22 17:44:51 2014 -0700 Input: elantech - add support for newer elantech touchpads commit ae4bedf0679d99f0a9b80a7ea9b8dd205de05d06 upstream. Newer elantech touchpads are not recognized by the current driver, since it fails to detect their firmware version number. This prevents more advanced touchpad features from being usable such as two-finger scrolling. This patch allows newer touchpads to be detected and be fully functional. Tested on Sony Vaio SVF13N17PXB. Signed-off-by: Jordan Rife Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings commit 4881050ef0c893d76ca8bcd163402cc60514300f Author: Matt Walker Date: Thu Dec 5 12:39:02 2013 -0800 Input: elantech - add support for newer (August 2013) devices commit 9cb80b965eaf7af1369f6e16f48a05fbaaccc021 upstream. Added detection for newer Elantech touchpads, so that kernel doesn't fall-back to default PS/2 driver. Supports touchpads released after ~August 2013. Fixes bug: https://lists.launchpad.net/kernel-packages/msg18481.html Tested on an Acer Aspire S7-392-6302. Signed-off by: Matt Walker Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings commit f605bc363ee5e851629fa7728c8b5fb039aba0ab Author: Matteo Delfino Date: Sat Jul 6 21:52:26 2013 -0700 Input: elantech - fix for newer hardware versions (v7) commit 9eebed7de660c0b5ab129a9de4f89d20b60de68c upstream. * Fix version recognition in elantech_set_properties The new hardware reports itself as v7 but the packets' structure is unaltered. * Fix packet type recognition in elantech_packet_check_v4 The bitmask used for v6 is too wide, only the last three bits of the third byte in a packet (packet[3] & 0x03) are actually used to distinguish between packet types. Starting from v7, additional information (to be interpreted) is stored in the remaining bits (packets[3] & 0x1c). In addition, the value stored in (packet[0] & 0x0c) is no longer a constant but contains additional information yet to be deciphered. This change should be backwards compatible with v6 hardware. Additional-author: Giovanni Frigione Signed-off-by: Matteo Delfino Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings commit db54381f113fb48705c931216497fdb088060c36 Author: John D. Blair Date: Thu Jun 4 13:18:19 2015 -0700 USB: cp210x: add ID for HubZ dual ZigBee and Z-Wave dongle commit df72d588c54dad57dabb3cc8a87475d8ed66d806 upstream. Added the USB serial device ID for the HubZ dual ZigBee and Z-Wave radio dongle. Signed-off-by: John D. Blair Signed-off-by: Johan Hovold Signed-off-by: Ben Hutchings commit 7751e0e89bce8d805869116724ad1acb0b2e6f29 Author: Clemens Ladisch Date: Wed Jun 3 11:36:51 2015 +0200 ALSA: usb-audio: fix missing input volume controls in MAYA44 USB(+) commit ea114fc27dc0cb9a550b6add5426720feb66262a upstream. The driver worked around an error in the MAYA44 USB(+)'s mixer unit descriptor by aborting before parsing the missing field. However, aborting parsing too early prevented parsing of the other units connected to this unit, so the capture mixer controls would be missing. Fix this by moving the check for this descriptor error after the parsing of the unit's input pins. Reported-by: nightmixes Tested-by: nightmixes Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai [bwh: Backported to 3.2: - Adjust context - Logging statement was different] Signed-off-by: Ben Hutchings commit a2066716effdbaa16500427710c59db7e540fd5a Author: Clemens Ladisch Date: Wed Jun 3 11:36:42 2015 +0200 ALSA: usb-audio: add MAYA44 USB+ mixer control names commit 044bddb9ca8d49edb91bc22b9940a463b0dbb97f upstream. Add mixer control names for the ESI Maya44 USB+ (which appears to be identical width the AudioTrak Maya44 USB). Reported-by: nightmixes Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 47188f4e51c0dc5b84457e247800bdf1d31c63d4 Author: Hans de Goede Date: Tue Jun 2 10:40:50 2015 -0700 Input: elantech - fix detection of touchpads where the revision matches a known rate commit 5f0ee9d17aae628b22be86966471db65be21f262 upstream. Make the check to skip the rate check more lax, so that it applies to all hw_version 4 models. This fixes the touchpad not being detected properly on Asus PU551LA laptops. Reported-and-tested-by: David Zafra Gómez Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings commit 8dfc8b9e8432f50606820b40a7d63618d9d61a07 Author: Sasha Levin Date: Wed Jan 28 15:30:43 2015 -0500 vfs: read file_handle only once in handle_to_path commit 161f873b89136eb1e69477c847d5a5033239d9ba upstream. We used to read file_handle twice. Once to get the amount of extra bytes, and once to fetch the entire structure. This may be problematic since we do size verifications only after the first read, so if the number of extra bytes changes in userspace between the first and second calls, we'll have an incoherent view of file_handle. Instead, read the constant size once, and copy that over to the final structure without having to re-read it again. Signed-off-by: Sasha Levin Cc: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 4797489ce83a5f42d0b38089695a48d4a3d1ee0b Author: Ben Hutchings Date: Tue Jul 21 15:42:59 2015 +0100 x86_64: Fix strnlen_user() to not touch memory after specified maximum Inspired by commit f18c34e483ff ("lib: Fix strnlen_user() to not touch memory after specified maximum") upstream. This version of strnlen_user(), no longer present upstream, has a similar off-by-one error. Signed-off-by: Ben Hutchings Cc: Jan Kara commit 48793a2e5abc126a6446d8497c2117489622e9db Author: Andy Grover Date: Fri May 22 14:07:44 2015 -0700 target/pscsi: Don't leak scsi_host if hba is VIRTUAL_HOST commit 5a7125c64def3b21f8147eca8b54949a60963942 upstream. See https://bugzilla.redhat.com/show_bug.cgi?id=1025672 We need to put() the reference to the scsi host that we got in pscsi_configure_device(). In VIRTUAL_HOST mode it is associated with the dev_virt, not the hba_virt. Signed-off-by: Andy Grover Signed-off-by: Nicholas Bellinger [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 7a1cc643ca060a2f6506f7c94c4c46f865a7726f Author: Wolfram Sang Date: Fri May 29 19:50:56 2015 +0900 ALSA: usb-audio: Add mic volume fix quirk for Logitech Quickcam Fusion commit 1ef9f0583514508bc93427106ceef3215e4eb1a5 upstream. Fix this from the logs: usb 7-1: New USB device found, idVendor=046d, idProduct=08ca ... usb 7-1: Warning! Unlikely big volume range (=3072), cval->res is probably wrong. usb 7-1: [5] FU [Mic Capture Volume] ch = 1, val = 4608/7680/1 Signed-off-by: Wolfram Sang Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit c430c2311cc75ad22d69796c43dd8cbe48db8588 Author: Maksim A. Boyko Date: Sat Aug 10 12:20:02 2013 +0400 ALSA: usb-audio: Fix invalid volume resolution for Logitech HD Webcam C525 commit 140d37de62ffe8405282a1d6498f3b4099006384 upstream. Add the volume control quirk for avoiding the kernel warning for the Logitech HD Webcam C525 as in the similar commit 36691e1be6ec551eef4a5225f126a281f8c051c2 for the Logitech HD Webcam C310. Reported-by: Maksim Boyko Tested-by: Maksim Boyko Signed-off-by: Maksim Boyko Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 60593faea74ea54e84cb638f9cc59e32d8268f37 Author: Al Viro Date: Thu May 28 23:09:19 2015 -0400 d_walk() might skip too much commit 2159184ea01e4ae7d15f2017e296d4bc82d5aeb0 upstream. when we find that a child has died while we'd been trying to ascend, we should go into the first live sibling itself, rather than its sibling. Off-by-one in question had been introduced in "deal with deadlock in d_walk()" and the fix needs to be backported to all branches this one has been backported to. Signed-off-by: Al Viro [bwh: Backported to 3.2: apply to the 3 copies of this logic we ended up with] Signed-off-by: Ben Hutchings commit a5045e0fee1a7b2cf132afb94977d4c8d781bd04 Author: Sasha Levin Date: Thu May 28 15:44:29 2015 -0700 fs, omfs: add NULL terminator in the end up the token list commit dcbff39da3d815f08750552fdd04f96b51751129 upstream. match_token() expects a NULL terminator at the end of the token list so that it would know where to stop. Not having one causes it to overrun to invalid memory. In practice, passing a mount option that omfs didn't recognize would sometimes panic the system. Signed-off-by: Sasha Levin Signed-off-by: Bob Copeland Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 74b469cfb9b8eca325bb5822708fda9c6dc3626a Author: Andrew Morton Date: Thu May 28 15:44:24 2015 -0700 fs/binfmt_elf.c:load_elf_binary(): return -EINVAL on zero-length mappings commit 2b1d3ae940acd11be44c6eced5873d47c2e00ffa upstream. load_elf_binary() returns `retval', not `error'. Fixes: a87938b2e246b81b4fb ("fs/binfmt_elf.c: fix bug in loading of PIE binaries") Reported-by: James Hogan Cc: Michael Davidson Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit a8f5259269671acb4f0bdb6e0a53974aa5b351ff Author: Rusty Russell Date: Wed May 27 10:59:26 2015 +0930 lguest: fix out-by-one error in address checking. commit 83a35114d0e4583e6b0ca39502e68b6a92e2910c upstream. This bug has been there since day 1; addresses in the top guest physical page weren't considered valid. You could map that page (the check in check_gpte() is correct), but if a guest tried to put a pagetable there we'd check that address manually when walking it, and kill the guest. Signed-off-by: Rusty Russell Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit a8139dccd98bdece27deac8da46b4145ec7f61c1 Author: Alexei Starovoitov Date: Fri May 22 15:42:55 2015 -0700 x86: bpf_jit: fix compilation of large bpf programs commit 3f7352bf21f8fd7ba3e2fcef9488756f188e12be upstream. x86 has variable length encoding. x86 JIT compiler is trying to pick the shortest encoding for given bpf instruction. While doing so the jump targets are changing, so JIT is doing multiple passes over the program. Typical program needs 3 passes. Some very short programs converge with 2 passes. Large programs may need 4 or 5. But specially crafted bpf programs may hit the pass limit and if the program converges on the last iteration the JIT compiler will be producing an image full of 'int 3' insns. Fix this corner case by doing final iteration over bpf program. Fixes: 0a14842f5a3c ("net: filter: Just In Time compiler for x86-64") Reported-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Tested-by: Daniel Borkmann Acked-by: Daniel Borkmann Signed-off-by: David S. Miller [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 7795fea34180ddf093d2f7cbdcabc9aa7630a0bc Author: Thadeu Lima de Souza Cascardo Date: Fri May 22 12:18:59 2015 -0300 bridge: fix parsing of MLDv2 reports commit 47cc84ce0c2fe75c99ea5963c4b5704dd78ead54 upstream. When more than a multicast address is present in a MLDv2 report, all but the first address is ignored, because the code breaks out of the loop if there has not been an error adding that address. This has caused failures when two guests connected through the bridge tried to communicate using IPv6. Neighbor discoveries would not be transmitted to the other guest when both used a link-local address and a static address. This only happens when there is a MLDv2 querier in the network. The fix will only break out of the loop when there is a failure adding a multicast address. The mdb before the patch: dev ovirtmgmt port vnet0 grp ff02::1:ff7d:6603 temp dev ovirtmgmt port vnet1 grp ff02::1:ff7d:6604 temp dev ovirtmgmt port bond0.86 grp ff02::2 temp After the patch: dev ovirtmgmt port vnet0 grp ff02::1:ff7d:6603 temp dev ovirtmgmt port vnet1 grp ff02::1:ff7d:6604 temp dev ovirtmgmt port bond0.86 grp ff02::fb temp dev ovirtmgmt port bond0.86 grp ff02::2 temp dev ovirtmgmt port bond0.86 grp ff02::d temp dev ovirtmgmt port vnet0 grp ff02::1:ff00:76 temp dev ovirtmgmt port bond0.86 grp ff02::16 temp dev ovirtmgmt port vnet1 grp ff02::1:ff00:77 temp dev ovirtmgmt port bond0.86 grp ff02::1:ff00:def temp dev ovirtmgmt port bond0.86 grp ff02::1:ffa1:40bf temp Fixes: 08b202b67264 ("bridge br_multicast: IPv6 MLD support.") Reported-by: Rik Theys Signed-off-by: Thadeu Lima de Souza Cascardo Tested-by: Rik Theys Signed-off-by: David S. Miller [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings Cc: Jonathan Toppins commit 0539d75746f9a3f282b9c2f45da1e1cc0a804f54 Author: Harald Freudenberger Date: Thu May 21 10:01:11 2015 +0200 crypto: s390/ghash - Fix incorrect ghash icv buffer handling. commit a1cae34e23b1293eccbcc8ee9b39298039c3952a upstream. Multitheaded tests showed that the icv buffer in the current ghash implementation is not handled correctly. A move of this working ghash buffer value to the descriptor context fixed this. Code is tested and verified with an multithreaded application via af_alg interface. Signed-off-by: Harald Freudenberger Signed-off-by: Gerald Schaefer Reported-by: Herbert Xu Signed-off-by: Herbert Xu Signed-off-by: Ben Hutchings commit cf80348f6420632e175f78a4163e40aedace37e6 Author: Patrick Riphagen Date: Tue May 19 10:03:01 2015 +0200 USB: serial: ftdi_sio: Add support for a Motion Tracker Development Board commit 1df5b888f54070a373a73b34488cc78c2365b7b4 upstream. This adds support for new Xsens device, Motion Tracker Development Board, using Xsens' own Vendor ID Signed-off-by: Patrick Riphagen Signed-off-by: Johan Hovold Signed-off-by: Ben Hutchings commit 14204ab641926fca1fed8afb61dcf8f4dc382166 Author: David Vrabel Date: Tue May 19 18:40:49 2015 +0100 xen/events: don't bind non-percpu VIRQs with percpu chip commit 77bb3dfdc0d554befad58fdefbc41be5bc3ed38a upstream. A non-percpu VIRQ (e.g., VIRQ_CONSOLE) may be freed on a different VCPU than it is bound to. This can result in a race between handle_percpu_irq() and removing the action in __free_irq() because handle_percpu_irq() does not take desc->lock. The interrupt handler sees a NULL action and oopses. Only use the percpu chip/handler for per-CPU VIRQs (like VIRQ_TIMER). # cat /proc/interrupts | grep virq 40: 87246 0 xen-percpu-virq timer0 44: 0 0 xen-percpu-virq debug0 47: 0 20995 xen-percpu-virq timer1 51: 0 0 xen-percpu-virq debug1 69: 0 0 xen-dyn-virq xen-pcpu 74: 0 0 xen-dyn-virq mce 75: 29 0 xen-dyn-virq hvc_console Signed-off-by: David Vrabel [bwh: Backported to 3.2: adjust filename, context, indentation] Signed-off-by: Ben Hutchings commit fd6b72574fcdaee123768804d8f1ac28c2a5b3de Author: Mark Hounschell Date: Wed May 13 10:49:09 2015 +0200 sd: Disable support for 256 byte/sector disks commit 74856fbf441929918c49ff262ace9835048e4e6a upstream. 256 bytes per sector support has been broken since 2.6.X, and no-one stepped up to fix this. So disable support for it. Signed-off-by: Mark Hounschell Signed-off-by: Hannes Reinecke Signed-off-by: James Bottomley [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 0cc2c958f7301947de507114deac6c8df5455ef6 Author: David Henningsson Date: Wed May 13 13:28:54 2015 +0200 ALSA: hda - Add Conexant codecs CX20721, CX20722, CX20723 and CX20724 commit 6ffc0898b29a2811a6c0569c5dd9b581980110df upstream. This patch adds support for Conexant HD Audio codecs CX20721, CX20722, CX20723 and CX20724. BugLink: https://bugs.launchpad.net/bugs/1454656 Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 2f6a2bcc01bc9ed73bfb4d698da94ed2a5fcb18c Author: Darrick J. Wong Date: Thu May 14 19:11:50 2015 -0400 jbd2: fix r_count overflows leading to buffer overflow in journal recovery commit e531d0bceb402e643a4499de40dd3fa39d8d2e43 upstream. The journal revoke block recovery code does not check r_count for sanity, which means that an evil value of r_count could result in the kernel reading off the end of the revoke table and into whatever garbage lies beyond. This could crash the kernel, so fix that. However, in testing this fix, I discovered that the code to write out the revoke tables also was not correctly checking to see if the block was full -- the current offset check is fine so long as the revoke table space size is a multiple of the record size, but this is not true when either journal_csum_v[23] are set. Signed-off-by: Darrick J. Wong Signed-off-by: Theodore Ts'o Reviewed-by: Jan Kara [bwh: Backported to 3.2: journal checksumming is not supported, so only the first fix is needed] Signed-off-by: Ben Hutchings commit 93fa5e650858847f56d90bfdabb18d87bc859663 Author: Eryu Guan Date: Thu May 14 19:00:45 2015 -0400 ext4: check for zero length extent explicitly commit 2f974865ffdfe7b9f46a9940836c8b167342563d upstream. The following commit introduced a bug when checking for zero length extent 5946d08 ext4: check for overlapping extents in ext4_valid_extent_entries() Zero length extent could pass the check if lblock is zero. Adding the explicit check for zero length back. Signed-off-by: Eryu Guan Signed-off-by: Theodore Ts'o Signed-off-by: Ben Hutchings commit b7314518be7eae2f25ca7c07986b8d970595d0f7 Author: Jean Delvare Date: Thu May 14 14:40:50 2015 +0200 firmware: dmi_scan: Fix ordering of product_uuid commit 5c1ac56b51b9d222ab202dec1ac2f4215346129d upstream. In function dmi_present(), dmi_walk_early() calls dmi_table(), which calls dmi_decode(), which ultimately calls dmi_save_uuid(). This last function makes a decision based on the value of global variable dmi_ver. The problem is that this variable is set right _after_ dmi_walk_early() returns. So dmi_save_uuid() always sees dmi_ver == 0 regardless of the actual version implemented. This causes /sys/class/dmi/id/product_uuid to always use the old ordering even on systems implementing DMI/SMBIOS 2.6 or later, which should use the new ordering. This is broken since kernel v3.8 for legacy DMI implementations and since kernel v3.10 for SMBIOS 2 implementations. SMBIOS 3 implementations with the 64-bit entry point are not affected. The first breakage does not matter much as in practice legacy DMI implementations are always for versions older than 2.6, which is when the UUID ordering changed. The second breakage is more problematic as it affects the vast majority of x86 systems manufactured since 2009. Signed-off-by: Jean Delvare Fixes: 9f9c9cbb6057 ("drivers/firmware/dmi_scan.c: fetch dmi version from SMBIOS if it exists") Fixes: 79bae42d51a5 ("dmi_scan: refactor dmi_scan_machine(), {smbios,dmi}_present()") Acked-by: Zhenzhong Duan Cc: Ben Hutchings Cc: Artem Savkov Cc: Ivan Khoronzhuk Cc: Matt Fleming [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 5c64725826c10634168ee2a2d5d955ca5ea68cb4 Author: Ben Hutchings Date: Tue Apr 30 15:27:46 2013 -0700 dmi_scan: refactor dmi_scan_machine(), {smbios,dmi}_present() commit 79bae42d51a5d498500c890c19ef76df41d2bf59 upstream. Move the calls to memcpy_fromio() up into the loop in dmi_scan_machine(), and move the signature checks back down into dmi_decode(). We need to check at 16-byte intervals but keep a 32-byte buffer for an SMBIOS entry, so shift the buffer after each iteration. Merge smbios_present() into dmi_present(), so we look for an SMBIOS signature at the beginning of the given buffer and then for a DMI signature at an offset of 16 bytes. [artem.savkov@gmail.com: use proper buf type in dmi_present()] Signed-off-by: Ben Hutchings Reported-by: Tim McGrath Tested-by: Tim Mcgrath Cc: Zhenzhong Duan Signed-off-by: Artem Savkov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [bwh: Prerequisite for "firmware: dmi_scan: Fix ordering of product_uuid"] commit 303241421684cdd2f9e931bc42b9de811320e7fd Author: Anton Blanchard Date: Thu May 14 14:45:40 2015 +1000 powerpc: Align TOC to 256 bytes commit 5e95235ccd5442d4a4fe11ec4eb99ba1b7959368 upstream. Recent toolchains force the TOC to be 256 byte aligned. We need to enforce this alignment in our linker script, otherwise pointers to our TOC variables (__toc_start, __prom_init_toc_start) could be incorrect. If they are bad, we die a few hundred instructions into boot. Signed-off-by: Anton Blanchard Signed-off-by: Michael Ellerman Signed-off-by: Ben Hutchings commit 16c8bd10b8a0454f3e3938a2bd1f99aff5442562 Author: Benjamin Tissoires Date: Thu Apr 23 09:08:43 2015 -0700 Input: elantech - fix semi-mt protocol for v3 HW commit 3c0213d17a09601e0c6c0ae0e27caf70d988290f upstream. When the v3 hardware sees more than one finger, it uses the semi-mt protocol to report the touches. However, it currently works when num_fingers is 0, 1 or 2, but when it is 3 and above, it sends only 1 finger as if num_fingers was 1. This confuses userspace which knows how to deal with extra fingers when all the slots are used, but not when some are missing. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=90101 Signed-off-by: Benjamin Tissoires Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings commit fd1797f04c8a2025802dcc41b5780fd3811fc907 Author: Zidan Wang Date: Tue May 12 14:58:50 2015 +0800 ASoC: wm8994: correct BCLK DIV 348 to 384 commit 17fc2e0a3db11889e942c5ab15a1fcb876638f25 upstream. According to the RM of wm8958, BCLK DIV 348 doesn't exist, correct it to 384. Signed-off-by: Zidan Wang Acked-by: Charles Keepax Signed-off-by: Mark Brown Signed-off-by: Ben Hutchings commit 699d38472d83a373241d0f4c49c5ccc6c27e03fc Author: Zidan Wang Date: Tue May 12 14:58:36 2015 +0800 ASoC: wm8960: fix "RINPUT3" audio route error commit 85e36a1f4a735d991ba5106781ea48e89a0b8901 upstream. It should be "RINPUT3" instead of "LINPUT3" route to "Right Input Mixer". Signed-off-by: Zidan Wang Acked-by: Charles Keepax Signed-off-by: Mark Brown Signed-off-by: Ben Hutchings commit b9d2bbcdce078d8b59c45e5e101c13ed1e35b6e8 Author: Koro Chen Date: Mon May 11 10:36:53 2015 +0800 ASoC: dapm: Modify widget stream name according to prefix commit fdb6eb0a12871d5bfaf266c5a0d5259a5437a72f upstream. When there is prefix specified, currently we will add this prefix in widget->name, but not in widget->sname. it causes failure at snd_soc_dapm_link_dai_widgets: if (!w->sname || !strstr(w->sname, dai_w->name)) because dai_w->name has prefix added, but w->sname does not. We should also add prefix for stream name Signed-off-by: Koro Chen Signed-off-by: Mark Brown [bwh: Backported to 3.2: - Adjust context - s/prefix/dapm->codec->name_prefix] Signed-off-by: Ben Hutchings commit c36b570ffcc2cf8d0de724f24ac9fc99e2f16421 Author: Paolo Bonzini Date: Thu Apr 2 11:04:05 2015 +0200 KVM: MMU: fix CR4.SMEP=1, CR0.WP=0 with shadow pages commit 898761158be7682082955e3efa4ad24725305fc7 upstream. smep_andnot_wp is initialized in kvm_init_shadow_mmu and shadow pages should not be reused for different values of it. Thus, it has to be added to the mask in kvm_mmu_pte_write. Reviewed-by: Xiao Guangrong Signed-off-by: Paolo Bonzini [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 06b9576ec258ff39f0f95a226c49a03d7aca68a1 Author: Janusz Dziedzic Date: Mon May 11 11:31:15 2015 +0200 mac80211: move WEP tailroom size check commit 47b4e1fc4972cc43a19121bc2608a60aef3bf216 upstream. Remove checking tailroom when adding IV as it uses only headroom, and move the check to the ICV generation that actually needs the tailroom. In other case I hit such warning and datapath don't work, when testing: - IBSS + WEP - ath9k with hw crypt enabled - IPv6 data (ping6) WARNING: CPU: 3 PID: 13301 at net/mac80211/wep.c:102 ieee80211_wep_add_iv+0x129/0x190 [mac80211]() [...] Call Trace: [] dump_stack+0x45/0x57 [] warn_slowpath_common+0x8a/0xc0 [] warn_slowpath_null+0x1a/0x20 [] ieee80211_wep_add_iv+0x129/0x190 [mac80211] [] ieee80211_crypto_wep_encrypt+0x6b/0xd0 [mac80211] [] invoke_tx_handlers+0xc51/0xf30 [mac80211] [...] Signed-off-by: Janusz Dziedzic Signed-off-by: Johannes Berg [bwh: Backported to 3.2: s/IEEE80211_WEP/WEP/] Signed-off-by: Ben Hutchings commit ee156f0adfe053ba0a745cd77c7d697cbd153014 Author: Dan Williams Date: Fri May 8 15:23:55 2015 -0400 ahci: avoton port-disable reset-quirk commit dbfe8ef5599a5370abc441fcdbb382b656563eb4 upstream. Avoton AHCI occasionally sees drive probe timeouts at driver load time. When this happens SCR_STATUS indicates device detected, but no D2H FIS reception. Reset the internal link state machines by bouncing port-enable in the PCS register when this occurs. Signed-off-by: Dan Williams Signed-off-by: Tejun Heo [bwh: Backported to 3.2: - Adjust context - Call ahci_start_engine() directly] Signed-off-by: Ben Hutchings commit 15eb903daa9fcd80e3b4edfb5960793e6dfc6f67 Author: Rob Herring Date: Fri Aug 17 09:51:50 2012 -0500 ahci: un-staticize ahci_dev_classify commit bbb4ab43f82adf02c8b4d0d7e7b7e79d24204b05 upstream. Make ahci_dev_classify available to the ahci platform driver for custom hard reset function. Signed-off-by: Rob Herring Signed-off-by: Jeff Garzik Signed-off-by: Ben Hutchings commit 35434e855747e1530de4573bf2807eb2c6f693ec Author: Hans de Goede Date: Thu Apr 30 11:09:44 2015 +0200 usb-storage: Add NO_WP_DETECT quirk for Lacie 059f:0651 devices commit 172115090f5e739660b97694618a2ba86457063a upstream. Without this flag some versions of these enclosures do not work. Reported-and-tested-by: Christian Schaller Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 645d64a5b0ab2eae42c1280029ad2b13e7509308 Author: Joe Lawrence Date: Thu Apr 30 17:16:04 2015 +0300 xhci: gracefully handle xhci_irq dead device commit 948fa13504f80b9765d2b753691ab94c83a10341 upstream. If the xHCI host controller has died (ie, device removed) or suffered other serious fatal error (STS_FATAL), then xhci_irq should handle this condition with IRQ_HANDLED instead of -ESHUTDOWN. Signed-off-by: Joe Lawrence Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit f810a6a0e02c9651bd2cb3a3c2a076dcdef88d13 Author: Mathias Nyman Date: Thu Apr 30 17:16:03 2015 +0300 xhci: Solve full event ring by increasing TRBS_PER_SEGMENT to 256 commit 18cc2f4cbbaf825a4fedcf2d60fd388d291e0a38 upstream. Our event ring consists of only one segment, and we risk filling the event ring in case we get isoc transfers with short intervals such as webcams that fill a TD every microframe (125us) With 64 TRB segment size one usb camera could fill the event ring in 8ms. A setup with several cameras and other devices can fill up the event ring as it is shared between all devices. This has occurred when uvcvideo queues 5 * 32TD URBs which then get cancelled when the video mode changes. The cancelled URBs are returned in the xhci interrupt context and blocks the interrupt handler from handling the new events. A full event ring will block xhci from scheduling traffic and affect all devices conneted to the xhci, will see errors such as Missed Service Intervals for isoc devices, and and Split transaction errors for LS/FS interrupt devices. Increasing the TRB_PER_SEGMENT will also increase the default endpoint ring size, which is welcome as for most isoc transfer we had to dynamically expand the endpoint ring anyway to be able to queue the 5 * 32TDs uvcvideo queues. The default size used to be 64 TRBs per segment Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 4c1e45b88d04eb89046694e08e8af4effb87d7c5 Author: Mathias Nyman Date: Thu Apr 30 17:16:02 2015 +0300 xhci: fix isoc endpoint dequeue from advancing too far on transaction error commit d104d0152a97fade389f47635b73a9ccc7295d0b upstream. Isoc TDs usually consist of one TRB, sometimes two. When all goes well we receive only one success event for a TD, and move the dequeue pointer to the next TD. This fails if the TD consists of two TRBs and we get a transfer error on the first TRB, we will then see two events for that TD. Fix this by making sure the event we get is for the last TRB in that TD before moving the dequeue pointer to the next TD. This will resolve some of the uvc and dvb issues with the "ERROR Transfer event TRB DMA ptr not part of current TD" error message Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 9ada08c05bf2c88a0551e89c51301ff0d35219c1 Author: Tommi Rantala Date: Thu May 7 15:12:21 2015 +0300 ipvs: fix memory leak in ip_vs_ctl.c commit f30bf2a5cac6c60ab366c4bc6db913597bf4d6ab upstream. Fix memory leak introduced in commit a0840e2e165a ("IPVS: netns, ip_vs_ctl local vars moved to ipvs struct."): unreferenced object 0xffff88005785b800 (size 2048): comm "(-localed)", pid 1434, jiffies 4294755650 (age 1421.089s) hex dump (first 32 bytes): bb 89 0b 83 ff ff ff ff b0 78 f0 4e 00 88 ff ff .........x.N.... 04 00 00 00 a4 01 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] kmemleak_alloc+0x4e/0xb0 [] __kmalloc_track_caller+0x244/0x430 [] kmemdup+0x20/0x50 [] ip_vs_control_net_init+0x1f7/0x510 [] __ip_vs_init+0x100/0x250 [] ops_init+0x41/0x190 [] setup_net+0x93/0x150 [] copy_net_ns+0x82/0x140 [] create_new_namespaces+0xfd/0x190 [] unshare_nsproxy_namespaces+0x5a/0xc0 [] SyS_unshare+0x173/0x310 [] system_call_fastpath+0x12/0x6f [] 0xffffffffffffffff Fixes: a0840e2e165a ("IPVS: netns, ip_vs_ctl local vars moved to ipvs struct.") Signed-off-by: Tommi Rantala Acked-by: Julian Anastasov Signed-off-by: Simon Horman Signed-off-by: Ben Hutchings commit c20694a054e903745591f4f85b39ecbce4e58349 Author: NeilBrown Date: Fri May 8 18:19:34 2015 +1000 md/raid5: don't record new size if resize_stripes fails. commit 6e9eac2dcee5e19f125967dd2be3e36558c42fff upstream. If any memory allocation in resize_stripes fails we will return -ENOMEM, but in some cases we update conf->pool_size anyway. This means that if we try again, the allocations will be assumed to be larger than they are, and badness results. So only update pool_size if there is no error. This bug was introduced in 2.6.17 and the patch is suitable for -stable. Fixes: ad01c9e3752f ("[PATCH] md: Allow stripes to be expanded in preparation for expanding an array") Signed-off-by: NeilBrown Signed-off-by: Ben Hutchings commit d370a4107e9b9fcbf76e23119e6fb447c42c3f91 Author: Rafael J. Wysocki Date: Thu May 7 21:19:39 2015 +0200 ACPI / init: Fix the ordering of acpi_reserve_resources() commit b9a5e5e18fbf223502c0b2264c15024e393da928 upstream. Since acpi_reserve_resources() is defined as a device_initcall(), there's no guarantee that it will be executed in the right order with respect to the rest of the ACPI initialization code. On some systems this leads to breakage if, for example, the address range that should be reserved for the ACPI fixed registers is given to the PCI host bridge instead if the race is won by the wrong code path. Fix this by turning acpi_reserve_resources() into a void function and calling it directly from within the ACPI initialization sequence. Reported-and-tested-by: George McCollister Link: http://marc.info/?t=143092384600002&r=1&w=2 Signed-off-by: Rafael J. Wysocki Signed-off-by: Ben Hutchings commit bbdef5d38abb4917f4f25bc3f94ccf4ff46ffec5 Author: Junxiao Bi Date: Tue May 5 16:24:02 2015 -0700 ocfs2: dlm: fix race between purge and get lock resource commit b1432a2a35565f538586774a03bf277c27fc267d upstream. There is a race window in dlm_get_lock_resource(), which may return a lock resource which has been purged. This will cause the process to hang forever in dlmlock() as the ast msg can't be handled due to its lock resource not existing. dlm_get_lock_resource { ... spin_lock(&dlm->spinlock); tmpres = __dlm_lookup_lockres_full(dlm, lockid, namelen, hash); if (tmpres) { spin_unlock(&dlm->spinlock); >>>>>>>> race window, dlm_run_purge_list() may run and purge the lock resource spin_lock(&tmpres->spinlock); ... spin_unlock(&tmpres->spinlock); } } Signed-off-by: Junxiao Bi Cc: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 74e08b1cc7be2c4eecdd277484ed89fcacb0d3dd Author: Ryusuke Konishi Date: Tue May 5 16:24:00 2015 -0700 nilfs2: fix sanity check of btree level in nilfs_btree_root_broken() commit d8fd150fe3935e1692bf57c66691e17409ebb9c1 upstream. The range check for b-tree level parameter in nilfs_btree_root_broken() is wrong; it accepts the case of "level == NILFS_BTREE_LEVEL_MAX" even though the level is limited to values in the range of 0 to (NILFS_BTREE_LEVEL_MAX - 1). Since the level parameter is read from storage device and used to index nilfs_btree_path array whose element count is NILFS_BTREE_LEVEL_MAX, it can cause memory overrun during btree operations if the boundary value is set to the level parameter on device. This fixes the broken sanity check and adds a comment to clarify that the upper bound NILFS_BTREE_LEVEL_MAX is exclusive. Signed-off-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 38787a8ce9e6e053070b12ea19945b962d79d579 Author: Christoph Hellwig Date: Tue Apr 28 15:41:15 2015 +0200 nfsd: fix the check for confirmed openowner in nfs4_preprocess_stateid_op commit ebe9cb3bb13e7b9b281969cd279ce70834f7500f upstream. If we find a non-confirmed openowner we jump to exit the function, but do not set an error value. Fix this by factoring out a helper to do the check and properly set the error from nfsd4_validate_stateid. Signed-off-by: Christoph Hellwig Signed-off-by: J. Bruce Fields [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit b221184ff664276d80833a1205411b5dc39672a6 Author: Grygorii Strashko Date: Thu Apr 23 13:43:43 2015 +0300 mmc: core: add missing pm event in mmc_pm_notify to fix hib restore commit 184af16b09360d6273fd6160e6ff7f8e2482ef23 upstream. The PM_RESTORE_PREPARE is not handled now in mmc_pm_notify(), as result mmc_rescan() could be scheduled and executed at late hibernation restore stages when MMC device is suspended already - which, in turn, will lead to system crash on TI dra7-evm board: WARNING: CPU: 0 PID: 3188 at drivers/bus/omap_l3_noc.c:148 l3_interrupt_handler+0x258/0x374() 44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Idle): Data Access in User mode during Functional access Hence, add missed PM_RESTORE_PREPARE PM event in mmc_pm_notify(). Fixes: 4c2ef25fe0b8 (mmc: fix all hangs related to mmc/sd card...) Signed-off-by: Grygorii Strashko Signed-off-by: Ulf Hansson [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 4209178b876408926ef6f02e51dd447bcebde977 Author: Davide Italiano Date: Sat May 2 23:21:15 2015 -0400 ext4: move check under lock scope to close a race. commit 280227a75b56ab5d35854f3a77ef74a7ad56a203 upstream. fallocate() checks that the file is extent-based and returns EOPNOTSUPP in case is not. Other tasks can convert from and to indirect and extent so it's safe to check only after grabbing the inode mutex. Signed-off-by: Davide Italiano Signed-off-by: Theodore Ts'o [bwh: Backported to 3.2: - Adjust context - Add the 'out' label] Signed-off-by: Ben Hutchings commit 7807354f17297234692897fd5a0700e79b7949a9 Author: Nathan Fontenot Date: Wed Apr 29 20:42:06 2015 -0500 powerpc/pseries: Correct cpu affinity for dlpar added cpus commit f32393c943e297b8ae180c8f83d81a156c7d0412 upstream. The incorrect ordering of operations during cpu dlpar add results in invalid affinity for the cpu being added. The ibm,associativity property in the device tree is populated with all zeroes for the added cpu which results in invalid affinity mappings and all cpus appear to belong to node 0. This occurs because rtas configure-connector is called prior to making the rtas set-indicator calls. Phyp does not assign affinity information for a cpu until the rtas set-indicator calls are made to set the isolation and allocation state. Correct the order of operations to make the rtas set-indicator calls (done in dlpar_acquire_drc) before calling rtas configure-connector. Fixes: 1a8061c46c46 ("powerpc/pseries: Add kernel based CPU DLPAR handling") Signed-off-by: Nathan Fontenot Signed-off-by: Michael Ellerman [bwh: Backported to 3.2: - Adjust context - Keep using goto instead of directly returning] Signed-off-by: Ben Hutchings commit 5e3a0d7c5c5f3bac1c35595d6b16f2f638e42b53 Author: Johan Hovold Date: Tue Apr 21 17:42:09 2015 +0200 gpio: sysfs: fix memory leaks and device hotplug commit 483d821108791092798f5d230686868112927044 upstream. Unregister GPIOs requested through sysfs at chip remove to avoid leaking the associated memory and sysfs entries. The stale sysfs entries prevented the gpio numbers from being exported when the gpio range was later reused (e.g. at device reconnect). This also fixes the related module-reference leak. Note that kernfs makes sure that any on-going sysfs operations finish before the class devices are unregistered and that further accesses fail. The chip exported flag is used to prevent gpiod exports during removal. This also makes it harder to trigger, but does not fix, the related race between gpiochip_remove and export_store, which is really a race with gpiod_request that needs to be addressed separately. Also note that this would prevent the crashes (e.g. NULL-dereferences) at reconnect that affects pre-3.18 kernels, as well as use-after-free on operations on open attribute files on pre-3.14 kernels (prior to kernfs). Fixes: d8f388d8dc8d ("gpio: sysfs interface") Signed-off-by: Johan Hovold Signed-off-by: Linus Walleij [bwh: Backported to 3.2: - Adjust filename, context - Move up initialisation of 'desc' in gpio_export() - Use global 'gpio_desc' array and gpio_free() function in gpiochip_unexport()] Signed-off-by: Ben Hutchings commit c833e96de15cb46c8587271a32c651c0acc40dd3 Author: Johan Hovold Date: Mon Jan 12 17:12:29 2015 +0100 gpio: unregister gpiochip device before removing it commit 01cca93a9491ed95992523ff7e79dd9bfcdea8e0 upstream. Unregister gpiochip device (used to export information through sysfs) before removing it internally. This way removal will reverse addition. Signed-off-by: Johan Hovold Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 56481c2920bb35e8a0b8abd55eeb5e52e8bce042 Author: Ben Hutchings Date: Mon Apr 13 00:26:35 2015 +0100 xen-pciback: Add name prefix to global 'permissive' variable commit 8014bcc86ef112eab9ee1db312dba4e6b608cf89 upstream. The variable for the 'permissive' module parameter used to be static but was recently changed to be extern. This puts it in the kernel global namespace if the driver is built-in, so its name should begin with a prefix identifying the driver. Signed-off-by: Ben Hutchings Fixes: af6fc858a35b ("xen-pciback: limit guest control of command register") Signed-off-by: David Vrabel commit cf24c628650f2197e69d90289e413fe0098e4df9 Author: Jason A. Donenfeld Date: Wed Apr 22 14:35:08 2015 +0200 USB: pl2303: Remove support for Samsung I330 commit 48ef23a4f686b1e4519d4193c20d26834ff810ff upstream. This phone is already supported by the visor driver. Signed-off-by: Jason A. Donenfeld Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Johan Hovold [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 4a7e721f7db80f4feccab1ba03398d5cb4dd0be1 Author: Mark Edwards Date: Tue Apr 14 08:52:34 2015 -0400 USB: cp210x: add ID for KCF Technologies PRN device commit c735ed74d83f8ecb45c4c4c95a16853c9c3c8157 upstream. Added the USB serial console device ID for KCF Technologies PRN device which has a USB port for its serial console. Signed-off-by: Mark Edwards Signed-off-by: Johan Hovold Signed-off-by: Ben Hutchings commit 22df023245f6eac89753ac2602bdfc25d0ae26ec Author: Peter Zubaj Date: Tue Apr 28 21:57:29 2015 +0200 ALSA: emu10k1: Emu10k2 32 bit DMA mode commit 7241ea558c6715501e777396b5fc312c372e11d9 upstream. Looks like audigy emu10k2 (probably emu10k1 - sb live too) support two modes for DMA. Second mode is useful for 64 bit os with more then 2 GB of ram (fixes problems with big soundfont loading) 1) 32MB from 2 GB address space using 8192 pages (used now as default) 2) 16MB from 4 GB address space using 4096 pages Mode is set using HCFG_EXPANDED_MEM flag in HCFG register. Also format of emu10k2 page table is then different. Signed-off-by: Peter Zubaj Tested-by: Takashi Iwai Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit f696aa6f0c43ba1c180b28e4e895ef005092d331 Author: Takashi Iwai Date: Tue Apr 28 17:11:44 2015 +0200 ALSA: emux: Fix mutex deadlock in OSS emulation commit 1c94e65c668f44d2c69ae7e7fc268ab3268fba3e upstream. The OSS emulation in synth-emux helper has a potential AB/BA deadlock at the simultaneous closing and opening: close -> snd_seq_release() -> sne_seq_free_client() -> snd_seq_delete_all_ports(): takes client->ports_mutex -> port_delete() -> snd_emux_unuse(): takes emux->register_mutex open -> snd_seq_oss_open() -> snd_emux_open_seq_oss(): takes emux->register_mutex -> snd_seq_event_port_attach() -> snd_seq_create_port(): takes client->ports_mutex This patch addresses the deadlock by reducing the rance taking emux->register_mutex in snd_emux_open_seq_oss(). The lock is needed for the refcount handling, so move it locally. The calls in emux_seq.c are already with the mutex, thus they are replaced with the version without mutex lock/unlock. Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 7bb3b886cd0c9968d870e064a9ec0eb6cce424e3 Author: Michal Simek Date: Tue Apr 14 12:03:09 2015 +0200 serial: of-serial: Remove device_type = "serial" registration commit 6befa9d883385c580369a2cc9e53fbf329771f6d upstream. Do not probe all serial drivers by of_serial.c which are using device_type = "serial"; property. Only drivers which have valid compatible strings listed in the driver should be probed. When PORT_UNKNOWN is setup probe will fail anyway. Arnd quotation about driver historical background: "when I wrote that driver initially, the idea was that it would get used as a stub to hook up all other serial drivers but after that, the common code learned to create platform devices from DT" This patch fix the problem with on the system with xilinx_uartps and 16550a where of_serial failed to register for xilinx_uartps and because of irq_dispose_mapping() removed irq_desc. Then when xilinx_uartps was asking for irq with request_irq() EINVAL is returned. Signed-off-by: Michal Simek Acked-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 300547d271d7c1569c1833c1b10626cbd8ee707a Author: Michal Simek Date: Mon Apr 13 16:34:21 2015 +0200 serial: xilinx: Use platform_get_irq to get irq description structure commit 5c90c07b98c02198d9777a7c4f3047b0a94bf7ed upstream. For systems with CONFIG_SERIAL_OF_PLATFORM=y and device_type = "serial"; property in DT of_serial.c driver maps and unmaps IRQ (because driver probe fails). Then a driver is called but irq mapping is not created that's why driver is failing again in again on request_irq(). Based on this use platform_get_irq() instead of platform_get_resource() which is doing irq_desc allocation and driver itself can request IRQ. Fix both xilinx serial drivers in the tree. Signed-off-by: Michal Simek Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: - Adjust context - Return directly on failure in xuartps_probe()] Signed-off-by: Ben Hutchings commit 56e6aa7fc2169206d213bfa2f5c6a481ed9e7722 Author: Larry Finger Date: Fri Apr 24 11:03:37 2015 -0500 rtlwifi: rtl8192cu: Fix kernel deadlock commit 414b7e3b9ce8b0577f613e656fdbc36b34b444dd upstream. The USB mini-driver in rtlwifi, which is used by rtl8192cu, issues a call to usb_control_msg() with a timeout value of 0. In some instances where the interface is shutting down, this infinite wait results in a CPU deadlock. A one second timeout fixes this problem without affecting any normal operations. This bug is reported at https://bugzilla.novell.com/show_bug.cgi?id=927786. Reported-by: Bernhard Wiedemann Tested-by: Bernhard Wiedemann Signed-off-by: Larry Finger Cc: Bernhard Wiedemann Cc: Takashi Iwai Signed-off-by: Kalle Valo [bwh: Backported to 3.2: adjust context, indentation] Signed-off-by: Ben Hutchings commit a1cd4189c48044fe4d9830b14a1941d0c0c98eb0 Author: Quentin Casasnovas Date: Tue Apr 14 11:25:43 2015 +0200 cdc-acm: prevent infinite loop when parsing CDC headers. commit 0d3bba0287d4e284c3ec7d3397e81eec920d5e7e upstream. Phil and I found out a problem with commit: 7e860a6e7aa6 ("cdc-acm: add sanity checks") It added some sanity checks to ignore potential garbage in CDC headers but also introduced a potential infinite loop. This can happen at the first loop iteration (elength = 0 in that case) if the description isn't a DT_CS_INTERFACE or later if 'buffer[0]' is zero. It should also be noted that the wrong length was being added to 'buffer' in case 'buffer[1]' was not a DT_CS_INTERFACE descriptor, since elength was assigned after that check in the loop. A specially crafted USB device could be used to trigger this infinite loop. Fixes: 7e860a6e7aa6 ("cdc-acm: add sanity checks") Signed-off-by: Phil Turnbull Signed-off-by: Quentin Casasnovas CC: Sergei Shtylyov CC: Oliver Neukum CC: Adam Lee Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit c245a412c7f135fb0a74b4c38b40f5b738ff8912 Author: Christoph Hellwig Date: Thu Apr 23 09:48:51 2015 +0200 3w-9xxx: fix command completion race commit 118c855b5623f3e2e6204f02623d88c09e0c34de upstream. The 3w-9xxx driver needs to tear down the dma mappings before returning the command to the midlayer, as there is no guarantee the sglist and count are valid after that point. Also remove the dma mapping helpers which have another inherent race due to the request_id index. Signed-off-by: Christoph Hellwig Acked-by: Adam Radford Signed-off-by: James Bottomley Signed-off-by: Ben Hutchings commit 278b6cf917977593d14059b555f2204f8867b902 Author: Christoph Hellwig Date: Thu Apr 23 09:48:50 2015 +0200 3w-xxxx: fix command completion race commit 9cd9554615cba14f0877cc9972a6537ad2bdde61 upstream. The 3w-xxxx driver needs to tear down the dma mappings before returning the command to the midlayer, as there is no guarantee the sglist and count are valid after that point. Also remove the dma mapping helpers which have another inherent race due to the request_id index. Signed-off-by: Christoph Hellwig Acked-by: Adam Radford Signed-off-by: James Bottomley Signed-off-by: Ben Hutchings commit 4fcafc95800aaa813435f5b9038182ca03dc6280 Author: Christoph Hellwig Date: Thu Apr 23 09:48:49 2015 +0200 3w-sas: fix command completion race commit 579d69bc1fd56d5af5761969aa529d1d1c188300 upstream. The 3w-sas driver needs to tear down the dma mappings before returning the command to the midlayer, as there is no guarantee the sglist and count are valid after that point. Also remove the dma mapping helpers which have another inherent race due to the request_id index. Signed-off-by: Christoph Hellwig Reported-by: Torsten Luettgert Tested-by: Bernd Kardatzki Acked-by: Adam Radford Signed-off-by: James Bottomley Signed-off-by: Ben Hutchings commit b14b5688328d7c3af29afe4aa3b65c4be36706b2 Author: Takashi Iwai Date: Mon Apr 27 14:50:39 2015 +0200 ALSA: emux: Fix mutex deadlock at unloading commit 07b0e5d49d227e3950cb13a3e8caf248ef2a310e upstream. The emux-synth driver has a possible AB/BA mutex deadlock at unloading the emu10k1 driver: snd_emux_free() -> snd_emux_detach_seq(): mutex_lock(&emu->register_mutex) -> snd_seq_delete_kernel_client() -> snd_seq_free_client(): mutex_lock(®ister_mutex) snd_seq_release() -> snd_seq_free_client(): mutex_lock(®ister_mutex) -> snd_seq_delete_all_ports() -> snd_emux_unuse(): mutex_lock(&emu->register_mutex) Basically snd_emux_detach_seq() doesn't need a protection of emu->register_mutex as it's already being unregistered. So, we can get rid of this for avoiding the deadlock. Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 172210296cc6debd42698165f1999a384d008fa3 Author: Takashi Iwai Date: Mon Apr 27 13:00:09 2015 +0200 ALSA: emu10k1: Fix card shortname string buffer overflow commit d02260824e2cad626fb2a9d62e27006d34b6dedc upstream. Some models provide too long string for the shortname that has 32bytes including the terminator, and it results in a non-terminated string exposed to the user-space. This isn't too critical, though, as the string is stopped at the succeeding longname string. This patch fixes such entries by dropping "SB" prefix (it's enough to fit within 32 bytes, so far). Meanwhile, it also changes strcpy() with strlcpy() to make sure that this kind of problem won't happen in future, too. Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 6d2cf32d106b396d29fd43a80fb6764535f7a1a3 Author: Gabriele Mazzotta Date: Sat Apr 25 19:52:37 2015 +0200 libata: Ignore spurious PHY event on LPM policy change commit 09c5b4803a80a5451d950d6a539d2eb311dc0fb1 upstream. When the LPM policy is set to ATA_LPM_MAX_POWER, the device might generate a spurious PHY event that cuases errors on the link. Ignore this event if it occured within 10s after the policy change. The timeout was chosen observing that on a Dell XPS13 9333 these spurious events can occur up to roughly 6s after the policy change. Link: http://lkml.kernel.org/g/3352987.ugV1Ipy7Z5@xps13 Signed-off-by: Gabriele Mazzotta Signed-off-by: Tejun Heo [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit bc14e871a99dfdd14fbd685c75e7e4466449c65c Author: Gabriele Mazzotta Date: Sat Apr 25 19:52:36 2015 +0200 libata: Add helper to determine when PHY events should be ignored commit 8393b811f38acdf7fd8da2028708edad3e68ce1f upstream. This is a preparation commit that will allow to add other criteria according to which PHY events should be dropped. Signed-off-by: Gabriele Mazzotta Signed-off-by: Tejun Heo Signed-off-by: Ben Hutchings commit 57279928b028b49bb26bb5af62aa455759521d32 Author: Tejun Heo Date: Tue Apr 21 16:49:13 2015 -0400 writeback: use |1 instead of +1 to protect against div by zero commit 464d1387acb94dc43ba772b35242345e3d2ead1b upstream. mm/page-writeback.c has several places where 1 is added to the divisor to prevent division by zero exceptions; however, if the original divisor is equivalent to -1, adding 1 leads to division by zero. There are three places where +1 is used for this purpose - one in pos_ratio_polynom() and two in bdi_position_ratio(). The second one in bdi_position_ratio() actually triggered div-by-zero oops on a machine running a 3.10 kernel. The divisor is x_intercept - bdi_setpoint + 1 == span + 1 span is confirmed to be (u32)-1. It isn't clear how it ended up that but it could be from write bandwidth calculation underflow fixed by c72efb658f7c ("writeback: fix possible underflow in write bandwidth calculation"). At any rate, +1 isn't a proper protection against div-by-zero. This patch converts all +1 protections to |1. Note that bdi_update_dirty_ratelimit() was already using |1 before this patch. Signed-off-by: Tejun Heo Reviewed-by: Jan Kara Signed-off-by: Jens Axboe Signed-off-by: Ben Hutchings commit 330a80fdcee47ec8eb0a1a37edeaebdcf3720960 Author: Ben Serebrin Date: Thu Apr 16 11:58:05 2015 -0700 KVM: VMX: Preserve host CR4.MCE value while in guest mode. commit 085e68eeafbf76e21848ad5bafaecec88a11dd64 upstream. The host's decision to enable machine check exceptions should remain in force during non-root mode. KVM was writing 0 to cr4 on VCPU reset and passed a slightly-modified 0 to the vmcs.guest_cr4 value. Tested: Built. On earlier version, tested by injecting machine check while a guest is spinning. Before the change, if guest CR4.MCE==0, then the machine check is escalated to Catastrophic Error (CATERR) and the machine dies. If guest CR4.MCE==1, then the machine check causes VMEXIT and is handled normally by host Linux. After the change, injecting a machine check causes normal Linux machine check handling. Signed-off-by: Ben Serebrin Reviewed-by: Venkatesh Srinivas Signed-off-by: Paolo Bonzini [bwh: Backported to 3.2: use read_cr4() instead of cr4_read_shadow()] Signed-off-by: Ben Hutchings commit 0fd0b9f448e1ff459ea4f718def61a197b15bb4c Author: Dan Carpenter Date: Thu Apr 16 12:48:35 2015 -0700 memstick: mspro_block: add missing curly braces commit 13f6b191aaa11c7fd718d35a0c565f3c16bc1d99 upstream. Using the indenting we can see the curly braces were obviously intended. This is a static checker fix, but my guess is that we don't read enough bytes, because we don't calculate "t_len" correctly. Fixes: f1d82698029b ('memstick: use fully asynchronous request processing') Signed-off-by: Dan Carpenter Cc: Alex Dubov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit e3f81ba2f0546f030fc234f7aade3016532c75b1 Author: Oleg Nesterov Date: Thu Apr 16 12:47:29 2015 -0700 ptrace: fix race between ptrace_resume() and wait_task_stopped() commit b72c186999e689cb0b055ab1c7b3cd8fffbeb5ed upstream. ptrace_resume() is called when the tracee is still __TASK_TRACED. We set tracee->exit_code and then wake_up_state() changes tracee->state. If the tracer's sub-thread does wait() in between, task_stopped_code(ptrace => T) wrongly looks like another report from tracee. This confuses debugger, and since wait_task_stopped() clears ->exit_code the tracee can miss a signal. Test-case: #include #include #include #include #include #include int pid; void *waiter(void *arg) { int stat; for (;;) { assert(pid == wait(&stat)); assert(WIFSTOPPED(stat)); if (WSTOPSIG(stat) == SIGHUP) continue; assert(WSTOPSIG(stat) == SIGCONT); printf("ERR! extra/wrong report:%x\n", stat); } } int main(void) { pthread_t thread; pid = fork(); if (!pid) { assert(ptrace(PTRACE_TRACEME, 0,0,0) == 0); for (;;) kill(getpid(), SIGHUP); } assert(pthread_create(&thread, NULL, waiter, NULL) == 0); for (;;) ptrace(PTRACE_CONT, pid, 0, SIGCONT); return 0; } Note for stable: the bug is very old, but without 9899d11f6544 "ptrace: ensure arch_ptrace/ptrace_request can never race with SIGKILL" the fix should use lock_task_sighand(child). Signed-off-by: Oleg Nesterov Reported-by: Pavel Labath Tested-by: Pavel Labath Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 11efded2cfc62ad72e5e1b666ac09b4e458ee931 Author: Nicolas Iooss Date: Thu Apr 16 12:44:02 2015 -0700 firmware/ihex2fw.c: restore missing default in switch statement commit d43698e8abb58a6ac47d16e0f47bb55f452e4fc4 upstream. Commit 2473238eac95 ("ihex: add support for CS:IP/EIP records") removes the "default:" statement in the switch block, making the "return usage();" line dead code and ihex2fw silently ignoring unknown options. Restore this statement. This bug was found by building with HOSTCC=clang and adding -Wunreachable-code-return to HOSTCFLAGS. Fixes: 2473238eac95 ("ihex: add support for CS:IP/EIP records") Signed-off-by: Nicolas Iooss Cc: Mark Brown Cc: David Woodhouse Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit de49525aa1250da3eac2040591b322d1157831db Author: Christoph Hellwig Date: Wed Apr 15 09:44:37 2015 -0700 megaraid_sas: use raw_smp_processor_id() commit 16b8528d20607925899b1df93bfd8fbab98d267c upstream. We only want to steer the I/O completion towards a queue, but don't actually access any per-CPU data, so the raw_ version is fine to use and avoids the warnings when using smp_processor_id(). Signed-off-by: Christoph Hellwig Reported-by: Andy Lutomirski Tested-by: Andy Lutomirski Acked-by: Sumit Saxena Signed-off-by: James Bottomley [bwh: Backported to 3.2: drop changes to megasas_build_dcdb_fusion()] Signed-off-by: Ben Hutchings commit 400eef848152754708c0ccef1887fd673a5cef60 Author: Erez Shitrit Date: Thu Apr 2 13:39:05 2015 +0300 IB/mlx4: Fix WQE LSO segment calculation commit ca9b590caa17bcbbea119594992666e96cde9c2f upstream. The current code decreases from the mss size (which is the gso_size from the kernel skb) the size of the packet headers. It shouldn't do that because the mss that comes from the stack (e.g IPoIB) includes only the tcp payload without the headers. The result is indication to the HW that each packet that the HW sends is smaller than what it could be, and too many packets will be sent for big messages. An easy way to demonstrate one more aspect of the problem is by configuring the ipoib mtu to be less than 2*hlen (2*56) and then run app sending big TCP messages. This will tell the HW to send packets with giant (negative value which under unsigned arithmetics becomes a huge positive one) length and the QP moves to SQE state. Fixes: b832be1e4007 ('IB/mlx4: Add IPoIB LSO support') Reported-by: Matthew Finlay Signed-off-by: Erez Shitrit Signed-off-by: Or Gerlitz Signed-off-by: Doug Ledford Signed-off-by: Ben Hutchings commit 111a87bbfd89bf6360c0d6b776c20171a11da7b1 Author: Yann Droneaud Date: Mon Apr 13 14:56:23 2015 +0200 IB/core: don't disallow registering region starting at 0x0 commit 66578b0b2f69659f00b6169e6fe7377c4b100d18 upstream. In a call to ib_umem_get(), if address is 0x0 and size is already page aligned, check added in commit 8494057ab5e4 ("IB/uverbs: Prevent integer overflow in ib_umem_get address arithmetic") will refuse to register a memory region that could otherwise be valid (provided vm.mmap_min_addr sysctl and mmap_low_allowed SELinux knobs allow userspace to map something at address 0x0). This patch allows back such registration: ib_umem_get() should probably don't care of the base address provided it can be pinned with get_user_pages(). There's two possible overflows, in (addr + size) and in PAGE_ALIGN(addr + size), this patch keep ensuring none of them happen while allowing to pin memory at address 0x0. Anyway, the case of size equal 0 is no more (partially) handled as 0-length memory region are disallowed by an earlier check. Link: http://mid.gmane.org/cover.1428929103.git.ydroneaud@opteya.com Cc: Shachar Raindel Cc: Jack Morgenstein Cc: Or Gerlitz Signed-off-by: Yann Droneaud Reviewed-by: Sagi Grimberg Reviewed-by: Haggai Eran Signed-off-by: Doug Ledford Signed-off-by: Ben Hutchings commit 6c0537d6933db0de53a60d1141862744d7a326bf Author: Yann Droneaud Date: Mon Apr 13 14:56:22 2015 +0200 IB/core: disallow registering 0-sized memory region commit 8abaae62f3fdead8f4ce0ab46b4ab93dee39bab2 upstream. If ib_umem_get() is called with a size equal to 0 and an non-page aligned address, one page will be pinned and a 0-sized umem will be returned to the caller. This should not be allowed: it's not expected for a memory region to have a size equal to 0. This patch adds a check to explicitly refuse to register a 0-sized region. Link: http://mid.gmane.org/cover.1428929103.git.ydroneaud@opteya.com Cc: Shachar Raindel Cc: Jack Morgenstein Cc: Or Gerlitz Signed-off-by: Yann Droneaud Signed-off-by: Doug Ledford Signed-off-by: Ben Hutchings commit c3727815f928a838e845b5755b4dde4efb2841c9 Author: Michael Davidson Date: Tue Apr 14 15:47:38 2015 -0700 fs/binfmt_elf.c: fix bug in loading of PIE binaries commit a87938b2e246b81b4fb713edb371a9fa3c5c3c86 upstream. With CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE enabled, and a normal top-down address allocation strategy, load_elf_binary() will attempt to map a PIE binary into an address range immediately below mm->mmap_base. Unfortunately, load_elf_ binary() does not take account of the need to allocate sufficient space for the entire binary which means that, while the first PT_LOAD segment is mapped below mm->mmap_base, the subsequent PT_LOAD segment(s) end up being mapped above mm->mmap_base into the are that is supposed to be the "gap" between the stack and the binary. Since the size of the "gap" on x86_64 is only guaranteed to be 128MB this means that binaries with large data segments > 128MB can end up mapping part of their data segment over their stack resulting in corruption of the stack (and the data segment once the binary starts to run). Any PIE binary with a data segment > 128MB is vulnerable to this although address randomization means that the actual gap between the stack and the end of the binary is normally greater than 128MB. The larger the data segment of the binary the higher the probability of failure. Fix this by calculating the total size of the binary in the same way as load_elf_interp(). Signed-off-by: Michael Davidson Cc: Alexander Viro Cc: Jiri Kosina Cc: Kees Cook Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 6d42341b8ab3962359dde19bbe0feeb20002fe85 Author: Lv Zheng Date: Mon Apr 13 11:48:58 2015 +0800 ACPICA: Utilities: split IO address types from data type models. commit 2b8760100e1de69b6ff004c986328a82947db4ad upstream. ACPICA commit aacf863cfffd46338e268b7415f7435cae93b451 It is reported that on a physically 64-bit addressed machine, 32-bit kernel can trigger crashes in accessing the memory regions that are beyond the 32-bit boundary. The region field's start address should still be 32-bit compliant, but after a calculation (adding some offsets), it may exceed the 32-bit boundary. This case is rare and buggy, but there are real BIOSes leaked with such issues (see References below). This patch fixes this gap by always defining IO addresses as 64-bit, and allows OSPMs to optimize it for a real 32-bit machine to reduce the size of the internal objects. Internal acpi_physical_address usages in the structures that can be fixed by this change include: 1. struct acpi_object_region: acpi_physical_address address; 2. struct acpi_address_range: acpi_physical_address start_address; acpi_physical_address end_address; 3. struct acpi_mem_space_context; acpi_physical_address address; 4. struct acpi_table_desc acpi_physical_address address; See known issues 1 for other usages. Note that acpi_io_address which is used for ACPI_PROCESSOR may also suffer from same problem, so this patch changes it accordingly. For iasl, it will enforce acpi_physical_address as 32-bit to generate 32-bit OSPM compatible tables on 32-bit platforms, we need to define ACPI_32BIT_PHYSICAL_ADDRESS for it in acenv.h. Known issues: 1. Cleanup of mapped virtual address In struct acpi_mem_space_context, acpi_physical_address is used as a virtual address: acpi_physical_address mapped_physical_address; It is better to introduce acpi_virtual_address or use acpi_size instead. This patch doesn't make such a change. Because this should be done along with a change to acpi_os_map_memory()/acpi_os_unmap_memory(). There should be no functional problem to leave this unchanged except that only this structure is enlarged unexpectedly. Link: https://github.com/acpica/acpica/commit/aacf863c Reference: https://bugzilla.kernel.org/show_bug.cgi?id=87971 Reference: https://bugzilla.kernel.org/show_bug.cgi?id=79501 Reported-and-tested-by: Paul Menzel Reported-and-tested-by: Sial Nije Signed-off-by: Lv Zheng Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 3c9d9d2cc60b5063cda0e92d4b6cdb92da268e7b Author: Anton Blanchard Date: Tue Apr 14 07:51:03 2015 +1000 powerpc/perf: Cap 64bit userspace backtraces to PERF_MAX_STACK_DEPTH commit 9a5cbce421a283e6aea3c4007f141735bf9da8c3 upstream. We cap 32bit userspace backtraces to PERF_MAX_STACK_DEPTH (currently 127), but we forgot to do the same for 64bit backtraces. Signed-off-by: Anton Blanchard Signed-off-by: Michael Ellerman [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings commit aae89a4f7996bb0f5ded693fb1768f2faa9f4ace Author: Filipe Manana Date: Mon Mar 30 18:23:59 2015 +0100 Btrfs: fix inode eviction infinite loop after cloning into it commit ccccf3d67294714af2d72a6fd6fd7d73b01c9329 upstream. If we attempt to clone a 0 length region into a file we can end up inserting a range in the inode's extent_io tree with a start offset that is greater then the end offset, which triggers immediately the following warning: [ 3914.619057] WARNING: CPU: 17 PID: 4199 at fs/btrfs/extent_io.c:435 insert_state+0x4b/0x10b [btrfs]() [ 3914.620886] BTRFS: end < start 4095 4096 (...) [ 3914.638093] Call Trace: [ 3914.638636] [] dump_stack+0x4c/0x65 [ 3914.639620] [] warn_slowpath_common+0xa1/0xbb [ 3914.640789] [] ? insert_state+0x4b/0x10b [btrfs] [ 3914.642041] [] warn_slowpath_fmt+0x46/0x48 [ 3914.643236] [] insert_state+0x4b/0x10b [btrfs] [ 3914.644441] [] __set_extent_bit+0x107/0x3f4 [btrfs] [ 3914.645711] [] lock_extent_bits+0x65/0x1bf [btrfs] [ 3914.646914] [] ? _raw_spin_unlock+0x28/0x33 [ 3914.648058] [] ? test_range_bit+0xcc/0xde [btrfs] [ 3914.650105] [] lock_extent+0x13/0x15 [btrfs] [ 3914.651361] [] lock_extent_range+0x3d/0xcd [btrfs] [ 3914.652761] [] btrfs_ioctl_clone+0x278/0x388 [btrfs] [ 3914.654128] [] ? might_fault+0x58/0xb5 [ 3914.655320] [] btrfs_ioctl+0xb51/0x2195 [btrfs] (...) [ 3914.669271] ---[ end trace 14843d3e2e622fc1 ]--- This later makes the inode eviction handler enter an infinite loop that keeps dumping the following warning over and over: [ 3915.117629] WARNING: CPU: 22 PID: 4228 at fs/btrfs/extent_io.c:435 insert_state+0x4b/0x10b [btrfs]() [ 3915.119913] BTRFS: end < start 4095 4096 (...) [ 3915.137394] Call Trace: [ 3915.137913] [] dump_stack+0x4c/0x65 [ 3915.139154] [] warn_slowpath_common+0xa1/0xbb [ 3915.140316] [] ? insert_state+0x4b/0x10b [btrfs] [ 3915.141505] [] warn_slowpath_fmt+0x46/0x48 [ 3915.142709] [] insert_state+0x4b/0x10b [btrfs] [ 3915.143849] [] __set_extent_bit+0x107/0x3f4 [btrfs] [ 3915.145120] [] ? btrfs_kill_super+0x17/0x23 [btrfs] [ 3915.146352] [] ? deactivate_locked_super+0x3b/0x50 [ 3915.147565] [] lock_extent_bits+0x65/0x1bf [btrfs] [ 3915.148785] [] ? _raw_write_unlock+0x28/0x33 [ 3915.149931] [] btrfs_evict_inode+0x196/0x482 [btrfs] [ 3915.151154] [] evict+0xa0/0x148 [ 3915.152094] [] dispose_list+0x39/0x43 [ 3915.153081] [] evict_inodes+0xdc/0xeb [ 3915.154062] [] generic_shutdown_super+0x49/0xef [ 3915.155193] [] kill_anon_super+0x13/0x1e [ 3915.156274] [] btrfs_kill_super+0x17/0x23 [btrfs] (...) [ 3915.167404] ---[ end trace 14843d3e2e622fc2 ]--- So just bail out of the clone ioctl if the length of the region to clone is zero, without locking any extent range, in order to prevent this issue (same behaviour as a pwrite with a 0 length for example). This is trivial to reproduce. For example, the steps for the test I just made for fstests: mkfs.btrfs -f SCRATCH_DEV mount SCRATCH_DEV $SCRATCH_MNT touch $SCRATCH_MNT/foo touch $SCRATCH_MNT/bar $CLONER_PROG -s 0 -d 4096 -l 0 $SCRATCH_MNT/foo $SCRATCH_MNT/bar umount $SCRATCH_MNT A test case for fstests follows soon. Signed-off-by: Filipe Manana Reviewed-by: Omar Sandoval Signed-off-by: Chris Mason Signed-off-by: Ben Hutchings commit 98b4a75c0792d281beb904911e2271d45c71511a Author: Heiko Carstens Date: Wed Mar 25 10:13:33 2015 +0100 s390/hibernate: fix save and restore of kernel text section commit d74419495633493c9cd3f2bbeb7f3529d0edded6 upstream. Sebastian reported a crash caused by a jump label mismatch after resume. This happens because we do not save the kernel text section during suspend and therefore also do not restore it during resume, but use the kernel image that restores the old system. This means that after a suspend/resume cycle we lost all modifications done to the kernel text section. The reason for this is the pfn_is_nosave() function, which incorrectly returns that read-only pages don't need to be saved. This is incorrect since we mark the kernel text section read-only. We still need to make sure to not save and restore pages contained within NSS and DCSS segment. To fix this add an extra case for the kernel text section and only save those pages if they are not contained within an NSS segment. Fixes the following crash (and the above bugs as well): Jump label code mismatch at netif_receive_skb_internal+0x28/0xd0 Found: c0 04 00 00 00 00 Expected: c0 f4 00 00 00 11 New: c0 04 00 00 00 00 Kernel panic - not syncing: Corrupted kernel text CPU: 0 PID: 9 Comm: migration/0 Not tainted 3.19.0-01975-gb1b096e70f23 #4 Call Trace: [<0000000000113972>] show_stack+0x72/0xf0 [<000000000081f15e>] dump_stack+0x6e/0x90 [<000000000081c4e8>] panic+0x108/0x2b0 [<000000000081be64>] jump_label_bug.isra.2+0x104/0x108 [<0000000000112176>] __jump_label_transform+0x9e/0xd0 [<00000000001121e6>] __sm_arch_jump_label_transform+0x3e/0x50 [<00000000001d1136>] multi_cpu_stop+0x12e/0x170 [<00000000001d1472>] cpu_stopper_thread+0xb2/0x168 [<000000000015d2ac>] smpboot_thread_fn+0x134/0x1b0 [<0000000000158baa>] kthread+0x10a/0x110 [<0000000000824a86>] kernel_thread_starter+0x6/0xc Reported-and-tested-by: Sebastian Ott Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky [bwh: Backported to 3.2: add necessary #include directives] Signed-off-by: Ben Hutchings commit b36fe5eacb9b5487dcf217a27eec7f2e86175f6b Author: Nicolas Dichtel Date: Fri Apr 10 16:24:28 2015 +0200 selinux/nlmsg: add XFRM_MSG_MAPPING commit bd2cba07381a6dba60bc1c87ed8b37931d244da1 upstream. This command is missing. Fixes: 3a2dfbe8acb1 ("xfrm: Notify changes in UDP encapsulation via netlink") CC: Martin Willi Reported-by: Stephen Smalley Signed-off-by: Nicolas Dichtel Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 64e30bebb39dce7c8396291187ebfcbb24068ec6 Author: Nicolas Dichtel Date: Fri Apr 10 16:24:27 2015 +0200 selinux/nlmsg: add XFRM_MSG_MIGRATE commit 8d465bb777179c4bea731b828ec484088cc9fbc1 upstream. This command is missing. Fixes: 5c79de6e79cd ("[XFRM]: User interface for handling XFRM_MSG_MIGRATE") Reported-by: Stephen Smalley Signed-off-by: Nicolas Dichtel Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 28e0c160a50326fd86ea0bd6effe4a2b67d1de45 Author: Nicolas Dichtel Date: Fri Apr 10 16:24:26 2015 +0200 selinux/nlmsg: add XFRM_MSG_REPORT commit b0b59b0056acd6f157a04cc895f7e24692fb08aa upstream. This command is missing. Fixes: 97a64b4577ae ("[XFRM]: Introduce XFRM_MSG_REPORT.") Reported-by: Stephen Smalley Signed-off-by: Nicolas Dichtel Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 07213eed86c17c544bb10568fc04e49e03730ab7 Author: Al Viro Date: Sat Mar 21 20:08:18 2015 -0400 sg_start_req(): make sure that there's not too many elements in iovec commit 451a2886b6bf90e2fb378f7c46c655450fb96e81 upstream. unfortunately, allowing an arbitrary 16bit value means a possibility of overflow in the calculation of total number of pages in bio_map_user_iov() - we rely on there being no more than PAGE_SIZE members of sum in the first loop there. If that sum wraps around, we end up allocating too small array of pointers to pages and it's easy to overflow it in the second loop. X-Coverup: TINC (and there's no lumber cartel either) Signed-off-by: Al Viro [bwh: s/MAX_UIOVEC/UIO_MAXIOV/. This was fixed upstream by commit fdc81f45e9f5 ("sg_start_req(): use import_iovec()"), but we don't have that function.] Signed-off-by: Ben Hutchings commit d6de5ca93fd6425dcdb21cc341365991c0c444cc Author: Dave Olson Date: Thu Apr 2 21:28:45 2015 -0700 powerpc: Fix missing L2 cache size in /sys/devices/system/cpu commit f7e9e358362557c3aa2c1ec47490f29fe880a09e upstream. This problem appears to have been introduced in 2.6.29 by commit 93197a36a9c1 "Rewrite sysfs processor cache info code". This caused lscpu to error out on at least e500v2 devices, eg: error: cannot open /sys/devices/system/cpu/cpu0/cache/index2/size: No such file or directory Some embedded powerpc systems use cache-size in DTS for the unified L2 cache size, not d-cache-size, so we need to allow for both DTS names. Added a new CACHE_TYPE_UNIFIED_D cache_type_info structure to handle this. Fixes: 93197a36a9c1 ("powerpc: Rewrite sysfs processor cache info code") Signed-off-by: Dave Olson Signed-off-by: Michael Ellerman [bwh: Backported to 3.2: - Adjust context - Preserve __cpuinit attribute on cache_do_one_devnode_unified()] Signed-off-by: Ben Hutchings commit 6cc0e3dd8ad7858810b37cbf39f4e9f0debb0712 Author: Michael Gernoth Date: Thu Apr 9 23:42:15 2015 +0200 ALSA: emu10k1: don't deadlock in proc-functions commit 91bf0c2dcb935a87e5c0795f5047456b965fd143 upstream. The functions snd_emu10k1_proc_spdif_read and snd_emu1010_fpga_read acquire the emu_lock before accessing the FPGA. The function used to access the FPGA (snd_emu1010_fpga_read) also tries to take the emu_lock which causes a deadlock. Remove the outer locking in the proc-functions (guarding only the already safe fpga read) to prevent this deadlock. [removed superfluous flags variables too -- tiwai] Signed-off-by: Michael Gernoth Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 83911b9e069169fffd82212f478952d474ee1e8d Author: K. Y. Srinivasan Date: Fri Mar 27 00:27:18 2015 -0700 scsi: storvsc: Fix a bug in copy_from_bounce_buffer() commit 8de580742fee8bc34d116f57a20b22b9a5f08403 upstream. We may exit this function without properly freeing up the maapings we may have acquired. Fix the bug. Signed-off-by: K. Y. Srinivasan Reviewed-by: Long Li Signed-off-by: James Bottomley [bwh: Backported to 3.2: - Adjust filename - Keep using kmap_atomic()/kunmap_atomic(), not the sg_-prefixed functions] Signed-off-by: Ben Hutchings commit 1ea590d49d06394e1f073653ba99be404484e54d Author: Aravind Gopalakrishnan Date: Thu Apr 9 10:51:48 2015 +0200 x86/iommu: Fix header comments regarding standard and _FINISH macros commit b44915927ca88084a7292e4ddd4cf91036f365e1 upstream. The comment line regarding IOMMU_INIT and IOMMU_INIT_FINISH macros is incorrect: "The standard vs the _FINISH differs in that the _FINISH variant will continue detecting other IOMMUs in the call list..." It should be "..the *standard* variant will continue detecting..." Fix that. Also, make it readable while at it. Signed-off-by: Aravind Gopalakrishnan Signed-off-by: Borislav Petkov Cc: H. Peter Anvin Cc: Thomas Gleixner Cc: konrad.wilk@oracle.com Fixes: 6e9636693373 ("x86, iommu: Update header comments with appropriate naming") Link: http://lkml.kernel.org/r/1428508017-5316-1-git-send-email-Aravind.Gopalakrishnan@amd.com Signed-off-by: Ingo Molnar Signed-off-by: Ben Hutchings commit 505a9c1793dd997d1d45ecdacace4837249199f8 Author: Nicolas Dichtel Date: Wed Apr 8 18:36:42 2015 +0200 selinux/nlmsg: add XFRM_MSG_[NEW|GET]SADINFO commit 5b5800fad072133e4a9c2efbf735baaac83dec86 upstream. These commands are missing. Fixes: 28d8909bc790 ("[XFRM]: Export SAD info.") Signed-off-by: Nicolas Dichtel Signed-off-by: David S. Miller [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 1991a690154033cbc5efe246444b179bc0be6d71 Author: Nicolas Dichtel Date: Wed Apr 8 18:36:41 2015 +0200 selinux/nlmsg: add XFRM_MSG_GETSPDINFO commit 5e6deebafb45fb271ae6939d48832e920b8fb74e upstream. This command is missing. Fixes: ecfd6b183780 ("[XFRM]: Export SPD info") Signed-off-by: Nicolas Dichtel Signed-off-by: David S. Miller [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 74f9ee201a77eaad7192e24d1a37d3ea018dc45c Author: Sowmini Varadhan Date: Wed Apr 8 12:33:45 2015 -0400 RDS: Documentation: Document AF_RDS, PF_RDS and SOL_RDS correctly. commit ebe96e641dee2cbd135ee802ae7e40c361640088 upstream. AF_RDS, PF_RDS and SOL_RDS are available in header files, and there is no need to get their values from /proc. Document this correctly. Fixes: 0c5f9b8830aa ("RDS: Documentation") Signed-off-by: Sowmini Varadhan Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit a14933644ecedf73067b13ef10d73eb216d74858 Author: Ulrik De Bie Date: Mon Apr 6 15:35:38 2015 -0700 Input: elantech - fix absolute mode setting on some ASUS laptops commit bd884149aca61de269fd9bad83fe2a4232ffab21 upstream. On ASUS TP500LN and X750JN, the touchpad absolute mode is reset each time set_rate is done. In order to fix this, we will verify the firmware version, and if it matches the one in those laptops, the set_rate function is overloaded with a function elantech_set_rate_restore_reg_07 that performs the set_rate with the original function, followed by a restore of reg_07 (the register that sets the absolute mode on elantech v4 hardware). Also the ASUS TP500LN and X750JN firmware version, capabilities, and button constellation is added to elantech.c Reported-and-tested-by: George Moutsopoulos Signed-off-by: Ulrik De Bie Signed-off-by: Dmitry Torokhov [bwh: Backported to 3.2: - Adjust context - Drop the insertion into a comment we don't have] Signed-off-by: Ben Hutchings commit bf2011ac7616484ebd38d8970ba5c3d2d80eef5d Author: Alexander Duyck Date: Tue Mar 31 14:19:10 2015 -0700 jhash: Update jhash_[321]words functions to use correct initval commit 2e7056c433216f406b90a003aa0ba42e19d3bdcf upstream. Looking over the implementation for jhash2 and comparing it to jhash_3words I realized that the two hashes were in fact very different. Doing a bit of digging led me to "The new jhash implementation" in which lookup2 was supposed to have been replaced with lookup3. In reviewing the patch I noticed that jhash2 had originally initialized a and b to JHASH_GOLDENRATIO and c to initval, but after the patch a, b, and c were initialized to initval + (length << 2) + JHASH_INITVAL. However the changes in jhash_3words simply replaced the initialization of a and b with JHASH_INITVAL. This change corrects what I believe was an oversight so that a, b, and c in jhash_3words all have the same value added consisting of initval + (length << 2) + JHASH_INITVAL so that jhash2 and jhash_3words will now produce the same hash result given the same inputs. Fixes: 60d509c823cca ("The new jhash implementation") Signed-off-by: Alexander Duyck Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 64bd2394daf84a6ec29fa5a4b6d39ef45625df81 Author: Lukas Czerner Date: Fri Apr 3 10:46:58 2015 -0400 ext4: make fsync to sync parent dir in no-journal for real this time commit e12fb97222fc41e8442896934f76d39ef99b590a upstream. Previously commit 14ece1028b3ed53ffec1b1213ffc6acaf79ad77c added a support for for syncing parent directory of newly created inodes to make sure that the inode is not lost after a power failure in no-journal mode. However this does not work in majority of cases, namely: - if the directory has inline data - if the directory is already indexed - if the directory already has at least one block and: - the new entry fits into it - or we've successfully converted it to indexed So in those cases we might lose the inode entirely even after fsync in the no-journal mode. This also includes ext2 default mode obviously. I've noticed this while running xfstest generic/321 and even though the test should fail (we need to run fsck after a crash in no-journal mode) I could not find a newly created entries even when if it was fsynced before. Fix this by adjusting the ext4_add_entry() successful exit paths to set the inode EXT4_STATE_NEWENTRY so that fsync has the chance to fsync the parent directory as well. Signed-off-by: Lukas Czerner Signed-off-by: Theodore Ts'o Reviewed-by: Jan Kara Cc: Frank Mayhar [bwh: Backported to 3.2: inline data is not supported] Signed-off-by: Ben Hutchings commit 738f1509ae86591d59092f9942b059ce09716504 Author: Pascal Huerst Date: Thu Apr 2 10:17:40 2015 +0200 ASoC: cs4271: Increase delay time after reset commit 74ff960222d90999508b4ba0d3449f796695b6d5 upstream. The delay time after a reset in the codec probe callback was too short, and did not work on certain hw because the codec needs more time to power on. This increases the delay time from 1us to 1ms. Signed-off-by: Pascal Huerst Acked-by: Brian Austin Signed-off-by: Mark Brown [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit c72fbde01bc60208d3a0c1cc985a5457ea8e0ee0 Author: Huacai Chen Date: Sun Mar 29 10:54:05 2015 +0800 MIPS: Hibernate: flush TLB entries earlier commit 2a21dc7c196209d94cb570a0d340faa6c760f7f8 upstream. We found that TLB mismatch not only happens after kernel resume, but also happens during snapshot restore. So move it to the beginning of swsusp_arch_suspend(). Signed-off-by: Huacai Chen Cc: Steven J. Hill Cc: linux-mips@linux-mips.org Cc: Fuxin Zhang Cc: Zhangjin Wu Patchwork: https://patchwork.linux-mips.org/patch/9621/ Signed-off-by: Ralf Baechle Signed-off-by: Ben Hutchings commit a43724adb415f21865d66d7fb8bc5b71626740ec Author: Larry Finger Date: Mon Mar 23 18:14:10 2015 -0500 rtlwifi: rtl8192cu: Add new USB ID commit 2f92b314f4daff2117847ac5343c54d3d041bf78 upstream. USB ID 2001:330d is used for a D-Link DWA-131. Signed-off-by: Larry Finger Signed-off-by: Kalle Valo Signed-off-by: Ben Hutchings commit 0e75ad3733bf2086beb13b493c73f168a691e6e4 Author: Andrey Ryabinin Date: Fri Mar 20 15:42:27 2015 +0100 ARM: 8320/1: fix integer overflow in ELF_ET_DYN_BASE commit 8defb3367fcd19d1af64c07792aade0747b54e0f upstream. Usually ELF_ET_DYN_BASE is 2/3 of TASK_SIZE. With 3G/1G user/kernel split this is not so, because 2*TASK_SIZE overflows 32 bits, so the actual value of ELF_ET_DYN_BASE is: (2 * TASK_SIZE / 3) = 0x2a000000 When ASLR is disabled PIE binaries will load at ELF_ET_DYN_BASE address. On 32bit platforms AddressSanitzer uses addresses [0x20000000 - 0x40000000] for shadow memory [1]. So ASan doesn't work for PIE binaries when ASLR disabled as it fails to map shadow memory. Also after Kees's 'split ET_DYN ASLR from mmap ASLR' patchset PIE binaries has a high chance of loading somewhere in between [0x2a000000 - 0x40000000] even if ASLR enabled. This makes ASan with PIE absolutely incompatible. Fix overflow by dividing TASK_SIZE prior to multiplying. After this patch ELF_ET_DYN_BASE equals to (for CONFIG_VMSPLIT_3G=y): (TASK_SIZE / 3 * 2) = 0x7f555554 [1] https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerAlgorithm#Mapping Signed-off-by: Andrey Ryabinin Reported-by: Maria Guseva Signed-off-by: Russell King Signed-off-by: Ben Hutchings commit 07489bed80696168a3e43212f63832e55e18b4ae Author: David Sterba Date: Wed Mar 25 19:26:41 2015 +0100 btrfs: don't accept bare namespace as a valid xattr commit 3c3b04d10ff1811a27f86684ccd2f5ba6983211d upstream. Due to insufficient check in btrfs_is_valid_xattr, this unexpectedly works: $ touch file $ setfattr -n user. -v 1 file $ getfattr -d file user.="1" ie. the missing attribute name after the namespace. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94291 Reported-by: William Douglas Signed-off-by: David Sterba Signed-off-by: Chris Mason [bwh: Backported to 3.2: XATTR_BTRFS_PREFIX is not supported] Signed-off-by: Ben Hutchings commit d7aac3477aa40744eb9c101a163a910d4bc7b27a Author: Filipe Manana Date: Mon Mar 23 14:07:40 2015 +0000 Btrfs: fix log tree corruption when fs mounted with -o discard commit dcc82f4783ad91d4ab654f89f37ae9291cdc846a upstream. While committing a transaction we free the log roots before we write the new super block. Freeing the log roots implies marking the disk location of every node/leaf (metadata extent) as pinned before the new super block is written. This is to prevent the disk location of log metadata extents from being reused before the new super block is written, otherwise we would have a corrupted log tree if before the new super block is written a crash/reboot happens and the location of any log tree metadata extent ended up being reused and rewritten. Even though we pinned the log tree's metadata extents, we were issuing a discard against them if the fs was mounted with the -o discard option, resulting in corruption of the log tree if a crash/reboot happened before writing the new super block - the next time the fs was mounted, during the log replay process we would find nodes/leafs of the log btree with a content full of zeroes, causing the process to fail and require the use of the tool btrfs-zero-log to wipeout the log tree (and all data previously fsynced becoming lost forever). Fix this by not doing a discard when pinning an extent. The discard will be done later when it's safe (after the new super block is committed) at extent-tree.c:btrfs_finish_extent_commit(). Fixes: e688b7252f78 (Btrfs: fix extent pinning bugs in the tree log) Signed-off-by: Filipe Manana Signed-off-by: Chris Mason Signed-off-by: Ben Hutchings commit d10a0e6883ab52708de46ebc0bae09c424c6c91a Author: K. Y. Srinivasan Date: Thu Mar 19 08:11:34 2015 -0700 Drivers: hv: vmbus: Don't wait after requesting offers commit 73cffdb65e679b98893f484063462c045adcf212 upstream. Don't wait after sending request for offers to the host. This wait is unnecessary and simply adds 5 seconds to the boot time. Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: deleted variable t was declared as int] Signed-off-by: Ben Hutchings commit e406cf29146f6aa1213a573dcc96c661c4a485c5 Author: Brian Norris Date: Sat Feb 28 02:23:28 2015 -0800 UBI: fix check for "too many bytes" commit 299d0c5b27346a77a0777c993372bf8777d4f2e5 upstream. The comparison from the previous line seems to have been erroneously (partially) copied-and-pasted onto the next. The second line should be checking req.bytes, not req.lnum. Coverity CID #139400 Signed-off-by: Brian Norris [rw: Fixed comparison] Signed-off-by: Richard Weinberger Signed-off-by: Ben Hutchings commit a966861972654ab3fdfd736e8932e4c4798b34bf Author: Brian Norris Date: Sat Feb 28 02:23:27 2015 -0800 UBI: initialize LEB number variable commit f16db8071ce18819fbd705ddcc91c6f392fb61f8 upstream. In some of the 'out_not_moved' error paths, lnum may be used uninitialized. Don't ignore the warning; let's fix it. This uninitialized variable doesn't have much visible effect in the end, since we just schedule the PEB for erasure, and its LEB number doesn't really matter (it just gets printed in debug messages). But let's get it straight anyway. Coverity CID #113449 Signed-off-by: Brian Norris Signed-off-by: Richard Weinberger [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 4d1519d8538a6a91ffcd10d56a15f538804b5bad Author: Brian Norris Date: Sat Feb 28 02:23:26 2015 -0800 UBI: fix out of bounds write commit d74adbdb9abf0d2506a6c4afa534d894f28b763f upstream. If aeb->len >= vol->reserved_pebs, we should not be writing aeb into the PEB->LEB mapping. Caught by Coverity, CID #711212. Signed-off-by: Brian Norris Signed-off-by: Richard Weinberger [bwh: Backported to 3.2: adjust context; s/leb/seb/g] Signed-off-by: Ben Hutchings commit 5daa0af639b0be923694f1e12f3029f0562f8dfc Author: Brian Norris Date: Sat Feb 28 02:23:25 2015 -0800 UBI: account for bitflips in both the VID header and data commit 8eef7d70f7c6772c3490f410ee2bceab3b543fa1 upstream. We are completely discarding the earlier value of 'bitflips', which could reflect a bitflip found in ubi_io_read_vid_hdr(). Let's use the bitwise OR of header and data 'bitflip' statuses instead. Coverity CID #1226856 Signed-off-by: Brian Norris Signed-off-by: Richard Weinberger [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings commit ccb0032b68ef886cc581f7f31f86114704681a94 Author: Sudip Mukherjee Date: Tue Mar 24 16:29:32 2015 +0530 staging: panel: fix lcd type commit 2c20d92dad5db6440cfa88d811b69fd605240ce4 upstream. the lcd type as defined in the Kconfig is not matching in the code. as a result the rs, rw and en pins were getting interchanged. Kconfig defines the value of PANEL_LCD to be 1 if we select custom configuration but in the code LCD_TYPE_CUSTOM is defined as 5. my hardware is LCD_TYPE_CUSTOM, but the pins were assigned to it as pins of LCD_TYPE_OLD, and it was not working. Now values are corrected with referenece to the values defined in Kconfig and it is working. checked on JHD204A lcd with LCD_TYPE_CUSTOM configuration. Signed-off-by: Sudip Mukherjee Acked-by: Willy Tarreau Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: parameter description was split across two lines] Signed-off-by: Ben Hutchings commit c29889982fd1ba3ff260c33b2312a3971217ed9c Author: Oliver Neukum Date: Fri Mar 20 14:29:34 2015 +0100 cdc-wdm: fix endianness bug in debug statements commit 323ece54e0761198946ecd0c2091f1d2bfdfcb64 upstream. Values directly from descriptors given in debug statements must be converted to native endianness. Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit e9a498d91caee0e874f998ddad613f4363aaa4fa Author: Sergej Sawazki Date: Tue Mar 24 21:13:22 2015 +0100 ASoC: wm8741: Fix rates constraints values commit 8787041d9bb832b9449b1eb878cedcebce42c61a upstream. The WM8741 DAC supports the following typical audio sampling rates: 44.1kHz, 88.2kHz, 176.4kHz (eg: with a master clock of 22.5792MHz) 32kHz, 48kHz, 96kHz, 192kHz (eg: with a master clock of 24.576MHz) For the rates lists, we should use 82000 instead of 88235, 176400 instead of 1764000 and 192000 instead of 19200 (seems to be a typo). Signed-off-by: Sergej Sawazki Acked-by: Charles Keepax Signed-off-by: Mark Brown [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 3a0e4c9233a128776793b86d016057032329af89 Author: mancha security Date: Wed Mar 18 18:47:25 2015 +0100 lib: memzero_explicit: use barrier instead of OPTIMIZER_HIDE_VAR commit 0b053c9518292705736329a8fe20ef4686ffc8e9 upstream. OPTIMIZER_HIDE_VAR(), as defined when using gcc, is insufficient to ensure protection from dead store optimization. For the random driver and crypto drivers, calls are emitted ... $ gdb vmlinux (gdb) disassemble memzero_explicit Dump of assembler code for function memzero_explicit: 0xffffffff813a18b0 <+0>: push %rbp 0xffffffff813a18b1 <+1>: mov %rsi,%rdx 0xffffffff813a18b4 <+4>: xor %esi,%esi 0xffffffff813a18b6 <+6>: mov %rsp,%rbp 0xffffffff813a18b9 <+9>: callq 0xffffffff813a7120 0xffffffff813a18be <+14>: pop %rbp 0xffffffff813a18bf <+15>: retq End of assembler dump. (gdb) disassemble extract_entropy [...] 0xffffffff814a5009 <+313>: mov %r12,%rdi 0xffffffff814a500c <+316>: mov $0xa,%esi 0xffffffff814a5011 <+321>: callq 0xffffffff813a18b0 0xffffffff814a5016 <+326>: mov -0x48(%rbp),%rax [...] ... but in case in future we might use facilities such as LTO, then OPTIMIZER_HIDE_VAR() is not sufficient to protect gcc from a possible eviction of the memset(). We have to use a compiler barrier instead. Minimal test example when we assume memzero_explicit() would *not* be a call, but would have been *inlined* instead: static inline void memzero_explicit(void *s, size_t count) { memset(s, 0, count); } int main(void) { char buff[20]; snprintf(buff, sizeof(buff) - 1, "test"); printf("%s", buff); memzero_explicit(buff, sizeof(buff)); return 0; } With := OPTIMIZER_HIDE_VAR(): (gdb) disassemble main Dump of assembler code for function main: [...] 0x0000000000400464 <+36>: callq 0x400410 0x0000000000400469 <+41>: xor %eax,%eax 0x000000000040046b <+43>: add $0x28,%rsp 0x000000000040046f <+47>: retq End of assembler dump. With := barrier(): (gdb) disassemble main Dump of assembler code for function main: [...] 0x0000000000400464 <+36>: callq 0x400410 0x0000000000400469 <+41>: movq $0x0,(%rsp) 0x0000000000400471 <+49>: movq $0x0,0x8(%rsp) 0x000000000040047a <+58>: movl $0x0,0x10(%rsp) 0x0000000000400482 <+66>: xor %eax,%eax 0x0000000000400484 <+68>: add $0x28,%rsp 0x0000000000400488 <+72>: retq End of assembler dump. As can be seen, movq, movq, movl are being emitted inlined via memset(). Reference: http://thread.gmane.org/gmane.linux.kernel.cryptoapi/13764/ Fixes: d4c5efdb9777 ("random: add and use memzero_explicit() for clearing data") Cc: Theodore Ts'o Signed-off-by: mancha security Signed-off-by: Daniel Borkmann Acked-by: Hannes Frederic Sowa Acked-by: Stephan Mueller Signed-off-by: Herbert Xu Signed-off-by: Ben Hutchings commit e6388ad732ed8498ba68c9fab3d4a1fdc06c3328 Author: Alex Deucher Date: Tue Feb 24 11:29:21 2015 -0500 drm/radeon: fix doublescan modes (v2) commit fd99a0943ffaa0320ea4f69d09ed188f950c0432 upstream. Use the correct flags for atom. v2: handle DRM_MODE_FLAG_DBLCLK Signed-off-by: Alex Deucher Signed-off-by: Ben Hutchings commit 1fec2a0340939821bc28baa7f37188297a7da780 Author: Baruch Siach Date: Mon Mar 9 19:20:30 2015 +0200 pinctrl: fix example .get_group_pins implementation signature commit 838d030bda9e2da5f9dcf7251f4e117c6258cb2f upstream. The callback function signature has changed in commit a5818a8bd0 (pinctrl: get_group_pins() const fixes) Fixes: a5818a8bd0 ('pinctrl: get_group_pins() const fixes') Cc: Stephen Warren Signed-off-by: Baruch Siach Signed-off-by: Linus Walleij Signed-off-by: Ben Hutchings commit 98a1fb97fe6f6b40e008669070de090fb6c87d62 Author: Krzysztof Kozlowski Date: Thu Mar 12 08:44:00 2015 +0100 compal-laptop: Check return value of power_supply_register commit 1915a718b1872edffcb13e5436a9f7302d3d36f0 upstream. The return value of power_supply_register() call was not checked and even on error probe() function returned 0. If registering failed then during unbind the driver tried to unregister power supply which was not actually registered. This could lead to memory corruption because power_supply_unregister() unconditionally cleans up given power supply. Fix this by checking return status of power_supply_register() call. In case of failure, clean up sysfs entries and fail the probe. Signed-off-by: Krzysztof Kozlowski Fixes: 9be0fcb5ed46 ("compal-laptop: add JHL90, battery & hwmon interface") Signed-off-by: Sebastian Reichel [bwh: Backported to 3.2: insert the appropriate cleanup code as there is no common 'remove' label] Signed-off-by: Ben Hutchings commit 48a3b3037c59087b07f61c2b981382df479c9902 Author: Felipe Balbi Date: Mon Dec 30 12:33:53 2013 -0600 usb: musb: core: fix TX/RX endpoint order commit e3c93e1a3f35be4cf1493d3ccfb0c6d9209e4922 upstream. As per Mentor Graphics' documentation, we should always handle TX endpoints before RX endpoints. This patch fixes that error while also updating some hard-to-read comments which were scattered around musb_interrupt(). This patch should be backported as far back as possible since this error has been in the driver since it's conception. Signed-off-by: Felipe Balbi [bwh: Backported to 3.2: adjust context, indentation] Signed-off-by: Ben Hutchings commit 3e8e73f832aec6c73a61fb3f53816bf4ee37c723 Author: Ekaterina Tumanova Date: Tue Mar 3 09:54:41 2015 +0100 KVM: s390: Zero out current VMDB of STSI before including level3 data. commit b75f4c9afac2604feb971441116c07a24ecca1ec upstream. s390 documentation requires words 0 and 10-15 to be reserved and stored as zeros. As we fill out all other fields, we can memset the full structure. Signed-off-by: Ekaterina Tumanova Reviewed-by: David Hildenbrand Signed-off-by: Christian Borntraeger Signed-off-by: Ben Hutchings commit f655adbac3de7ce92b2b0f9ce2d426b55b600e38 Author: Sabrina Dubroca Date: Thu Feb 26 05:35:41 2015 +0000 e1000: add dummy allocator to fix race condition between mtu change and netpoll commit 08e8331654d1d7b2c58045e549005bc356aa7810 upstream. There is a race condition between e1000_change_mtu's cleanups and netpoll, when we change the MTU across jumbo size: Changing MTU frees all the rx buffers: e1000_change_mtu -> e1000_down -> e1000_clean_all_rx_rings -> e1000_clean_rx_ring Then, close to the end of e1000_change_mtu: pr_info -> ... -> netpoll_poll_dev -> e1000_clean -> e1000_clean_rx_irq -> e1000_alloc_rx_buffers -> e1000_alloc_frag And when we come back to do the rest of the MTU change: e1000_up -> e1000_configure -> e1000_configure_rx -> e1000_alloc_jumbo_rx_buffers alloc_jumbo finds the buffers already != NULL, since data (shared with page in e1000_rx_buffer->rxbuf) has been re-alloc'd, but it's garbage, or at least not what is expected when in jumbo state. This results in an unusable adapter (packets don't get through), and a NULL pointer dereference on the next call to e1000_clean_rx_ring (other mtu change, link down, shutdown): BUG: unable to handle kernel NULL pointer dereference at (null) IP: [] put_compound_page+0x7e/0x330 [...] Call Trace: [] put_page+0x55/0x60 [] e1000_clean_rx_ring+0x134/0x200 [] e1000_clean_all_rx_rings+0x45/0x60 [] e1000_down+0x1c0/0x1d0 [] ? deactivate_slab+0x7f0/0x840 [] e1000_change_mtu+0xdc/0x170 [] dev_set_mtu+0xa0/0x140 [] do_setlink+0x218/0xac0 [] ? nla_parse+0xb9/0x120 [] rtnl_newlink+0x6d0/0x890 [] ? kvm_clock_read+0x20/0x40 [] ? sched_clock_cpu+0xa8/0x100 [] rtnetlink_rcv_msg+0x92/0x260 By setting the allocator to a dummy version, netpoll can't mess up our rx buffers. The allocator is set back to a sane value in e1000_configure_rx. Fixes: edbbb3ca1077 ("e1000: implement jumbo receive with partial descriptors") Signed-off-by: Sabrina Dubroca Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Ben Hutchings commit c551ce23bfc919747797f8d0fa9ecf319508378d Author: K. Y. Srinivasan Date: Fri Feb 27 11:26:04 2015 -0800 Drivers: hv: vmbus: Fix a bug in the error path in vmbus_open() commit 40384e4bbeb9f2651fe9bffc0062d9f31ef625bf upstream. Correctly rollback state if the failure occurs after we have handed over the ownership of the buffer to the host. Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 5f7c3cbe030b39e9adb584c2be1fb842bfc0899f Author: Alexander Ploumistos Date: Fri Feb 13 21:05:11 2015 +0200 Bluetooth: ath3k: Add support Atheros AR5B195 combo Mini PCIe card commit 2eeff0b4317a02f0e281df891d990194f0737aae upstream. Add 04f2:aff1 to ath3k.c supported devices list and btusb.c blacklist, so that the device can load the ath3k firmware and re-enumerate itself as an AR3011 device. T: Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04f2 ProdID=aff1 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: Alexander Ploumistos Signed-off-by: Marcel Holtmann Signed-off-by: Ben Hutchings