commit 0199619b21f7320482e8a2db14cf8bc974a7766a Author: Sasha Levin Date: Tue Dec 12 10:21:44 2017 -0500 Linux 4.1.48 Signed-off-by: Sasha Levin commit 2f952d47911f36766122918cc4e6ae782780f513 Author: Ville Syrjälä Date: Thu Nov 23 21:41:57 2017 +0200 drm/i915: Prevent zero length "index" write [ Upstream commit 56350fb8978bbf4aafe08f21234e161dd128b417 ] The hardware always writes one or two bytes in the index portion of an indexed transfer. Make sure the message we send as the index doesn't have a zero length. Cc: stable@vger.kernel.org Cc: Daniel Kurtz Cc: Chris Wilson Cc: Daniel Vetter Cc: Sean Paul Fixes: 56f9eac05489 ("drm/i915/intel_i2c: use INDEX cycles for i2c read transactions") Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20171123194157.25367-3-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson (cherry picked from commit bb9e0d4bca50f429152e74a459160b41f3d60fb2) Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin commit b504b57060a2f285de5393dabfc64d71d654e748 Author: Ville Syrjälä Date: Thu Nov 23 21:41:56 2017 +0200 drm/i915: Don't try indexed reads to alternate slave addresses [ Upstream commit ae5c631e605a452a5a0e73205a92810c01ed954b ] We can only specify the one slave address to indexed reads/writes. Make sure the messages we check are destined to the same slave address before deciding to do an indexed transfer. Cc: stable@vger.kernel.org Cc: Daniel Kurtz Cc: Chris Wilson Cc: Daniel Vetter Cc: Sean Paul Fixes: 56f9eac05489 ("drm/i915/intel_i2c: use INDEX cycles for i2c read transactions") Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20171123194157.25367-2-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson (cherry picked from commit c4deb62d7821672265b87952bcd1c808f3bf3e8f) Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin commit 27460f85f87ee7ff8abe5a6e548928835ac2f471 Author: NeilBrown Date: Fri Aug 25 17:34:41 2017 +1000 NFS: revalidate "." etc correctly on "open". [ Upstream commit b688741cb06695312f18b730653d6611e1bad28d ] For correct close-to-open semantics, NFS must validate the change attribute of a directory (or file) on open. Since commit ecf3d1f1aa74 ("vfs: kill FS_REVAL_DOT by adding a d_weak_revalidate dentry op"), open() of "." or a path ending ".." is not revalidated reliably (except when that direct is a mount point). Prior to that commit, "." was revalidated using nfs_lookup_revalidate() which checks the LOOKUP_OPEN flag and forces revalidation if the flag is set. Since that commit, nfs_weak_revalidate() is used for NFSv3 (which ignores the flags) and nothing is used for NFSv4. This is fixed by using nfs_lookup_verify_inode() in nfs_weak_revalidate(). This does the revalidation exactly when needed. Also, add a definition of .d_weak_revalidate for NFSv4. The incorrect behavior is easily demonstrated by running "echo *" in some non-mountpoint NFS directory while watching network traffic. Without this patch, "echo *" sometimes doesn't produce any traffic. With the patch it always does. Fixes: ecf3d1f1aa74 ("vfs: kill FS_REVAL_DOT by adding a d_weak_revalidate dentry op") cc: stable@vger.kernel.org (3.9+) Signed-off-by: NeilBrown Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 95dcd5bd1d02720d610ec331738117a5bab47726 Author: Brent Taylor Date: Mon Oct 30 22:32:45 2017 -0500 mtd: nand: Fix writing mtdoops to nand flash. [ Upstream commit 30863e38ebeb500a31cecee8096fb5002677dd9b ] When mtdoops calls mtd_panic_write(), it eventually calls panic_nand_write() in nand_base.c. In order to properly wait for the nand chip to be ready in panic_nand_wait(), the chip must first be selected. When using the atmel nand flash controller, a panic would occur due to a NULL pointer exception. Fixes: 2af7c6539931 ("mtd: Add panic_write for NAND flashes") Cc: Signed-off-by: Brent Taylor Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin commit b7937be8df3b7ded0f9f37849e54bd70f11db959 Author: Jonathan Liu Date: Mon Aug 7 21:55:45 2017 +1000 drm/panel: simple: Add missing panel_simple_unprepare() calls [ Upstream commit f3621a8eb59a913612c8e6e37d81f16b649f8b6c ] During panel removal or system shutdown panel_simple_disable() is called which disables the panel backlight but the panel is still powered due to missing calls to panel_simple_unprepare(). Fixes: d02fd93e2cd8 ("drm/panel: simple - Disable panel on shutdown") Cc: stable@vger.kernel.org # v3.16+ Signed-off-by: Jonathan Liu Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/20170807115545.27747-1-net147@gmail.com Signed-off-by: Sasha Levin commit 6c917e099dae9190f1947a5630d910dfbc6b2182 Author: Huacai Chen Date: Fri Nov 24 15:14:25 2017 -0800 bcache: Fix building error on MIPS [ Upstream commit cf33c1ee5254c6a430bc1538232b49c3ea13e613 ] This patch try to fix the building error on MIPS. The reason is MIPS has already defined the PTR macro, which conflicts with the PTR macro in include/uapi/linux/bcache.h. [fixed by mlyle: corrected a line-length issue] Cc: stable@vger.kernel.org Signed-off-by: Huacai Chen Reviewed-by: Michael Lyle Signed-off-by: Michael Lyle Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 9aaebcbeb063168251f9b816a3126c4c4dee70fb Author: Heiner Kallweit Date: Fri Nov 24 07:47:50 2017 +0100 eeprom: at24: check at24_read/write arguments [ Upstream commit d9bcd462daf34aebb8de9ad7f76de0198bb5a0f0 ] So far we completely rely on the caller to provide valid arguments. To be on the safe side perform an own sanity check. Cc: stable@vger.kernel.org Signed-off-by: Heiner Kallweit Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 8fe2cf2527e2f43f543be6a7fcdf470bea5bd415 Author: Adrian Hunter Date: Tue Nov 21 15:42:29 2017 +0200 mmc: core: Do not leave the block driver in a suspended state [ Upstream commit ebe7dd45cf49e3b49cacbaace17f9f878f21fbea ] The block driver must be resumed if the mmc bus fails to suspend the card. Signed-off-by: Adrian Hunter Reviewed-by: Linus Walleij Cc: stable@vger.kernel.org # v3.19+ Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 4dfff01e8224a39bd75aa95c9b842b63e2b05b94 Author: Paolo Bonzini Date: Fri Nov 10 10:49:38 2017 +0100 KVM: x86: inject exceptions produced by x86_decode_insn [ Upstream commit 6ea6e84309ca7e0e850b3083e6b09344ee15c290 ] Sometimes, a processor might execute an instruction while another processor is updating the page tables for that instruction's code page, but before the TLB shootdown completes. The interesting case happens if the page is in the TLB. In general, the processor will succeed in executing the instruction and nothing bad happens. However, what if the instruction is an MMIO access? If *that* happens, KVM invokes the emulator, and the emulator gets the updated page tables. If the update side had marked the code page as non present, the page table walk then will fail and so will x86_decode_insn. Unfortunately, even though kvm_fetch_guest_virt is correctly returning X86EMUL_PROPAGATE_FAULT, x86_decode_insn's caller treats the failure as a fatal error if the instruction cannot simply be reexecuted (as is the case for MMIO). And this in fact happened sometimes when rebooting Windows 2012r2 guests. Just checking ctxt->have_exception and injecting the exception if true is enough to fix the case. Thanks to Eduardo Habkost for helping in the debugging of this issue. Reported-by: Yanan Fu Cc: Eduardo Habkost Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Radim Krčmář Signed-off-by: Sasha Levin commit ae6b501e55fb000462e67e7cfdcb0d643033e8f3 Author: Liran Alon Date: Sun Nov 5 16:56:32 2017 +0200 KVM: x86: Exit to user-mode on #UD intercept when emulator requires [ Upstream commit 61cb57c9ed631c95b54f8e9090c89d18b3695b3c ] Instruction emulation after trapping a #UD exception can result in an MMIO access, for example when emulating a MOVBE on a processor that doesn't support the instruction. In this case, the #UD vmexit handler must exit to user mode, but there wasn't any code to do so. Add it for both VMX and SVM. Signed-off-by: Liran Alon Reviewed-by: Nikita Leshenko Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Konrad Rzeszutek Wilk Reviewed-by: Wanpeng Li Reviewed-by: Paolo Bonzini Cc: stable@vger.kernel.org Signed-off-by: Radim Krčmář Signed-off-by: Sasha Levin commit 30e1d8ae6e02b03588caa706e237d0dc4549010f Author: Liran Alon Date: Sun Nov 5 16:11:30 2017 +0200 KVM: x86: pvclock: Handle first-time write to pvclock-page contains random junk [ Upstream commit 51c4b8bba674cfd2260d173602c4dac08e4c3a99 ] When guest passes KVM it's pvclock-page GPA via WRMSR to MSR_KVM_SYSTEM_TIME / MSR_KVM_SYSTEM_TIME_NEW, KVM don't initialize pvclock-page to some start-values. It just requests a clock-update which will happen before entering to guest. The clock-update logic will call kvm_setup_pvclock_page() to update the pvclock-page with info. However, kvm_setup_pvclock_page() *wrongly* assumes that the version-field is initialized to an even number. This is wrong because at first-time write, field could be any-value. Fix simply makes sure that if first-time version-field is odd, increment it once more to make it even and only then start standard logic. This follows same logic as done in other pvclock shared-pages (See kvm_write_wall_clock() and record_steal_time()). Signed-off-by: Liran Alon Reviewed-by: Nikita Leshenko Reviewed-by: Konrad Rzeszutek Wilk Signed-off-by: Konrad Rzeszutek Wilk Reviewed-by: Paolo Bonzini Cc: stable@vger.kernel.org Signed-off-by: Radim Krčmář Signed-off-by: Sasha Levin commit fd170970fecedee7045b8aba17bcb371d8dfa07f Author: Josef Bacik Date: Fri Nov 17 14:50:46 2017 -0500 btrfs: clear space cache inode generation always [ Upstream commit 8e138e0d92c6c9d3d481674fb14e3439b495be37 ] We discovered a box that had double allocations, and suspected the space cache may be to blame. While auditing the write out path I noticed that if we've already setup the space cache we will just carry on. This means that any error we hit after cache_save_setup before we go to actually write the cache out we won't reset the inode generation, so whatever was already written will be considered correct, except it'll be stale. Fix this by _always_ resetting the generation on the block group inode, this way we only ever have valid or invalid cache. With this patch I was no longer able to reproduce cache corruption with dm-log-writes and my bpf error injection tool. Cc: stable@vger.kernel.org Signed-off-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 83c85849819bd60f2806b079a01f283f8ae27f37 Author: chenjie Date: Wed Nov 29 16:10:54 2017 -0800 mm/madvise.c: fix madvise() infinite loop under special circumstances [ Upstream commit 6ea8d958a2c95a1d514015d4e29ba21a8c0a1a91 ] MADVISE_WILLNEED has always been a noop for DAX (formerly XIP) mappings. Unfortunately madvise_willneed() doesn't communicate this information properly to the generic madvise syscall implementation. The calling convention is quite subtle there. madvise_vma() is supposed to either return an error or update &prev otherwise the main loop will never advance to the next vma and it will keep looping for ever without a way to get out of the kernel. It seems this has been broken since introduction. Nobody has noticed because nobody seems to be using MADVISE_WILLNEED on these DAX mappings. [mhocko@suse.com: rewrite changelog] Link: http://lkml.kernel.org/r/20171127115318.911-1-guoxuenan@huawei.com Fixes: fe77ba6f4f97 ("[PATCH] xip: madvice/fadvice: execute in place") Signed-off-by: chenjie Signed-off-by: guoxuenan Acked-by: Michal Hocko Cc: Minchan Kim Cc: zhangyi (F) Cc: Miao Xie Cc: Mike Rapoport Cc: Shaohua Li Cc: Andrea Arcangeli Cc: Mel Gorman Cc: Kirill A. Shutemov Cc: David Rientjes Cc: Anshuman Khandual Cc: Rik van Riel Cc: Carsten Otte Cc: Dan Williams Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 88c251ffb80e140339cbe74f320d6cba38360ab5 Author: Kirill A. Shutemov Date: Mon Nov 27 06:21:25 2017 +0300 mm, thp: Do not make page table dirty unconditionally in touch_p[mu]d() [ Upstream commit a8f97366452ed491d13cf1e44241bc0b5740b1f0 ] Currently, we unconditionally make page table dirty in touch_pmd(). It may result in false-positive can_follow_write_pmd(). We may avoid the situation, if we would only make the page table entry dirty if caller asks for write access -- FOLL_WRITE. The patch also changes touch_pud() in the same way. Signed-off-by: Kirill A. Shutemov Cc: Michal Hocko Cc: Hugh Dickins Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 82cf23e1b0ca95ef53afead81d9563081d8bc431 Author: Sai Praneeth Date: Wed Dec 9 15:41:08 2015 -0800 x86/efi-bgrt: Fix kernel panic when mapping BGRT data [ Upstream commit 50a0cb565246f20d59cdb161778531e4b19d35ac ] Starting with this commit 35eb8b81edd4 ("x86/efi: Build our own page table structures") efi regions have a separate page directory called "efi_pgd". In order to access any efi region we have to first shift %cr3 to this page table. In the bgrt code we are trying to copy bgrt_header and image, but these regions fall under "EFI_BOOT_SERVICES_DATA" and to access these regions we have to shift %cr3 to efi_pgd and not doing so will cause page fault as shown below. [ 0.251599] Last level dTLB entries: 4KB 64, 2MB 0, 4MB 0, 1GB 4 [ 0.259126] Freeing SMP alternatives memory: 32K (ffffffff8230e000 - ffffffff82316000) [ 0.271803] BUG: unable to handle kernel paging request at fffffffefce35002 [ 0.279740] IP: [] efi_bgrt_init+0x144/0x1fd [ 0.286383] PGD 300f067 PUD 0 [ 0.289879] Oops: 0000 [#1] SMP [ 0.293566] Modules linked in: [ 0.297039] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.0-rc1-eywa-eywa-built-in-47041+ #2 [ 0.306619] Hardware name: Intel Corporation Skylake Client platform/Skylake Y LPDDR3 RVP3, BIOS SKLSE2R1.R00.B104.B01.1511110114 11/11/2015 [ 0.320925] task: ffffffff820134c0 ti: ffffffff82000000 task.ti: ffffffff82000000 [ 0.329420] RIP: 0010:[] [] efi_bgrt_init+0x144/0x1fd [ 0.338821] RSP: 0000:ffffffff82003f18 EFLAGS: 00010246 [ 0.344852] RAX: fffffffefce35000 RBX: fffffffefce35000 RCX: fffffffefce2b000 [ 0.352952] RDX: 000000008a82b000 RSI: ffffffff8235bb80 RDI: 000000008a835000 [ 0.361050] RBP: ffffffff82003f30 R08: 000000008a865000 R09: ffffffffff202850 [ 0.369149] R10: ffffffff811ad62f R11: 0000000000000000 R12: 0000000000000000 [ 0.377248] R13: ffff88016dbaea40 R14: ffffffff822622c0 R15: ffffffff82003fb0 [ 0.385348] FS: 0000000000000000(0000) GS:ffff88016d800000(0000) knlGS:0000000000000000 [ 0.394533] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.401054] CR2: fffffffefce35002 CR3: 000000000300c000 CR4: 00000000003406f0 [ 0.409153] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 0.417252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 0.425350] Stack: [ 0.427638] ffffffffffffffff ffffffff82256900 ffff88016dbaea40 ffffffff82003f40 [ 0.436086] ffffffff821bbce0 ffffffff82003f88 ffffffff8219c0c2 0000000000000000 [ 0.444533] ffffffff8219ba4a ffffffff822622c0 0000000000083000 00000000ffffffff [ 0.452978] Call Trace: [ 0.455763] [] efi_late_init+0x9/0xb [ 0.461697] [] start_kernel+0x463/0x47f [ 0.467928] [] ? set_init_arg+0x55/0x55 [ 0.474159] [] ? early_idt_handler_array+0x120/0x120 [ 0.481669] [] x86_64_start_reservations+0x2a/0x2c [ 0.488982] [] x86_64_start_kernel+0x13d/0x14c [ 0.495897] Code: 00 41 b4 01 48 8b 78 28 e8 09 36 01 00 48 85 c0 48 89 c3 75 13 48 c7 c7 f8 ac d3 81 31 c0 e8 d7 3b fb fe e9 b5 00 00 00 45 84 e4 <44> 8b 6b 02 74 0d be 06 00 00 00 48 89 df e8 ae 34 0$ [ 0.518151] RIP [] efi_bgrt_init+0x144/0x1fd [ 0.524888] RSP [ 0.528851] CR2: fffffffefce35002 [ 0.532615] ---[ end trace 7b06521e6ebf2aea ]--- [ 0.537852] Kernel panic - not syncing: Attempted to kill the idle task! As said above one way to fix this bug is to shift %cr3 to efi_pgd but we are not doing that way because it leaks inner details of how we switch to EFI page tables into a new call site and it also adds duplicate code. Instead, we remove the call to efi_lookup_mapped_addr() and always perform early_mem*() instead of early_io*() because we want to remap RAM regions and not I/O regions. We also delete efi_lookup_mapped_addr() because we are no longer using it. Signed-off-by: Sai Praneeth Prakhya Reported-by: Wendy Wang Cc: Borislav Petkov Cc: Josh Triplett Cc: Ricardo Neri Cc: Ravi Shankar Signed-off-by: Matt Fleming Signed-off-by: Sasha Levin commit acec4640403299178447552a13fa466cbed57b2d Author: Matt Fleming Date: Fri Nov 27 21:09:34 2015 +0000 x86/efi: Build our own page table structures [ Upstream commit 67a9108ed4313b85a9c53406d80dc1ae3f8c3e36 ] With commit e1a58320a38d ("x86/mm: Warn on W^X mappings") all users booting on 64-bit UEFI machines see the following warning, ------------[ cut here ]------------ WARNING: CPU: 7 PID: 1 at arch/x86/mm/dump_pagetables.c:225 note_page+0x5dc/0x780() x86/mm: Found insecure W+X mapping at address ffff88000005f000/0xffff88000005f000 ... x86/mm: Checked W+X mappings: FAILED, 165660 W+X pages found. ... This is caused by mapping EFI regions with RWX permissions. There isn't much we can do to restrict the permissions for these regions due to the way the firmware toolchains mix code and data, but we can at least isolate these mappings so that they do not appear in the regular kernel page tables. In commit d2f7cbe7b26a ("x86/efi: Runtime services virtual mapping") we started using 'trampoline_pgd' to map the EFI regions because there was an existing identity mapping there which we use during the SetVirtualAddressMap() call and for broken firmware that accesses those addresses. But 'trampoline_pgd' shares some PGD entries with 'swapper_pg_dir' and does not provide the isolation we require. Notably the virtual address for __START_KERNEL_map and MODULES_START are mapped by the same PGD entry so we need to be more careful when copying changes over in efi_sync_low_kernel_mappings(). This patch doesn't go the full mile, we still want to share some PGD entries with 'swapper_pg_dir'. Having completely separate page tables brings its own issues such as synchronising new mappings after memory hotplug and module loading. Sharing also keeps memory usage down. Signed-off-by: Matt Fleming Reviewed-by: Borislav Petkov Acked-by: Borislav Petkov Cc: Andrew Morton Cc: Andy Lutomirski Cc: Andy Lutomirski Cc: Ard Biesheuvel Cc: Borislav Petkov Cc: Brian Gerst Cc: Dave Jones Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Sai Praneeth Prakhya Cc: Stephen Smalley Cc: Thomas Gleixner Cc: Toshi Kani Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/1448658575-17029-6-git-send-email-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 59a845d40c87f1b5c2e760373c11da2e716fbeb7 Author: Matt Fleming Date: Fri Nov 27 21:09:33 2015 +0000 x86/efi: Hoist page table switching code into efi_call_virt() [ Upstream commit c9f2a9a65e4855b74d92cdad688f6ee4a1a323ff ] This change is a prerequisite for pending patches that switch to a dedicated EFI page table, instead of using 'trampoline_pgd' which shares PGD entries with 'swapper_pg_dir'. The pending patches make it impossible to dereference the runtime service function pointer without first switching %cr3. It's true that we now have duplicated switching code in efi_call_virt() and efi_call_phys_{prolog,epilog}() but we are sacrificing code duplication for a little more clarity and the ease of writing the page table switching code in C instead of asm. Signed-off-by: Matt Fleming Reviewed-by: Borislav Petkov Acked-by: Borislav Petkov Cc: Andrew Morton Cc: Andy Lutomirski Cc: Andy Lutomirski Cc: Ard Biesheuvel Cc: Borislav Petkov Cc: Brian Gerst Cc: Dave Jones Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Sai Praneeth Prakhya Cc: Stephen Smalley Cc: Thomas Gleixner Cc: Toshi Kani Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/1448658575-17029-5-git-send-email-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit d7ba9d2638b53022a493492d4da89a955ab6fc22 Author: Matt Fleming Date: Fri Nov 27 21:09:31 2015 +0000 x86/mm/pat: Ensure cpa->pfn only contains page frame numbers [ Upstream commit edc3b9129cecd0f0857112136f5b8b1bc1d45918 ] The x86 pageattr code is confused about the data that is stored in cpa->pfn, sometimes it's treated as a page frame number, sometimes it's treated as an unshifted physical address, and in one place it's treated as a pte. The result of this is that the mapping functions do not map the intended physical address. This isn't a problem in practice because most of the addresses we're mapping in the EFI code paths are already mapped in 'trampoline_pgd' and so the pageattr mapping functions don't actually do anything in this case. But when we move to using a separate page table for the EFI runtime this will be an issue. Signed-off-by: Matt Fleming Reviewed-by: Borislav Petkov Acked-by: Borislav Petkov Cc: Andy Lutomirski Cc: Ard Biesheuvel Cc: Borislav Petkov Cc: Brian Gerst Cc: Dave Hansen Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Sai Praneeth Prakhya Cc: Thomas Gleixner Cc: Toshi Kani Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/1448658575-17029-3-git-send-email-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 5e80f6036c71f6ce1dbba0ad2925c331767f76ac Author: Herbert Xu Date: Thu Oct 19 20:51:10 2017 +0800 ipsec: Fix aborted xfrm policy dump crash [ Upstream commit 1137b5e2529a8f5ca8ee709288ecba3e68044df2 ] An independent security researcher, Mohamed Ghannam, has reported this vulnerability to Beyond Security's SecuriTeam Secure Disclosure program. The xfrm_dump_policy_done function expects xfrm_dump_policy to have been called at least once or it will crash. This can be triggered if a dump fails because the target socket's receive buffer is full. This patch fixes it by using the cb->start mechanism to ensure that the initialisation is always done regardless of the buffer situation. Fixes: 12a169e7d8f4 ("ipsec: Put dumpers on the dump list") Signed-off-by: Herbert Xu Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 40bb024a89e588c618bc00f70d90bd9ef90b6fce Author: Tom Herbert Date: Tue Dec 15 15:41:37 2015 -0800 netlink: add a start callback for starting a netlink dump [ Upstream commit fc9e50f5a5a4e1fa9ba2756f745a13e693cf6a06 ] The start callback allows the caller to set up a context for the dump callbacks. Presumably, the context can then be destroyed in the done callback. Signed-off-by: Tom Herbert Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ef94a033320fba2d0795ed517b7a5d5468d68d5a Author: Juergen Gross Date: Thu Dec 22 08:19:46 2016 +0100 xen: xenbus driver must not accept invalid transaction ids [ Upstream commit 639b08810d6ad74ded2c5f6e233c4fcb9d147168 ] When accessing Xenstore in a transaction the user is specifying a transaction id which he normally obtained from Xenstore when starting the transaction. Xenstore is validating a transaction id against all known transaction ids of the connection the request came in. As all requests of a domain not being the one where Xenstore lives share one connection, validation of transaction ids of different users of Xenstore in that domain should be done by the kernel of that domain being the multiplexer between the Xenstore users in that domain and Xenstore. In order to prohibit one Xenstore user "hijacking" a transaction from another user the xenbus driver has to verify a given transaction id against all known transaction ids of the user before forwarding it to Xenstore. Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin commit 466c181ada32570a14931df9489cabf0f38fefdc Author: Heiko Carstens Date: Tue Dec 20 12:58:10 2016 +0100 s390/kbuild: enable modversions for symbols exported from asm [ Upstream commit cabab3f9f5ca077535080b3252e6168935b914af ] s390 version of commit 334bb7738764 ("x86/kbuild: enable modversions for symbols exported from asm") so we get also rid of all these warnings: WARNING: EXPORT symbol "_mcount" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "memcpy" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "memmove" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "memset" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "save_fpu_regs" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "sie64a" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "sie_exit" [vmlinux] version generation failed, symbol will not be versioned. Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit 9a921388d86fb1773aea41d03dfe040c1abd12fa Author: Richard Fitzgerald Date: Tue Dec 20 10:29:12 2016 +0000 ASoC: wm_adsp: Don't overrun firmware file buffer when reading region data [ Upstream commit 1cab2a84f470e15ecc8e5143bfe9398c6e888032 ] Protect against corrupt firmware files by ensuring that the length we get for the data in a region actually lies within the available firmware file data buffer. Signed-off-by: Richard Fitzgerald Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4841c9437173d8ebf1f9dc46fbacb714342d5b73 Author: Colin Ian King Date: Thu Dec 8 13:05:43 2016 +0000 ASoC: rsnd: don't double free kctrl [ Upstream commit 0ea617a298dcdc2251b4e10f83ac3f3e627b66e3 ] On an error, snd_ctl_add already free's kctrl, so calling snd_ctl_free_one to free it again leads to a double free error. Fix this by removing the extraneous snd_ctl_free_one call. Issue found using static analysis with CoverityScan, CID 1372908 Signed-off-by: Colin Ian King Acked-by: Kuninori Morimoto Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1dd95d380e10500f2c469af98a351bcbe0c4eac8 Author: Florian Westphal Date: Tue Dec 13 13:59:33 2016 +0100 netfilter: nf_tables: fix oob access [ Upstream commit 3e38df136e453aa69eb4472108ebce2fb00b1ba6 ] BUG: KASAN: slab-out-of-bounds in nf_tables_rule_destroy+0xf1/0x130 at addr ffff88006a4c35c8 Read of size 8 by task nft/1607 When we've destroyed last valid expr, nft_expr_next() returns an invalid expr. We must not dereference it unless it passes != nft_expr_last() check. Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit ff7fd3f8ce5806531050c70754d728fa59e9e53d Author: Pablo Neira Ayuso Date: Sun Dec 11 20:46:51 2016 +0100 netfilter: nft_queue: use raw_smp_processor_id() [ Upstream commit c2e756ff9e699865d294cdc112acfc36419cf5cc ] Using smp_processor_id() causes splats with PREEMPT_RCU: [19379.552780] BUG: using smp_processor_id() in preemptible [00000000] code: ping/32389 [19379.552793] caller is debug_smp_processor_id+0x17/0x19 [...] [19379.552823] Call Trace: [19379.552832] [] dump_stack+0x67/0x90 [19379.552837] [] check_preemption_disabled+0xe5/0xf5 [19379.552842] [] debug_smp_processor_id+0x17/0x19 [19379.552849] [] nft_queue_eval+0x35/0x20c [nft_queue] No need to disable preemption since we only fetch the numeric value, so let's use raw_smp_processor_id() instead. Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 253a504621f7679961a2f25096c6bbe7206e5d18 Author: Pan Bian Date: Sat Dec 3 21:44:30 2016 +0800 staging: iio: cdc: fix improper return value [ Upstream commit 91ca1a8c584f55857b1f6ab20a1d3a1ce7a559bb ] At the end of function ad7150_write_event_config(), directly returns 0. As a result, the errors will be ignored by the callers. It may be better to return variable "ret". Signed-off-by: Pan Bian Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit d57efe91fbd709e6a13397a966657d1b7e50aa33 Author: Pan Bian Date: Sat Dec 3 17:24:17 2016 +0800 iio: light: fix improper return value [ Upstream commit db4e5376d058af8924fafd0520a0942d92538d0e ] In function cm3232_reg_init(), it returns 0 even if the last call to i2c_smbus_write_byte_data() returns a negative value (indicates error). As a result, the return value may be inconsistent with the execution status, and the caller of cm3232_reg_init() will not be able to detect the error. This patch fixes the bug. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188641 Signed-off-by: Pan Bian Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit a60c66435e3f9002cc777d49f875742f2268b063 Author: Masashi Honma Date: Wed Nov 30 09:06:04 2016 +0900 mac80211: Suppress NEW_PEER_CANDIDATE event if no room [ Upstream commit 11197d006bcfabf0173a7820a163fcaac420d10e ] Previously, kernel sends NEW_PEER_CANDIDATE event to user land even if the found peer does not have any room to accept other peer. This causes continuous connection trials. Signed-off-by: Masashi Honma Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit ff212c6eceb041f02cefb8c707b9165f4d1cb3c4 Author: Masashi Honma Date: Thu Dec 8 10:15:50 2016 +0900 mac80211: Remove invalid flag operations in mesh TSF synchronization [ Upstream commit 76f43b4c0a9337af22827d78de4f2b8fd5328489 ] mesh_sync_offset_adjust_tbtt() implements Extensible synchronization framework ([1] 13.13.2 Extensible synchronization framework). It shall not operate the flag "TBTT Adjusting subfield" ([1] 8.4.2.100.8 Mesh Capability), since it is used only for MBCA ([1] 13.13.4 Mesh beacon collision avoidance, see 13.13.4.4.3 TBTT scanning and adjustment procedures for detail). So this patch remove the flag operations. [1] IEEE Std 802.11 2012 Signed-off-by: Masashi Honma [remove adjusting_tbtt entirely, since it's now unused] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 316a5d63aa3b8380f5df5d4fea18356d463601c0 Author: Gabriele Mazzotta Date: Sat Dec 24 19:50:00 2016 +0100 ALSA: hda - Apply ALC269_FIXUP_NO_SHUTUP on HDA_FIXUP_ACT_PROBE [ Upstream commit 972aa2c708703c21f14eb958b37e82aae2530e44 ] Setting shutup when the action is HDA_FIXUP_ACT_PRE_PROBE might not have the desired effect since it could be overridden by another more generic shutup function. Prevent this by setting the more specific shutup function on HDA_FIXUP_ACT_PROBE. Signed-off-by: Gabriele Mazzotta Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 548d0033afa486003a15a0d39454422e2af8c322 Author: Christian Lamparter Date: Thu Dec 29 16:12:09 2016 +0200 ath10k: fix potential memory leak in ath10k_wmi_tlv_op_pull_fw_stats() [ Upstream commit 097e46d2ae90265d1afe141ba6208ba598b79e01 ] ath10k_wmi_tlv_op_pull_fw_stats() uses tb = ath10k_wmi_tlv_parse_alloc(...) function, which allocates memory. If any of the three error-paths are taken, this tb needs to be freed. Signed-off-by: Christian Lamparter Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 4111d947598a89e6cf8b9662ce6af24a488ffefc Author: Ryan Hsu Date: Tue Dec 13 14:55:19 2016 -0800 ath10k: fix incorrect txpower set by P2P_DEVICE interface [ Upstream commit 88407beb1b1462f706a1950a355fd086e1c450b6 ] Ath10k reports the phy capability that supports P2P_DEVICE interface. When we use the P2P supported wpa_supplicant to start connection, it'll create two interfaces, one is wlan0 (vdev_id=0) and one is P2P_DEVICE p2p-dev-wlan0 which is for p2p control channel (vdev_id=1). ath10k_pci mac vdev create 0 (add interface) type 2 subtype 0 ath10k_add_interface: vdev_id: 0, txpower: 0, bss_power: 0 ... ath10k_pci mac vdev create 1 (add interface) type 2 subtype 1 ath10k_add_interface: vdev_id: 1, txpower: 0, bss_power: 0 And the txpower in per vif bss_conf will only be set to valid tx power when the interface is assigned with channel_ctx. But this P2P_DEVICE interface will never be used for any connection, so that the uninitialized bss_conf.txpower=0 is assinged to the arvif->txpower when interface created. Since the txpower configuration is firmware per physical interface. So the smallest txpower of all vifs will be the one limit the tx power of the physical device, that causing the low txpower issue on other active interfaces. wlan0: Limiting TX power to 21 (24 - 3) dBm ath10k_pci mac vdev_id 0 txpower 21 ath10k_mac_txpower_recalc: vdev_id: 1, txpower: 0 ath10k_mac_txpower_recalc: vdev_id: 0, txpower: 21 ath10k_pci mac txpower 0 This issue only happens when we use the wpa_supplicant that supports P2P or if we use the iw tool to create the control P2P_DEVICE interface. Signed-off-by: Ryan Hsu Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 82caca28dc6e21f3def96dc79ddefbd1745226a0 Author: Daniel Vetter Date: Fri Dec 30 17:38:52 2016 +0100 drm/armada: Fix compile fail [ Upstream commit 7357f89954b6d005df6ab8929759e78d7d9a80f9 ] I reported the include issue for tracepoints a while ago, but nothing seems to have happened. Now it bit us, since the drm_mm_print conversion was broken for armada. Fix it, so I can re-enable armada in the drm-misc build configs. v2: Rebase just the compile fix on top of Chris' build fix. Cc: Russell King Cc: Chris Wilson Acked: Chris Wilson Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1483115932-19584-1-git-send-email-daniel.vetter@ffwll.ch Signed-off-by: Sasha Levin commit 3c06adbfa0c1b14435093fa0c79e90d88253f5e2 Author: Thomas Preisner Date: Fri Dec 30 03:37:53 2016 +0100 net: 3com: typhoon: typhoon_init_one: fix incorrect return values [ Upstream commit 107fded7bf616ad6f46823d98b8ed6405d7adf2d ] In a few cases the err-variable is not set to a negative error code if a function call in typhoon_init_one() fails and thus 0 is returned instead. It may be better to set err to the appropriate negative error code before returning. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188841 Reported-by: Pan Bian Signed-off-by: Thomas Preisner Signed-off-by: Milan Stephan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3dae1805ba9fe8560868d5455da1914da53da1db Author: Thomas Preisner Date: Fri Dec 30 03:37:54 2016 +0100 net: 3com: typhoon: typhoon_init_one: make return values more specific [ Upstream commit 6b6bbb5922a4b1d4b58125a572da91010295fba3 ] In some cases the return value of a failing function is not being used and the function typhoon_init_one() returns another negative error code instead. Signed-off-by: Thomas Preisner Signed-off-by: Milan Stephan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2f6bfe3d1d8ed8df33b78865f81c8fe89658aea7 Author: Bjorn Helgaas Date: Mon Jan 2 14:04:24 2017 -0600 PCI: Apply _HPX settings only to relevant devices [ Upstream commit 977509f7c5c6fb992ffcdf4291051af343b91645 ] Previously we didn't check the type of device before trying to apply Type 1 (PCI-X) or Type 2 (PCIe) Setting Records from _HPX. We don't support PCI-X Setting Records, so this was harmless, but the warning was useless. We do support PCIe Setting Records, and we didn't check whether a device was PCIe before applying settings. I don't think anything bad happened on non-PCIe devices because pcie_capability_clear_and_set_word(), pcie_cap_has_lnkctl(), etc., would fail before doing any harm. But it's ugly to depend on those internals. Check the device type before attempting to apply Type 1 and Type 2 Setting Records (Type 0 records are applicable to PCI, PCI-X, and PCIe devices). A side benefit is that this prevents useless "not supported" warnings when a BIOS supplies a Type 1 (PCI-X) Setting Record and we try to apply it to every single device: pci 0000:00:00.0: PCI-X settings not supported After this patch, we'll get the warning only when a BIOS supplies a Type 1 record and we have a PCI-X device to which it should be applied. Link: https://bugzilla.kernel.org/show_bug.cgi?id=187731 Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 783941bd9f445a37c2854ec0b4cb9f9e603193a7 Author: Santosh Shilimkar Date: Mon Jul 4 17:04:37 2016 -0700 RDS: RDMA: return appropriate error on rdma map failures [ Upstream commit 584a8279a44a800dea5a5c1e9d53a002e03016b4 ] The first message to a remote node should prompt a new connection even if it is RDMA operation. For RDMA operation the MR mapping can fail because connections is not yet up. Since the connection establishment is asynchronous, we make sure the map failure because of unavailable connection reach to the user by appropriate error code. Before returning to the user, lets trigger the connection so that its ready for the next retry. Signed-off-by: Santosh Shilimkar Signed-off-by: Sasha Levin commit e79a49391fa2462746e1bb1616dc67270224e8b1 Author: Benjamin Poirier Date: Fri Jul 21 11:36:26 2017 -0700 e1000e: Separate signaling for link check/link up [ Upstream commit 19110cfbb34d4af0cdfe14cd243f3b09dc95b013 ] Lennart reported the following race condition: \ e1000_watchdog_task \ e1000e_has_link \ hw->mac.ops.check_for_link() === e1000e_check_for_copper_link /* link is up */ mac->get_link_status = false; /* interrupt */ \ e1000_msix_other hw->mac.get_link_status = true; link_active = !hw->mac.get_link_status /* link_active is false, wrongly */ This problem arises because the single flag get_link_status is used to signal two different states: link status needs checking and link status is down. Avoid the problem by using the return value of .check_for_link to signal the link status to e1000e_has_link(). Reported-by: Lennart Sorensen Signed-off-by: Benjamin Poirier Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 9fe77855443367f0f478fc6f4f6bb3728b4c5224 Author: Benjamin Poirier Date: Fri Jul 21 11:36:25 2017 -0700 e1000e: Fix return value test [ Upstream commit d3509f8bc7b0560044c15f0e3ecfde1d9af757a6 ] All the helpers return -E1000_ERR_PHY. Signed-off-by: Benjamin Poirier Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit c5360244f3254d06439015ed4fec7beaadaca216 Author: Benjamin Poirier Date: Fri Jul 21 11:36:23 2017 -0700 e1000e: Fix error path in link detection [ Upstream commit c4c40e51f9c32c6dd8adf606624c930a1c4d9bbb ] In case of error from e1e_rphy(), the loop will exit early and "success" will be set to true erroneously. Signed-off-by: Benjamin Poirier Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 63424f2032a2bb2be99be66c279c8148afba1ea3 Author: Tuomas Tynkkynen Date: Wed Sep 6 17:59:08 2017 +0300 net/9p: Switch to wait_event_killable() [ Upstream commit 9523feac272ccad2ad8186ba4fcc89103754de52 ] Because userspace gets Very Unhappy when calls like stat() and execve() return -EINTR on 9p filesystem mounts. For instance, when bash is looking in PATH for things to execute and some SIGCHLD interrupts stat(), bash can throw a spurious 'command not found' since it doesn't retry the stat(). In practice, hitting the problem is rare and needs a really slow/bogged down 9p server. Cc: stable@vger.kernel.org Signed-off-by: Tuomas Tynkkynen Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 3c442f7cafa5caec2244ff6bf9bbafbe5900b5e6 Author: Ricardo Ribalda Delgado Date: Tue Oct 17 11:48:50 2017 -0400 media: v4l2-ctrl: Fix flags field on Control events [ Upstream commit 9cac9d2fb2fe0e0cadacdb94415b3fe49e3f724f ] VIDIOC_DQEVENT and VIDIOC_QUERY_EXT_CTRL should give the same output for the control flags field. This patch creates a new function user_flags(), that calculates the user exported flags value (which is different than the kernel internal flags structure). This function is then used by all the code that exports the internal flags to userspace. Reported-by: Dimitrios Katsaros Signed-off-by: Ricardo Ribalda Delgado Signed-off-by: Hans Verkuil Cc: # for v3.17 and up Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit ee16c9ea4ef98684378e020df9a4efa32955d767 Author: Johan Hovold Date: Thu Sep 21 05:40:18 2017 -0300 [media] cx231xx-cards: fix NULL-deref on missing association descriptor [ Upstream commit 6c3b047fa2d2286d5e438bcb470c7b1a49f415f6 ] Make sure to check that we actually have an Interface Association Descriptor before dereferencing it during probe to avoid dereferencing a NULL-pointer. Fixes: e0d3bafd0258 ("V4L/DVB (10954): Add cx231xx USB driver") Cc: stable # 2.6.30 Reported-by: Andrey Konovalov Signed-off-by: Johan Hovold Tested-by: Andrey Konovalov Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 6302460e31ff6ad3c18aa9f84558e679053e8497 Author: Sean Young Date: Sun Oct 8 14:18:52 2017 -0400 media: rc: check for integer overflow [ Upstream commit 3e45067f94bbd61dec0619b1c32744eb0de480c8 ] The ioctl LIRC_SET_REC_TIMEOUT would set a timeout of 704ns if called with a timeout of 4294968us. Cc: Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 89f6f75a59ed27cec4865816abd98fd4caf2fc85 Author: Michele Baldessari Date: Mon Nov 6 08:50:22 2017 -0500 media: Don't do DMA on stack for firmware upload in the AS102 driver [ Upstream commit b3120d2cc447ee77b9d69bf4ad7b452c9adb4d39 ] Firmware load on AS102 is using the stack which is not allowed any longer. We currently fail with: kernel: transfer buffer not dma capable kernel: ------------[ cut here ]------------ kernel: WARNING: CPU: 0 PID: 598 at drivers/usb/core/hcd.c:1595 usb_hcd_map_urb_for_dma+0x41d/0x620 kernel: Modules linked in: amd64_edac_mod(-) edac_mce_amd as102_fe dvb_as102(+) kvm_amd kvm snd_hda_codec_realtek dvb_core snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_hda_codec irqbypass crct10dif_pclmul crc32_pclmul snd_hda_core snd_hwdep snd_seq ghash_clmulni_intel sp5100_tco fam15h_power wmi k10temp i2c_piix4 snd_seq_device snd_pcm snd_timer parport_pc parport tpm_infineon snd tpm_tis soundcore tpm_tis_core tpm shpchp acpi_cpufreq xfs libcrc32c amdgpu amdkfd amd_iommu_v2 radeon hid_logitech_hidpp i2c_algo_bit drm_kms_helper crc32c_intel ttm drm r8169 mii hid_logitech_dj kernel: CPU: 0 PID: 598 Comm: systemd-udevd Not tainted 4.13.10-200.fc26.x86_64 #1 kernel: Hardware name: ASUS All Series/AM1I-A, BIOS 0505 03/13/2014 kernel: task: ffff979933b24c80 task.stack: ffffaf83413a4000 kernel: RIP: 0010:usb_hcd_map_urb_for_dma+0x41d/0x620 systemd-fsck[659]: /dev/sda2: clean, 49/128016 files, 268609/512000 blocks kernel: RSP: 0018:ffffaf83413a7728 EFLAGS: 00010282 systemd-udevd[604]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable. kernel: RAX: 000000000000001f RBX: ffff979930bce780 RCX: 0000000000000000 kernel: RDX: 0000000000000000 RSI: ffff97993ec0e118 RDI: ffff97993ec0e118 kernel: RBP: ffffaf83413a7768 R08: 000000000000039a R09: 0000000000000000 kernel: R10: 0000000000000001 R11: 00000000ffffffff R12: 00000000fffffff5 kernel: R13: 0000000001400000 R14: 0000000000000001 R15: ffff979930806800 kernel: FS: 00007effaca5c8c0(0000) GS:ffff97993ec00000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 00007effa9fca962 CR3: 0000000233089000 CR4: 00000000000406f0 kernel: Call Trace: kernel: usb_hcd_submit_urb+0x493/0xb40 kernel: ? page_cache_tree_insert+0x100/0x100 kernel: ? xfs_iunlock+0xd5/0x100 [xfs] kernel: ? xfs_file_buffered_aio_read+0x57/0xc0 [xfs] kernel: usb_submit_urb+0x22d/0x560 kernel: usb_start_wait_urb+0x6e/0x180 kernel: usb_bulk_msg+0xb8/0x160 kernel: as102_send_ep1+0x49/0xe0 [dvb_as102] kernel: ? devres_add+0x3f/0x50 kernel: as102_firmware_upload.isra.0+0x1dc/0x210 [dvb_as102] kernel: as102_fw_upload+0xb6/0x1f0 [dvb_as102] kernel: as102_dvb_register+0x2af/0x2d0 [dvb_as102] kernel: as102_usb_probe+0x1f3/0x260 [dvb_as102] kernel: usb_probe_interface+0x124/0x300 kernel: driver_probe_device+0x2ff/0x450 kernel: __driver_attach+0xa4/0xe0 kernel: ? driver_probe_device+0x450/0x450 kernel: bus_for_each_dev+0x6e/0xb0 kernel: driver_attach+0x1e/0x20 kernel: bus_add_driver+0x1c7/0x270 kernel: driver_register+0x60/0xe0 kernel: usb_register_driver+0x81/0x150 kernel: ? 0xffffffffc0807000 kernel: as102_usb_driver_init+0x1e/0x1000 [dvb_as102] kernel: do_one_initcall+0x50/0x190 kernel: ? __vunmap+0x81/0xb0 kernel: ? kfree+0x154/0x170 kernel: ? kmem_cache_alloc_trace+0x15f/0x1c0 kernel: ? do_init_module+0x27/0x1e9 kernel: do_init_module+0x5f/0x1e9 kernel: load_module+0x2602/0x2c30 kernel: SYSC_init_module+0x170/0x1a0 kernel: ? SYSC_init_module+0x170/0x1a0 kernel: SyS_init_module+0xe/0x10 kernel: do_syscall_64+0x67/0x140 kernel: entry_SYSCALL64_slow_path+0x25/0x25 kernel: RIP: 0033:0x7effab6cf3ea kernel: RSP: 002b:00007fff5cfcbbc8 EFLAGS: 00000246 ORIG_RAX: 00000000000000af kernel: RAX: ffffffffffffffda RBX: 00005569e0b83760 RCX: 00007effab6cf3ea kernel: RDX: 00007effac2099c5 RSI: 0000000000009a13 RDI: 00005569e0b98c50 kernel: RBP: 00007effac2099c5 R08: 00005569e0b83ed0 R09: 0000000000001d80 kernel: R10: 00007effab98db00 R11: 0000000000000246 R12: 00005569e0b98c50 kernel: R13: 00005569e0b81c60 R14: 0000000000020000 R15: 00005569dfadfdf7 kernel: Code: 48 39 c8 73 30 80 3d 59 60 9d 00 00 41 bc f5 ff ff ff 0f 85 26 ff ff ff 48 c7 c7 b8 6b d0 92 c6 05 3f 60 9d 00 01 e8 24 3d ad ff <0f> ff 8b 53 64 e9 09 ff ff ff 65 48 8b 0c 25 00 d3 00 00 48 8b kernel: ---[ end trace c4cae366180e70ec ]--- kernel: as10x_usb: error during firmware upload part1 Let's allocate the the structure dynamically so we can get the firmware loaded correctly: [ 14.243057] as10x_usb: firmware: as102_data1_st.hex loaded with success [ 14.500777] as10x_usb: firmware: as102_data2_st.hex loaded with success Signed-off-by: Michele Baldessari Cc: stable@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 465be3fd07491033f6a034a8097384d4266e731f Author: Naveen N. Rao Date: Thu Aug 31 21:55:57 2017 +0530 powerpc/signal: Properly handle return value from uprobe_deny_signal() [ Upstream commit 46725b17f1c6c815a41429259b3f070c01e71bc1 ] When a uprobe is installed on an instruction that we currently do not emulate, we copy the instruction into a xol buffer and single step that instruction. If that instruction generates a fault, we abort the single stepping before invoking the signal handler. Once the signal handler is done, the uprobe trap is hit again since the instruction is retried and the process repeats. We use uprobe_deny_signal() to detect if the xol instruction triggered a signal. If so, we clear TIF_SIGPENDING and set TIF_UPROBE so that the signal is not handled until after the single stepping is aborted. In this case, uprobe_deny_signal() returns true and get_signal() ends up returning 0. However, in do_signal(), we are not looking at the return value, but depending on ksig.sig for further action, all with an uninitialized ksig that is not touched in this scenario. Fix the same by initializing ksig.sig to 0. Fixes: 129b69df9c90 ("powerpc: Use get_signal() signal_setup_done()") Cc: stable@vger.kernel.org # v3.17+ Reported-by: Anton Blanchard Signed-off-by: Naveen N. Rao Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit f828edeff5ec3ea4a1403dfebeb2497c451017c8 Author: John David Anglin Date: Sat Nov 11 17:11:16 2017 -0500 parisc: Fix validity check of pointer size argument in new CAS implementation [ Upstream commit 05f016d2ca7a4fab99d5d5472168506ddf95e74f ] As noted by Christoph Biedl, passing a pointer size of 4 in the new CAS implementation causes a kernel crash. The attached patch corrects the off by one error in the argument validity check. In reviewing the code, I noticed that we only perform word operations with the pointer size argument. The subi instruction intentionally uses a word condition on 64-bit kernels. Nullification was used instead of a cmpib instruction as the branch should never be taken. The shlw pseudo-operation generates a depw,z instruction and it clears the target before doing a shift left word deposit. Thus, we don't need to clip the upper 32 bits of this argument on 64-bit kernels. Tested with a gcc testsuite run with a 64-bit kernel. The gcc atomic code in libgcc is the only direct user of the new CAS implementation that I am aware of. Signed-off-by: John David Anglin Cc: stable@vger.kernel.org # 3.13+ Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit e1db7b149ac65a822e197b3f1f9e5354aaaaa08a Author: Brian King Date: Fri Nov 17 11:05:43 2017 -0600 ixgbe: Fix skb list corruption on Power systems [ Upstream commit 0a9a17e3bb4564caf4bfe2a6783ae1287667d188 ] This patch fixes an issue seen on Power systems with ixgbe which results in skb list corruption and an eventual kernel oops. The following is what was observed: CPU 1 CPU2 ============================ ============================ 1: ixgbe_xmit_frame_ring ixgbe_clean_tx_irq 2: first->skb = skb eop_desc = tx_buffer->next_to_watch 3: ixgbe_tx_map read_barrier_depends() 4: wmb check adapter written status bit 5: first->next_to_watch = tx_desc napi_consume_skb(tx_buffer->skb ..); 6: writel(i, tx_ring->tail); The read_barrier_depends is insufficient to ensure that tx_buffer->skb does not get loaded prior to tx_buffer->next_to_watch, which then results in loading a stale skb pointer. This patch replaces the read_barrier_depends with smp_rmb to ensure loads are ordered with respect to the load of tx_buffer->next_to_watch. Cc: stable Signed-off-by: Brian King Acked-by: Jesse Brandeburg Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 375555f64cf7855cb9bdd1179056f77a449cb4dd Author: Brian King Date: Fri Nov 17 11:05:48 2017 -0600 fm10k: Use smp_rmb rather than read_barrier_depends [ Upstream commit 7b8edcc685b5e2c3c37aa13dc50a88e84a5bfef8 ] The original issue being fixed in this patch was seen with the ixgbe driver, but the same issue exists with fm10k as well, as the code is very similar. read_barrier_depends is not sufficient to ensure loads following it are not speculatively loaded out of order by the CPU, which can result in stale data being loaded, causing potential system crashes. Cc: stable Signed-off-by: Brian King Acked-by: Jesse Brandeburg Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit fc160aac2c865f92891e2f2834ca32e9b14256c6 Author: Brian King Date: Fri Nov 17 11:05:49 2017 -0600 i40evf: Use smp_rmb rather than read_barrier_depends [ Upstream commit f72271e2a0ae4277d53c4053f5eed8bb346ba38a ] The original issue being fixed in this patch was seen with the ixgbe driver, but the same issue exists with i40evf as well, as the code is very similar. read_barrier_depends is not sufficient to ensure loads following it are not speculatively loaded out of order by the CPU, which can result in stale data being loaded, causing potential system crashes. Cc: stable Signed-off-by: Brian King Acked-by: Jesse Brandeburg Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit bfee5738f28cd53486803a2d414624b835c8c6da Author: Brian King Date: Fri Nov 17 11:05:45 2017 -0600 ixgbevf: Use smp_rmb rather than read_barrier_depends [ Upstream commit ae0c585d93dfaf923d2c7eb44b2c3ab92854ea9b ] The original issue being fixed in this patch was seen with the ixgbe driver, but the same issue exists with ixgbevf as well, as the code is very similar. read_barrier_depends is not sufficient to ensure loads following it are not speculatively loaded out of order by the CPU, which can result in stale data being loaded, causing potential system crashes. Cc: stable Signed-off-by: Brian King Acked-by: Jesse Brandeburg Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit d536e7b952d2ba5c5ec97123e6692718083d23d7 Author: Brian King Date: Fri Nov 17 11:05:46 2017 -0600 igbvf: Use smp_rmb rather than read_barrier_depends [ Upstream commit 1e1f9ca546556e508d021545861f6b5fc75a95fe ] The original issue being fixed in this patch was seen with the ixgbe driver, but the same issue exists with igbvf as well, as the code is very similar. read_barrier_depends is not sufficient to ensure loads following it are not speculatively loaded out of order by the CPU, which can result in stale data being loaded, causing potential system crashes. Cc: stable Signed-off-by: Brian King Acked-by: Jesse Brandeburg Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit cc1f30344e2e435b723df46ce0b7e141b471dee6 Author: Brian King Date: Fri Nov 17 11:05:47 2017 -0600 igb: Use smp_rmb rather than read_barrier_depends [ Upstream commit c4cb99185b4cc96c0a1c70104dc21ae14d7e7f28 ] The original issue being fixed in this patch was seen with the ixgbe driver, but the same issue exists with igb as well, as the code is very similar. read_barrier_depends is not sufficient to ensure loads following it are not speculatively loaded out of order by the CPU, which can result in stale data being loaded, causing potential system crashes. Cc: stable Signed-off-by: Brian King Acked-by: Jesse Brandeburg Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 6300747282840447a88f9f00498e88912ce5adff Author: Brian King Date: Fri Nov 17 11:05:44 2017 -0600 i40e: Use smp_rmb rather than read_barrier_depends [ Upstream commit 52c6912fde0133981ee50ba08808f257829c4c93 ] The original issue being fixed in this patch was seen with the ixgbe driver, but the same issue exists with i40e as well, as the code is very similar. read_barrier_depends is not sufficient to ensure loads following it are not speculatively loaded out of order by the CPU, which can result in stale data being loaded, causing potential system crashes. Cc: stable Signed-off-by: Brian King Acked-by: Jesse Brandeburg Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit e94491da9a9d3adde0d245ad8ab4b7068bc96afa Author: Johan Hovold Date: Sun Jul 9 13:08:58 2017 +0200 NFC: fix device-allocation error return [ Upstream commit c45e3e4c5b134b081e8af362109905427967eb19 ] A recent change fixing NFC device allocation itself introduced an error-handling bug by returning an error pointer in case device-id allocation failed. This is clearly broken as the callers still expected NULL to be returned on errors as detected by Dan's static checker. Fix this up by returning NULL in the event that we've run out of memory when allocating a new device id. Note that the offending commit is marked for stable (3.8) so this fix needs to be backported along with it. Fixes: 20777bc57c34 ("NFC: fix broken device allocation") Cc: stable # 3.8 Reported-by: Dan Carpenter Signed-off-by: Johan Hovold Signed-off-by: Samuel Ortiz Signed-off-by: Sasha Levin commit 761b04bf1c435a1046da0701a77f098eb6992251 Author: Bart Van Assche Date: Wed Oct 11 10:27:26 2017 -0700 IB/srp: Avoid that a cable pull can trigger a kernel crash [ Upstream commit 8a0d18c62121d3c554a83eb96e2752861d84d937 ] This patch fixes the following kernel crash: general protection fault: 0000 [#1] PREEMPT SMP Workqueue: ib_mad2 timeout_sends [ib_core] Call Trace: ib_sa_path_rec_callback+0x1c4/0x1d0 [ib_core] send_handler+0xb2/0xd0 [ib_core] timeout_sends+0x14d/0x220 [ib_core] process_one_work+0x200/0x630 worker_thread+0x4e/0x3b0 kthread+0x113/0x150 Fixes: commit aef9ec39c47f ("IB: Add SCSI RDMA Protocol (SRP) initiator") Signed-off-by: Bart Van Assche Reviewed-by: Sagi Grimberg Cc: Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin commit ce3f6cfe785e728340b3be863d09cc5e2679c7ca Author: Bart Van Assche Date: Wed Oct 11 10:27:22 2017 -0700 IB/srpt: Do not accept invalid initiator port names [ Upstream commit c70ca38960399a63d5c048b7b700612ea321d17e ] Make srpt_parse_i_port_id() return a negative value if hex2bin() fails. Fixes: commit a42d985bd5b2 ("ib_srpt: Initial SRP Target merge for v3.3-rc1") Signed-off-by: Bart Van Assche Cc: Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin commit 98784aea7284741f78fb8126e56606bb21ef1491 Author: Johan Hovold Date: Sat Nov 11 17:29:29 2017 +0100 clk: ti: dra7-atl-clock: fix child-node lookups [ Upstream commit 33ec6dbc5a02677509d97fe36cd2105753f0f0ea ] Fix child node-lookup during probe, which ended up searching the whole device tree depth-first starting at parent rather than just matching on its children. Note that the original premature free of the parent node has already been fixed separately, but that fix was apparently never backported to stable. Fixes: 9ac33b0ce81f ("CLK: TI: Driver for DRA7 ATL (Audio Tracking Logic)") Fixes: 660e15519399 ("clk: ti: dra7-atl-clock: Fix of_node reference counting") Cc: stable # 3.16: 660e15519399 Cc: Peter Ujfalusi Signed-off-by: Johan Hovold Acked-by: Peter Ujfalusi Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit d1ec3dfd2d2d71d2a274ac567550450dbe6313be Author: Peter Ujfalusi Date: Fri Mar 11 16:13:32 2016 +0200 clk: ti: dra7-atl-clock: Fix of_node reference counting [ Upstream commit 660e1551939931657808d47838a3f443c0e83fd0 ] of_find_node_by_name() will call of_node_put() on the node so we need to get it first to avoid warnings. The cfg_node needs to be put after we have finished processing the properties. Signed-off-by: Peter Ujfalusi Tested-by: Nishanth Menon Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 6e83ab146a18288704f824517169b1fb7d7f5ac9 Author: Trond Myklebust Date: Tue Oct 10 17:31:42 2017 -0400 SUNRPC: Fix tracepoint storage issues with svc_recv and svc_rqst_status [ Upstream commit e9d4bf219c83d09579bc62512fea2ca10f025d93 ] There is no guarantee that either the request or the svc_xprt exist by the time we get round to printing the trace message. Signed-off-by: Trond Myklebust Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit 19b36dc359933da0b9db8ec8954d9089387462f0 Author: Paolo Bonzini Date: Thu Oct 26 09:13:27 2017 +0200 KVM: SVM: obey guest PAT [ Upstream commit 15038e14724799b8c205beb5f20f9e54896013c3 ] For many years some users of assigned devices have reported worse performance on AMD processors with NPT than on AMD without NPT, Intel or bare metal. The reason turned out to be that SVM is discarding the guest PAT setting and uses the default (PA0=PA4=WB, PA1=PA5=WT, PA2=PA6=UC-, PA3=UC). The guest might be using a different setting, and especially might want write combining but isn't getting it (instead getting slow UC or UC- accesses). Thanks a lot to geoff@hostfission.com for noticing the relation to the g_pat setting. The patch has been tested also by a bunch of people on VFIO users forums. Fixes: 709ddebf81cb40e3c36c6109a7892e8b93a09464 Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=196409 Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Reviewed-by: David Hildenbrand Tested-by: Nick Sarnie Signed-off-by: Radim Krčmář Signed-off-by: Sasha Levin commit 668c41b9d86401bb2fa277a23e2ff3aabeeb4bf9 Author: Ladi Prosek Date: Wed Oct 11 16:54:42 2017 +0200 KVM: nVMX: set IDTR and GDTR limits when loading L1 host state [ Upstream commit 21f2d551183847bc7fbe8d866151d00cdad18752 ] Intel SDM 27.5.2 Loading Host Segment and Descriptor-Table Registers: "The GDTR and IDTR limits are each set to FFFFH." Signed-off-by: Ladi Prosek Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 4271e66fe6a235f1b8abe73f2e27bc64b4ae4262 Author: Nicholas Bellinger Date: Fri Oct 27 20:52:56 2017 -0700 iscsi-target: Fix non-immediate TMR reference leak [ Upstream commit 3fc9fb13a4b2576aeab86c62fd64eb29ab68659c ] This patch fixes a se_cmd->cmd_kref reference leak that can occur when a non immediate TMR is proceeded our of command sequence number order, and CMDSN_LOWER_THAN_EXP is returned by iscsit_sequence_cmd(). To address this bug, call target_put_sess_cmd() during this special case following what iscsit_process_scsi_cmd() does upon CMDSN_LOWER_THAN_EXP. Cc: Mike Christie Cc: Hannes Reinecke Cc: stable@vger.kernel.org # 3.10+ Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin commit 4da59ffbe060ccf577c4b82eede4ba492db0662a Author: Tuomas Tynkkynen Date: Wed Sep 6 17:59:07 2017 +0300 fs/9p: Compare qid.path in v9fs_test_inode [ Upstream commit 8ee031631546cf2f7859cc69593bd60bbdd70b46 ] Commit fd2421f54423 ("fs/9p: When doing inode lookup compare qid details and inode mode bits.") transformed v9fs_qid_iget() to use iget5_locked() instead of iget_locked(). However, the test() callback is not checking fid.path at all, which means that a lookup in the inode cache can now accidentally locate a completely wrong inode from the same inode hash bucket if the other fields (qid.type and qid.version) match. Fixes: fd2421f54423 ("fs/9p: When doing inode lookup compare qid details and inode mode bits.") Cc: stable@vger.kernel.org Reviewed-by: Latchesar Ionkov Signed-off-by: Tuomas Tynkkynen Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit b25bba399bb95ad7a1cd97383f11713dc0f2b678 Author: Al Viro Date: Sun Sep 24 18:36:44 2017 -0400 fix a page leak in vhost_scsi_iov_to_sgl() error recovery [ Upstream commit 11d49e9d089ccec81be87c2386dfdd010d7f7f6e ] we are advancing sg as we go, so the pages we need to drop in case of error are *before* the current sg. Cc: stable@vger.kernel.org Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 42bb63beb78cba9a7cf4831c18abd019a531c0a2 Author: Takashi Iwai Date: Tue Nov 21 16:36:11 2017 +0100 ALSA: timer: Remove kernel warning at compat ioctl error paths [ Upstream commit 3d4e8303f2c747c8540a0a0126d0151514f6468b ] Some timer compat ioctls have NULL checks of timer instance with snd_BUG_ON() that bring up WARN_ON() when the debug option is set. Actually the condition can be met in the normal situation and it's confusing and bad to spew kernel warnings with stack trace there. Let's remove snd_BUG_ON() invocation and replace with the simple checks. Also, correct the error code to EBADFD to follow the native ioctl error handling. Reported-by: syzbot Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 9f8edc402a18be594ef64dd68cbe0d652776c1f3 Author: Takashi Iwai Date: Tue Nov 21 17:28:06 2017 +0100 ALSA: usb-audio: Add sanity checks in v2 clock parsers [ Upstream commit 0a62d6c966956d77397c32836a5bbfe3af786fc1 ] The helper functions to parse and look for the clock source, selector and multiplier unit may return the descriptor with a too short length than required, while there is no sanity check in the caller side. Add some sanity checks in the parsers, at least, to guarantee the given descriptor size, for avoiding the potential crashes. Fixes: 79f920fbff56 ("ALSA: usb-audio: parse clock topology of UAC2 devices") Reported-by: Andrey Konovalov Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 0392f95be48f1601672f35a7831f4985fadea0d6 Author: Takashi Iwai Date: Tue Nov 21 17:00:32 2017 +0100 ALSA: usb-audio: Fix potential out-of-bound access at parsing SU [ Upstream commit f658f17b5e0e339935dca23e77e0f3cad591926b ] The usb-audio driver may trigger an out-of-bound access at parsing a malformed selector unit, as it checks the header length only after evaluating bNrInPins field, which can be already above the given length. Fix it by adding the length check beforehand. Fixes: 99fc86450c43 ("ALSA: usb-mixer: parse descriptors with structs") Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit c3c314dc77d098dd9990c3fb39ce5f37ff29215d Author: Takashi Iwai Date: Tue Nov 21 16:55:51 2017 +0100 ALSA: usb-audio: Add sanity checks to FE parser [ Upstream commit d937cd6790a2bef2d07b500487646bd794c039bb ] When the usb-audio descriptor contains the malformed feature unit description with a too short length, the driver may access out-of-bounds. Add a sanity check of the header size at the beginning of parse_audio_feature_unit(). Fixes: 23caaf19b11e ("ALSA: usb-mixer: Add support for Audio Class v2.0") Reported-by: Andrey Konovalov Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit b02b56d57d4c266617f0f832a2c2d6d8ff84f3f7 Author: Henrik Eriksson Date: Tue Nov 21 09:29:28 2017 +0100 ALSA: pcm: update tstamp only if audio_tstamp changed [ Upstream commit 20e3f985bb875fea4f86b04eba4b6cc29bfd6b71 ] commit 3179f6200188 ("ALSA: core: add .get_time_info") had a side effect of changing the behaviour of the PCM runtime tstamp. Prior to this change tstamp was not updated by snd_pcm_update_hw_ptr0() unless the hw_ptr had moved, after this change tstamp was always updated. For an application using alsa-lib, doing snd_pcm_readi() followed by snd_pcm_status() to estimate the age of the read samples by subtracting status->avail * [sample rate] from status->tstamp this change degraded the accuracy of the estimate on devices where the pcm hw does not provide a granular hw_ptr, e.g., devices using soc-generic-dmaengine-pcm.c and a dma-engine with residue_granularity DMA_RESIDUE_GRANULARITY_DESCRIPTOR. The accuracy of the estimate depended on the latency between the PCM hw completing a period and the driver called snd_pcm_period_elapsed() to notify ALSA core, typically determined by interrupt handling latency. After the change the accuracy of the estimate depended on the latency between the PCM hw completing a period and the application calling snd_pcm_status(), determined by the scheduling of the application process. The maximum error of the estimate is one period length in both cases, but the error average and variance is smaller when it depends on interrupt latency. Instead of always updating tstamp, update it only if audio_tstamp changed. Fixes: 3179f6200188 ("ALSA: core: add .get_time_info") Suggested-by: Pierre-Louis Bossart Signed-off-by: Henrik Eriksson Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit b80b2641eb4b47be8b49c8035e758c7b56a74a1f Author: Theodore Ts'o Date: Fri Oct 6 23:09:55 2017 -0400 ext4: fix interaction between i_size, fallocate, and delalloc after a crash [ Upstream commit 51e3ae81ec58e95f10a98ef3dd6d7bce5d8e35a2 ] If there are pending writes subject to delayed allocation, then i_size will show size after the writes have completed, while i_disksize contains the value of i_size on the disk (since the writes have not been persisted to disk). If fallocate(2) is called with the FALLOC_FL_KEEP_SIZE flag, either with or without the FALLOC_FL_ZERO_RANGE flag set, and the new size after the fallocate(2) is between i_size and i_disksize, then after a crash, if a journal commit has resulted in the changes made by the fallocate() call to be persisted after a crash, but the delayed allocation write has not resolved itself, i_size would not be updated, and this would cause the following e2fsck complaint: Inode 12, end of extent exceeds allowed value (logical block 33, physical block 33441, len 7) This can only take place on a sparse file, where the fallocate(2) call is allocating blocks in a range which is before a pending delayed allocation write which is extending i_size. Since this situation is quite rare, and the window in which the crash must take place is typically < 30 seconds, in practice this condition will rarely happen. Nevertheless, it can be triggered in testing, and in particular by xfstests generic/456. Signed-off-by: Theodore Ts'o Reported-by: Amir Goldstein Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 46c4e7ce42ad8494a887d3415ff82b7f1f18e62a Author: Rameshwar Prasad Sahu Date: Thu Nov 2 16:31:07 2017 +0530 ata: fixes kernel crash while tracing ata_eh_link_autopsy event [ Upstream commit f1601113ddc0339a745e702f4fb1ca37d4875e65 ] When tracing ata link error event, the kernel crashes when the disk is removed due to NULL pointer access by trace_ata_eh_link_autopsy API. This occurs as the dev is NULL when the disk disappeared. This patch fixes this crash by calling trace_ata_eh_link_autopsy only if "dev" is not NULL. v2 changes: Removed direct passing "link" pointer instead of "dev" in trace API. Signed-off-by: Rameshwar Prasad Sahu Signed-off-by: Tejun Heo Fixes: 255c03d15a29 ("libata: Add tracepoints") Cc: stable@vger.kernel.org # v4.1+ Signed-off-by: Sasha Levin commit f47718513ae31bff58b91c87f9e9f6fd2ef4cb63 Author: Andrew Elble Date: Fri Nov 3 14:06:31 2017 -0400 nfsd: deal with revoked delegations appropriately [ Upstream commit 95da1b3a5aded124dd1bda1e3cdb876184813140 ] If a delegation has been revoked by the server, operations using that delegation should error out with NFS4ERR_DELEG_REVOKED in the >4.1 case, and NFS4ERR_BAD_STATEID otherwise. The server needs NFSv4.1 clients to explicitly free revoked delegations. If the server returns NFS4ERR_DELEG_REVOKED, the client will do that; otherwise it may just forget about the delegation and be unable to recover when it later sees SEQ4_STATUS_RECALLABLE_STATE_REVOKED set on a SEQUENCE reply. That can cause the Linux 4.1 client to loop in its stage manager. Signed-off-by: Andrew Elble Reviewed-by: Trond Myklebust Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit ca66fb48e1d670f7383937728aa49ab076ed4bd3 Author: Chuck Lever Date: Sun Nov 5 15:45:22 2017 -0500 nfs: Fix ugly referral attributes [ Upstream commit c05cefcc72416a37eba5a2b35f0704ed758a9145 ] Before traversing a referral and performing a mount, the mounted-on directory looks strange: dr-xr-xr-x. 2 4294967294 4294967294 0 Dec 31 1969 dir.0 nfs4_get_referral is wiping out any cached attributes with what was returned via GETATTR(fs_locations), but the bit mask for that operation does not request any file attributes. Retrieve owner and timestamp information so that the memcpy in nfs4_get_referral fills in more attributes. Changes since v1: - Don't request attributes that the client unconditionally replaces - Request only MOUNTED_ON_FILEID or FILEID attribute, not both - encode_fs_locations() doesn't use the third bitmask word Fixes: 6b97fd3da1ea ("NFSv4: Follow a referral") Suggested-by: Pradeep Thomas Signed-off-by: Chuck Lever Cc: stable@vger.kernel.org Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 42ab3b1b50e58d2397de89fba60895c7f25bfa97 Author: Joshua Watt Date: Tue Nov 7 16:25:47 2017 -0600 NFS: Fix typo in nomigration mount option [ Upstream commit f02fee227e5f21981152850744a6084ff3fa94ee ] The option was incorrectly masking off all other options. Signed-off-by: Joshua Watt Cc: stable@vger.kernel.org #3.7 Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit b0a726a0ca7f9b325b87d0dfaa463de31d5274e9 Author: Arnd Bergmann Date: Thu Oct 19 16:47:48 2017 +0200 isofs: fix timestamps beyond 2027 [ Upstream commit 34be4dbf87fc3e474a842305394534216d428f5d ] isofs uses a 'char' variable to load the number of years since 1900 for an inode timestamp. On architectures that use a signed char type by default, this results in an invalid date for anything beyond 2027. This changes the function argument to a 'u8' array, which is defined the same way on all architectures, and unambiguously lets us use years until 2155. This should be backported to all kernels that might still be in use by that date. Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 0635f5f74161a3fbd29a734125dea44a89ab2a86 Author: Coly Li Date: Fri Oct 13 16:35:29 2017 -0700 bcache: check ca->alloc_thread initialized before wake up it [ Upstream commit 91af8300d9c1d7c6b6a2fd754109e08d4798b8d8 ] In bcache code, sysfs entries are created before all resources get allocated, e.g. allocation thread of a cache set. There is posibility for NULL pointer deference if a resource is accessed but which is not initialized yet. Indeed Jorg Bornschein catches one on cache set allocation thread and gets a kernel oops. The reason for this bug is, when bch_bucket_alloc() is called during cache set registration and attaching, ca->alloc_thread is not properly allocated and initialized yet, call wake_up_process() on ca->alloc_thread triggers NULL pointer deference failure. A simple and fast fix is, before waking up ca->alloc_thread, checking whether it is allocated, and only wake up ca->alloc_thread when it is not NULL. Signed-off-by: Coly Li Reported-by: Jorg Bornschein Cc: Kent Overstreet Cc: stable@vger.kernel.org Reviewed-by: Michael Lyle Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 3b75ba26f7987968a903efb49a0c75fb199b3777 Author: Dan Carpenter Date: Tue Aug 22 23:41:28 2017 +0300 eCryptfs: use after free in ecryptfs_release_messaging() [ Upstream commit db86be3a12d0b6e5c5b51c2ab2a48f06329cb590 ] We're freeing the list iterator so we should be using the _safe() version of hlist_for_each_entry(). Fixes: 88b4a07e6610 ("[PATCH] eCryptfs: Public key transport mechanism") Signed-off-by: Dan Carpenter Cc: Signed-off-by: Tyler Hicks Signed-off-by: Sasha Levin commit bcaa9a9440c5708dbe5b911bfa2602b97d986ab4 Author: Andreas Rohner Date: Fri Nov 17 15:29:35 2017 -0800 nilfs2: fix race condition that causes file system corruption [ Upstream commit 31ccb1f7ba3cfe29631587d451cf5bb8ab593550 ] There is a race condition between nilfs_dirty_inode() and nilfs_set_file_dirty(). When a file is opened, nilfs_dirty_inode() is called to update the access timestamp in the inode. It calls __nilfs_mark_inode_dirty() in a separate transaction. __nilfs_mark_inode_dirty() caches the ifile buffer_head in the i_bh field of the inode info structure and marks it as dirty. After some data was written to the file in another transaction, the function nilfs_set_file_dirty() is called, which adds the inode to the ns_dirty_files list. Then the segment construction calls nilfs_segctor_collect_dirty_files(), which goes through the ns_dirty_files list and checks the i_bh field. If there is a cached buffer_head in i_bh it is not marked as dirty again. Since nilfs_dirty_inode() and nilfs_set_file_dirty() use separate transactions, it is possible that a segment construction that writes out the ifile occurs in-between the two. If this happens the inode is not on the ns_dirty_files list, but its ifile block is still marked as dirty and written out. In the next segment construction, the data for the file is written out and nilfs_bmap_propagate() updates the b-tree. Eventually the bmap root is written into the i_bh block, which is not dirty, because it was written out in another segment construction. As a result the bmap update can be lost, which leads to file system corruption. Either the virtual block address points to an unallocated DAT block, or the DAT entry will be reused for something different. The error can remain undetected for a long time. A typical error message would be one of the "bad btree" errors or a warning that a DAT entry could not be found. This bug can be reproduced reliably by a simple benchmark that creates and overwrites millions of 4k files. Link: http://lkml.kernel.org/r/1509367935-3086-2-git-send-email-konishi.ryusuke@lab.ntt.co.jp Signed-off-by: Andreas Rohner Signed-off-by: Ryusuke Konishi Tested-by: Andreas Rohner Tested-by: Ryusuke Konishi Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 9f83cd76d1a64b91ca26730fd297da0372cdd89a Author: NeilBrown Date: Fri Nov 17 15:29:13 2017 -0800 autofs: don't fail mount for transient error [ Upstream commit ecc0c469f27765ed1e2b967be0aa17cee1a60b76 ] Currently if the autofs kernel module gets an error when writing to the pipe which links to the daemon, then it marks the whole moutpoint as catatonic, and it will stop working. It is possible that the error is transient. This can happen if the daemon is slow and more than 16 requests queue up. If a subsequent process tries to queue a request, and is then signalled, the write to the pipe will return -ERESTARTSYS and autofs will take that as total failure. So change the code to assess -ERESTARTSYS and -ENOMEM as transient failures which only abort the current request, not the whole mountpoint. It isn't a crash or a data corruption, but having autofs mountpoints suddenly stop working is rather inconvenient. Ian said: : And given the problems with a half dozen (or so) user space applications : consuming large amounts of CPU under heavy mount and umount activity this : could happen more easily than we expect. Link: http://lkml.kernel.org/r/87y3norvgp.fsf@notabene.neil.brown.name Signed-off-by: NeilBrown Acked-by: Ian Kent Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 854aee179ca3d331b275f6e957838661fc9b4ec2 Author: Mirko Parthey Date: Thu May 18 21:30:03 2017 +0200 MIPS: BCM47XX: Fix LED inversion for WRT54GSv1 [ Upstream commit 56a46acf62af5ba44fca2f3f1c7c25a2d5385b19 ] The WLAN LED on the Linksys WRT54GSv1 is active low, but the software treats it as active high. Fix the inverted logic. Fixes: 7bb26b169116 ("MIPS: BCM47xx: Fix LEDs on WRT54GS V1.0") Signed-off-by: Mirko Parthey Looks-ok-by: Rafał Miłecki Cc: Hauke Mehrtens Cc: linux-mips@linux-mips.org Cc: # 3.17+ Patchwork: https://patchwork.linux-mips.org/patch/16071/ Signed-off-by: James Hogan Signed-off-by: Sasha Levin commit a942f26652068989b1e40aad22b92c4647fdeda4 Author: Maciej W. Rozycki Date: Tue Nov 7 19:09:20 2017 +0000 MIPS: Fix an n32 core file generation regset support regression [ Upstream commit 547da673173de51f73887377eb275304775064ad ] Fix a commit 7aeb753b5353 ("MIPS: Implement task_user_regset_view.") regression, then activated by commit 6a9c001b7ec3 ("MIPS: Switch ELF core dumper to use regsets.)", that caused n32 processes to dump o32 core files by failing to set the EF_MIPS_ABI2 flag in the ELF core file header's `e_flags' member: $ file tls-core tls-core: ELF 32-bit MSB executable, MIPS, N32 MIPS64 rel2 version 1 (SYSV), [...] $ ./tls-core Aborted (core dumped) $ file core core: ELF 32-bit MSB core file MIPS, MIPS-I version 1 (SYSV), SVR4-style $ Previously the flag was set as the result of a: statement placed in arch/mips/kernel/binfmt_elfn32.c, however in the regset case, i.e. when CORE_DUMP_USE_REGSET is set, ELF_CORE_EFLAGS is no longer used by `fill_note_info' in fs/binfmt_elf.c, and instead the `->e_flags' member of the regset view chosen is. We have the views defined in arch/mips/kernel/ptrace.c, however only an o32 and an n64 one, and the latter is used for n32 as well. Consequently an o32 core file is incorrectly dumped from n32 processes (the ELF32 vs ELF64 class is chosen elsewhere, and the 32-bit one is correctly selected for n32). Correct the issue then by defining an n32 regset view and using it as appropriate. Issue discovered in GDB testing. Fixes: 7aeb753b5353 ("MIPS: Implement task_user_regset_view.") Signed-off-by: Maciej W. Rozycki Cc: Ralf Baechle Cc: Djordje Todorovic Cc: linux-mips@linux-mips.org Cc: # 3.13+ Patchwork: https://patchwork.linux-mips.org/patch/17617/ Signed-off-by: James Hogan Signed-off-by: Sasha Levin commit 48e57f6ddb74d12b71b6edbf15ba4c94035caa02 Author: Hou Tao Date: Wed Nov 1 15:42:36 2017 +0800 dm: fix race between dm_get_from_kobject() and __dm_destroy() [ Upstream commit b9a41d21dceadf8104812626ef85dc56ee8a60ed ] The following BUG_ON was hit when testing repeat creation and removal of DM devices: kernel BUG at drivers/md/dm.c:2919! CPU: 7 PID: 750 Comm: systemd-udevd Not tainted 4.1.44 Call Trace: [] dm_get_from_kobject+0x34/0x3a [] dm_attr_show+0x2b/0x5e [] ? mutex_lock+0x26/0x44 [] sysfs_kf_seq_show+0x83/0xcf [] kernfs_seq_show+0x23/0x25 [] seq_read+0x16f/0x325 [] kernfs_fop_read+0x3a/0x13f [] __vfs_read+0x26/0x9d [] ? security_file_permission+0x3c/0x44 [] ? rw_verify_area+0x83/0xd9 [] vfs_read+0x8f/0xcf [] ? __fdget_pos+0x12/0x41 [] SyS_read+0x4b/0x76 [] system_call_fastpath+0x12/0x71 The bug can be easily triggered, if an extra delay (e.g. 10ms) is added between the test of DMF_FREEING & DMF_DELETING and dm_get() in dm_get_from_kobject(). To fix it, we need to ensure the test of DMF_FREEING & DMF_DELETING and dm_get() are done in an atomic way, so _minor_lock is used. The other callers of dm_get() have also been checked to be OK: some callers invoke dm_get() under _minor_lock, some callers invoke it under _hash_lock, and dm_start_request() invoke it after increasing md->open_count. Cc: stable@vger.kernel.org Signed-off-by: Hou Tao Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit f843dc030223fa8b56472ad41268941ebe3bbc28 Author: Eric Biggers Date: Wed Nov 15 16:38:09 2017 -0800 dm bufio: fix integer overflow when limiting maximum cache size [ Upstream commit 74d4108d9e681dbbe4a2940ed8fdff1f6868184c ] The default max_cache_size_bytes for dm-bufio is meant to be the lesser of 25% of the size of the vmalloc area and 2% of the size of lowmem. However, on 32-bit systems the intermediate result in the expression (VMALLOC_END - VMALLOC_START) * DM_BUFIO_VMALLOC_PERCENT / 100 overflows, causing the wrong result to be computed. For example, on a 32-bit system where the vmalloc area is 520093696 bytes, the result is 1174405 rather than the expected 130023424, which makes the maximum cache size much too small (far less than 2% of lowmem). This causes severe performance problems for dm-verity users on affected systems. Fix this by using mult_frac() to correctly multiply by a percentage. Do this for all places in dm-bufio that multiply by a percentage. Also replace (VMALLOC_END - VMALLOC_START) with VMALLOC_TOTAL, which contrary to the comment is now defined in include/linux/vmalloc.h. Depends-on: 9993bc635 ("sched/x86: Fix overflow in cyc2ns_offset") Fixes: 95d402f057f2 ("dm: add bufio") Cc: # v3.2+ Signed-off-by: Eric Biggers Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit aaca41849159f31b910dca21a04dbe8bc1fe8075 Author: Vijendar Mukunda Date: Thu Nov 23 20:07:00 2017 +0530 ALSA: hda: Add Raven PCI ID [ Upstream commit 9ceace3c9c18c67676e75141032a65a8e01f9a7a ] This commit adds PCI ID for Raven platform Signed-off-by: Vijendar Mukunda Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit bfaf1d113e39ea25c02e0fbf8b43ad658f3e9557 Author: Mathias Kresin Date: Thu May 11 08:11:15 2017 +0200 MIPS: ralink: Fix typo in mt7628 pinmux function [ Upstream commit 05a67cc258e75ac9758e6f13d26337b8be51162a ] There is a typo inside the pinmux setup code. The function is called refclk and not reclk. Fixes: 53263a1c6852 ("MIPS: ralink: add mt7628an support") Signed-off-by: Mathias Kresin Acked-by: John Crispin Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: # 3.19+ Patchwork: https://patchwork.linux-mips.org/patch/16047/ Signed-off-by: James Hogan Signed-off-by: Sasha Levin commit ede836959c9b604aa28827232a426159b43eba93 Author: Mathias Kresin Date: Thu May 11 08:11:14 2017 +0200 MIPS: ralink: Fix MT7628 pinmux [ Upstream commit 8ef4b43cd3794d63052d85898e42424fd3b14d24 ] According to the datasheet the REFCLK pin is shared with GPIO#37 and the PERST pin is shared with GPIO#36. Fixes: 53263a1c6852 ("MIPS: ralink: add mt7628an support") Signed-off-by: Mathias Kresin Acked-by: John Crispin Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: # 3.19+ Patchwork: https://patchwork.linux-mips.org/patch/16046/ Signed-off-by: James Hogan Signed-off-by: Sasha Levin commit 44b6b0eac0a6be78869b1623d7125745ea047353 Author: Philip Derrin Date: Tue Nov 14 00:55:26 2017 +0100 ARM: 8721/1: mm: dump: check hardware RO bit for LPAE [ Upstream commit 3b0c0c922ff4be275a8beb87ce5657d16f355b54 ] When CONFIG_ARM_LPAE is set, the PMD dump relies on the software read-only bit to determine whether a page is writable. This concealed a bug which left the kernel text section writable (AP2=0) while marked read-only in the software bit. In a kernel with the AP2 bug, the dump looks like this: ---[ Kernel Mapping ]--- 0xc0000000-0xc0200000 2M RW NX SHD 0xc0200000-0xc0600000 4M ro x SHD 0xc0600000-0xc0800000 2M ro NX SHD 0xc0800000-0xc4800000 64M RW NX SHD The fix is to check that the software and hardware bits are both set before displaying "ro". The dump then shows the true perms: ---[ Kernel Mapping ]--- 0xc0000000-0xc0200000 2M RW NX SHD 0xc0200000-0xc0600000 4M RW x SHD 0xc0600000-0xc0800000 2M RW NX SHD 0xc0800000-0xc4800000 64M RW NX SHD Fixes: ded947798469 ("ARM: 8109/1: mm: Modify pte_write and pmd_write logic for LPAE") Signed-off-by: Philip Derrin Tested-by: Neil Dick Reviewed-by: Kees Cook Cc: stable@vger.kernel.org Signed-off-by: Russell King Signed-off-by: Sasha Levin commit 6d39f29038178a84e42986ddd65ed4de201515ec Author: Philip Derrin Date: Tue Nov 14 00:55:25 2017 +0100 ARM: 8722/1: mm: make STRICT_KERNEL_RWX effective for LPAE [ Upstream commit 400eeffaffc7232c0ae1134fe04e14ae4fb48d8c ] Currently, for ARM kernels with CONFIG_ARM_LPAE and CONFIG_STRICT_KERNEL_RWX enabled, the 2MiB pages mapping the kernel code and rodata are writable. They are marked read-only in a software bit (L_PMD_SECT_RDONLY) but the hardware read-only bit is not set (PMD_SECT_AP2). For user mappings, the logic that propagates the software bit to the hardware bit is in set_pmd_at(); but for the kernel, section_update() writes the PMDs directly, skipping this logic. The fix is to set PMD_SECT_AP2 for read-only sections in section_update(), at the same time as L_PMD_SECT_RDONLY. Fixes: 1e3479225acb ("ARM: 8275/1: mm: fix PMD_SECT_RDONLY undeclared compile error") Signed-off-by: Philip Derrin Reported-by: Neil Dick Tested-by: Neil Dick Tested-by: Laura Abbott Reviewed-by: Kees Cook Cc: stable@vger.kernel.org Signed-off-by: Russell King Signed-off-by: Sasha Levin commit d540647e85de1494323c5b9cd502f5ffe6d364f4 Author: Masami Hiramatsu Date: Fri Nov 24 13:56:30 2017 +0900 x86/decoder: Add new TEST instruction pattern [ Upstream commit 12a78d43de767eaf8fb272facb7a7b6f2dc6a9df ] The kbuild test robot reported this build warning: Warning: arch/x86/tools/test_get_len found difference at :ffffffff8103dd2c Warning: ffffffff8103dd82: f6 09 d8 testb $0xd8,(%rcx) Warning: objdump says 3 bytes, but insn_get_length() says 2 Warning: decoded and checked 1569014 instructions with 1 warnings This sequence seems to be a new instruction not in the opcode map in the Intel SDM. The instruction sequence is "F6 09 d8", means Group3(F6), MOD(00)REG(001)RM(001), and 0xd8. Intel SDM vol2 A.4 Table A-6 said the table index in the group is "Encoding of Bits 5,4,3 of the ModR/M Byte (bits 2,1,0 in parenthesis)" In that table, opcodes listed by the index REG bits as: 000 001 010 011 100 101 110 111 TEST Ib/Iz,(undefined),NOT,NEG,MUL AL/rAX,IMUL AL/rAX,DIV AL/rAX,IDIV AL/rAX So, it seems TEST Ib is assigned to 001. Add the new pattern. Reported-by: kbuild test robot Signed-off-by: Masami Hiramatsu Cc: Greg Kroah-Hartman Cc: Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 6800ce16ab818634724b94cc7099d5398a964845 Author: Paul E. McKenney Date: Mon Sep 18 08:54:40 2017 -0700 sched: Make resched_cpu() unconditional [ Upstream commit 7c2102e56a3f7d85b5d8f33efbd7aecc1f36fdd8 ] The current implementation of synchronize_sched_expedited() incorrectly assumes that resched_cpu() is unconditional, which it is not. This means that synchronize_sched_expedited() can hang when resched_cpu()'s trylock fails as follows (analysis by Neeraj Upadhyay): o CPU1 is waiting for expedited wait to complete: sync_rcu_exp_select_cpus rdp->exp_dynticks_snap & 0x1 // returns 1 for CPU5 IPI sent to CPU5 synchronize_sched_expedited_wait ret = swait_event_timeout(rsp->expedited_wq, sync_rcu_preempt_exp_done(rnp_root), jiffies_stall); expmask = 0x20, CPU 5 in idle path (in cpuidle_enter()) o CPU5 handles IPI and fails to acquire rq lock. Handles IPI sync_sched_exp_handler resched_cpu returns while failing to try lock acquire rq->lock need_resched is not set o CPU5 calls rcu_idle_enter() and as need_resched is not set, goes to idle (schedule() is not called). o CPU 1 reports RCU stall. Given that resched_cpu() is now used only by RCU, this commit fixes the assumption by making resched_cpu() unconditional. Reported-by: Neeraj Upadhyay Suggested-by: Neeraj Upadhyay Signed-off-by: Paul E. McKenney Acked-by: Steven Rostedt (VMware) Acked-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 45b58ae24436cd06e8b95b1565a8be8c9c05c298 Author: WANG Cong Date: Fri May 19 11:21:59 2017 -0700 vsock: use new wait API for vsock_stream_sendmsg() [ Upstream commit 499fde662f1957e3cb8d192a94a099ebe19c714b ] As reported by Michal, vsock_stream_sendmsg() could still sleep at vsock_stream_has_space() after prepare_to_wait(): vsock_stream_has_space vmci_transport_stream_has_space vmci_qpair_produce_free_space qp_lock qp_acquire_queue_mutex mutex_lock Just switch to the new wait API like we did for commit d9dc8b0f8b4e ("net: fix sleeping for sk_wait_event()"). Reported-by: Michal Kubecek Cc: Stefan Hajnoczi Cc: Jorgen Hansen Cc: "Michael S. Tsirkin" Cc: Claudio Imbrenda Signed-off-by: Cong Wang Reviewed-by: Stefan Hajnoczi Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1139f46fbe954b598ce2ab6f3c0834eefd7df791 Author: Claudio Imbrenda Date: Tue Mar 22 17:05:52 2016 +0100 AF_VSOCK: Shrink the area influenced by prepare_to_wait [ Upstream commit f7f9b5e7f8eccfd68ffa7b8d74b07c478bb9e7f0 ] When a thread is prepared for waiting by calling prepare_to_wait, sleeping is not allowed until either the wait has taken place or finish_wait has been called. The existing code in af_vsock imposed unnecessary no-sleep assumptions to a broad list of backend functions. This patch shrinks the influence of prepare_to_wait to the area where it is strictly needed, therefore relaxing the no-sleep restriction there. Signed-off-by: Claudio Imbrenda Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 17e898d9303cb18842be44d6579b9a92f92159bf Author: WANG Cong Date: Tue Jun 20 11:42:27 2017 -0700 ipv6: only call ip6_route_dev_notify() once for NETDEV_UNREGISTER [ Upstream commit 76da0704507bbc51875013f6557877ab308cfd0a ] In commit 242d3a49a2a1 ("ipv6: reorder ip6_route_dev_notifier after ipv6_dev_notf") I assumed NETDEV_REGISTER and NETDEV_UNREGISTER are paired, unfortunately, as reported by jeffy, netdev_wait_allrefs() could rebroadcast NETDEV_UNREGISTER event until all refs are gone. We have to add an additional check to avoid this corner case. For netdev_wait_allrefs() dev->reg_state is NETREG_UNREGISTERED, for dev_change_net_namespace(), dev->reg_state is NETREG_REGISTERED. So check for dev->reg_state != NETREG_UNREGISTERED. Fixes: 242d3a49a2a1 ("ipv6: reorder ip6_route_dev_notifier after ipv6_dev_notf") Reported-by: jeffy Cc: David Ahern Signed-off-by: Cong Wang Acked-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f690f9b4fe20408f43458ec130858028a2f6099b Author: Vasily Gorbik Date: Wed Nov 15 14:15:36 2017 +0100 s390/disassembler: increase show_code buffer size [ Upstream commit b192571d1ae375e0bbe0aa3ccfa1a3c3704454b9 ] Current buffer size of 64 is too small. objdump shows that there are instructions which would require up to 75 bytes buffer (with current formating). 128 bytes "ought to be enough for anybody". Also replaces 8 spaces with a single tab to reduce the memory footprint. Fixes the following KASAN finding: BUG: KASAN: stack-out-of-bounds in number+0x3fe/0x538 Write of size 1 at addr 000000005a4a75a0 by task bash/1282 CPU: 1 PID: 1282 Comm: bash Not tainted 4.14.0+ #215 Hardware name: IBM 2964 N96 702 (z/VM 6.4.0) Call Trace: ([<000000000011eeb6>] show_stack+0x56/0x88) [<0000000000e1ce1a>] dump_stack+0x15a/0x1b0 [<00000000004e2994>] print_address_description+0xf4/0x288 [<00000000004e2cf2>] kasan_report+0x13a/0x230 [<0000000000e38ae6>] number+0x3fe/0x538 [<0000000000e3dfe4>] vsnprintf+0x194/0x948 [<0000000000e3ea42>] sprintf+0xa2/0xb8 [<00000000001198dc>] print_insn+0x374/0x500 [<0000000000119346>] show_code+0x4ee/0x538 [<000000000011f234>] show_registers+0x34c/0x388 [<000000000011f2ae>] show_regs+0x3e/0xa8 [<000000000011f502>] die+0x1ea/0x2e8 [<0000000000138f0e>] do_no_context+0x106/0x168 [<0000000000139a1a>] do_protection_exception+0x4da/0x7d0 [<0000000000e55914>] pgm_check_handler+0x16c/0x1c0 [<000000000090639e>] sysrq_handle_crash+0x46/0x58 ([<0000000000000007>] 0x7) [<00000000009073fa>] __handle_sysrq+0x102/0x218 [<0000000000907c06>] write_sysrq_trigger+0xd6/0x100 [<000000000061d67a>] proc_reg_write+0xb2/0x128 [<0000000000520be6>] __vfs_write+0xee/0x368 [<0000000000521222>] vfs_write+0x21a/0x278 [<000000000052156a>] SyS_write+0xda/0x178 [<0000000000e555cc>] system_call+0xc4/0x270 The buggy address belongs to the page: page:000003d1016929c0 count:0 mapcount:0 mapping: (null) index:0x0 flags: 0x0() raw: 0000000000000000 0000000000000000 0000000000000000 ffffffff00000000 raw: 0000000000000100 0000000000000200 0000000000000000 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: 000000005a4a7480: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 000000005a4a7500: 00 00 00 00 00 00 00 00 f2 f2 f2 f2 00 00 00 00 >000000005a4a7580: 00 00 00 00 f3 f3 f3 f3 00 00 00 00 00 00 00 00 ^ 000000005a4a7600: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 f8 f8 000000005a4a7680: f2 f2 f2 f2 f2 f2 f8 f8 f2 f2 f3 f3 f3 f3 00 00 ================================================================== Cc: Signed-off-by: Vasily Gorbik Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit 90039c00f21de4ac038ec8aee0029ae9dd920252 Author: Heiko Carstens Date: Tue Sep 26 09:16:48 2017 +0200 s390/disassembler: add missing end marker for e7 table [ Upstream commit 5c50538752af7968f53924b22dede8ed4ce4cb3b ] The e7 opcode table does not have an end marker. Hence when trying to find an unknown e7 instruction the code will access memory behind the table until it finds something that matches the opcode, or the kernel crashes, whatever comes first. This affects not only the in-kernel disassembler but also uprobes and kprobes which refuse to set a probe on unknown instructions, and therefore search the opcode tables to figure out if instructions are known or not. Cc: # v3.18+ Fixes: 3585cb0280654 ("s390/disassembler: add vector instructions") Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit 7495a7ea56bccbc058e57020cb2110b43aafa214 Author: Heiko Carstens Date: Mon Sep 11 11:24:22 2017 +0200 s390/runtime instrumention: fix possible memory corruption [ Upstream commit d6e646ad7cfa7034d280459b2b2546288f247144 ] For PREEMPT enabled kernels the runtime instrumentation (RI) code contains a possible use-after-free bug. If a task that makes use of RI exits, it will execute do_exit() while still enabled for preemption. That function will call exit_thread_runtime_instr() via exit_thread(). If exit_thread_runtime_instr() gets preempted after the RI control block of the task has been freed but before the pointer to it is set to NULL, then save_ri_cb(), called from switch_to(), will write to already freed memory. Avoid this and simply disable preemption while freeing the control block and setting the pointer to NULL. Fixes: e4b8b3f33fca ("s390: add support for runtime instrumentation") Cc: # v3.7+ Reviewed-by: Christian Borntraeger Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit 59075c07a1bb36bd9fcf22ced6d5643fe0bd88e8 Author: Sasha Levin Date: Fri Dec 8 00:29:39 2017 -0500 Revert "MIPS: init: Ensure bootmem does not corrupt reserved memory" This reverts commit 78d36a51aff258a26c4c2c12c4d86de0fae64e3a. Signed-off-by: Sasha Levin