commit 2d5f6b0413359df065fd02d695c08bbc7d998bbd Author: Greg Kroah-Hartman Date: Sun Jan 31 11:23:48 2016 -0800 Linux 4.1.17 commit d17367a77457f556e7614f2e80db5d5a902e1268 Author: libin Date: Tue Nov 3 08:58:47 2015 +0800 recordmcount: Fix endianness handling bug for nop_mcount commit c84da8b9ad3761eef43811181c7e896e9834b26b upstream. In nop_mcount, shdr->sh_offset and welp->r_offset should handle endianness properly, otherwise it will trigger Segmentation fault if the recordmcount main and file.o have different endianness. Link: http://lkml.kernel.org/r/563806C7.7070606@huawei.com Signed-off-by: Li Bin Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 1f6d936d33f4b5875ca3aed0e8084e0fb56d4e0d Author: Yang Shi Date: Wed Nov 18 10:48:55 2015 -0800 arm64: restore bogomips information in /proc/cpuinfo commit 92e788b749862ebe9920360513a718e5dd4da7a9 upstream. As previously reported, some userspace applications depend on bogomips showed by /proc/cpuinfo. Although there is much less legacy impact on aarch64 than arm, it does break libvirt. This patch reverts commit 326b16db9f69 ("arm64: delay: don't bother reporting bogomips in /proc/cpuinfo"), but with some tweak due to context change and without the pr_info(). Fixes: 326b16db9f69 ("arm64: delay: don't bother reporting bogomips in /proc/cpuinfo") Signed-off-by: Yang Shi Acked-by: Will Deacon Cc: # 3.12+ Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 705164dbe08ff960bce54eb2edad20f8def2b247 Author: Guenter Roeck Date: Sat Nov 28 08:52:04 2015 -0800 mn10300: Select CONFIG_HAVE_UID16 to fix build failure commit c86576ea114a9a881cf7328dc7181052070ca311 upstream. mn10300 builds fail with fs/stat.c: In function 'cp_old_stat': fs/stat.c:163:2: error: 'old_uid_t' undeclared ipc/util.c: In function 'ipc64_perm_to_ipc_perm': ipc/util.c:540:2: error: 'old_uid_t' undeclared Select CONFIG_HAVE_UID16 and remove local definition of CONFIG_UID16 to fix the problem. Fixes: fbc416ff8618 ("arm64: fix building without CONFIG_UID16") Cc: Arnd Bergmann Acked-by: Arnd Bergmann Acked-by: Acked-by: David Howells Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 57b7d61c2d89e3e0665b9cdcc8fb73b08d10f0c2 Author: Al Viro Date: Tue Dec 8 12:22:47 2015 -0500 fix the regression from "direct-io: Fix negative return from dio read beyond eof" commit 2d4594acbf6d8f75a27f3578476b6a27d8b13ebb upstream. Sure, it's better to bail out of past-the-eof read and return 0 than return a bogus negative value on such. Only we'd better make sure we are bailing out with 0 and not -ENOMEM... Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 8885e7f3d76a9d42eb4fd97a3cfc5a8ac7f6f2ff Author: Jan Kara Date: Mon Nov 30 10:15:42 2015 -0700 direct-io: Fix negative return from dio read beyond eof commit 74cedf9b6c603f2278a05bc91b140b32b434d0b5 upstream. Assume a filesystem with 4KB blocks. When a file has size 1000 bytes and we issue direct IO read at offset 1024, blockdev_direct_IO() reads the tail of the last block and the logic for handling short DIO reads in dio_complete() results in a return value -24 (1000 - 1024) which obviously confuses userspace. Fix the problem by bailing out early once we sample i_size and can reliably check that direct IO read starts beyond i_size. Reported-by: Avi Kivity Fixes: 9fe55eea7e4b444bafc42fa0000cc2d1d2847275 CC: Steven Whitehouse Signed-off-by: Jan Kara Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit b824d64b153a9683aed6730e9f093a7102c36799 Author: Salva Peiró Date: Wed Oct 7 07:09:26 2015 -0300 media/vivid-osd: fix info leak in ioctl commit eda98796aff0d9bf41094b06811f5def3b4c333c upstream. The vivid_fb_ioctl() code fails to initialize the 16 _reserved bytes of struct fb_vblank after the ->hcount member. Add an explicit memset(0) before filling the structure to avoid the info leak. Signed-off-by: Salva Peiró Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 3f0cf7dcf712ef29ca47cd2f0b20292aab6e1d59 Author: Al Viro Date: Tue Dec 1 19:52:12 2015 +0000 staging: lustre: echo_copy.._lsm() dereferences userland pointers directly commit 9225c0b7b976dd9ceac2b80727a60d8fcb906a62 upstream. missing get_user() Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit b50a2b556d1e487c2430e13042a98325adca0be5 Author: Richard Purdie Date: Fri Sep 18 16:31:33 2015 -0700 HID: core: Avoid uninitialized buffer access commit 79b568b9d0c7c5d81932f4486d50b38efdd6da6d upstream. hid_connect adds various strings to the buffer but they're all conditional. You can find circumstances where nothing would be written to it but the kernel will still print the supposedly empty buffer with printk. This leads to corruption on the console/in the logs. Ensure buf is initialized to an empty string. Signed-off-by: Richard Purdie [dvhart: Initialize string to "" rather than assign buf[0] = NULL;] Cc: Jiri Kosina Cc: linux-input@vger.kernel.org Signed-off-by: Darren Hart Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit c777e9ab2a44c802ca1453b820f9e3ff5dbe11a4 Author: Mikulas Patocka Date: Mon Nov 30 14:47:46 2015 -0500 parisc iommu: fix panic due to trying to allocate too large region commit e46e31a3696ae2d66f32c207df3969613726e636 upstream. When using the Promise TX2+ SATA controller on PA-RISC, the system often crashes with kernel panic, for example just writing data with the dd utility will make it crash. Kernel panic - not syncing: drivers/parisc/sba_iommu.c: I/O MMU @ 000000000000a000 is out of mapping resources CPU: 0 PID: 18442 Comm: mkspadfs Not tainted 4.4.0-rc2 #2 Backtrace: [<000000004021497c>] show_stack+0x14/0x20 [<0000000040410bf0>] dump_stack+0x88/0x100 [<000000004023978c>] panic+0x124/0x360 [<0000000040452c18>] sba_alloc_range+0x698/0x6a0 [<0000000040453150>] sba_map_sg+0x260/0x5b8 [<000000000c18dbb4>] ata_qc_issue+0x264/0x4a8 [libata] [<000000000c19535c>] ata_scsi_translate+0xe4/0x220 [libata] [<000000000c19a93c>] ata_scsi_queuecmd+0xbc/0x320 [libata] [<0000000040499bbc>] scsi_dispatch_cmd+0xfc/0x130 [<000000004049da34>] scsi_request_fn+0x6e4/0x970 [<00000000403e95a8>] __blk_run_queue+0x40/0x60 [<00000000403e9d8c>] blk_run_queue+0x3c/0x68 [<000000004049a534>] scsi_run_queue+0x2a4/0x360 [<000000004049be68>] scsi_end_request+0x1a8/0x238 [<000000004049de84>] scsi_io_completion+0xfc/0x688 [<0000000040493c74>] scsi_finish_command+0x17c/0x1d0 The cause of the crash is not exhaustion of the IOMMU space, there is plenty of free pages. The function sba_alloc_range is called with size 0x11000, thus the pages_needed variable is 0x11. The function sba_search_bitmap is called with bits_wanted 0x11 and boundary size is 0x10 (because dma_get_seg_boundary(dev) returns 0xffff). The function sba_search_bitmap attempts to allocate 17 pages that must not cross 16-page boundary - it can't satisfy this requirement (iommu_is_span_boundary always returns true) and fails even if there are many free entries in the IOMMU space. How did it happen that we try to allocate 17 pages that don't cross 16-page boundary? The cause is in the function iommu_coalesce_chunks. This function tries to coalesce adjacent entries in the scatterlist. The function does several checks if it may coalesce one entry with the next, one of those checks is this: if (startsg->length + dma_len > max_seg_size) break; When it finishes coalescing adjacent entries, it allocates the mapping: sg_dma_len(contig_sg) = dma_len; dma_len = ALIGN(dma_len + dma_offset, IOVP_SIZE); sg_dma_address(contig_sg) = PIDE_FLAG | (iommu_alloc_range(ioc, dev, dma_len) << IOVP_SHIFT) | dma_offset; It is possible that (startsg->length + dma_len > max_seg_size) is false (we are just near the 0x10000 max_seg_size boundary), so the funcion decides to coalesce this entry with the next entry. When the coalescing succeeds, the function performs dma_len = ALIGN(dma_len + dma_offset, IOVP_SIZE); And now, because of non-zero dma_offset, dma_len is greater than 0x10000. iommu_alloc_range (a pointer to sba_alloc_range) is called and it attempts to allocate 17 pages for a device that must not cross 16-page boundary. To fix the bug, we must make sure that dma_len after addition of dma_offset and alignment doesn't cross the segment boundary. I.e. change if (startsg->length + dma_len > max_seg_size) break; to if (ALIGN(dma_len + dma_offset + startsg->length, IOVP_SIZE) > max_seg_size) break; This patch makes this change (it precalculates max_seg_boundary at the beginning of the function iommu_coalesce_chunks). I also added a check that the mapping length doesn't exceed dma_get_seg_boundary(dev) (it is not needed for Promise TX2+ SATA, but it may be needed for other devices that have dma_get_seg_boundary lower than dma_get_max_seg_size). Signed-off-by: Mikulas Patocka Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit e479822e1e3a518250cb7c9be51ed8f857dfab86 Author: David Woodhouse Date: Thu Oct 15 09:28:06 2015 +0100 iommu/vt-d: Fix ATSR handling for Root-Complex integrated endpoints commit d14053b3c714178525f22660e6aaf41263d00056 upstream. The VT-d specification says that "Software must enable ATS on endpoint devices behind a Root Port only if the Root Port is reported as supporting ATS transactions." We walk up the tree to find a Root Port, but for integrated devices we don't find one — we get to the host bridge. In that case we *should* allow ATS. Currently we don't, which means that we are incorrectly failing to use ATS for the integrated graphics. Fix that. We should never break out of this loop "naturally" with bus==NULL, since we'll always find bridge==NULL in that case (and now return 1). So remove the check for (!bridge) after the loop, since it can never happen. If it did, it would be worthy of a BUG_ON(!bridge). But since it'll oops anyway in that case, that'll do just as well. Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit f21731a54a666aec2242849207f6369dc976079c Author: Will Deacon Date: Thu Dec 10 16:05:36 2015 +0000 arm64: mm: ensure that the zero page is visible to the page table walker commit 32d6397805d00573ce1fa55f408ce2bca15b0ad3 upstream. In paging_init, we allocate the zero page, memset it to zero and then point TTBR0 to it in order to avoid speculative fetches through the identity mapping. In order to guarantee that the freshly zeroed page is indeed visible to the page table walker, we need to execute a dsb instruction prior to writing the TTBR. Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 3e804c36399e7b39b39eff847a44f3933f48ac52 Author: John Blackwood Date: Mon Dec 7 11:50:34 2015 +0000 arm64: Clear out any singlestep state on a ptrace detach operation commit 5db4fd8c52810bd9740c1240ebf89223b171aa70 upstream. Make sure to clear out any ptrace singlestep state when a ptrace(2) PTRACE_DETACH call is made on arm64 systems. Otherwise, the previously ptraced task will die off with a SIGTRAP signal if the debugger just previously singlestepped the ptraced task. Signed-off-by: John Blackwood [will: added comment to justify why this is in the arch code] Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 426bfb6a778411df0245373aa0979ce11d8fff85 Author: Ard Biesheuvel Date: Thu Dec 3 09:25:22 2015 +0100 ARM/arm64: KVM: correct PTE uncachedness check commit 0de58f852875a0f0dcfb120bb8433e4e73c7803b upstream. Commit e6fab5442345 ("ARM/arm64: KVM: test properly for a PTE's uncachedness") modified the logic to test whether a HYP or stage-2 mapping needs flushing, from [incorrectly] interpreting the page table attributes to [incorrectly] checking whether the PFN that backs the mapping is covered by host system RAM. The PFN number is part of the output of the translation, not the input, so we have to use pte_pfn() on the contents of the PTE, not __phys_to_pfn() on the HYP virtual address or stage-2 intermediate physical address. Fixes: e6fab5442345 ("ARM/arm64: KVM: test properly for a PTE's uncachedness") Tested-by: Pavel Fedin Signed-off-by: Ard Biesheuvel Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit 3f0b20e1a2d8e9eadbe8ca81dfc7e3d324b813da Author: Arnd Bergmann Date: Fri Nov 20 12:12:21 2015 +0100 arm64: fix building without CONFIG_UID16 commit fbc416ff86183e2203cdf975e2881d7c164b0271 upstream. As reported by Michal Simek, building an ARM64 kernel with CONFIG_UID16 disabled currently fails because the system call table still needs to reference the individual function entry points that are provided by kernel/sys_ni.c in this case, and the declarations are hidden inside of #ifdef CONFIG_UID16: arch/arm64/include/asm/unistd32.h:57:8: error: 'sys_lchown16' undeclared here (not in a function) __SYSCALL(__NR_lchown, sys_lchown16) I believe this problem only exists on ARM64, because older architectures tend to not need declarations when their system call table is built in assembly code, while newer architectures tend to not need UID16 support. ARM64 only uses these system calls for compatibility with 32-bit ARM binaries. This changes the CONFIG_UID16 check into CONFIG_HAVE_UID16, which is set unconditionally on ARM64 with CONFIG_COMPAT, so we see the declarations whenever we need them, but otherwise the behavior is unchanged. Fixes: af1839eb4bd4 ("Kconfig: clean up the long arch list for the UID16 config option") Signed-off-by: Arnd Bergmann Acked-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit f94cf332a8061d7cec4940d29f58b6f5a1e3f765 Author: Marc Zyngier Date: Mon Nov 16 10:28:17 2015 +0000 arm64: KVM: Fix AArch32 to AArch64 register mapping commit c0f0963464c24e034b858441205455bf2a5d93ad upstream. When running a 32bit guest under a 64bit hypervisor, the ARMv8 architecture defines a mapping of the 32bit registers in the 64bit space. This includes banked registers that are being demultiplexed over the 64bit ones. On exceptions caused by an operation involving a 32bit register, the HW exposes the register number in the ESR_EL2 register. It was so far understood that SW had to distinguish between AArch32 and AArch64 accesses (based on the current AArch32 mode and register number). It turns out that I misinterpreted the ARM ARM, and the clue is in D1.20.1: "For some exceptions, the exception syndrome given in the ESR_ELx identifies one or more register numbers from the issued instruction that generated the exception. Where the exception is taken from an Exception level using AArch32 these register numbers give the AArch64 view of the register." Which means that the HW is already giving us the translated version, and that we shouldn't try to interpret it at all (for example, doing an MMIO operation from the IRQ mode using the LR register leads to very unexpected behaviours). The fix is thus not to perform a call to vcpu_reg32() at all from vcpu_reg(), and use whatever register number is supplied directly. The only case we need to find out about the mapping is when we actively generate a register access, which only occurs when injecting a fault in a guest. Reviewed-by: Robin Murphy Signed-off-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Greg Kroah-Hartman commit 959cad3a68a7b47370f092fd76be3ea411127515 Author: Ard Biesheuvel Date: Tue Nov 10 15:11:20 2015 +0100 ARM/arm64: KVM: test properly for a PTE's uncachedness commit e6fab54423450d699a09ec2b899473a541f61971 upstream. The open coded tests for checking whether a PTE maps a page as uncached use a flawed '(pte_val(xxx) & CONST) != CONST' pattern, which is not guaranteed to work since the type of a mapping is not a set of mutually exclusive bits For HYP mappings, the type is an index into the MAIR table (i.e, the index itself does not contain any information whatsoever about the type of the mapping), and for stage-2 mappings it is a bit field where normal memory and device types are defined as follows: #define MT_S2_NORMAL 0xf #define MT_S2_DEVICE_nGnRE 0x1 I.e., masking *and* comparing with the latter matches on the former, and we have been getting lucky merely because the S2 device mappings also have the PTE_UXN bit set, or we would misidentify memory mappings as device mappings. Since the unmap_range() code path (which contains one instance of the flawed test) is used both for HYP mappings and stage-2 mappings, and considering the difference between the two, it is non-trivial to fix this by rewriting the tests in place, as it would involve passing down the type of mapping through all the functions. However, since HYP mappings and stage-2 mappings both deal with host physical addresses, we can simply check whether the mapping is backed by memory that is managed by the host kernel, and only perform the D-cache maintenance if this is the case. Signed-off-by: Ard Biesheuvel Tested-by: Pavel Fedin Reviewed-by: Christoffer Dall Signed-off-by: Christoffer Dall Signed-off-by: Greg Kroah-Hartman commit 75f1fde24b56a5838c22f6eea2a16593a1b80fb4 Author: Lorenzo Pieralisi Date: Tue Nov 17 11:50:51 2015 +0000 arm64: kernel: pause/unpause function graph tracer in cpu_suspend() commit de818bd4522c40ea02a81b387d2fa86f989c9623 upstream. The function graph tracer adds instrumentation that is required to trace both entry and exit of a function. In particular the function graph tracer updates the "return address" of a function in order to insert a trace callback on function exit. Kernel power management functions like cpu_suspend() are called upon power down entry with functions called "finishers" that are in turn called to trigger the power down sequence but they may not return to the kernel through the normal return path. When the core resumes from low-power it returns to the cpu_suspend() function through the cpu_resume path, which leaves the trace stack frame set-up by the function tracer in an incosistent state upon return to the kernel when tracing is enabled. This patch fixes the issue by pausing/resuming the function graph tracer on the thread executing cpu_suspend() (ie the function call that subsequently triggers the "suspend finishers"), so that the function graph tracer state is kept consistent across functions that enter power down states and never return by effectively disabling graph tracer while they are executing. Fixes: 819e50e25d0c ("arm64: Add ftrace support") Signed-off-by: Lorenzo Pieralisi Reported-by: Catalin Marinas Reported-by: AKASHI Takahiro Suggested-by: Steven Rostedt Acked-by: Steven Rostedt Cc: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit f22c64cd0745e9b6bc1c68d82affe9dd2151625a Author: Zi Shen Lim Date: Wed Nov 4 20:43:59 2015 -0800 arm64: bpf: fix mod-by-zero case commit 14e589ff4aa3f28a5424e92b6495ecb8950080f7 upstream. Turns out in the case of modulo by zero in a BPF program: A = A % X; (X == 0) the expected behavior is to terminate with return value 0. The bug in JIT is exposed by a new test case [1]. [1] https://lkml.org/lkml/2015/11/4/499 Signed-off-by: Zi Shen Lim Reported-by: Yang Shi Reported-by: Xi Wang CC: Alexei Starovoitov Fixes: e54bcde3d69d ("arm64: eBPF JIT compiler") Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 40c5dde6eb7e1d23ab8f4152d28bd71b5e30f8f6 Author: Zi Shen Lim Date: Tue Nov 3 22:56:44 2015 -0800 arm64: bpf: fix div-by-zero case commit 251599e1d6906621f49218d7b474ddd159e58f3b upstream. In the case of division by zero in a BPF program: A = A / X; (X == 0) the expected behavior is to terminate with return value 0. This is confirmed by the test case introduced in commit 86bf1721b226 ("test_bpf: add tests checking that JIT/interpreter sets A and X to 0."). Reported-by: Yang Shi Tested-by: Yang Shi CC: Xi Wang CC: Alexei Starovoitov CC: linux-arm-kernel@lists.infradead.org CC: linux-kernel@vger.kernel.org Fixes: e54bcde3d69d ("arm64: eBPF JIT compiler") Signed-off-by: Zi Shen Lim Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 8831ded35abdb2ff1eaaa10c3e756a8d45a9d171 Author: Li Bin Date: Fri Oct 30 16:31:04 2015 +0800 recordmcount: arm64: Replace the ignored mcount call into nop commit 2ee8a74f2a5da913637f75a19a0da0e7a08c0f86 upstream. By now, the recordmcount only records the function that in following sections: .text/.ref.text/.sched.text/.spinlock.text/.irqentry.text/ .kprobes.text/.text.unlikely For the function that not in these sections, the call mcount will be in place and not be replaced when kernel boot up. And it will bring performance overhead, such as do_mem_abort (in .exception.text section). This patch make the call mcount to nop for this case in recordmcount. Link: http://lkml.kernel.org/r/1446019445-14421-1-git-send-email-huawei.libin@huawei.com Link: http://lkml.kernel.org/r/1446193864-24593-4-git-send-email-huawei.libin@huawei.com Cc: Cc: Cc: Acked-by: Will Deacon Signed-off-by: Li Bin Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit a33b8ff3d6cb996ae964dc04a99c536f31fc463f Author: Ulrich Weigand Date: Tue Jan 12 23:14:23 2016 +1100 powerpc/module: Handle R_PPC64_ENTRY relocations commit a61674bdfc7c2bf909c4010699607b62b69b7bec upstream. GCC 6 will include changes to generated code with -mcmodel=large, which is used to build kernel modules on powerpc64le. This was necessary because the large model is supposed to allow arbitrary sizes and locations of the code and data sections, but the ELFv2 global entry point prolog still made the unconditional assumption that the TOC associated with any particular function can be found within 2 GB of the function entry point: func: addis r2,r12,(.TOC.-func)@ha addi r2,r2,(.TOC.-func)@l .localentry func, .-func To remove this assumption, GCC will now generate instead this global entry point prolog sequence when using -mcmodel=large: .quad .TOC.-func func: .reloc ., R_PPC64_ENTRY ld r2, -8(r12) add r2, r2, r12 .localentry func, .-func The new .reloc triggers an optimization in the linker that will replace this new prolog with the original code (see above) if the linker determines that the distance between .TOC. and func is in range after all. Since this new relocation is now present in module object files, the kernel module loader is required to handle them too. This patch adds support for the new relocation and implements the same optimization done by the GNU linker. Signed-off-by: Ulrich Weigand Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 1e2c53f19cefa0689798e4a37ecb73f2c8a7d7c7 Author: Ulrich Weigand Date: Tue Jan 12 23:14:22 2016 +1100 scripts/recordmcount.pl: support data in text section on powerpc commit 2e50c4bef77511b42cc226865d6bc568fa7f8769 upstream. If a text section starts out with a data blob before the first function start label, disassembly parsing doing in recordmcount.pl gets confused on powerpc, leading to creation of corrupted module objects. This was not a problem so far since the compiler would never create such text sections. However, this has changed with a recent change in GCC 6 to support distances of > 2GB between a function and its assoicated TOC in the ELFv2 ABI, exposing this problem. There is already code in recordmcount.pl to handle such data blobs on the sparc64 platform. This patch uses the same method to handle those on powerpc as well. Acked-by: Steven Rostedt Signed-off-by: Ulrich Weigand Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 4126ac7cdcefc74d2e14f975f43615f09d263c2c Author: Boqun Feng Date: Mon Nov 2 09:30:32 2015 +0800 powerpc: Make {cmp}xchg* and their atomic_ versions fully ordered commit 81d7a3294de7e9828310bbf986a67246b13fa01e upstream. According to memory-barriers.txt, xchg*, cmpxchg* and their atomic_ versions all need to be fully ordered, however they are now just RELEASE+ACQUIRE, which are not fully ordered. So also replace PPC_RELEASE_BARRIER and PPC_ACQUIRE_BARRIER with PPC_ATOMIC_ENTRY_BARRIER and PPC_ATOMIC_EXIT_BARRIER in __{cmp,}xchg_{u32,u64} respectively to guarantee fully ordered semantics of atomic{,64}_{cmp,}xchg() and {cmp,}xchg(), as a complement of commit b97021f85517 ("powerpc: Fix atomic_xxx_return barrier semantics") This patch depends on patch "powerpc: Make value-returning atomics fully ordered" for PPC_ATOMIC_ENTRY_BARRIER definition. Signed-off-by: Boqun Feng Reviewed-by: Paul E. McKenney Acked-by: Peter Zijlstra (Intel) Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit af69fe1f70afcd8cf5aa71320e012ca2abedbabe Author: Boqun Feng Date: Mon Nov 2 09:30:31 2015 +0800 powerpc: Make value-returning atomics fully ordered commit 49e9cf3f0c04bf76ffa59242254110309554861d upstream. According to memory-barriers.txt: > Any atomic operation that modifies some state in memory and returns > information about the state (old or new) implies an SMP-conditional > general memory barrier (smp_mb()) on each side of the actual > operation ... Which mean these operations should be fully ordered. However on PPC, PPC_ATOMIC_ENTRY_BARRIER is the barrier before the actual operation, which is currently "lwsync" if SMP=y. The leading "lwsync" can not guarantee fully ordered atomics, according to Paul Mckenney: https://lkml.org/lkml/2015/10/14/970 To fix this, we define PPC_ATOMIC_ENTRY_BARRIER as "sync" to guarantee the fully-ordered semantics. This also makes futex atomics fully ordered, which can avoid possible memory ordering problems if userspace code relies on futex system call for fully ordered semantics. Fixes: b97021f85517 ("powerpc: Fix atomic_xxx_return barrier semantics") Signed-off-by: Boqun Feng Reviewed-by: Paul E. McKenney Acked-by: Peter Zijlstra (Intel) Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 1e14dd5a386443f9dd4237f7da4df3669d903f0d Author: Stewart Smith Date: Fri Dec 11 12:08:23 2015 +1100 powerpc/powernv: pr_warn_once on unsupported OPAL_MSG type commit 98da62b716a3b24ab8e77453c9a8a954124c18cd upstream. When running on newer OPAL firmware that supports sending extra OPAL_MSG types, we would print a warning on *every* message received. This could be a problem for kernels that don't support OPAL_MSG_OCC on machines that are running real close to thermal limits and the OCC is throttling the chip. For a kernel that is paying attention to the message queue, we could get these notifications quite often. Conceivably, future message types could also come fairly often, and printing that we didn't understand them 10,000 times provides no further information than printing them once. Signed-off-by: Stewart Smith Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit a54d3a4234121d8a9749331f7b10e6ff02f886ba Author: Michael Neuling Date: Thu Nov 19 15:44:45 2015 +1100 powerpc/tm: Check for already reclaimed tasks commit 7f821fc9c77a9b01fe7b1d6e72717b33d8d64142 upstream. Currently we can hit a scenario where we'll tm_reclaim() twice. This results in a TM bad thing exception because the second reclaim occurs when not in suspend mode. The scenario in which this can happen is the following. We attempt to deliver a signal to userspace. To do this we need obtain the stack pointer to write the signal context. To get this stack pointer we must tm_reclaim() in case we need to use the checkpointed stack pointer (see get_tm_stackpointer()). Normally we'd then return directly to userspace to deliver the signal without going through __switch_to(). Unfortunatley, if at this point we get an error (such as a bad userspace stack pointer), we need to exit the process. The exit will result in a __switch_to(). __switch_to() will attempt to save the process state which results in another tm_reclaim(). This tm_reclaim() now causes a TM Bad Thing exception as this state has already been saved and the processor is no longer in TM suspend mode. Whee! This patch checks the state of the MSR to ensure we are TM suspended before we attempt the tm_reclaim(). If we've already saved the state away, we should no longer be in TM suspend mode. This has the additional advantage of checking for a potential TM Bad Thing exception. Found using syscall fuzzer. Fixes: fb09692e71f1 ("powerpc: Add reclaim and recheckpoint functions for context switching transactional memory processes") Signed-off-by: Michael Neuling Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 567a215dd1586dae787f21b8f3e484018763a710 Author: Michael Neuling Date: Thu Nov 19 15:44:44 2015 +1100 powerpc/tm: Block signal return setting invalid MSR state commit d2b9d2a5ad5ef04ff978c9923d19730cb05efd55 upstream. Currently we allow both the MSR T and S bits to be set by userspace on a signal return. Unfortunately this is a reserved configuration and will cause a TM Bad Thing exception if attempted (via rfid). This patch checks for this case in both the 32 and 64 bit signals code. If both T and S are set, we mark the context as invalid. Found using a syscall fuzzer. Fixes: 2b0a576d15e0 ("powerpc: Add new transactional memory state to the signal context") Signed-off-by: Michael Neuling Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit eeca98948d8c4922e6deb16bfc9ee0bd9902dbb0 Author: Dan Streetman Date: Thu Oct 29 09:51:16 2015 -0400 xfrm: dst_entries_init() per-net dst_ops [ Upstream commit a8a572a6b5f2a79280d6e302cb3c1cb1fbaeb3e8 ] Remove the dst_entries_init/destroy calls for xfrm4 and xfrm6 dst_ops templates; their dst_entries counters will never be used. Move the xfrm dst_ops initialization from the common xfrm/xfrm_policy.c to xfrm4/xfrm4_policy.c and xfrm6/xfrm6_policy.c, and call dst_entries_init and dst_entries_destroy for each net namespace. The ipv4 and ipv6 xfrms each create dst_ops template, and perform dst_entries_init on the templates. The template values are copied to each net namespace's xfrm.xfrm*_dst_ops. The problem there is the dst_ops pcpuc_entries field is a percpu counter and cannot be used correctly by simply copying it to another object. The result of this is a very subtle bug; changes to the dst entries counter from one net namespace may sometimes get applied to a different net namespace dst entries counter. This is because of how the percpu counter works; it has a main count field as well as a pointer to the percpu variables. Each net namespace maintains its own main count variable, but all point to one set of percpu variables. When any net namespace happens to change one of the percpu variables to outside its small batch range, its count is moved to the net namespace's main count variable. So with multiple net namespaces operating concurrently, the dst_ops entries counter can stray from the actual value that it should be; if counts are consistently moved from one net namespace to another (which my testing showed is likely), then one net namespace winds up with a negative dst_ops count while another winds up with a continually increasing count, eventually reaching its gc_thresh limit, which causes all new traffic on the net namespace to fail with -ENOBUFS. Signed-off-by: Dan Streetman Signed-off-by: Dan Streetman Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit 139bd872dc6868296a992a2b8142b4daba964d3f Author: Joe Jin Date: Mon Oct 19 13:37:17 2015 +0800 xen-netfront: update num_queues to real created [ Upstream commit ca88ea1247dfee094e2467a3578eaec9bdf0833a ] Sometimes xennet_create_queues() may failed to created all requested queues, we need to update num_queues to real created to avoid NULL pointer dereference. Signed-off-by: Joe Jin Cc: Boris Ostrovsky Cc: Konrad Rzeszutek Wilk Cc: Wei Liu Cc: Ian Campbell Cc: David S. Miller Reviewed-by: Boris Ostrovsky Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a1edfa789d1a7f111dffb142bacbc6f2aa9d2e29 Author: Wei Liu Date: Thu Sep 10 11:18:58 2015 +0100 xen-netfront: respect user provided max_queues [ Upstream commit 32a844056fd43dda647e1c3c6b9983bdfa04d17d ] Originally that parameter was always reset to num_online_cpus during module initialisation, which renders it useless. The fix is to only set max_queues to num_online_cpus when user has not provided a value. Signed-off-by: Wei Liu Cc: David Vrabel Reviewed-by: David Vrabel Tested-by: David Vrabel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 21edf40b5ccbdf48720758fe525f3cbc19c8a202 Author: Wei Liu Date: Thu Sep 10 11:18:57 2015 +0100 xen-netback: respect user provided max_queues [ Upstream commit 4c82ac3c37363e8c4ded6a5fe1ec5fa756b34df3 ] Originally that parameter was always reset to num_online_cpus during module initialisation, which renders it useless. The fix is to only set max_queues to num_online_cpus when user has not provided a value. Reported-by: Johnny Strom Signed-off-by: Wei Liu Reviewed-by: David Vrabel Acked-by: Ian Campbell Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 534e9016cd88ccd577b226b7172e5cd079f5fb02 Author: Karl Heiss Date: Thu Sep 24 12:15:07 2015 -0400 sctp: Prevent soft lockup when sctp_accept() is called during a timeout event [ Upstream commit 635682a14427d241bab7bbdeebb48a7d7b91638e ] A case can occur when sctp_accept() is called by the user during a heartbeat timeout event after the 4-way handshake. Since sctp_assoc_migrate() changes both assoc->base.sk and assoc->ep, the bh_sock_lock in sctp_generate_heartbeat_event() will be taken with the listening socket but released with the new association socket. The result is a deadlock on any future attempts to take the listening socket lock. Note that this race can occur with other SCTP timeouts that take the bh_lock_sock() in the event sctp_accept() is called. BUG: soft lockup - CPU#9 stuck for 67s! [swapper:0] ... RIP: 0010:[] [] _spin_lock+0x1e/0x30 RSP: 0018:ffff880028323b20 EFLAGS: 00000206 RAX: 0000000000000002 RBX: ffff880028323b20 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff880028323be0 RDI: ffff8804632c4b48 RBP: ffffffff8100bb93 R08: 0000000000000000 R09: 0000000000000000 R10: ffff880610662280 R11: 0000000000000100 R12: ffff880028323aa0 R13: ffff8804383c3880 R14: ffff880028323a90 R15: ffffffff81534225 FS: 0000000000000000(0000) GS:ffff880028320000(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 00000000006df528 CR3: 0000000001a85000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process swapper (pid: 0, threadinfo ffff880616b70000, task ffff880616b6cab0) Stack: ffff880028323c40 ffffffffa01c2582 ffff880614cfb020 0000000000000000 0100000000000000 00000014383a6c44 ffff8804383c3880 ffff880614e93c00 ffff880614e93c00 0000000000000000 ffff8804632c4b00 ffff8804383c38b8 Call Trace: [] ? sctp_rcv+0x492/0xa10 [sctp] [] ? nf_iterate+0x69/0xb0 [] ? ip_local_deliver_finish+0x0/0x2d0 [] ? nf_hook_slow+0x76/0x120 [] ? ip_local_deliver_finish+0x0/0x2d0 [] ? ip_local_deliver_finish+0xdd/0x2d0 [] ? ip_local_deliver+0x98/0xa0 [] ? ip_rcv_finish+0x12d/0x440 [] ? ip_rcv+0x275/0x350 [] ? __netif_receive_skb+0x4ab/0x750 ... With lockdep debugging: ===================================== [ BUG: bad unlock balance detected! ] ------------------------------------- CslRx/12087 is trying to release lock (slock-AF_INET) at: [] sctp_generate_timeout_event+0x40/0xe0 [sctp] but there are no more locks to release! other info that might help us debug this: 2 locks held by CslRx/12087: #0: (&asoc->timers[i]){+.-...}, at: [] run_timer_softirq+0x16f/0x3e0 #1: (slock-AF_INET){+.-...}, at: [] sctp_generate_timeout_event+0x23/0xe0 [sctp] Ensure the socket taken is also the same one that is released by saving a copy of the socket before entering the timeout event critical section. Signed-off-by: Karl Heiss Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 490c963c1eb9a7f5f74446f4b9738c9fb1b8e325 Author: Ido Schimmel Date: Mon Jan 18 17:30:22 2016 +0200 team: Replace rcu_read_lock with a mutex in team_vlan_rx_kill_vid [ Upstream commit 60a6531bfe49555581ccd65f66a350cc5693fcde ] We can't be within an RCU read-side critical section when deleting VLANs, as underlying drivers might sleep during the hardware operation. Therefore, replace the RCU critical section with a mutex. This is consistent with team_vlan_rx_add_vid. Fixes: 3d249d4ca7d0 ("net: introduce ethernet teaming device") Acked-by: Jiri Pirko Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 95785b105fa2f784ad7b6be0238338b648ed892a Author: Sven Eckelmann Date: Tue Jan 5 12:06:20 2016 +0100 batman-adv: Drop immediate orig_node free function [ Upstream commit 42eff6a617e23b691f8e4467f4687ed7245a92db ] It is not allowed to free the memory of an object which is part of a list which is protected by rcu-read-side-critical sections without making sure that no other context is accessing the object anymore. This usually happens by removing the references to this object and then waiting until the rcu grace period is over and no one (allowedly) accesses it anymore. But the _now functions ignore this completely. They free the object directly even when a different context still tries to access it. This has to be avoided and thus these functions must be removed and all functions have to use batadv_orig_node_free_ref. Fixes: 72822225bd41 ("batman-adv: Fix rcu_barrier() miss due to double call_rcu() in TT code") Signed-off-by: Sven Eckelmann Signed-off-by: Marek Lindner Signed-off-by: Antonio Quartulli Signed-off-by: Greg Kroah-Hartman commit ae3eb44e0e8b4e0fe4ab51e0a91d76517abc1e30 Author: Sven Eckelmann Date: Tue Jan 5 12:06:25 2016 +0100 batman-adv: Drop immediate batadv_hard_iface free function [ Upstream commit b4d922cfc9c08318eeb77d53b7633740e6b0efb0 ] It is not allowed to free the memory of an object which is part of a list which is protected by rcu-read-side-critical sections without making sure that no other context is accessing the object anymore. This usually happens by removing the references to this object and then waiting until the rcu grace period is over and no one (allowedly) accesses it anymore. But the _now functions ignore this completely. They free the object directly even when a different context still tries to access it. This has to be avoided and thus these functions must be removed and all functions have to use batadv_hardif_free_ref. Fixes: 89652331c00f ("batman-adv: split tq information in neigh_node struct") Signed-off-by: Sven Eckelmann Signed-off-by: Marek Lindner Signed-off-by: Antonio Quartulli Signed-off-by: Greg Kroah-Hartman commit 924224c6e44a393a2a41385d699230384ea23df5 Author: Sven Eckelmann Date: Tue Jan 5 12:06:24 2016 +0100 batman-adv: Drop immediate neigh_ifinfo free function [ Upstream commit ae3e1e36e3cb6c686a7a2725af20ca86aa46d62a ] It is not allowed to free the memory of an object which is part of a list which is protected by rcu-read-side-critical sections without making sure that no other context is accessing the object anymore. This usually happens by removing the references to this object and then waiting until the rcu grace period is over and no one (allowedly) accesses it anymore. But the _now functions ignore this completely. They free the object directly even when a different context still tries to access it. This has to be avoided and thus these functions must be removed and all functions have to use batadv_neigh_ifinfo_free_ref. Fixes: 89652331c00f ("batman-adv: split tq information in neigh_node struct") Signed-off-by: Sven Eckelmann Signed-off-by: Marek Lindner Signed-off-by: Antonio Quartulli Signed-off-by: Greg Kroah-Hartman commit 620493a90c78ce1bd150d48ca6f624ad964e0c8d Author: Sven Eckelmann Date: Tue Jan 5 12:06:22 2016 +0100 batman-adv: Drop immediate batadv_neigh_node free function [ Upstream commit 2baa753c276f27f8e844637561ad597867aa6fb6 ] It is not allowed to free the memory of an object which is part of a list which is protected by rcu-read-side-critical sections without making sure that no other context is accessing the object anymore. This usually happens by removing the references to this object and then waiting until the rcu grace period is over and no one (allowedly) accesses it anymore. But the _now functions ignore this completely. They free the object directly even when a different context still tries to access it. This has to be avoided and thus these functions must be removed and all functions have to use batadv_neigh_node_free_ref. Fixes: 89652331c00f ("batman-adv: split tq information in neigh_node struct") Signed-off-by: Sven Eckelmann Signed-off-by: Marek Lindner Signed-off-by: Antonio Quartulli Signed-off-by: Greg Kroah-Hartman commit 9d188c6b672c7d205f43da74b534d2114371edc5 Author: Sven Eckelmann Date: Tue Jan 5 12:06:21 2016 +0100 batman-adv: Drop immediate batadv_orig_ifinfo free function [ Upstream commit deed96605f5695cb945e0b3d79429581857a2b9d ] It is not allowed to free the memory of an object which is part of a list which is protected by rcu-read-side-critical sections without making sure that no other context is accessing the object anymore. This usually happens by removing the references to this object and then waiting until the rcu grace period is over and no one (allowedly) accesses it anymore. But the _now functions ignore this completely. They free the object directly even when a different context still tries to access it. This has to be avoided and thus these functions must be removed and all functions have to use batadv_orig_ifinfo_free_ref. Fixes: 7351a4822d42 ("batman-adv: split out router from orig_node") Signed-off-by: Sven Eckelmann Signed-off-by: Marek Lindner Signed-off-by: Antonio Quartulli Signed-off-by: Greg Kroah-Hartman commit 34c5bf7c7bf4e285274e28a36b08cbf3da5bd3e3 Author: Sven Eckelmann Date: Tue Jan 5 12:06:19 2016 +0100 batman-adv: Avoid recursive call_rcu for batadv_nc_node [ Upstream commit 44e8e7e91d6c7c7ab19688750f7257292640d1a0 ] The batadv_nc_node_free_ref function uses call_rcu to delay the free of the batadv_nc_node object until no (already started) rcu_read_lock is enabled anymore. This makes sure that no context is still trying to access the object which should be removed. But batadv_nc_node also contains a reference to orig_node which must be removed. The reference drop of orig_node was done in the call_rcu function batadv_nc_node_free_rcu but should actually be done in the batadv_nc_node_release function to avoid nested call_rcus. This is important because rcu_barrier (e.g. batadv_softif_free or batadv_exit) will not detect the inner call_rcu as relevant for its execution. Otherwise this barrier will most likely be inserted in the queue before the callback of the first call_rcu was executed. The caller of rcu_barrier will therefore continue to run before the inner call_rcu callback finished. Fixes: d56b1705e28c ("batman-adv: network coding - detect coding nodes and remove these after timeout") Signed-off-by: Sven Eckelmann Signed-off-by: Marek Lindner Signed-off-by: Antonio Quartulli Signed-off-by: Greg Kroah-Hartman commit 016cb1d02db9840a62c0e2a465ffd6617eacffc7 Author: Sven Eckelmann Date: Thu Jan 14 15:28:19 2016 +0100 batman-adv: Avoid recursive call_rcu for batadv_bla_claim [ Upstream commit 63b399272294e7a939cde41792dca38c549f0484 ] The batadv_claim_free_ref function uses call_rcu to delay the free of the batadv_bla_claim object until no (already started) rcu_read_lock is enabled anymore. This makes sure that no context is still trying to access the object which should be removed. But batadv_bla_claim also contains a reference to backbone_gw which must be removed. The reference drop of backbone_gw was done in the call_rcu function batadv_claim_free_rcu but should actually be done in the batadv_claim_release function to avoid nested call_rcus. This is important because rcu_barrier (e.g. batadv_softif_free or batadv_exit) will not detect the inner call_rcu as relevant for its execution. Otherwise this barrier will most likely be inserted in the queue before the callback of the first call_rcu was executed. The caller of rcu_barrier will therefore continue to run before the inner call_rcu callback finished. Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code") Signed-off-by: Sven Eckelmann Acked-by: Simon Wunderlich Signed-off-by: Marek Lindner Signed-off-by: Antonio Quartulli Signed-off-by: Greg Kroah-Hartman commit a50a93cc99286dc444c7e5ccc7dfb9d58c2d346d Author: Ben Hutchings Date: Sun Nov 1 16:22:53 2015 +0000 ppp, slip: Validate VJ compression slot parameters completely [ Upstream commit 4ab42d78e37a294ac7bc56901d563c642e03c4ae ] Currently slhc_init() treats out-of-range values of rslots and tslots as equivalent to 0, except that if tslots is too large it will dereference a null pointer (CVE-2015-7799). Add a range-check at the top of the function and make it return an ERR_PTR() on error instead of NULL. Change the callers accordingly. Compile-tested only. Reported-by: 郭永刚 References: http://article.gmane.org/gmane.comp.security.oss.general/17908 Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5984398539a2c47834caf1b00dc9f58b7bb2e67a Author: Ben Hutchings Date: Sun Nov 1 16:21:24 2015 +0000 isdn_ppp: Add checks for allocation failure in isdn_ppp_open() [ Upstream commit 0baa57d8dc32db78369d8b5176ef56c5e2e18ab3 ] Compile-tested only. Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9ba3d77689a5d07aa5020dbf38d10ce8f641aa16 Author: Raanan Avargil Date: Thu Oct 1 04:48:53 2015 -0700 tcp/dccp: fix old style declarations [ Upstream commit 8695a144da9e500a5a60fa34c06694346ec1048f ] I’m using the compilation flag -Werror=old-style-declaration, which requires that the “inline” word would come at the beginning of the code line. $ make drivers/net/ethernet/intel/e1000e/e1000e.ko ... include/net/inet_timewait_sock.h:116:1: error: ‘inline’ is not at beginning of declaration [-Werror=old-style-declaration] static void inline inet_twsk_schedule(struct inet_timewait_sock *tw, int timeo) include/net/inet_timewait_sock.h:121:1: error: ‘inline’ is not at beginning of declaration [-Werror=old-style-declaration] static void inline inet_twsk_reschedule(struct inet_timewait_sock *tw, int timeo) Fixes: ed2e92394589 ("tcp/dccp: fix timewait races in timer handling") Signed-off-by: Raanan Avargil Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 479b539a310152b10c1747ac8c5354ed7bc25181 Author: Eric Dumazet Date: Sat Sep 19 09:08:34 2015 -0700 tcp/dccp: fix timewait races in timer handling [ Upstream commit ed2e923945892a8372ab70d2f61d364b0b6d9054 ] When creating a timewait socket, we need to arm the timer before allowing other cpus to find it. The signal allowing cpus to find the socket is setting tw_refcnt to non zero value. As we set tw_refcnt in __inet_twsk_hashdance(), we therefore need to call inet_twsk_schedule() first. This also means we need to remove tw_refcnt changes from inet_twsk_schedule() and let the caller handle it. Note that because we use mod_timer_pinned(), we have the guarantee the timer wont expire before we set tw_refcnt as we run in BH context. To make things more readable I introduced inet_twsk_reschedule() helper. When rearming the timer, we can use mod_timer_pending() to make sure we do not rearm a canceled timer. Note: This bug can possibly trigger if packets of a flow can hit multiple cpus. This does not normally happen, unless flow steering is broken somehow. This explains this bug was spotted ~5 months after its introduction. A similar fix is needed for SYN_RECV sockets in reqsk_queue_hash_req(), but will be provided in a separate patch for proper tracking. Fixes: 789f558cfb36 ("tcp/dccp: get rid of central timewait timer") Signed-off-by: Eric Dumazet Reported-by: Ying Cai Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 332fb8799ed1c701339e9b4dad3efbed245b4cf8 Author: Nikolay Aleksandrov Date: Fri Jan 15 19:03:54 2016 +0100 bridge: fix lockdep addr_list_lock false positive splat [ Upstream commit c6894dec8ea9ae05747124dce98b3b5c2e69b168 ] After promisc mode management was introduced a bridge device could do dev_set_promiscuity from its ndo_change_rx_flags() callback which in turn can be called after the bridge's addr_list_lock has been taken (e.g. by dev_uc_add). This causes a false positive lockdep splat because the port interfaces' addr_list_lock is taken when br_manage_promisc() runs after the bridge's addr list lock was already taken. To remove the false positive introduce a custom bridge addr_list_lock class and set it on bridge init. A simple way to reproduce this is with the following: $ brctl addbr br0 $ ip l add l br0 br0.100 type vlan id 100 $ ip l set br0 up $ ip l set br0.100 up $ echo 1 > /sys/class/net/br0/bridge/vlan_filtering $ brctl addif br0 eth0 Splat: [ 43.684325] ============================================= [ 43.684485] [ INFO: possible recursive locking detected ] [ 43.684636] 4.4.0-rc8+ #54 Not tainted [ 43.684755] --------------------------------------------- [ 43.684906] brctl/1187 is trying to acquire lock: [ 43.685047] (_xmit_ETHER){+.....}, at: [] dev_set_rx_mode+0x1e/0x40 [ 43.685460] but task is already holding lock: [ 43.685618] (_xmit_ETHER){+.....}, at: [] dev_uc_add+0x27/0x80 [ 43.686015] other info that might help us debug this: [ 43.686316] Possible unsafe locking scenario: [ 43.686743] CPU0 [ 43.686967] ---- [ 43.687197] lock(_xmit_ETHER); [ 43.687544] lock(_xmit_ETHER); [ 43.687886] *** DEADLOCK *** [ 43.688438] May be due to missing lock nesting notation [ 43.688882] 2 locks held by brctl/1187: [ 43.689134] #0: (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x17/0x20 [ 43.689852] #1: (_xmit_ETHER){+.....}, at: [] dev_uc_add+0x27/0x80 [ 43.690575] stack backtrace: [ 43.690970] CPU: 0 PID: 1187 Comm: brctl Not tainted 4.4.0-rc8+ #54 [ 43.691270] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.8.1-20150318_183358- 04/01/2014 [ 43.691770] ffffffff826a25c0 ffff8800369fb8e0 ffffffff81360ceb ffffffff826a25c0 [ 43.692425] ffff8800369fb9b8 ffffffff810d0466 ffff8800369fb968 ffffffff81537139 [ 43.693071] ffff88003a08c880 0000000000000000 00000000ffffffff 0000000002080020 [ 43.693709] Call Trace: [ 43.693931] [] dump_stack+0x4b/0x70 [ 43.694199] [] __lock_acquire+0x1e46/0x1e90 [ 43.694483] [] ? netlink_broadcast_filtered+0x139/0x3e0 [ 43.694789] [] ? nlmsg_notify+0x5a/0xc0 [ 43.695064] [] lock_acquire+0xe5/0x1f0 [ 43.695340] [] ? dev_set_rx_mode+0x1e/0x40 [ 43.695623] [] _raw_spin_lock_bh+0x45/0x80 [ 43.695901] [] ? dev_set_rx_mode+0x1e/0x40 [ 43.696180] [] dev_set_rx_mode+0x1e/0x40 [ 43.696460] [] dev_set_promiscuity+0x3c/0x50 [ 43.696750] [] br_port_set_promisc+0x25/0x50 [bridge] [ 43.697052] [] br_manage_promisc+0x8a/0xe0 [bridge] [ 43.697348] [] br_dev_change_rx_flags+0x1e/0x20 [bridge] [ 43.697655] [] __dev_set_promiscuity+0x132/0x1f0 [ 43.697943] [] __dev_set_rx_mode+0x82/0x90 [ 43.698223] [] dev_uc_add+0x5e/0x80 [ 43.698498] [] vlan_device_event+0x542/0x650 [8021q] [ 43.698798] [] notifier_call_chain+0x5d/0x80 [ 43.699083] [] raw_notifier_call_chain+0x16/0x20 [ 43.699374] [] call_netdevice_notifiers_info+0x6e/0x80 [ 43.699678] [] call_netdevice_notifiers+0x16/0x20 [ 43.699973] [] br_add_if+0x47e/0x4c0 [bridge] [ 43.700259] [] add_del_if+0x6e/0x80 [bridge] [ 43.700548] [] br_dev_ioctl+0xaf/0xc0 [bridge] [ 43.700836] [] dev_ifsioc+0x30c/0x3c0 [ 43.701106] [] dev_ioctl+0xf9/0x6f0 [ 43.701379] [] ? mntput_no_expire+0x5/0x450 [ 43.701665] [] ? mntput_no_expire+0xae/0x450 [ 43.701947] [] sock_do_ioctl+0x42/0x50 [ 43.702219] [] sock_ioctl+0x1e5/0x290 [ 43.702500] [] do_vfs_ioctl+0x2cb/0x5c0 [ 43.702771] [] SyS_ioctl+0x79/0x90 [ 43.703033] [] entry_SYSCALL_64_fastpath+0x16/0x7a CC: Vlad Yasevich CC: Stephen Hemminger CC: Bridge list CC: Andy Gospodarek CC: Roopa Prabhu Fixes: 2796d0c648c9 ("bridge: Automatically manage port promiscuous mode.") Reported-by: Andy Gospodarek Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2980502b9f6d3e15a4dd6695d4cfff8ec3213209 Author: Eric Dumazet Date: Fri Jan 15 04:56:56 2016 -0800 ipv6: update skb->csum when CE mark is propagated [ Upstream commit 34ae6a1aa0540f0f781dd265366036355fdc8930 ] When a tunnel decapsulates the outer header, it has to comply with RFC 6080 and eventually propagate CE mark into inner header. It turns out IP6_ECN_set_ce() does not correctly update skb->csum for CHECKSUM_COMPLETE packets, triggering infamous "hw csum failure" messages and stack traces. Signed-off-by: Eric Dumazet Acked-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit dc1cfcc266978d0213d7d4f9f813bafd4e9f709a Author: Rabin Vincent Date: Tue Jan 12 20:17:08 2016 +0100 net: bpf: reject invalid shifts [ Upstream commit 229394e8e62a4191d592842cf67e80c62a492937 ] On ARM64, a BUG() is triggered in the eBPF JIT if a filter with a constant shift that can't be encoded in the immediate field of the UBFM/SBFM instructions is passed to the JIT. Since these shifts amounts, which are negative or >= regsize, are invalid, reject them in the eBPF verifier and the classic BPF filter checker, for all architectures. Signed-off-by: Rabin Vincent Acked-by: Alexei Starovoitov Acked-by: Daniel Borkmann Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2a1e5e4ab662a159e7e5dfd229597c4752d29b3c Author: Eric Dumazet Date: Tue Jan 12 08:58:00 2016 -0800 phonet: properly unshare skbs in phonet_rcv() [ Upstream commit 7aaed57c5c2890634cfadf725173c7c68ea4cb4f ] Ivaylo Dimitrov reported a regression caused by commit 7866a621043f ("dev: add per net_device packet type chains"). skb->dev becomes NULL and we crash in __netif_receive_skb_core(). Before above commit, different kind of bugs or corruptions could happen without major crash. But the root cause is that phonet_rcv() can queue skb without checking if skb is shared or not. Many thanks to Ivaylo Dimitrov for his help, diagnosis and tests. Reported-by: Ivaylo Dimitrov Tested-by: Ivaylo Dimitrov Signed-off-by: Eric Dumazet Cc: Remi Denis-Courmont Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7d9fb947be67ec2e0811a2ab6dd0582ad1bae4db Author: Karl Heiss Date: Mon Jan 11 08:28:43 2016 -0500 bonding: Prevent IPv6 link local address on enslaved devices [ Upstream commit 03d84a5f83a67e692af00a3d3901e7820e3e84d5 ] Commit 1f718f0f4f97 ("bonding: populate neighbour's private on enslave") undoes the fix provided by commit c2edacf80e15 ("bonding / ipv6: no addrconf for slaves separately from master") by effectively setting the slave flag after the slave has been opened. If the slave comes up quickly enough, it will go through the IPv6 addrconf before the slave flag has been set and will get a link local IPv6 address. In order to ensure that addrconf knows to ignore the slave devices on state change, set IFF_SLAVE before dev_open() during bonding enslavement. Fixes: 1f718f0f4f97 ("bonding: populate neighbour's private on enslave") Signed-off-by: Karl Heiss Signed-off-by: Jay Vosburgh Reviewed-by: Jarod Wilson Signed-off-by: Andy Gospodarek Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit abefd1b4087b9b5e83e7b4e7689f8b8e3cb2899c Author: Konstantin Khlebnikov Date: Fri Jan 8 15:21:46 2016 +0300 net: preserve IP control block during GSO segmentation [ Upstream commit 9207f9d45b0ad071baa128e846d7e7ed85016df3 ] Skb_gso_segment() uses skb control block during segmentation. This patch adds 32-bytes room for previous control block which will be copied into all resulting segments. This patch fixes kernel crash during fragmenting forwarded packets. Fragmentation requires valid IP CB in skb for clearing ip options. Also patch removes custom save/restore in ovs code, now it's redundant. Signed-off-by: Konstantin Khlebnikov Link: http://lkml.kernel.org/r/CALYGNiP-0MZ-FExV2HutTvE9U-QQtkKSoE--KN=JQE5STYsjAA@mail.gmail.com Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4bb526bce19d6e4c8cc862ce304b8c072ef43366 Author: Michal Kubeček Date: Mon Jan 11 07:50:30 2016 +0100 udp: disallow UFO for sockets with SO_NO_CHECK option [ Upstream commit 40ba330227ad00b8c0cdf2f425736ff9549cc423 ] Commit acf8dd0a9d0b ("udp: only allow UFO for packets from SOCK_DGRAM sockets") disallows UFO for packets sent from raw sockets. We need to do the same also for SOCK_DGRAM sockets with SO_NO_CHECK options, even if for a bit different reason: while such socket would override the CHECKSUM_PARTIAL set by ip_ufo_append_data(), gso_size is still set and bad offloading flags warning is triggered in __skb_gso_segment(). In the IPv6 case, SO_NO_CHECK option is ignored but we need to disallow UFO for packets sent by sockets with UDP_NO_CHECK6_TX option. Signed-off-by: Michal Kubecek Tested-by: Shannon Nelson Acked-by: Hannes Frederic Sowa Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e7bbeacbafc18a7781036c6111ffd9fe9eaa6ec0 Author: Neal Cardwell Date: Mon Jan 11 13:42:43 2016 -0500 tcp_yeah: don't set ssthresh below 2 [ Upstream commit 83d15e70c4d8909d722c0d64747d8fb42e38a48f ] For tcp_yeah, use an ssthresh floor of 2, the same floor used by Reno and CUBIC, per RFC 5681 (equation 4). tcp_yeah_ssthresh() was sometimes returning a 0 or negative ssthresh value if the intended reduction is as big or bigger than the current cwnd. Congestion control modules should never return a zero or negative ssthresh. A zero ssthresh generally results in a zero cwnd, causing the connection to stall. A negative ssthresh value will be interpreted as a u32 and will set a target cwnd for PRR near 4 billion. Oleksandr Natalenko reported that a system using tcp_yeah with ECN could see a warning about a prior_cwnd of 0 in tcp_cwnd_reduction(). Testing verified that this was due to tcp_yeah_ssthresh() misbehaving in this way. Reported-by: Oleksandr Natalenko Signed-off-by: Neal Cardwell Signed-off-by: Yuchung Cheng Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit add92082e2d14367b27b0e18b0deeaedd7c1f938 Author: Eric Dumazet Date: Fri Jan 8 09:35:51 2016 -0800 ipv6: tcp: add rcu locking in tcp_v6_send_synack() [ Upstream commit 3e4006f0b86a5ae5eb0e8215f9a9e1db24506977 ] When first SYNACK is sent, we already hold rcu_read_lock(), but this is not true if a SYNACK is retransmitted, as a timer (soft) interrupt does not hold rcu_read_lock() Fixes: 45f6fad84cc30 ("ipv6: add complete rcu protection around np->opt") Reported-by: Dave Jones Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bcea43fb3164cdcdc42c710ca0cb90aa9c6a5530 Author: Sasha Levin Date: Thu Jan 7 14:52:43 2016 -0500 net: sctp: prevent writes to cookie_hmac_alg from accessing invalid memory [ Upstream commit 320f1a4a175e7cd5d3f006f92b4d4d3e2cbb7bb5 ] proc_dostring() needs an initialized destination string, while the one provided in proc_sctp_do_hmac_alg() contains stack garbage. Thus, writing to cookie_hmac_alg would strlen() that garbage and end up accessing invalid memory. Fixes: 3c68198e7 ("sctp: Make hmac algorithm selection for cookie generation dynamic") Signed-off-by: Sasha Levin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a33704eb60850ac837ef83ecc380f5f6b2aa2906 Author: Nicolas Dichtel Date: Thu Jan 7 11:26:53 2016 +0100 vxlan: fix test which detect duplicate vxlan iface [ Upstream commit 07b9b37c227cb8d88d478b4a9c5634fee514ede1 ] When a vxlan interface is created, the driver checks that there is not another vxlan interface with the same properties. To do this, it checks the existing vxlan udp socket. Since commit 1c51a9159dde, the creation of the vxlan socket is done only when the interface is set up, thus it breaks that test. Example: $ ip l a vxlan10 type vxlan id 10 group 239.0.0.10 dev eth0 dstport 0 $ ip l a vxlan11 type vxlan id 10 group 239.0.0.10 dev eth0 dstport 0 $ ip -br l | grep vxlan vxlan10 DOWN f2:55:1c:6a:fb:00 vxlan11 DOWN 7a:cb:b9:38:59:0d Instead of checking sockets, let's loop over the vxlan iface list. Fixes: 1c51a9159dde ("vxlan: fix race caused by dropping rtnl_unlock") Reported-by: Thomas Faivre Signed-off-by: Nicolas Dichtel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8f5cd6eea8115c6a4153268508369b81f84e9dce Author: Francesco Ruggeri Date: Wed Jan 6 00:18:48 2016 -0800 net: possible use after free in dst_release [ Upstream commit 07a5d38453599052aff0877b16bb9c1585f08609 ] dst_release should not access dst->flags after decrementing __refcnt to 0. The dst_entry may be in dst_busy_list and dst_gc_task may dst_destroy it before dst_release gets a chance to access dst->flags. Fixes: d69bbf88c8d0 ("net: fix a race in dst_release()") Fixes: 27b75c95f10d ("net: avoid RCU for NOCACHE dst") Signed-off-by: Francesco Ruggeri Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 02a1fef61d06bb0417b60f1233320e141266860c Author: John Fastabend Date: Tue Jan 5 09:11:36 2016 -0800 net: sched: fix missing free per cpu on qstats [ Upstream commit 73c20a8b7245273125cfe92c4b46e6fdb568a801 ] When a qdisc is using per cpu stats (currently just the ingress qdisc) only the bstats are being freed. This also free's the qstats. Fixes: b0ab6f92752b9f9d8 ("net: sched: enable per cpu qstats") Signed-off-by: John Fastabend Acked-by: Eric Dumazet Acked-by: Daniel Borkmann Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5596242a6263ece70ee14f3b6861f02b8dc82d11 Author: Rabin Vincent Date: Tue Jan 5 16:23:07 2016 +0100 net: filter: make JITs zero A for SKF_AD_ALU_XOR_X [ Upstream commit 55795ef5469290f89f04e12e662ded604909e462 ] The SKF_AD_ALU_XOR_X ancillary is not like the other ancillary data instructions since it XORs A with X while all the others replace A with some loaded value. All the BPF JITs fail to clear A if this is used as the first instruction in a filter. This was found using american fuzzy lop. Add a helper to determine if A needs to be cleared given the first instruction in a filter, and use this in the JITs. Except for ARM, the rest have only been compile-tested. Fixes: 3480593131e0 ("net: filter: get rid of BPF_S_* enum") Signed-off-by: Rabin Vincent Acked-by: Daniel Borkmann Acked-by: Alexei Starovoitov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a6b1d24893805bb4f2e7c7bc6f86a98ec37065ee Author: Hannes Frederic Sowa Date: Tue Jan 5 10:46:00 2016 +0100 bridge: Only call /sbin/bridge-stp for the initial network namespace [ Upstream commit ff62198553e43cdffa9d539f6165d3e83f8a42bc ] [I stole this patch from Eric Biederman. He wrote:] > There is no defined mechanism to pass network namespace information > into /sbin/bridge-stp therefore don't even try to invoke it except > for bridge devices in the initial network namespace. > > It is possible for unprivileged users to cause /sbin/bridge-stp to be > invoked for any network device name which if /sbin/bridge-stp does not > guard against unreasonable arguments or being invoked twice on the > same network device could cause problems. [Hannes: changed patch using netns_eq] Cc: Eric W. Biederman Signed-off-by: Eric W. Biederman Signed-off-by: Hannes Frederic Sowa Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit dc6b0ec667f67d4768e72c1b7f1bbc14ea52379c Author: willy tarreau Date: Sun Jan 10 07:54:56 2016 +0100 unix: properly account for FDs passed over unix sockets [ Upstream commit 712f4aad406bb1ed67f3f98d04c044191f0ff593 ] It is possible for a process to allocate and accumulate far more FDs than the process' limit by sending them over a unix socket then closing them to keep the process' fd count low. This change addresses this problem by keeping track of the number of FDs in flight per user and preventing non-privileged processes from having more FDs in flight than their configured FD limit. Reported-by: socketpair@gmail.com Reported-by: Tetsuo Handa Mitigates: CVE-2013-4312 (Linux 2.0+) Suggested-by: Linus Torvalds Acked-by: Hannes Frederic Sowa Signed-off-by: Willy Tarreau Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f45f0213b831305572436cdd2f7f0709fcbe2887 Author: Florian Westphal Date: Thu Dec 31 14:26:33 2015 +0100 connector: bump skb->users before callback invocation [ Upstream commit 55285bf09427c5abf43ee1d54e892f352092b1f1 ] Dmitry reports memleak with syskaller program. Problem is that connector bumps skb usecount but might not invoke callback. So move skb_get to where we invoke the callback. Reported-by: Dmitry Vyukov Signed-off-by: Florian Westphal Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c000d76ec0d8bbadb7972b374bcf7ffe34deb592 Author: Xin Long Date: Tue Dec 29 17:49:25 2015 +0800 sctp: sctp should release assoc when sctp_make_abort_user return NULL in sctp_close [ Upstream commit 068d8bd338e855286aea54e70d1c101569284b21 ] In sctp_close, sctp_make_abort_user may return NULL because of memory allocation failure. If this happens, it will bypass any state change and never free the assoc. The assoc has no chance to be freed and it will be kept in memory with the state it had even after the socket is closed by sctp_close(). So if sctp_make_abort_user fails to allocate memory, we should abort the asoc via sctp_primitive_ABORT as well. Just like the annotation in sctp_sf_cookie_wait_prm_abort and sctp_sf_do_9_1_prm_abort said, "Even if we can't send the ABORT due to low memory delete the TCB. This is a departure from our typical NOMEM handling". But then the chunk is NULL (low memory) and the SCTP_CMD_REPLY cmd would dereference the chunk pointer, and system crash. So we should add SCTP_CMD_REPLY cmd only when the chunk is not NULL, just like other places where it adds SCTP_CMD_REPLY cmd. Signed-off-by: Xin Long Acked-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 45d52b0b1f9f5c8717e9212ee6e4964dc8ed095c Author: Bjørn Mork Date: Wed Dec 23 13:42:43 2015 +0100 net: cdc_ncm: avoid changing RX/TX buffers on MTU changes [ Upstream commit 1dfddff5fcd869fcab0c52fafae099dfa435a935 ] NCM buffer sizes are negotiated with the device independently of the network device MTU. The RX buffers are allocated by the usbnet framework based on the rx_urb_size value set by cdc_ncm. A single RX buffer can hold a number of MTU sized packets. The default usbnet change_mtu ndo only modifies rx_urb_size if it is equal to hard_mtu. And the cdc_ncm driver will set rx_urb_size and hard_mtu independently of each other, based on dwNtbInMaxSize and dwNtbOutMaxSize respectively. It was therefore assumed that usbnet_change_mtu() would never touch rx_urb_size. This failed to consider the case where dwNtbInMaxSize and dwNtbOutMaxSize happens to be equal. Fix by implementing an NCM specific change_mtu ndo, modifying the netdev MTU without touching the buffer size settings. Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6866b52c56db189f8471a13f951221c45c0089c7 Author: WANG Cong Date: Mon Dec 21 10:55:45 2015 -0800 addrconf: always initialize sysctl table data [ Upstream commit 5449a5ca9bc27dd51a462de7ca0b1cd861cd2bd0 ] When sysctl performs restrict writes, it allows to write from a middle position of a sysctl file, which requires us to initialize the table data before calling proc_dostring() for the write case. Fixes: 3d1bec99320d ("ipv6: introduce secret_stable to ipv6_devconf") Reported-by: Sasha Levin Acked-by: Hannes Frederic Sowa Tested-by: Sasha Levin Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8a39e24931d119c0418721923281d2b496275ad3 Author: Andrey Ryabinin Date: Mon Dec 21 12:54:45 2015 +0300 ipv6/addrlabel: fix ip6addrlbl_get() [ Upstream commit e459dfeeb64008b2d23bdf600f03b3605dbb8152 ] ip6addrlbl_get() has never worked. If ip6addrlbl_hold() succeeded, ip6addrlbl_get() will exit with '-ESRCH'. If ip6addrlbl_hold() failed, ip6addrlbl_get() will use about to be free ip6addrlbl_entry pointer. Fix this by inverting ip6addrlbl_hold() check. Fixes: 2a8cc6c89039 ("[IPV6] ADDRCONF: Support RFC3484 configurable address selection policy table.") Signed-off-by: Andrey Ryabinin Reviewed-by: Cong Wang Acked-by: YOSHIFUJI Hideaki Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 57d0c018b46ef5293da715af12c8adc32aa99847 Author: Vijay Pandurangan Date: Fri Dec 18 14:34:59 2015 -0500 veth: don’t modify ip_summed; doing so treats packets with bad checksums as good. [ Upstream commit ce8c839b74e3017996fad4e1b7ba2e2625ede82f ] Packets that arrive from real hardware devices have ip_summed == CHECKSUM_UNNECESSARY if the hardware verified the checksums, or CHECKSUM_NONE if the packet is bad or it was unable to verify it. The current version of veth will replace CHECKSUM_NONE with CHECKSUM_UNNECESSARY, which causes corrupt packets routed from hardware to a veth device to be delivered to the application. This caused applications at Twitter to receive corrupt data when network hardware was corrupting packets. We believe this was added as an optimization to skip computing and verifying checksums for communication between containers. However, locally generated packets have ip_summed == CHECKSUM_PARTIAL, so the code as written does nothing for them. As far as we can tell, after removing this code, these packets are transmitted from one stack to another unmodified (tcpdump shows invalid checksums on both sides, as expected), and they are delivered correctly to applications. We didn’t test every possible network configuration, but we tried a few common ones such as bridging containers, using NAT between the host and a container, and routing from hardware devices to containers. We have effectively deployed this in production at Twitter (by disabling RX checksum offloading on veth devices). This code dates back to the first version of the driver, commit ("[NET]: Virtual ethernet device driver"), so I suspect this bug occurred mostly because the driver API has evolved significantly since then. Commit <0b7967503dc97864f283a> ("net/veth: Fix packet checksumming") (in December 2010) fixed this for packets that get created locally and sent to hardware devices, by not changing CHECKSUM_PARTIAL. However, the same issue still occurs for packets coming in from hardware devices. Co-authored-by: Evan Jones Signed-off-by: Evan Jones Cc: Nicolas Dichtel Cc: Phil Sutter Cc: Toshiaki Makita Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Vijay Pandurangan Acked-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3fabd53542c866e28e13a2cff43904d7a66308e0 Author: Oliver Neukum Date: Thu Dec 3 15:03:34 2015 +0100 xhci: refuse loading if nousb is used commit 1eaf35e4dd592c59041bc1ed3248c46326da1f5f upstream. The module should fail to load. Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit 3f5e25aa380d0ed5a38a824049ed520dabb149a9 Author: Oliver Freyermuth Date: Mon Dec 28 18:37:38 2015 +0100 USB: cp210x: add ID for ELV Marble Sound Board 1 commit f7d7f59ab124748156ea551edf789994f05da342 upstream. Add the USB device ID for ELV Marble Sound Board 1. Signed-off-by: Oliver Freyermuth Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 887c3cc2557b3548eabcce9e03dce470303f29e9 Author: Dan Carpenter Date: Wed Dec 16 14:06:37 2015 +0300 USB: ipaq.c: fix a timeout loop commit abdc9a3b4bac97add99e1d77dc6d28623afe682b upstream. The code expects the loop to end with "retries" set to zero but, because it is a post-op, it will end set to -1. I have fixed this by moving the decrement inside the loop. Fixes: 014aa2a3c32e ('USB: ipaq: minor ipaq_open() cleanup.') Signed-off-by: Dan Carpenter Signed-off-by: Greg Kroah-Hartman commit a7e83b16c8d83a75c58989e845c664ecaa6e0aa6 Author: Alan Stern Date: Wed Dec 16 13:32:38 2015 -0500 USB: fix invalid memory access in hub_activate() commit e50293ef9775c5f1cf3fcc093037dd6a8c5684ea upstream. Commit 8520f38099cc ("USB: change hub initialization sleeps to delayed_work") changed the hub_activate() routine to make part of it run in a workqueue. However, the commit failed to take a reference to the usb_hub structure or to lock the hub interface while doing so. As a result, if a hub is plugged in and quickly unplugged before the work routine can run, the routine will try to access memory that has been deallocated. Or, if the hub is unplugged while the routine is running, the memory may be deallocated while it is in active use. This patch fixes the problem by taking a reference to the usb_hub at the start of hub_activate() and releasing it at the end (when the work is finished), and by locking the hub interface while the work routine is running. It also adds a check at the start of the routine to see if the hub has already been disconnected, in which nothing should be done. Signed-off-by: Alan Stern Reported-by: Alexandru Cornea Tested-by: Alexandru Cornea Fixes: 8520f38099cc ("USB: change hub initialization sleeps to delayed_work") CC: Signed-off-by: Greg Kroah-Hartman commit 5241134a79fa2fc2d45b66b2651c8467818482db Author: Antti Palosaari Date: Mon Oct 26 18:58:14 2015 -0200 airspy: increase USB control message buffer size commit aa0850e1d56623845b46350ffd971afa9241886d upstream. Driver requested device firmware version string during probe using only 24 byte long buffer. That buffer is too small for newer firmware versions, which causes device firmware hang - device stops responding to any commands after that. Increase buffer size to 128 which should be enough for any current and future version strings. Link: https://github.com/airspy/host/issues/27 Reported-by: Benjamin Vernoux Signed-off-by: Antti Palosaari Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit abcbfda367d4eb2b17dc9c5b036c99431ed3ea3c Author: Chunfeng Yun Date: Fri Dec 4 15:53:43 2015 +0200 usb: xhci: fix config fail of FS hub behind a HS hub with MTT commit 096b110a3dd3c868e4610937c80d2e3f3357c1a9 upstream. if a full speed hub connects to a high speed hub which supports MTT, the MTT field of its slot context will be set to 1 when xHCI driver setups an xHCI virtual device in xhci_setup_addressable_virt_dev(); once usb core fetch its hub descriptor, and need to update the xHC's internal data structures for the device, the HUB field of its slot context will be set to 1 too, meanwhile MTT is also set before, this will cause configure endpoint command fail, so in the case, we should clear MTT to 0 for full speed hub according to section 6.2.2 Signed-off-by: Chunfeng Yun Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 1f6a2cc39913518756d8b4dad4a10493d208f4c2 Author: Vinod Koul Date: Thu Jan 7 21:48:14 2016 +0530 ASoC: compress: Fix compress device direction check commit a1068045883ed4a18363a4ebad0c3d55e473b716 upstream. The detection of direction for compress was only taking into account codec capabilities and not CPU ones. Fix this by checking the CPU side capabilities as well Tested-by: Ashish Panwar Signed-off-by: Vinod Koul Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 20091f9139bc0a17544a45b51fd3a7780552682f Author: Nikesh Oswal Date: Wed Dec 23 14:18:05 2015 +0000 ASoC: arizona: Fix bclk for sample rates that are multiple of 4kHz commit e73694d871867cae8471d2350ce89acb38bc2b63 upstream. For a sample rate of 12kHz the bclk was taken from the 44.1kHz table as we test for a multiple of 8kHz. This patch fixes this issue by testing for multiples of 4kHz instead. Signed-off-by: Nikesh Oswal Signed-off-by: Charles Keepax Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 6ac84206a212c8d86277680ef6e9066020fc54f7 Author: Peter Ujfalusi Date: Fri Dec 11 13:06:24 2015 +0200 ASoC: davinci-mcasp: Fix XDATA check in mcasp_start_tx commit e2a0c9fa80227be5ee017b5476638829dd41cb39 upstream. The condition for checking for XDAT being cleared was not correct. Fixes: 36bcecd0a73eb ("ASoC: davinci-mcasp: Correct TX start sequence") Signed-off-by: Peter Ujfalusi Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 1fce19176555fdad16a9933965f36e514514d092 Author: Mans Rullgard Date: Fri Dec 11 11:27:08 2015 +0000 ASoC: wm8974: set cache type for regmap commit 1ea5998afe903384ddc16391d4c023cd4c867bea upstream. Attempting to use this codec driver triggers a BUG() in regcache_sync() since no cache type is set. The register map of this device is fairly small and has few holes so a flat cache is suitable. Signed-off-by: Mans Rullgard Acked-by: Charles Keepax Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 5a1109e05e0907b324db88b8e376fb5174facd2c Author: John Keeping Date: Wed Dec 9 11:38:13 2015 +0000 ASoC: es8328: Fix deemphasis values commit 84ebac4d04d25ac5c1b1dc3ae621fd465eb38f4e upstream. This is using completely the wrong mask and value when updating the register. Since the correct values are already defined in the header, switch to using a table with explicit constants rather than shifting the array index. Signed-off-by: John Keeping Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 64fa05313b0aa4802e0d5be0331eb6cd68baf7a0 Author: Sachin Pandhare Date: Tue Nov 10 23:38:02 2015 +0530 ASoC: wm8962: correct addresses for HPF_C_0/1 commit e9f96bc53c1b959859599cb30ce6fd4fbb4448c2 upstream. From datasheet: R17408 (4400h) HPF_C_1 R17409 (4401h) HPF_C_0 17048 -> 17408 (0x4400) 17049 -> 17409 (0x4401) Signed-off-by: Sachin Pandhare Acked-by: Charles Keepax Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 1c98861e646744157dc97cf24d2d584774521452 Author: Kuninori Morimoto Date: Thu Nov 5 23:53:03 2015 +0000 ASoC: rsnd: fixup SCU_SYS_INT_EN1 address commit 021c5d9469960b8c68aa1d1825f7bfd8d61e157d upstream. cfcefe0126 ("ASoC: rsnd: add recovery support for under/over flow error on SRC") added SCU_SYS_INT_EN1 address, but it should be 0x1d4, not 0x1c4. This patch fixup it. Fixes: cfcefe0126 ("ASoC: rsnd: add recovery support for under/over flow error on SRC") Signed-off-by: Kuninori Morimoto Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b309c8bf5a4a524b30f9e4013828eed9dbea1e5c Author: Takashi Iwai Date: Thu Jan 21 17:19:31 2016 +0100 ALSA: timer: Handle disconnection more safely commit 230323dac060123c340cf75997971145a42661ee upstream. Currently ALSA timer device doesn't take the disconnection into account very well; it merely unlinks the timer device at disconnection callback but does nothing else. Because of this, when an application accessing the timer device is disconnected, it may release the resource before actually closed. In most cases, it results in a warning message indicating a leftover timer instance like: ALSA: timer xxxx is busy? But basically this is an open race. This patch tries to address it. The strategy is like other ALSA devices: namely, - Manage card's refcount at each open/close - Wake up the pending tasks at disconnection - Check the shutdown flag appropriately at each possible call Note that this patch has one ugly hack to handle the wakeup of pending tasks. It'd be cleaner to introduce a new disconnect op to snd_timer_instance ops. But since it would lead to internal ABI breakage and it eventually increase my own work when backporting to stable kernels, I took a different path to implement locally in timer.c. A cleanup patch will follow at next for 4.5 kernel. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109431 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2b332719b8f033d77070a4b58e41105b658dc2eb Author: Takashi Iwai Date: Wed Jan 20 17:19:02 2016 +0100 ALSA: hda - Flush the pending probe work at remove commit 991f86d7ae4e1f8c15806e62f97af519e3cdd860 upstream. As HD-audio driver does deferred probe internally via workqueue, the driver might go into the mixed state doing both probe and remove when the module gets unloaded during the probe work. This eventually triggers an Oops, unsurprisingly. For avoiding this race, we just need to flush the pending probe work explicitly before actually starting the resource release. Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=960710 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a63fabd4ac6c29f01fa630e43c1597e8e6680a97 Author: Takashi Iwai Date: Mon Jan 18 09:17:30 2016 +0100 ALSA: hda - Fix bass pin fixup for ASUS N550JX commit db8948e653e12b218058bb6696f4a33fa7845f64 upstream. ASUS N550JX (PCI SSID 1043:13df) requires the same fixup for a bass speaker output pin as other N550 models. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=110001 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit efcf073d7fa1aa1fb2a8d3f3db373e1a5ecbc60a Author: Takashi Iwai Date: Mon Jan 18 14:12:40 2016 +0100 ALSA: control: Avoid kernel warnings from tlv ioctl with numid 0 commit c0bcdbdff3ff73a54161fca3cb8b6cdbd0bb8762 upstream. When a TLV ioctl with numid zero is handled, the driver may spew a kernel warning with a stack trace at each call. The check was intended obviously only for a kernel driver, but not for a user interaction. Let's fix it. This was spotted by syzkaller fuzzer. Reported-by: Dmitry Vyukov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 965b1203f399676ac4989a0876336e212a71085b Author: Takashi Iwai Date: Mon Jan 18 13:52:47 2016 +0100 ALSA: hrtimer: Fix stall by hrtimer_cancel() commit 2ba1fe7a06d3624f9a7586d672b55f08f7c670f3 upstream. hrtimer_cancel() waits for the completion from the callback, thus it must not be called inside the callback itself. This was already a problem in the past with ALSA hrtimer driver, and the early commit [fcfdebe70759: ALSA: hrtimer - Fix lock-up] tried to address it. However, the previous fix is still insufficient: it may still cause a lockup when the ALSA timer instance reprograms itself in its callback. Then it invokes the start function even in snd_timer_interrupt() that is called in hrtimer callback itself, results in a CPU stall. This is no hypothetical problem but actually triggered by syzkaller fuzzer. This patch tries to fix the issue again. Now we call hrtimer_try_to_cancel() at both start and stop functions so that it won't fall into a deadlock, yet giving some chance to cancel the queue if the functions have been called outside the callback. The proper hrtimer_cancel() is called in anyway at closing, so this should be enough. Reported-and-tested-by: Dmitry Vyukov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 281bedb8728f02a9b8bd5f5e342883e6d255abdc Author: Nicolas Boichat Date: Mon Jan 18 21:35:00 2016 +0800 ALSA: pcm: Fix snd_pcm_hw_params struct copy in compat mode commit 43c54b8c7cfe22f868a751ba8a59abf1724160b1 upstream. This reverts one hunk of commit ef44a1ec6eee ("ALSA: sound/core: use memdup_user()"), which replaced a number of kmalloc followed by memcpy with memdup calls. In this case, we are copying from a struct snd_pcm_hw_params32 to a struct snd_pcm_hw_params, but the latter is 4 bytes longer than the 32-bit version, so we need to separate kmalloc and copy calls. This actually leads to an out-of-bounds memory access later on in sound/soc/soc-pcm.c:soc_pcm_hw_params() (detected using KASan). Fixes: ef44a1ec6eee ('ALSA: sound/core: use memdup_user()') Signed-off-by: Nicolas Boichat Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d1a55757fefff39a7b71305a78c2722d3b9b6529 Author: Nicolas Boichat Date: Mon Jan 18 21:35:01 2016 +0800 ALSA: seq: Fix snd_seq_call_port_info_ioctl in compat mode commit 9586495dc3011a80602329094e746dbce16cb1f1 upstream. This reverts one hunk of commit ef44a1ec6eee ("ALSA: sound/core: use memdup_user()"), which replaced a number of kmalloc followed by memcpy with memdup calls. In this case, we are copying from a struct snd_seq_port_info32 to a struct snd_seq_port_info, but the latter is 4 bytes longer than the 32-bit version, so we need to separate kmalloc and copy calls. Fixes: ef44a1ec6eee ('ALSA: sound/core: use memdup_user()') Signed-off-by: Nicolas Boichat Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit dc5697eb3297920e20b53fdf4c40891e1ed0eafd Author: Takashi Iwai Date: Wed Jan 13 21:35:06 2016 +0100 ALSA: timer: Fix double unlink of active_list commit ee8413b01045c74340aa13ad5bdf905de32be736 upstream. ALSA timer instance object has a couple of linked lists and they are unlinked unconditionally at snd_timer_stop(). Meanwhile snd_timer_interrupt() unlinks it, but it calls list_del() which leaves the element list itself unchanged. This ends up with unlinking twice, and it was caught by syzkaller fuzzer. The fix is to use list_del_init() variant properly there, too. Reported-by: Dmitry Vyukov Tested-by: Dmitry Vyukov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ac905ca58370789645e813d8abfa5871c93e9e36 Author: Takashi Iwai Date: Wed Jan 13 17:48:01 2016 +0100 ALSA: timer: Fix race among timer ioctls commit af368027a49a751d6ff4ee9e3f9961f35bb4fede upstream. ALSA timer ioctls have an open race and this may lead to a use-after-free of timer instance object. A simplistic fix is to make each ioctl exclusive. We have already tread_sem for controlling the tread, and extend this as a global mutex to be applied to each ioctl. The downside is, of course, the worse concurrency. But these ioctls aren't to be parallel accessible, in anyway, so it should be fine to serialize there. Reported-by: Dmitry Vyukov Tested-by: Dmitry Vyukov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 042b42c579b94d2e5b53fe208d16dc8fb5dc0b10 Author: Hui Wang Date: Wed Jan 13 11:51:38 2016 +0800 ALSA: hda - fix the headset mic detection problem for a Dell laptop commit 0a1f90a982e85f4921bed606a6b41a24f4de2ae1 upstream. The machine uses codec alc255, and the pin configuration value for pin 0x14 on this machine is 0x90171130 which is not in the pin quirk table yet. BugLink: https://bugs.launchpad.net/bugs/1533461 Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 466c99bd815a1ae189d883b509b067c9a74a30f9 Author: Takashi Iwai Date: Thu Jan 14 16:30:58 2016 +0100 ALSA: timer: Harden slave timer list handling commit b5a663aa426f4884c71cd8580adae73f33570f0d upstream. A slave timer instance might be still accessible in a racy way while operating the master instance as it lacks of locking. Since the master operation is mostly protected with timer->lock, we should cope with it while changing the slave instance, too. Also, some linked lists (active_list and ack_list) of slave instances aren't unlinked immediately at stopping or closing, and this may lead to unexpected accesses. This patch tries to address these issues. It adds spin lock of timer->lock (either from master or slave, which is equivalent) in a few places. For avoiding a deadlock, we ensure that the global slave_active_lock is always locked at first before each timer lock. Also, ack and active_list of slave instances are properly unlinked at snd_timer_stop() and snd_timer_close(). Last but not least, remove the superfluous call of _snd_timer_stop() at removing slave links. This is a noop, and calling it may confuse readers wrt locking. Further cleanup will follow in a later patch. Actually we've got reports of use-after-free by syzkaller fuzzer, and this hopefully fixes these issues. Reported-by: Dmitry Vyukov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 27b496cc9e8c4cea094806ae1f54059696afabae Author: Takashi Iwai Date: Wed Jan 13 07:20:13 2016 +0100 ALSA: usb-audio: Fix mixer ctl regression of Native Instrument devices commit c4a359a0049f2e17b012b31e801e96566f6391e5 upstream. The commit [da6d276957ea: ALSA: usb-audio: Add resume support for Native Instruments controls] brought a regression where the Native Instrument audio devices don't get the correct value at update due to the missing shift at writing. This patch addresses it. Fixes: da6d276957ea ('ALSA: usb-audio: Add resume support for Native Instruments controls') Reported-and-tested-by: Owen Williams Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6aee1f8440bfd61d8939989197576e1577a01eb9 Author: Takashi Iwai Date: Tue Jan 12 21:06:39 2016 +0100 ALSA: hda - Fix white noise on Dell Latitude E5550 commit 98070576c4f77509459c83cd2358617ef0769a38 upstream. Dell Latitude E5550 (1028:062c) has a white noise problem like other Latitude E models, and it gets fixed by the very same quirk as well. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=110591 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 49c9eb3db86407868a664ade6da041fabeb457f8 Author: Takashi Iwai Date: Tue Jan 12 15:36:27 2016 +0100 ALSA: seq: Fix race at timer setup and close commit 3567eb6af614dac436c4b16a8d426f9faed639b3 upstream. ALSA sequencer code has an open race between the timer setup ioctl and the close of the client. This was triggered by syzkaller fuzzer, and a use-after-free was caught there as a result. This patch papers over it by adding a proper queue->timer_mutex lock around the timer-related calls in the relevant code path. Reported-by: Dmitry Vyukov Tested-by: Dmitry Vyukov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9a6003a362acb814fea7422209be344b822b047a Author: Takashi Iwai Date: Tue Jan 12 12:38:02 2016 +0100 ALSA: seq: Fix missing NULL check at remove_events ioctl commit 030e2c78d3a91dd0d27fef37e91950dde333eba1 upstream. snd_seq_ioctl_remove_events() calls snd_seq_fifo_clear() unconditionally even if there is no FIFO assigned, and this leads to an Oops due to NULL dereference. The fix is just to add a proper NULL check. Reported-by: Dmitry Vyukov Tested-by: Dmitry Vyukov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit aa13585b6672c9d6dc9e0f01de03ef3f8c5622b6 Author: Jurgen Kramer Date: Mon Jan 11 08:16:58 2016 +0100 ALSA: usb: Add native DSD support for Oppo HA-1 commit a4eae3a506ea4a7d4474cd74e20b423fa8053d91 upstream. This patch adds native DSD support for the Oppo HA-1. It uses a XMOS chipset but they use their own vendor ID. Signed-off-by: Jurgen Kramer Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 37191bd8b4dd9fa695806687235206ddc30d4761 Author: Mario Kleiner Date: Tue Dec 22 00:45:43 2015 +0100 ALSA: hda/realtek - Fix silent headphone output on MacPro 4,1 (v2) commit 9f660a1c43890c2cdd1f423fd73654e7ca08fe56 upstream. Without this patch, internal speaker and line-out work, but front headphone output jack stays silent on the Mac Pro 4,1. This code path also gets executed on the MacPro 5,1 due to identical codec SSID, but i don't know if it has any positive or adverse effects there or not. (v2) Implement feedback from Takashi Iwai: Reuse alc889_fixup_mbp_vref and just add a new nid 0x19 for the MacPro 4,1. Signed-off-by: Mario Kleiner Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b40f630cfe4d099deca538523542783b79471fc8 Author: Xiong Zhang Date: Fri Dec 18 13:29:18 2015 +0800 ALSA: hda - Set SKL+ hda controller power at freeze() and thaw() commit 3e6db33aaf1d42a30339f831ec4850570d6cc7a3 upstream. It takes three minutes to enter into hibernation on some OEM SKL machines and we see many codec spurious response after thaw() opertion. This is because HDA is still in D0 state after freeze() call and pci_pm_freeze/pci_pm_freeze_noirq() don't set D3 hot in pci_bus driver. It seems bios still access HDA when system enter into freeze state, HDA will receive codec response interrupt immediately after thaw() call. Because of this unexpected interrupt, HDA enter into a abnormal state and slow down the system enter into hibernation. In this patch, we put HDA into D3 hot state in azx_freeze_noirq() and put HDA into D0 state in azx_thaw_noirq(). V2: Only apply this fix to SKL+ Fix compile error when CONFIG_PM_SLEEP isn't defined [Yet another fix for CONFIG_PM_SLEEP ifdef and the additional comment by tiwai] Signed-off-by: Xiong Zhang Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 73a5fdacba1f8cf702e93e66ea9753fa85afc2fc Author: Anssi Hannula Date: Sun Dec 13 20:49:59 2015 +0200 ALSA: usb-audio: Add sample rate inquiry quirk for AudioQuest DragonFly commit 12a6116e66695a728bcb9616416c508ce9c051a1 upstream. Avoid getting sample rate on AudioQuest DragonFly as it is unsupported and causes noisy "cannot get freq at ep 0x1" messages when playback starts. Signed-off-by: Anssi Hannula Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 271126c7cbb6c0dabb5eb9dd25e224b53a48f715 Author: Anssi Hannula Date: Sun Dec 13 20:49:58 2015 +0200 ALSA: usb-audio: Add a more accurate volume quirk for AudioQuest DragonFly commit 42e3121d90f42e57f6dbd6083dff2f57b3ec7daa upstream. AudioQuest DragonFly DAC reports a volume control range of 0..50 (0x0000..0x0032) which in USB Audio means a range of 0 .. 0.2dB, which is obviously incorrect and would cause software using the dB information in e.g. volume sliders to have a massive volume difference in 100..102% range. Commit 2d1cb7f658fb ("ALSA: usb-audio: add dB range mapping for some devices") added a dB range mapping for it with range 0..50 dB. However, the actual volume mapping seems to be neither linear volume nor linear dB scale, but instead quite close to the cubic mapping e.g. alsamixer uses, with a range of approx. -53...0 dB. Replace the previous quirk with a custom dB mapping based on some basic output measurements, using a 10-item range TLV (which will still fit in alsa-lib MAX_TLV_RANGE_SIZE). Tested on AudioQuest DragonFly HW v1.2. The quirk is only applied if the range is 0..50, so if this gets fixed/changed in later HW revisions it will no longer be applied. v2: incorporated Takashi Iwai's suggestion for the quirk application method Signed-off-by: Anssi Hannula Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 228a0e09d53a3c9048050f976e90c96ea28a666e Author: Takashi Iwai Date: Tue Dec 15 14:59:58 2015 +0100 ALSA: hda - Set codec to D3 at reboot/shutdown on Thinkpads commit 70a0976b0c0d90f4246d7e63359d796ec82b87d6 upstream. Lenovo Thinkpads with Realtek codecs may still have some loud crackling noises at reboot/shutdown even though a few previous fixes have been applied. It's because the previous fix (disabling the default shutup callback) takes effect only at transition of the codec power state. Meanwhile, at reboot or shutdown, we don't take down the codec power as default, thus it triggers the same problem unless the codec is powered down casually by runtime PM. This patch tries to address the issue. It gives two things: - implement the separate reboot_notify hook to struct alc_spec, and call it optionally if defined. - turn off the codec to D3 for Thinkpad models via this new callback Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=958439 Reported-and-tested-by: Benjamin Poirier Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit be7c9844eea1a34939f808af288b2e59c1510fff Author: Takashi Iwai Date: Thu Dec 10 23:30:43 2015 +0100 ALSA: hda - Apply click noise workaround for Thinkpads generically commit 157f0b7f6c0cc0bc88647390006e959e267a0143 upstream. It seems that a workaround for Thinkpad T440s crackling noise can be applied generically to all Thinkpad models: namely, disabling the default alc269 shutup callback. This patch moves it to the existing alc_fixup_tpt440_dock() while also replacing the rest code with another existing alc_fixup_disable_aamix(). It resulted in a good code reduction. Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=958439 Reported-and-tested-by: Benjamin Poirier Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit dff55bf1b247c612600ba0855f792bf8c3833952 Author: Takashi Iwai Date: Thu Dec 10 12:20:20 2015 +0100 ALSA: hda - Add a fixup for Thinkpad X1 Carbon 2nd commit b6903c0ed9f0bcbbe88f67f7ed43d1721cbc6235 upstream. Apply the same fixup for Thinkpad with dock to Thinkpad X1 Carbon 2nd, too. This reduces the annoying loud cracking noise problem, as well as the support of missing docking port. Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=958439 Reported-and-tested-by: Benjamin Poirier Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit bc4d35b2c8c7c39b6d69cda22eac15b1d850b71a Author: Takashi Iwai Date: Wed Dec 9 15:17:43 2015 +0100 ALSA: hda - Fix noise problems on Thinkpad T440s commit 9a811230481243f384b8036c6a558bfdbd961f78 upstream. Lenovo Thinkpad T440s suffers from constant background noises, and it seems to be a generic hardware issue on this model: https://forums.lenovo.com/t5/ThinkPad-T400-T500-and-newer-T/T440s-speaker-noise/td-p/1339883 As the noise comes from the analog loopback path, disabling the path is the easy workaround. Also, the machine gives significant cracking noises at PM suspend. A workaround found by trial-and-error is to disable the shutup callback currently used for ALC269-variant. This patch addresses these noise issues by introducing a new fixup chain. Although the same workaround might be applicable to other Thinkpad models, it's applied only to T440s (17aa:220c) in this patch, so far, just to be safe (you chicken!). As a compromise, a new model option string "tp440" is provided now, though, so that owners of other Thinkpad models can test it more easily. Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=958504 Reported-and-tested-by: Tim Hardeck Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c5e609dc5cab66a6db129d11e5d33be7371624b7 Author: David Henningsson Date: Mon Dec 7 11:29:31 2015 +0100 ALSA: hda - Add inverted dmic for Packard Bell DOTS commit 02f6ff90400d055f08b0ba0b5f0707630b6faed7 upstream. On the internal mic of the Packard Bell DOTS, one channel has an inverted signal. Add a quirk to fix this up. BugLink: https://bugs.launchpad.net/bugs/1523232 Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit af95ff49d83b6ccb628bc5b7b1caa994fd2a27c9 Author: Takashi Iwai Date: Fri Dec 4 16:44:24 2015 +0100 ALSA: rme96: Fix unexpected volume reset after rate changes commit a74a821624c0c75388a193337babd17a8c02c740 upstream. rme96 driver needs to reset DAC depending on the sample rate, and this results in resetting to the max volume suddenly. It's because of the missing call of snd_rme96_apply_dac_volume(). However, calling this function right after the DAC reset still may not work, and we need some delay before this call. Since the DAC reset and the procedure after that are performed in the spinlock, we delay the DAC volume restore at the end after the spinlock. Reported-and-tested-by: Sylvain LABOISNE Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9bc3da2497b3b21e686175ce2a5bbb15182534fd Author: Takashi Iwai Date: Tue Nov 24 20:02:12 2015 +0100 ALSA: hda - Fix noise on Gigabyte Z170X mobo commit 0c25ad80408e95e0a4fbaf0056950206e95f726f upstream. Gigabyte Z710X mobo with ALC1150 codec gets significant noises from the analog loopback routes even if their inputs are all muted. Simply kill the aamix for fixing it. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=108301 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 842dd2467a244af77c59b6830a0656fe1d82c8cf Author: Takashi Iwai Date: Thu Nov 19 16:39:50 2015 +0100 ALSA: hda - Add fixup for Acer Aspire One Cloudbook 14 commit b9c2fa52135d49a931c56ed2bfc17d61f771b412 upstream. For making the speakers on Acer Aspire One Cloudbook 14 to work, we need the as same quirk as for another Chromebook. This patch adds the corresponding fixup entry. Reported-by: Patrick Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 5c7e814c1b3a350ebccde2303fbb4be933315d89 Author: Takashi Iwai Date: Mon Nov 9 14:46:35 2015 +0100 ALSA: hda - Apply HP headphone fixups more generically commit 196543d54574f50e3fd04df4e3048181e006a9da upstream. It turned out that many HP laptops suffer from the same problem as fixed in commit [c932b98c1e47: ALSA: hda - Apply pin fixup for HP ProBook 6550b]. But, it's tiresome to list up all such PCI SSIDs, as there are really lots of HP machines. Instead, we do a bit more clever, try to check the supposedly dock and built-in headphone pins, and apply the fixup when both seem valid. This rule can be applied generically to all models using the same quirk, so we'll fix all in a shot. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=107491 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c397bc975aa4b205a99b0c651af931537be871e5 Author: Takashi Sakamoto Date: Sun Oct 18 13:46:47 2015 +0900 ALSA: fireworks/bebob/oxfw/dice: enable to make as built-in commit df4833886f91eea0d20e6e97066adab308625ef8 upstream. When committed to upstream, these four modules had wrong entries for Makefile. This forces them to be loadable modules even if they're set as built-in. This commit fixes this bug. Fixes: b5b04336015e('ALSA: fireworks: Add skelton for Fireworks based devices') Fixes: fd6f4b0dc167('ALSA: bebob: Add skelton for BeBoB based devices') Fixes: 1a4e39c2e5ca('ALSA: oxfw: Move to its own directory') Fixes: 14ff6a094815('ALSA: dice: Move file to its own directory') Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 055fb07950beed4e3ee6e0a1d3b50ed84bb29fa5 Author: Takashi Iwai Date: Wed Nov 4 22:39:16 2015 +0100 ALSA: hda - Apply pin fixup for HP ProBook 6550b commit c932b98c1e47312822d911c1bb76e81ef50e389c upstream. HP ProBook 6550b needs the same pin fixup applied to other HP B-series laptops with docks for making its headphone and dock headphone jacks working properly. We just need to add the codec SSID to the list. Bugzilla: https://bugzilla.kernel.org/attachment.cgi?id=191971 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 29923678a8ef26de4fb186fd0c3b9c817c4b4738 Author: Alexandra Yates Date: Wed Nov 4 15:56:09 2015 -0800 ALSA: hda - Add Intel Lewisburg device IDs Audio commit 5cf92c8b3dc5da59e05dc81bdc069cedf6f38313 upstream. Adding Intel codename Lewisburg platform device IDs for audio. [rearranged the position by tiwai] Signed-off-by: Alexandra Yates Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e702f5856baa2d68c225662d57c572ea178351b5 Author: Takashi Iwai Date: Tue Oct 27 14:21:51 2015 +0100 ALSA: hda - Disable 64bit address for Creative HDA controllers commit cadd16ea33a938d49aee99edd4758cc76048b399 upstream. We've had many reports that some Creative sound cards with CA0132 don't work well. Some reported that it starts working after reloading the module, while some reported it starts working when a 32bit kernel is used. All these facts seem implying that the chip fails to communicate when the buffer is located in 64bit address. This patch addresses these issues by just adding AZX_DCAPS_NO_64BIT flag to the corresponding PCI entries. I casually had a chance to test an SB Recon3D board, and indeed this seems helping. Although this hasn't been tested on all Creative devices, it's safer to assume that this restriction applies to the rest of them, too. So the flag is applied to all Creative entries. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 69bed67bc32fd47774539eaddb9f33420df556fe Author: Jan Stancek Date: Tue Dec 8 13:57:51 2015 -0500 ipmi: move timer init to before irq is setup commit 27f972d3e00b50639deb4cc1392afaeb08d3cecc upstream. We encountered a panic on boot in ipmi_si on a dell per320 due to an uninitialized timer as follows. static int smi_start_processing(void *send_info, ipmi_smi_t intf) { /* Try to claim any interrupts. */ if (new_smi->irq_setup) new_smi->irq_setup(new_smi); --> IRQ arrives here and irq handler tries to modify uninitialized timer which triggers BUG_ON(!timer->function) in __mod_timer(). Call Trace: [] start_new_msg+0x47/0x80 [ipmi_si] [] start_check_enables+0x4e/0x60 [ipmi_si] [] smi_event_handler+0x1e8/0x640 [ipmi_si] [] ? __rcu_process_callbacks+0x54/0x350 [] si_irq_handler+0x3c/0x60 [ipmi_si] [] handle_IRQ_event+0x60/0x170 [] handle_edge_irq+0xde/0x180 [] handle_irq+0x49/0xa0 [] do_IRQ+0x6c/0xf0 [] ret_from_intr+0x0/0x11 /* Set up the timer that drives the interface. */ setup_timer(&new_smi->si_timer, smi_timeout, (long)new_smi); The following patch fixes the problem. To: Openipmi-developer@lists.sourceforge.net To: Corey Minyard CC: linux-kernel@vger.kernel.org Signed-off-by: Jan Stancek Signed-off-by: Tony Camuso Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman commit 8dfca273353b9131dfd82c2720ccd78f89fd44ae Author: Corey Minyard Date: Sat Sep 5 17:44:13 2015 -0500 ipmi: Start the timer and thread on internal msgs commit 0cfec916e86d881e209de4b4ae9959a6271e6660 upstream. The timer and thread were not being started for internal messages, so in interrupt mode if something hung the timer would never go off and clean things up. Factor out the internal message sending and start the timer for those messages, too. Signed-off-by: Corey Minyard Tested-by: Gouji, Masayuki Signed-off-by: Greg Kroah-Hartman commit c1a631b482a7b3cc5a78daa8f5babf28e67d4dc6 Author: Andy Lutomirski Date: Tue Jan 12 12:47:40 2016 -0800 x86/mm: Improve switch_mm() barrier comments commit 4eaffdd5a5fe6ff9f95e1ab4de1ac904d5e0fa8b upstream. My previous comments were still a bit confusing and there was a typo. Fix it up. Reported-by: Peter Zijlstra Signed-off-by: Andy Lutomirski Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Dave Hansen Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Rik van Riel Cc: Thomas Gleixner Fixes: 71b3c126e611 ("x86/mm: Add barriers and document switch_mm()-vs-flush synchronization") Link: http://lkml.kernel.org/r/0a0b43cdcdd241c5faaaecfbcc91a155ddedc9a1.1452631609.git.luto@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit ae535caf02c7e2e7feec62f4e07ac1f48ad5b336 Author: Andy Lutomirski Date: Wed Jan 6 12:21:01 2016 -0800 x86/mm: Add barriers and document switch_mm()-vs-flush synchronization commit 71b3c126e61177eb693423f2e18a1914205b165e upstream. When switch_mm() activates a new PGD, it also sets a bit that tells other CPUs that the PGD is in use so that TLB flush IPIs will be sent. In order for that to work correctly, the bit needs to be visible prior to loading the PGD and therefore starting to fill the local TLB. Document all the barriers that make this work correctly and add a couple that were missing. Signed-off-by: Andy Lutomirski Cc: Andrew Morton Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Dave Hansen Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Rik van Riel Cc: Thomas Gleixner Cc: linux-mm@kvack.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 4b6c3a55305de01d24d994d16ff7dc3dfaee2715 Author: H.J. Lu Date: Mon Jan 4 10:17:09 2016 -0800 x86/boot: Double BOOT_HEAP_SIZE to 64KB commit 8c31902cffc4d716450be549c66a67a8a3dd479c upstream. When decompressing kernel image during x86 bootup, malloc memory for ELF program headers may run out of heap space, which leads to system halt. This patch doubles BOOT_HEAP_SIZE to 64KB. Tested with 32-bit kernel which failed to boot without this patch. Signed-off-by: H.J. Lu Acked-by: H. Peter Anvin Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit eec2baa864792fc7d6b396b1934c83dad759905d Author: Mario Kleiner Date: Fri Dec 18 20:24:06 2015 +0100 x86/reboot/quirks: Add iMac10,1 to pci_reboot_dmi_table[] commit 2f0c0b2d96b1205efb14347009748d786c2d9ba5 upstream. Without the reboot=pci method, the iMac 10,1 simply hangs after printing "Restarting system" at the point when it should reboot. This fixes it. Signed-off-by: Mario Kleiner Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Dave Jones Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1450466646-26663-1-git-send-email-mario.kleiner.de@gmail.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 17f33d468f4dfbfd5e4c8782f5e26a0863167a66 Author: Paolo Bonzini Date: Thu Nov 12 16:42:18 2015 +0100 KVM: x86: correctly print #AC in traces commit aba2f06c070f604e388cf77b1dcc7f4cf4577eb0 upstream. Poor #AC was so unimportant until a few days ago that we were not even tracing its name correctly. But now it's all over the place. Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 8a3185c54d650a86dafc8d8bcafa124b50944315 Author: Paolo Bonzini Date: Thu Nov 12 14:49:17 2015 +0100 KVM: x86: expose MSR_TSC_AUX to userspace commit 9dbe6cf941a6fe82933aef565e4095fb10f65023 upstream. If we do not do this, it is not properly saved and restored across migration. Windows notices due to its self-protection mechanisms, and is very upset about it (blue screen of death). Cc: Radim Krcmar Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit e052d6eeedf13ad69db1686b0b49fb9192519d9e Author: Paul Mackerras Date: Thu Nov 12 16:43:02 2015 +1100 KVM: PPC: Book3S HV: Prohibit setting illegal transaction state in MSR commit c20875a3e638e4a03e099b343ec798edd1af5cc6 upstream. Currently it is possible for userspace (e.g. QEMU) to set a value for the MSR for a guest VCPU which has both of the TS bits set, which is an illegal combination. The result of this is that when we execute a hrfid (hypervisor return from interrupt doubleword) instruction to enter the guest, the CPU will take a TM Bad Thing type of program interrupt (vector 0x700). Now, if PR KVM is configured in the kernel along with HV KVM, we actually handle this without crashing the host or giving hypervisor privilege to the guest; instead what happens is that we deliver a program interrupt to the guest, with SRR0 reflecting the address of the hrfid instruction and SRR1 containing the MSR value at that point. If PR KVM is not configured in the kernel, then we try to run the host's program interrupt handler with the MMU set to the guest context, which almost certainly causes a host crash. This closes the hole by making kvmppc_set_msr_hv() check for the illegal combination and force the TS field to a safe value (00, meaning non-transactional). Signed-off-by: Paul Mackerras Signed-off-by: Greg Kroah-Hartman commit 19eaffefc4b03d92e0adfd1870b10b9539916106 Author: Paolo Bonzini Date: Tue Nov 10 09:14:39 2015 +0100 KVM: svm: unconditionally intercept #DB commit cbdb967af3d54993f5814f1cee0ed311a055377d upstream. This is needed to avoid the possibility that the guest triggers an infinite stream of #DB exceptions (CVE-2015-8104). VMX is not affected: because it does not save DR6 in the VMCS, it already intercepts #DB unconditionally. Reported-by: Jan Beulich Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 03e572f3dda7f5790930df631a3f013f4100558b Author: Radim Krčmář Date: Mon Nov 2 22:20:00 2015 +0100 KVM: VMX: fix SMEP and SMAP without EPT commit 656ec4a4928a3db7d16e5cb9bce351a478cfd3d5 upstream. The comment in code had it mostly right, but we enable paging for emulated real mode regardless of EPT. Without EPT (which implies emulated real mode), secondary VCPUs won't start unless we disable SM[AE]P when the guest doesn't use paging. Signed-off-by: Radim Krčmář Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit c12a3752a390994ad5e3b987f123ffe24143ad48 Author: Ouyang Zhaowei (Charles) Date: Wed May 6 09:47:04 2015 +0800 x86/xen: don't reset vcpu_info on a cancelled suspend commit 6a1f513776b78c994045287073e55bae44ed9f8c upstream. On a cancelled suspend the vcpu_info location does not change (it's still in the per-cpu area registered by xen_vcpu_setup()). So do not call xen_hvm_init_shared_info() which would make the kernel think its back in the shared info. With the wrong vcpu_info, events cannot be received and the domain will hang after a cancelled suspend. Signed-off-by: Charles Ouyang Reviewed-by: Boris Ostrovsky Signed-off-by: David Vrabel Signed-off-by: Greg Kroah-Hartman commit 702d87e2ff77d75c8ba8783510b71c68eef644f3 Author: Boris Ostrovsky Date: Tue Nov 10 15:10:33 2015 -0500 xen/gntdev: Grant maps should not be subject to NUMA balancing commit 9c17d96500f78d7ecdb71ca6942830158bc75a2b upstream. Doing so will cause the grant to be unmapped and then, during fault handling, the fault to be mistakenly treated as NUMA hint fault. In addition, even if those maps could partcipate in NUMA balancing, it wouldn't provide any benefit since we are unable to determine physical page's node (even if/when VNUMA is implemented). Marking grant maps' VMAs as VM_IO will exclude them from being part of NUMA balancing. Signed-off-by: Boris Ostrovsky Signed-off-by: David Vrabel Signed-off-by: Greg Kroah-Hartman commit 3ab6a090acfb20dfa49979d21c0a110019ad381f Author: Dmitry V. Levin Date: Tue Dec 1 00:54:36 2015 +0300 x86/signal: Fix restart_syscall number for x32 tasks commit 22eab1108781eff09961ae7001704f7bd8fb1dce upstream. When restarting a syscall with regs->ax == -ERESTART_RESTARTBLOCK, regs->ax is assigned to a restart_syscall number. For x32 tasks, this syscall number must have __X32_SYSCALL_BIT set, otherwise it will be an x86_64 syscall number instead of a valid x32 syscall number. This issue has been there since the introduction of x32. Reported-by: strace/tests/restart_syscall.test Reported-and-tested-by: Elvira Khabirova Signed-off-by: Dmitry V. Levin Cc: Elvira Khabirova Link: http://lkml.kernel.org/r/20151130215436.GA25996@altlinux.org Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit c24eedeca7b86abc1719f1705de671cee8853b8d Author: Dave Hansen Date: Mon Nov 30 16:31:13 2015 -0800 x86/mpx: Fix instruction decoder condition commit 8e8efe0379bd93e8219ca0fc6fa80b5dd85b09cb upstream. MPX decodes instructions in order to tell which bounds register was violated. Part of this decoding involves looking at the "REX prefix" which is a special instrucion prefix used to retrofit support for new registers in to old instructions. The X86_REX_*() macros are defined to return actual bit values: #define X86_REX_R(rex) ((rex) & 4) *not* boolean values. However, the MPX code was checking for them like they were booleans. This might have led to us mis-decoding the "REX prefix" and giving false information out to userspace about bounds violations. X86_REX_B() actually is bit 1, so this is really only broken for the X86_REX_X() case. Fix the conditionals up to tolerate the non-boolean values. Fixes: fcc7ffd67991 "x86, mpx: Decode MPX instruction to get bound violation information" Reported-by: Dan Carpenter Signed-off-by: Dave Hansen Cc: x86@kernel.org Cc: Dave Hansen Link: http://lkml.kernel.org/r/20151201003113.D800C1E0@viggo.jf.intel.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman