commit b6c197f7978b7e1efab7d2f2e3088f3b54cd6357 Author: Alexandre Frade Date: Tue Mar 23 00:09:37 2021 +0000 Linux 5.4.106-rt54-xanmod1 Signed-off-by: Alexandre Frade commit 4c00b733bde53bfdbdc1370f5609d754bdbf93ba Merge: d3abb9a70cbc e8529f7c9b5d Author: Alexandre Frade Date: Tue Mar 23 00:08:54 2021 +0000 Merge tag 'v5.4.106-rt54' into 5.4-rt Linux 5.4.106-rt54 commit d3abb9a70cbcd2a072d2ca010967b57562214bd5 Author: Nick Terrell Date: Mon Mar 22 05:16:15 2021 +0000 lib: zstd: Upgrade to latest upstream zstd version 1.4.6 Upgrade to the latest upstream zstd version 1.4.6. This patch is 100% generated from upstream zstd commit f45fa724fef1 [0]. This patch is very large because it is transitioning from the custom kernel zstd to using upstream directly. The new zstd follows upstreams file structure which is different. Future update patches will be much smaller because they will only contain the changes from one upstream zstd release. As an aid for review I've created a commit [1] that shows the diff between upstream zstd as-is (which doesn't compile), and the zstd code imported in this patch. The verion of zstd in this patch is generated from upstream with changes applied by automation to replace upstreams libc dependencies, remove unnecessary portability macros, and use the kernel's xxhash instead of bundling it. The benefits of this patch are as follows: 1. Using upstream directly with automated script to generate kernel code. This allows us to update the kernel every upstream release, so the kernel gets the latest bug fixes and performance improvements, and doesn't get 3 years out of date again. The automation and the translated code are tested every upstream commit to ensure it continues to work. 2. Upgrades from a custom zstd based on 1.3.1 to 1.4.6, getting 3 years of performance improvements and bug fixes. On x86_64 I've measured 15% faster BtrFS and SquashFS decompression+read speeds, 35% faster kernel decompression, and 30% faster ZRAM decompression+read speeds. Additionally, the latest zstd uses ~1 KB less stack space for compression. 3. Zstd-1.4.6 supports negative compression levels, which allow zstd to match or subsume lzo's performance. 4. Maintains the same kernel-specific wrapper API, so no callers have to be modified with zstd version updates. I chose the bulk update instead of replaying upstream commits because there have been ~3500 upstream commits since the 1.3.1 release, zstd wasn't ready to be used in the kernel as-is before a month ago, and not all upstream zstd commits build. The bulk update preserves bisectablity because bugs can be bisected to the zstd version update. At that point the update can be reverted, and we can work with upstream to find and fix the bug. Note that upstream zstd release 1.4.6 doesn't exist yet. I have cut a staging branch at f45fa724fef1 [0] and will apply any changes requested to the staging branch. Once we're ready to merge this update I will cut a zstd release at the commit we merge, so we have a known zstd release in the kernel. The implementation of the kernel API is contained in zstd_compress_module.c and zstd_decompress_module.c. [0] https://github.com/facebook/zstd/commit/f45fa724fef1e70449fa3806dc2360dda467561b [1] https://github.com/terrelln/linux/commit/ac2ee65dcb7318afe426ad08f6a844faf3aebb41 Signed-off-by: Nick Terrell commit 1361b4422ef51c3c81288a4ca8b26d806844f540 Author: Nick Terrell Date: Mon Sep 14 12:54:12 2020 -0700 lib: zstd: Add decompress_sources.h for decompress_unzstd Adds decompress_sources.h which includes every .c file necessary for zstd decompression. This is used in decompress_unzstd.c so the internal structure of the library isn't exposed. This allows us to upgrade the zstd library version without modifying any callers. Instead we just need to update decompress_sources.h. Signed-off-by: Nick Terrell commit 2be7644a1f0e6062042f742f1e90ec9fe9efc809 Author: Nick Terrell Date: Mon Mar 22 05:02:39 2021 +0000 lib: zstd: Add kernel-specific API This patch: - Moves `include/linux/zstd.h` -> `include/linux/zstd_lib.h` - Adds a new API in `include/linux/zstd.h` that is functionally equivalent to the in-use subset of the current API. Functions are renamed to avoid symbol collisions with zstd, to make it clear it is not the upstream zstd API, and to follow the kernel style guide. - Updates all callers to use the new API. There are no functional changes in this patch. Since there are no functional change, I felt it was okay to update all the callers in a single patch, since once the API is approved, the callers are mechanically changed. This patch is preparing the next patch in the series, which updates zstd to version 1.4.6. Since the upstream zstd API is no longer exposed to callers, the update can happen transparently. Signed-off-by: Nick Terrell commit e8529f7c9b5dfd2f06a1cf6a59e68211be260121 Author: Steven Rostedt (VMware) Date: Sat Mar 20 18:01:57 2021 -0400 Linux 5.4.106-rt54 commit ce6e489390a94aedb9a6bc7a80f54f6c54f88bd4 Merge: 08ed7a60866f 0437de26e28d Author: Steven Rostedt (VMware) Date: Fri Mar 19 14:01:12 2021 -0400 Merge tag 'v5.4.106' into v5.4-rt This is the 5.4.106 stable release commit 0437de26e28dd844f51fde7a749a82cb2d3694ad Author: Greg Kroah-Hartman Date: Wed Mar 17 17:03:58 2021 +0100 Linux 5.4.106 Tested-by: Jon Hunter Tested-by: Florian Fainelli Tested-by: Jason Self Tested-by: Linux Kernel Functional Testing Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Ross Schmidt Link: https://lore.kernel.org/r/20210315135550.333963635@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit b802b6ef28d65e28c95d6465a47ef74958f32074 Author: Juergen Gross Date: Mon Mar 15 09:22:38 2021 +0100 xen/events: avoid handling the same event on two cpus at the same time commit b6622798bc50b625a1e62f82c7190df40c1f5b21 upstream. When changing the cpu affinity of an event it can happen today that (with some unlucky timing) the same event will be handled on the old and the new cpu at the same time. Avoid that by adding an "event active" flag to the per-event data and call the handler only if this flag isn't set. Cc: stable@vger.kernel.org Reported-by: Julien Grall Signed-off-by: Juergen Gross Reviewed-by: Julien Grall Link: https://lore.kernel.org/r/20210306161833.4552-4-jgross@suse.com Signed-off-by: Boris Ostrovsky Signed-off-by: Greg Kroah-Hartman commit 92aefc62f483be76e16f8bb106201c2e358984e1 Author: Juergen Gross Date: Mon Mar 15 09:22:37 2021 +0100 xen/events: don't unmask an event channel when an eoi is pending commit 25da4618af240fbec6112401498301a6f2bc9702 upstream. An event channel should be kept masked when an eoi is pending for it. When being migrated to another cpu it might be unmasked, though. In order to avoid this keep three different flags for each event channel to be able to distinguish "normal" masking/unmasking from eoi related masking/unmasking and temporary masking. The event channel should only be able to generate an interrupt if all flags are cleared. Cc: stable@vger.kernel.org Fixes: 54c9de89895e ("xen/events: add a new "late EOI" evtchn framework") Reported-by: Julien Grall Signed-off-by: Juergen Gross Reviewed-by: Julien Grall Reviewed-by: Boris Ostrovsky Tested-by: Ross Lagerwall Link: https://lore.kernel.org/r/20210306161833.4552-3-jgross@suse.com [boris -- corrected Fixed tag format] Signed-off-by: Boris Ostrovsky Signed-off-by: Greg Kroah-Hartman commit 43d0b82bb45c32940f435e5e0001609e40af986e Author: Juergen Gross Date: Mon Mar 15 09:22:37 2021 +0100 xen/events: reset affinity of 2-level event when tearing it down commit 9e77d96b8e2724ed00380189f7b0ded61113b39f upstream. When creating a new event channel with 2-level events the affinity needs to be reset initially in order to avoid using an old affinity from earlier usage of the event channel port. So when tearing an event channel down reset all affinity bits. The same applies to the affinity when onlining a vcpu: all old affinity settings for this vcpu must be reset. As percpu events get initialized before the percpu event channel hook is called, resetting of the affinities happens after offlining a vcpu (this is working, as initial percpu memory is zeroed out). Cc: stable@vger.kernel.org Reported-by: Julien Grall Signed-off-by: Juergen Gross Reviewed-by: Julien Grall Link: https://lore.kernel.org/r/20210306161833.4552-2-jgross@suse.com Signed-off-by: Boris Ostrovsky Signed-off-by: Greg Kroah-Hartman commit 38563c1ff081642c33219a61d9d73d5e0809e158 Author: Marc Zyngier Date: Mon Mar 15 11:09:52 2021 +0000 KVM: arm64: Reject VM creation when the default IPA size is unsupported Commit 7d717558dd5ef10d28866750d5c24ff892ea3778 upstream. KVM/arm64 has forever used a 40bit default IPA space, partially due to its 32bit heritage (where the only choice is 40bit). However, there are implementations in the wild that have a *cough* much smaller *cough* IPA space, which leads to a misprogramming of VTCR_EL2, and a guest that is stuck on its first memory access if userspace dares to ask for the default IPA setting (which most VMMs do). Instead, blundly reject the creation of such VM, as we can't satisfy the requirements from userspace (with a one-off warning). Also clarify the boot warning, and document that the VM creation will fail when an unsupported IPA size is provided. Although this is an ABI change, it doesn't really change much for userspace: - the guest couldn't run before this change, but no error was returned. At least userspace knows what is happening. - a memory slot that was accepted because it did fit the default IPA space now doesn't even get a chance to be registered. The other thing that is left doing is to convince userspace to actually use the IPA space setting instead of relying on the antiquated default. Fixes: 233a7cb23531 ("kvm: arm64: Allow tuning the physical address size for VM") Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Reviewed-by: Andrew Jones Reviewed-by: Eric Auger Link: https://lore.kernel.org/r/20210311100016.3830038-2-maz@kernel.org Signed-off-by: Greg Kroah-Hartman commit da2e37b55d4c65baa713215e22419f54986d088f Author: Marc Zyngier Date: Mon Mar 15 11:10:00 2021 +0000 KVM: arm64: Ensure I-cache isolation between vcpus of a same VM Commit 01dc9262ff5797b675c32c0c6bc682777d23de05 upstream. It recently became apparent that the ARMv8 architecture has interesting rules regarding attributes being used when fetching instructions if the MMU is off at Stage-1. In this situation, the CPU is allowed to fetch from the PoC and allocate into the I-cache (unless the memory is mapped with the XN attribute at Stage-2). If we transpose this to vcpus sharing a single physical CPU, it is possible for a vcpu running with its MMU off to influence another vcpu running with its MMU on, as the latter is expected to fetch from the PoU (and self-patching code doesn't flush below that level). In order to solve this, reuse the vcpu-private TLB invalidation code to apply the same policy to the I-cache, nuking it every time the vcpu runs on a physical CPU that ran another vcpu of the same VM in the past. This involve renaming __kvm_tlb_flush_local_vmid() to __kvm_flush_cpu_context(), and inserting a local i-cache invalidation there. Cc: stable@vger.kernel.org Signed-off-by: Marc Zyngier Acked-by: Will Deacon Acked-by: Catalin Marinas Link: https://lore.kernel.org/r/20210303164505.68492-1-maz@kernel.org [maz: added 32bit ARM support] Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit 4e2156c0d37bba4afafaa92cf359a36ad49bf63e Author: Keith Busch Date: Thu Apr 9 09:09:00 2020 -0700 nvme: release namespace head reference on error commit ac262508daa88fb12c5dc53cf30bde163f9f26c9 upstream. If a namespace identification does not match the subsystem's head for that NSID, release the reference that was taken when the matching head was initially found. Signed-off-by: Keith Busch Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit eb565f052b3eb57d3a468bf46033f5c415a3513e Author: Keith Busch Date: Thu Apr 9 09:08:59 2020 -0700 nvme: unlink head after removing last namespace commit d567572906d986dedb78b37f111c44eba033f3ef upstream. The driver had been unlinking the namespace head from the subsystem's list only after the last reference was released, and outside of the list's subsys->lock protection. There is no reason to track an empty head, so unlink the entry from the subsystem's list when the last namespace using that head is removed and with the mutex lock protecting the list update. The next namespace to attach reusing the previous NSID will allocate a new head rather than find the old head with mismatched identifiers. Signed-off-by: Keith Busch Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 4535fb9ec5fdceab09012dfa905722b3e91ce079 Author: Marc Zyngier Date: Thu Mar 11 10:00:16 2021 +0000 KVM: arm64: Fix exclusive limit for IPA size commit 262b003d059c6671601a19057e9fe1a5e7f23722 upstream. When registering a memslot, we check the size and location of that memslot against the IPA size to ensure that we can provide guest access to the whole of the memory. Unfortunately, this check rejects memslot that end-up at the exact limit of the addressing capability for a given IPA size. For example, it refuses the creation of a 2GB memslot at 0x8000000 with a 32bit IPA space. Fix it by relaxing the check to accept a memslot reaching the limit of the IPA space. Fixes: c3058d5da222 ("arm/arm64: KVM: Ensure memslots are within KVM_PHYS_SIZE") Reviewed-by: Eric Auger Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Reviewed-by: Andrew Jones Link: https://lore.kernel.org/r/20210311100016.3830038-3-maz@kernel.org Signed-off-by: Greg Kroah-Hartman commit e28b19ca2aebfb9d01567e88cc859ed7c6e92f98 Author: Josh Poimboeuf Date: Fri Feb 5 08:24:02 2021 -0600 x86/unwind/orc: Disable KASAN checking in the ORC unwinder, part 2 commit e504e74cc3a2c092b05577ce3e8e013fae7d94e6 upstream. KASAN reserves "redzone" areas between stack frames in order to detect stack overruns. A read or write to such an area triggers a KASAN "stack-out-of-bounds" BUG. Normally, the ORC unwinder stays in-bounds and doesn't access the redzone. But sometimes it can't find ORC metadata for a given instruction. This can happen for code which is missing ORC metadata, or for generated code. In such cases, the unwinder attempts to fall back to frame pointers, as a best-effort type thing. This fallback often works, but when it doesn't, the unwinder can get confused and go off into the weeds into the KASAN redzone, triggering the aforementioned KASAN BUG. But in this case, the unwinder's confusion is actually harmless and working as designed. It already has checks in place to prevent off-stack accesses, but those checks get short-circuited by the KASAN BUG. And a BUG is a lot more disruptive than a harmless unwinder warning. Disable the KASAN checks by using READ_ONCE_NOCHECK() for all stack accesses. This finishes the job started by commit 881125bfe65b ("x86/unwind: Disable KASAN checking in the ORC unwinder"), which only partially fixed the issue. Fixes: ee9f8fce9964 ("x86/unwind: Add the ORC unwinder") Reported-by: Ivan Babrou Signed-off-by: Josh Poimboeuf Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Borislav Petkov Reviewed-by: Steven Rostedt (VMware) Tested-by: Ivan Babrou Cc: stable@kernel.org Link: https://lkml.kernel.org/r/9583327904ebbbeda399eca9c56d6c7085ac20fe.1612534649.git.jpoimboe@redhat.com Signed-off-by: Greg Kroah-Hartman commit c0e0ab60d0b15469e69db93215dad009999f5a5b Author: Lior Ribak Date: Fri Mar 12 21:07:41 2021 -0800 binfmt_misc: fix possible deadlock in bm_register_write commit e7850f4d844e0acfac7e570af611d89deade3146 upstream. There is a deadlock in bm_register_write: First, in the begining of the function, a lock is taken on the binfmt_misc root inode with inode_lock(d_inode(root)). Then, if the user used the MISC_FMT_OPEN_FILE flag, the function will call open_exec on the user-provided interpreter. open_exec will call a path lookup, and if the path lookup process includes the root of binfmt_misc, it will try to take a shared lock on its inode again, but it is already locked, and the code will get stuck in a deadlock To reproduce the bug: $ echo ":iiiii:E::ii::/proc/sys/fs/binfmt_misc/bla:F" > /proc/sys/fs/binfmt_misc/register backtrace of where the lock occurs (#5): 0 schedule () at ./arch/x86/include/asm/current.h:15 1 0xffffffff81b51237 in rwsem_down_read_slowpath (sem=0xffff888003b202e0, count=, state=state@entry=2) at kernel/locking/rwsem.c:992 2 0xffffffff81b5150a in __down_read_common (state=2, sem=) at kernel/locking/rwsem.c:1213 3 __down_read (sem=) at kernel/locking/rwsem.c:1222 4 down_read (sem=) at kernel/locking/rwsem.c:1355 5 0xffffffff811ee22a in inode_lock_shared (inode=) at ./include/linux/fs.h:783 6 open_last_lookups (op=0xffffc9000022fe34, file=0xffff888004098600, nd=0xffffc9000022fd10) at fs/namei.c:3177 7 path_openat (nd=nd@entry=0xffffc9000022fd10, op=op@entry=0xffffc9000022fe34, flags=flags@entry=65) at fs/namei.c:3366 8 0xffffffff811efe1c in do_filp_open (dfd=, pathname=pathname@entry=0xffff8880031b9000, op=op@entry=0xffffc9000022fe34) at fs/namei.c:3396 9 0xffffffff811e493f in do_open_execat (fd=fd@entry=-100, name=name@entry=0xffff8880031b9000, flags=, flags@entry=0) at fs/exec.c:913 10 0xffffffff811e4a92 in open_exec (name=) at fs/exec.c:948 11 0xffffffff8124aa84 in bm_register_write (file=, buffer=, count=19, ppos=) at fs/binfmt_misc.c:682 12 0xffffffff811decd2 in vfs_write (file=file@entry=0xffff888004098500, buf=buf@entry=0xa758d0 ":iiiii:E::ii::i:CF ", count=count@entry=19, pos=pos@entry=0xffffc9000022ff10) at fs/read_write.c:603 13 0xffffffff811defda in ksys_write (fd=, buf=0xa758d0 ":iiiii:E::ii::i:CF ", count=19) at fs/read_write.c:658 14 0xffffffff81b49813 in do_syscall_64 (nr=, regs=0xffffc9000022ff58) at arch/x86/entry/common.c:46 15 0xffffffff81c0007c in entry_SYSCALL_64 () at arch/x86/entry/entry_64.S:120 To solve the issue, the open_exec call is moved to before the write lock is taken by bm_register_write Link: https://lkml.kernel.org/r/20210228224414.95962-1-liorribak@gmail.com Fixes: 948b701a607f1 ("binfmt_misc: add persistent opened binary handler for containers") Signed-off-by: Lior Ribak Acked-by: Helge Deller Cc: Al Viro Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 106fea9ad246830090bb8397792cfe7e66063c45 Author: Naveen N. Rao Date: Thu Mar 4 07:34:11 2021 +0530 powerpc/64s: Fix instruction encoding for lis in ppc_function_entry() commit cea15316ceee2d4a51dfdecd79e08a438135416c upstream. 'lis r2,N' is 'addis r2,0,N' and the instruction encoding in the macro LIS_R2 is incorrect (it currently maps to 'addis r0,r2,N'). Fix the same. Fixes: c71b7eff426f ("powerpc: Add ABIv2 support to ppc_function_entry") Cc: stable@vger.kernel.org # v3.16+ Reported-by: Jiri Olsa Signed-off-by: Naveen N. Rao Acked-by: Segher Boessenkool Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210304020411.16796-1-naveen.n.rao@linux.vnet.ibm.com Signed-off-by: Greg Kroah-Hartman commit 907f7f2cf0ff7739350c02f4ccdd8233828e4beb Author: Mathieu Desnoyers Date: Wed Feb 17 11:56:51 2021 -0500 sched/membarrier: fix missing local execution of ipi_sync_rq_state() commit ce29ddc47b91f97e7f69a0fb7cbb5845f52a9825 upstream. The function sync_runqueues_membarrier_state() should copy the membarrier state from the @mm received as parameter to each runqueue currently running tasks using that mm. However, the use of smp_call_function_many() skips the current runqueue, which is unintended. Replace by a call to on_each_cpu_mask(). Fixes: 227a4aadc75b ("sched/membarrier: Fix p->mm->membarrier_state racy load") Reported-by: Nadav Amit Signed-off-by: Mathieu Desnoyers Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Cc: stable@vger.kernel.org # 5.4.x+ Link: https://lore.kernel.org/r/74F1E842-4A84-47BF-B6C2-5407DFDD4A4A@gmail.com Signed-off-by: Greg Kroah-Hartman commit 2306580a95b73bd7d97e6dc0890dc17e27155373 Author: Minchan Kim Date: Fri Mar 12 21:08:38 2021 -0800 zram: fix return value on writeback_store commit 57e0076e6575a7b7cef620a0bd2ee2549ef77818 upstream. writeback_store's return value is overwritten by submit_bio_wait's return value. Thus, writeback_store will return zero since there was no IO error. In the end, write syscall from userspace will see the zero as return value, which could make the process stall to keep trying the write until it will succeed. Link: https://lkml.kernel.org/r/20210312173949.2197662-1-minchan@kernel.org Fixes: 3b82a051c101("drivers/block/zram/zram_drv.c: fix error return codes not being returned in writeback_store") Signed-off-by: Minchan Kim Cc: Sergey Senozhatsky Cc: Colin Ian King Cc: John Dias Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 29e28a134a49e0d55c997209a61c688420f54230 Author: Matthew Wilcox (Oracle) Date: Fri Mar 12 21:08:03 2021 -0800 include/linux/sched/mm.h: use rcu_dereference in in_vfork() [ Upstream commit 149fc787353f65b7e72e05e7b75d34863266c3e2 ] Fix a sparse warning by using rcu_dereference(). Technically this is a bug and a sufficiently aggressive compiler could reload the `real_parent' pointer outside the protection of the rcu lock (and access freed memory), but I think it's pretty unlikely to happen. Link: https://lkml.kernel.org/r/20210221194207.1351703-1-willy@infradead.org Fixes: b18dc5f291c0 ("mm, oom: skip vforked tasks from being selected") Signed-off-by: Matthew Wilcox (Oracle) Reviewed-by: Miaohe Lin Acked-by: Michal Hocko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 99f1960cae4f417d513be5ea55136383c2a58798 Author: Arnd Bergmann Date: Fri Mar 12 21:07:04 2021 -0800 stop_machine: mark helpers __always_inline [ Upstream commit cbf78d85079cee662c45749ef4f744d41be85d48 ] With clang-13, some functions only get partially inlined, with a specialized version referring to a global variable. This triggers a harmless build-time check for the intel-rng driver: WARNING: modpost: drivers/char/hw_random/intel-rng.o(.text+0xe): Section mismatch in reference from the function stop_machine() to the function .init.text:intel_rng_hw_init() The function stop_machine() references the function __init intel_rng_hw_init(). This is often because stop_machine lacks a __init annotation or the annotation of intel_rng_hw_init is wrong. In this instance, an easy workaround is to force the stop_machine() function to be inline, along with related interfaces that did not show the same behavior at the moment, but theoretically could. The combination of the two patches listed below triggers the behavior in clang-13, but individually these commits are correct. Link: https://lkml.kernel.org/r/20210225130153.1956990-1-arnd@kernel.org Fixes: fe5595c07400 ("stop_machine: Provide stop_machine_cpuslocked()") Fixes: ee527cd3a20c ("Use stop_machine_run in the Intel RNG driver") Signed-off-by: Arnd Bergmann Cc: Nathan Chancellor Cc: Nick Desaulniers Cc: Thomas Gleixner Cc: Sebastian Andrzej Siewior Cc: "Paul E. McKenney" Cc: Ingo Molnar Cc: Prarit Bhargava Cc: Daniel Bristot de Oliveira Cc: Peter Zijlstra Cc: Valentin Schneider Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit aaf92d0538d2f2d6cbb0a1ff6be704d5967d47f0 Author: Anna-Maria Behnsen Date: Tue Feb 23 17:02:40 2021 +0100 hrtimer: Update softirq_expires_next correctly after __hrtimer_get_next_event() [ Upstream commit 46eb1701c046cc18c032fa68f3c8ccbf24483ee4 ] hrtimer_force_reprogram() and hrtimer_interrupt() invokes __hrtimer_get_next_event() to find the earliest expiry time of hrtimer bases. __hrtimer_get_next_event() does not update cpu_base::[softirq_]_expires_next to preserve reprogramming logic. That needs to be done at the callsites. hrtimer_force_reprogram() updates cpu_base::softirq_expires_next only when the first expiring timer is a softirq timer and the soft interrupt is not activated. That's wrong because cpu_base::softirq_expires_next is left stale when the first expiring timer of all bases is a timer which expires in hard interrupt context. hrtimer_interrupt() does never update cpu_base::softirq_expires_next which is wrong too. That becomes a problem when clock_settime() sets CLOCK_REALTIME forward and the first soft expiring timer is in the CLOCK_REALTIME_SOFT base. Setting CLOCK_REALTIME forward moves the clock MONOTONIC based expiry time of that timer before the stale cpu_base::softirq_expires_next. cpu_base::softirq_expires_next is cached to make the check for raising the soft interrupt fast. In the above case the soft interrupt won't be raised until clock monotonic reaches the stale cpu_base::softirq_expires_next value. That's incorrect, but what's worse it that if the softirq timer becomes the first expiring timer of all clock bases after the hard expiry timer has been handled the reprogramming of the clockevent from hrtimer_interrupt() will result in an interrupt storm. That happens because the reprogramming does not use cpu_base::softirq_expires_next, it uses __hrtimer_get_next_event() which returns the actual expiry time. Once clock MONOTONIC reaches cpu_base::softirq_expires_next the soft interrupt is raised and the storm subsides. Change the logic in hrtimer_force_reprogram() to evaluate the soft and hard bases seperately, update softirq_expires_next and handle the case when a soft expiring timer is the first of all bases by comparing the expiry times and updating the required cpu base fields. Split this functionality into a separate function to be able to use it in hrtimer_interrupt() as well without copy paste. Fixes: 5da70160462e ("hrtimer: Implement support for softirq based hrtimers") Reported-by: Mikael Beckius Suggested-by: Thomas Gleixner Tested-by: Mikael Beckius Signed-off-by: Anna-Maria Behnsen Signed-off-by: Thomas Gleixner Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20210223160240.27518-1-anna-maria@linutronix.de Signed-off-by: Sasha Levin commit 88c79851b82d5563d91f79cddf6b44423ed7a568 Author: Ard Biesheuvel Date: Wed Mar 10 18:15:11 2021 +0100 arm64: mm: use a 48-bit ID map when possible on 52-bit VA builds [ Upstream commit 7ba8f2b2d652cd8d8a2ab61f4be66973e70f9f88 ] 52-bit VA kernels can run on hardware that is only 48-bit capable, but configure the ID map as 52-bit by default. This was not a problem until recently, because the special T0SZ value for a 52-bit VA space was never programmed into the TCR register anwyay, and because a 52-bit ID map happens to use the same number of translation levels as a 48-bit one. This behavior was changed by commit 1401bef703a4 ("arm64: mm: Always update TCR_EL1 from __cpu_set_tcr_t0sz()"), which causes the unsupported T0SZ value for a 52-bit VA to be programmed into TCR_EL1. While some hardware simply ignores this, Mark reports that Amberwing systems choke on this, resulting in a broken boot. But even before that commit, the unsupported idmap_t0sz value was exposed to KVM and used to program TCR_EL2 incorrectly as well. Given that we already have to deal with address spaces being either 48-bit or 52-bit in size, the cleanest approach seems to be to simply default to a 48-bit VA ID map, and only switch to a 52-bit one if the placement of the kernel in DRAM requires it. This is guaranteed not to happen unless the system is actually 52-bit VA capable. Fixes: 90ec95cda91a ("arm64: mm: Introduce VA_BITS_MIN") Reported-by: Mark Salter Link: http://lore.kernel.org/r/20210310003216.410037-1-msalter@redhat.com Signed-off-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20210310171515.416643-2-ardb@kernel.org Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 73aa6f93e1e980f392b3da4fee830b0e0a4a40ff Author: Daiyue Zhang Date: Mon Mar 1 14:10:53 2021 +0800 configfs: fix a use-after-free in __configfs_open_file [ Upstream commit 14fbbc8297728e880070f7b077b3301a8c698ef9 ] Commit b0841eefd969 ("configfs: provide exclusion between IO and removals") uses ->frag_dead to mark the fragment state, thus no bothering with extra refcount on config_item when opening a file. The configfs_get_config_item was removed in __configfs_open_file, but not with config_item_put. So the refcount on config_item will lost its balance, causing use-after-free issues in some occasions like this: Test: 1. Mount configfs on /config with read-only items: drwxrwx--- 289 root root 0 2021-04-01 11:55 /config drwxr-xr-x 2 root root 0 2021-04-01 11:54 /config/a --w--w--w- 1 root root 4096 2021-04-01 11:53 /config/a/1.txt ...... 2. Then run: for file in /config do echo $file grep -R 'key' $file done 3. __configfs_open_file will be called in parallel, the first one got called will do: if (file->f_mode & FMODE_READ) { if (!(inode->i_mode & S_IRUGO)) goto out_put_module; config_item_put(buffer->item); kref_put() package_details_release() kfree() the other one will run into use-after-free issues like this: BUG: KASAN: use-after-free in __configfs_open_file+0x1bc/0x3b0 Read of size 8 at addr fffffff155f02480 by task grep/13096 CPU: 0 PID: 13096 Comm: grep VIP: 00 Tainted: G W 4.14.116-kasan #1 TGID: 13096 Comm: grep Call trace: dump_stack+0x118/0x160 kasan_report+0x22c/0x294 __asan_load8+0x80/0x88 __configfs_open_file+0x1bc/0x3b0 configfs_open_file+0x28/0x34 do_dentry_open+0x2cc/0x5c0 vfs_open+0x80/0xe0 path_openat+0xd8c/0x2988 do_filp_open+0x1c4/0x2fc do_sys_open+0x23c/0x404 SyS_openat+0x38/0x48 Allocated by task 2138: kasan_kmalloc+0xe0/0x1ac kmem_cache_alloc_trace+0x334/0x394 packages_make_item+0x4c/0x180 configfs_mkdir+0x358/0x740 vfs_mkdir2+0x1bc/0x2e8 SyS_mkdirat+0x154/0x23c el0_svc_naked+0x34/0x38 Freed by task 13096: kasan_slab_free+0xb8/0x194 kfree+0x13c/0x910 package_details_release+0x524/0x56c kref_put+0xc4/0x104 config_item_put+0x24/0x34 __configfs_open_file+0x35c/0x3b0 configfs_open_file+0x28/0x34 do_dentry_open+0x2cc/0x5c0 vfs_open+0x80/0xe0 path_openat+0xd8c/0x2988 do_filp_open+0x1c4/0x2fc do_sys_open+0x23c/0x404 SyS_openat+0x38/0x48 el0_svc_naked+0x34/0x38 To fix this issue, remove the config_item_put in __configfs_open_file to balance the refcount of config_item. Fixes: b0841eefd969 ("configfs: provide exclusion between IO and removals") Signed-off-by: Daiyue Zhang Signed-off-by: Yi Chen Signed-off-by: Ge Qiu Reviewed-by: Chao Yu Acked-by: Al Viro Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit babd55002dd41ba79025092a6212fe2bc4128701 Author: Jia-Ju Bai Date: Tue Mar 9 19:30:17 2021 -0800 block: rsxx: fix error return code of rsxx_pci_probe() [ Upstream commit df66617bfe87487190a60783d26175b65d2502ce ] When create_singlethread_workqueue returns NULL to card->event_wq, no error return code of rsxx_pci_probe() is assigned. To fix this bug, st is assigned with -ENOMEM in this case. Fixes: 8722ff8cdbfa ("block: IBM RamSan 70/80 device driver") Reported-by: TOTE Robot Signed-off-by: Jia-Ju Bai Link: https://lore.kernel.org/r/20210310033017.4023-1-baijiaju1990@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 41deefab452aa53f8919f6c8c07e106a04b6aca0 Author: Ondrej Mosnacek Date: Fri Jan 15 18:43:56 2021 +0100 NFSv4.2: fix return value of _nfs4_get_security_label() [ Upstream commit 53cb245454df5b13d7063162afd7a785aed6ebf2 ] An xattr 'get' handler is expected to return the length of the value on success, yet _nfs4_get_security_label() (and consequently also nfs4_xattr_get_nfs4_label(), which is used as an xattr handler) returns just 0 on success. Fix this by returning label.len instead, which contains the length of the result. Fixes: aa9c2669626c ("NFS: Client implementation of Labeled-NFS") Signed-off-by: Ondrej Mosnacek Reviewed-by: James Morris Reviewed-by: Paul Moore Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 86954a52d8297a0112eb449ce84e0516d5092e09 Author: Trond Myklebust Date: Mon Mar 8 14:42:52 2021 -0500 NFS: Don't gratuitously clear the inode cache when lookup failed [ Upstream commit 47397915ede0192235474b145ebcd81b37b03624 ] The fact that the lookup revalidation failed, does not mean that the inode contents have changed. Fixes: 5ceb9d7fdaaf ("NFS: Refactor nfs_lookup_revalidate()") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit d29f9aa6a8b2acc9183deb8468a9d9e7ff76f2f8 Author: Trond Myklebust Date: Mon Mar 8 14:42:51 2021 -0500 NFS: Don't revalidate the directory permissions on a lookup failure [ Upstream commit 82e7ca1334ab16e2e04fafded1cab9dfcdc11b40 ] There should be no reason to expect the directory permissions to change just because the directory contents changed or a negative lookup timed out. So let's avoid doing a full call to nfs_mark_for_revalidate() in that case. Furthermore, if this is a negative dentry, and we haven't actually done a new lookup, then we have no reason yet to believe the directory has changed at all. So let's remove the gratuitous directory inode invalidation altogether when called from nfs_lookup_revalidate_negative(). Reported-by: Geert Jansen Fixes: 5ceb9d7fdaaf ("NFS: Refactor nfs_lookup_revalidate()") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit d5a69ed759314c66c0d262cd5d9d0f2227bcc492 Author: Benjamin Coddington Date: Wed Mar 3 08:47:16 2021 -0500 SUNRPC: Set memalloc_nofs_save() for sync tasks [ Upstream commit f0940f4b3284a00f38a5d42e6067c2aaa20e1f2e ] We could recurse into NFS doing memory reclaim while sending a sync task, which might result in a deadlock. Set memalloc_nofs_save for sync task execution. Fixes: a1231fda7e94 ("SUNRPC: Set memalloc_nofs_save() on all rpciod/xprtiod jobs") Signed-off-by: Benjamin Coddington Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 9c9ea7ac18b2575254cba91eff72b38832288bbd Author: Anshuman Khandual Date: Fri Mar 5 10:54:57 2021 +0530 arm64/mm: Fix pfn_valid() for ZONE_DEVICE based memory [ Upstream commit eeb0753ba27b26f609e61f9950b14f1b934fe429 ] pfn_valid() validates a pfn but basically it checks for a valid struct page backing for that pfn. It should always return positive for memory ranges backed with struct page mapping. But currently pfn_valid() fails for all ZONE_DEVICE based memory types even though they have struct page mapping. pfn_valid() asserts that there is a memblock entry for a given pfn without MEMBLOCK_NOMAP flag being set. The problem with ZONE_DEVICE based memory is that they do not have memblock entries. Hence memblock_is_map_memory() will invariably fail via memblock_search() for a ZONE_DEVICE based address. This eventually fails pfn_valid() which is wrong. memblock_is_map_memory() needs to be skipped for such memory ranges. As ZONE_DEVICE memory gets hotplugged into the system via memremap_pages() called from a driver, their respective memory sections will not have SECTION_IS_EARLY set. Normal hotplug memory will never have MEMBLOCK_NOMAP set in their memblock regions. Because the flag MEMBLOCK_NOMAP was specifically designed and set for firmware reserved memory regions. memblock_is_map_memory() can just be skipped as its always going to be positive and that will be an optimization for the normal hotplug memory. Like ZONE_DEVICE based memory, all normal hotplugged memory too will not have SECTION_IS_EARLY set for their sections Skipping memblock_is_map_memory() for all non early memory sections would fix pfn_valid() problem for ZONE_DEVICE based memory and also improve its performance for normal hotplug memory as well. Cc: Catalin Marinas Cc: Will Deacon Cc: Ard Biesheuvel Cc: Robin Murphy Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Acked-by: David Hildenbrand Fixes: 73b20c84d42d ("arm64: mm: implement pte_devmap support") Signed-off-by: Anshuman Khandual Acked-by: Catalin Marinas Link: https://lore.kernel.org/r/1614921898-4099-2-git-send-email-anshuman.khandual@arm.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 19bb2a20710d4756dd70e319f3f20808c928bb94 Author: Sergey Shtylyov Date: Sun Feb 28 23:26:34 2021 +0300 sh_eth: fix TRSCER mask for R7S72100 [ Upstream commit 75be7fb7f978202c4c3a1a713af4485afb2ff5f6 ] According to the RZ/A1H Group, RZ/A1M Group User's Manual: Hardware, Rev. 4.00, the TRSCER register has bit 9 reserved, hence we can't use the driver's default TRSCER mask. Add the explicit initializer for sh_eth_cpu_data::trscer_err_mask for R7S72100. Fixes: db893473d313 ("sh_eth: Add support for r7s72100") Signed-off-by: Sergey Shtylyov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c3c1defad2dd1275ccf94fcf97fe512c1433841d Author: Ian Abbott Date: Tue Feb 23 14:30:50 2021 +0000 staging: comedi: pcl818: Fix endian problem for AI command data commit 148e34fd33d53740642db523724226de14ee5281 upstream. The analog input subdevice supports Comedi asynchronous commands that use Comedi's 16-bit sample format. However, the call to `comedi_buf_write_samples()` is passing the address of a 32-bit integer parameter. On bigendian machines, this will copy 2 bytes from the wrong end of the 32-bit value. Fix it by changing the type of the parameter holding the sample value to `unsigned short`. [Note: the bug was introduced in commit edf4537bcbf5 ("staging: comedi: pcl818: use comedi_buf_write_samples()") but the patch applies better to commit d615416de615 ("staging: comedi: pcl818: introduce pcl818_ai_write_sample()").] Fixes: d615416de615 ("staging: comedi: pcl818: introduce pcl818_ai_write_sample()") Cc: # 4.0+ Signed-off-by: Ian Abbott Link: https://lore.kernel.org/r/20210223143055.257402-10-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman commit c5916897a6e1b6ed1aaad2a2752e620731a684e4 Author: Ian Abbott Date: Tue Feb 23 14:30:49 2021 +0000 staging: comedi: pcl711: Fix endian problem for AI command data commit a084303a645896e834883f2c5170d044410dfdb3 upstream. The analog input subdevice supports Comedi asynchronous commands that use Comedi's 16-bit sample format. However, the call to `comedi_buf_write_samples()` is passing the address of a 32-bit integer variable. On bigendian machines, this will copy 2 bytes from the wrong end of the 32-bit value. Fix it by changing the type of the variable holding the sample value to `unsigned short`. Fixes: 1f44c034de2e ("staging: comedi: pcl711: use comedi_buf_write_samples()") Cc: # 3.19+ Signed-off-by: Ian Abbott Link: https://lore.kernel.org/r/20210223143055.257402-9-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman commit 7d8ec7bef320a8901f93b263b21542589f5409dc Author: Ian Abbott Date: Tue Feb 23 14:30:48 2021 +0000 staging: comedi: me4000: Fix endian problem for AI command data commit b39dfcced399d31e7c4b7341693b18e01c8f655e upstream. The analog input subdevice supports Comedi asynchronous commands that use Comedi's 16-bit sample format. However, the calls to `comedi_buf_write_samples()` are passing the address of a 32-bit integer variable. On bigendian machines, this will copy 2 bytes from the wrong end of the 32-bit value. Fix it by changing the type of the variable holding the sample value to `unsigned short`. Fixes: de88924f67d1 ("staging: comedi: me4000: use comedi_buf_write_samples()") Cc: # 3.19+ Signed-off-by: Ian Abbott Link: https://lore.kernel.org/r/20210223143055.257402-8-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman commit e70294943c89912c878e533d95908fa6fb656ee1 Author: Ian Abbott Date: Tue Feb 23 14:30:47 2021 +0000 staging: comedi: dmm32at: Fix endian problem for AI command data commit 54999c0d94b3c26625f896f8e3460bc029821578 upstream. The analog input subdevice supports Comedi asynchronous commands that use Comedi's 16-bit sample format. However, the call to `comedi_buf_write_samples()` is passing the address of a 32-bit integer variable. On bigendian machines, this will copy 2 bytes from the wrong end of the 32-bit value. Fix it by changing the type of the variable holding the sample value to `unsigned short`. [Note: the bug was introduced in commit 1700529b24cc ("staging: comedi: dmm32at: use comedi_buf_write_samples()") but the patch applies better to the later (but in the same kernel release) commit 0c0eadadcbe6e ("staging: comedi: dmm32at: introduce dmm32_ai_get_sample()").] Fixes: 0c0eadadcbe6e ("staging: comedi: dmm32at: introduce dmm32_ai_get_sample()") Cc: # 3.19+ Signed-off-by: Ian Abbott Link: https://lore.kernel.org/r/20210223143055.257402-7-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman commit 47a2af64eea32773e67a788b3da655fda96482b7 Author: Ian Abbott Date: Tue Feb 23 14:30:46 2021 +0000 staging: comedi: das800: Fix endian problem for AI command data commit 459b1e8c8fe97fcba0bd1b623471713dce2c5eaf upstream. The analog input subdevice supports Comedi asynchronous commands that use Comedi's 16-bit sample format. However, the call to `comedi_buf_write_samples()` is passing the address of a 32-bit integer variable. On bigendian machines, this will copy 2 bytes from the wrong end of the 32-bit value. Fix it by changing the type of the variable holding the sample value to `unsigned short`. Fixes: ad9eb43c93d8 ("staging: comedi: das800: use comedi_buf_write_samples()") Cc: # 3.19+ Signed-off-by: Ian Abbott Link: https://lore.kernel.org/r/20210223143055.257402-6-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman commit 0f2522ec71b6a2d2fc2f21587e1ccb7b9a7a4780 Author: Ian Abbott Date: Tue Feb 23 14:30:45 2021 +0000 staging: comedi: das6402: Fix endian problem for AI command data commit 1c0f20b78781b9ca50dc3ecfd396d0db5b141890 upstream. The analog input subdevice supports Comedi asynchronous commands that use Comedi's 16-bit sample format. However, the call to `comedi_buf_write_samples()` is passing the address of a 32-bit integer variable. On bigendian machines, this will copy 2 bytes from the wrong end of the 32-bit value. Fix it by changing the type of the variable holding the sample value to `unsigned short`. Fixes: d1d24cb65ee3 ("staging: comedi: das6402: read analog input samples in interrupt handler") Cc: # 3.19+ Signed-off-by: Ian Abbott Link: https://lore.kernel.org/r/20210223143055.257402-5-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman commit e91490b9edb9c6d2c8136b54fcb37696d3de40a8 Author: Ian Abbott Date: Tue Feb 23 14:30:44 2021 +0000 staging: comedi: adv_pci1710: Fix endian problem for AI command data commit b2e78630f733a76508b53ba680528ca39c890e82 upstream. The analog input subdevice supports Comedi asynchronous commands that use Comedi's 16-bit sample format. However, the calls to `comedi_buf_write_samples()` are passing the address of a 32-bit integer variable. On bigendian machines, this will copy 2 bytes from the wrong end of the 32-bit value. Fix it by changing the type of the variables holding the sample value to `unsigned short`. The type of the `val` parameter of `pci1710_ai_read_sample()` is changed to `unsigned short *` accordingly. The type of the `val` variable in `pci1710_ai_insn_read()` is also changed to `unsigned short` since its address is passed to `pci1710_ai_read_sample()`. Fixes: a9c3a015c12f ("staging: comedi: adv_pci1710: use comedi_buf_write_samples()") Cc: # 4.0+ Signed-off-by: Ian Abbott Link: https://lore.kernel.org/r/20210223143055.257402-4-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman commit 4d6505edee5aa70965be14bc782d118ec8256fe8 Author: Ian Abbott Date: Tue Feb 23 14:30:43 2021 +0000 staging: comedi: addi_apci_1500: Fix endian problem for command sample commit ac0bbf55ed3be75fde1f8907e91ecd2fd589bde3 upstream. The digital input subdevice supports Comedi asynchronous commands that read interrupt status information. This uses 16-bit Comedi samples (of which only the bottom 8 bits contain status information). However, the interrupt handler is calling `comedi_buf_write_samples()` with the address of a 32-bit variable `unsigned int status`. On a bigendian machine, this will copy 2 bytes from the wrong end of the variable. Fix it by changing the type of the variable to `unsigned short`. Fixes: a8c66b684efa ("staging: comedi: addi_apci_1500: rewrite the subdevice support functions") Cc: #4.0+ Signed-off-by: Ian Abbott Link: https://lore.kernel.org/r/20210223143055.257402-3-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman commit f258c1c26f6418fe14a60e61876eb691a572bb41 Author: Ian Abbott Date: Tue Feb 23 14:30:42 2021 +0000 staging: comedi: addi_apci_1032: Fix endian problem for COS sample commit 25317f428a78fde71b2bf3f24d05850f08a73a52 upstream. The Change-Of-State (COS) subdevice supports Comedi asynchronous commands to read 16-bit change-of-state values. However, the interrupt handler is calling `comedi_buf_write_samples()` with the address of a 32-bit integer `&s->state`. On bigendian architectures, it will copy 2 bytes from the wrong end of the 32-bit integer. Fix it by transferring the value via a 16-bit integer. Fixes: 6bb45f2b0c86 ("staging: comedi: addi_apci_1032: use comedi_buf_write_samples()") Cc: # 3.19+ Signed-off-by: Ian Abbott Link: https://lore.kernel.org/r/20210223143055.257402-2-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman commit e644fc4ab7bb852d984ddd7f96cfb05e6ee3cfb7 Author: Lee Gibson Date: Fri Feb 26 14:51:57 2021 +0000 staging: rtl8192e: Fix possible buffer overflow in _rtl92e_wx_set_scan commit 8687bf9ef9551bcf93897e33364d121667b1aadf upstream. Function _rtl92e_wx_set_scan calls memcpy without checking the length. A user could control that length and trigger a buffer overflow. Fix by checking the length is within the maximum allowed size. Reviewed-by: Dan Carpenter Signed-off-by: Lee Gibson Cc: stable Link: https://lore.kernel.org/r/20210226145157.424065-1-leegib@gmail.com Signed-off-by: Greg Kroah-Hartman commit 8f586a59829bbbab06241d2d6517dfa32a0cb18e Author: Lee Gibson Date: Mon Mar 1 13:26:48 2021 +0000 staging: rtl8712: Fix possible buffer overflow in r8712_sitesurvey_cmd commit b93c1e3981af19527beee1c10a2bef67a228c48c upstream. Function r8712_sitesurvey_cmd calls memcpy without checking the length. A user could control that length and trigger a buffer overflow. Fix by checking the length is within the maximum allowed size. Signed-off-by: Lee Gibson Link: https://lore.kernel.org/r/20210301132648.420296-1-leegib@gmail.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit 9fe42273b2c6bbd98b031fa93a6fa9ab2e99f121 Author: Dan Carpenter Date: Tue Mar 2 14:19:39 2021 +0300 staging: ks7010: prevent buffer overflow in ks_wlan_set_scan() commit e163b9823a0b08c3bb8dc4f5b4b5c221c24ec3e5 upstream. The user can specify a "req->essid_len" of up to 255 but if it's over IW_ESSID_MAX_SIZE (32) that can lead to memory corruption. Fixes: 13a9930d15b4 ("staging: ks7010: add driver from Nanonote extra-repository") Signed-off-by: Dan Carpenter Cc: stable Link: https://lore.kernel.org/r/YD4fS8+HmM/Qmrw6@mwanda Signed-off-by: Greg Kroah-Hartman commit ab42f28d5f3471a2880e9f522964627b45a3e22e Author: Dan Carpenter Date: Fri Mar 5 11:56:32 2021 +0300 staging: rtl8188eu: fix potential memory corruption in rtw_check_beacon_data() commit d4ac640322b06095128a5c45ba4a1e80929fe7f3 upstream. The "ie_len" is a value in the 1-255 range that comes from the user. We have to cap it to ensure that it's not too large or it could lead to memory corruption. Fixes: 9a7fe54ddc3a ("staging: r8188eu: Add source files for new driver - part 1") Signed-off-by: Dan Carpenter Cc: stable Link: https://lore.kernel.org/r/YEHyQCrFZKTXyT7J@mwanda Signed-off-by: Greg Kroah-Hartman commit 1a866057e970e640ceba8d021748e0805a01dda9 Author: Dan Carpenter Date: Wed Feb 24 11:45:59 2021 +0300 staging: rtl8712: unterminated string leads to read overflow commit d660f4f42ccea50262c6ee90c8e7ad19a69fb225 upstream. The memdup_user() function does not necessarily return a NUL terminated string so this can lead to a read overflow. Switch from memdup_user() to strndup_user() to fix this bug. Fixes: c6dc001f2add ("staging: r8712u: Merging Realtek's latest (v2.6.6). Various fixes.") Cc: stable Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/YDYSR+1rj26NRhvb@mwanda Signed-off-by: Greg Kroah-Hartman commit da5abe369b03447b3df1e5816b9560cbae503993 Author: Dan Carpenter Date: Fri Mar 5 11:58:03 2021 +0300 staging: rtl8188eu: prevent ->ssid overflow in rtw_wx_set_scan() commit 74b6b20df8cfe90ada777d621b54c32e69e27cd7 upstream. This code has a check to prevent read overflow but it needs another check to prevent writing beyond the end of the ->ssid[] array. Fixes: a2c60d42d97c ("staging: r8188eu: Add files for new driver - part 16") Signed-off-by: Dan Carpenter Cc: stable Link: https://lore.kernel.org/r/YEHymwsnHewzoam7@mwanda Signed-off-by: Greg Kroah-Hartman commit a311b6a7f099ba3825219b3a9dc34b2300d92216 Author: Dan Carpenter Date: Fri Mar 5 11:12:49 2021 +0300 staging: rtl8192u: fix ->ssid overflow in r8192_wx_set_scan() commit 87107518d7a93fec6cdb2559588862afeee800fb upstream. We need to cap len at IW_ESSID_MAX_SIZE (32) to avoid memory corruption. This can be controlled by the user via the ioctl. Fixes: 5f53d8ca3d5d ("Staging: add rtl8192SU wireless usb driver") Signed-off-by: Dan Carpenter Cc: stable Link: https://lore.kernel.org/r/YEHoAWMOSZBUw91F@mwanda Signed-off-by: Greg Kroah-Hartman commit e4b52c7cbaaf4d11288d331b654b0fac450e4971 Author: Dmitry Baryshkov Date: Fri Feb 12 22:26:58 2021 +0300 misc: fastrpc: restrict user apps from sending kernel RPC messages commit 20c40794eb85ea29852d7bc37c55713802a543d6 upstream. Verify that user applications are not using the kernel RPC message handle to restrict them from directly attaching to guest OS on the remote subsystem. This is a port of CVE-2019-2308 fix. Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context Invoke method") Cc: Srinivas Kandagatla Cc: Jonathan Marek Cc: stable@vger.kernel.org Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20210212192658.3476137-1-dmitry.baryshkov@linaro.org Signed-off-by: Greg Kroah-Hartman commit 9009b59dfd5fe7e1cfdd9c6d07a3d23563f11a81 Author: Shile Zhang Date: Thu Feb 18 20:31:16 2021 +0800 misc/pvpanic: Export module FDT device table commit 65527a51c66f4edfa28602643d7dd4fa366eb826 upstream. Export the module FDT device table to ensure the FDT compatible strings are listed in the module alias. This help the pvpanic driver can be loaded on boot automatically not only the ACPI device, but also the FDT device. Fixes: 46f934c9a12fc ("misc/pvpanic: add support to get pvpanic device info FDT") Signed-off-by: Shile Zhang Link: https://lore.kernel.org/r/20210218123116.207751-1-shile.zhang@linux.alibaba.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit 0a58a400a93b7af9c8e6ab9f31bc72af786ab648 Author: Shuah Khan Date: Sun Mar 7 20:53:31 2021 -0700 usbip: fix vudc usbip_sockfd_store races leading to gpf commit 46613c9dfa964c0c60b5385dbdf5aaa18be52a9c upstream. usbip_sockfd_store() is invoked when user requests attach (import) detach (unimport) usb gadget device from usbip host. vhci_hcd sends import request and usbip_sockfd_store() exports the device if it is free for export. Export and unexport are governed by local state and shared state - Shared state (usbip device status, sockfd) - sockfd and Device status are used to determine if stub should be brought up or shut down. Device status is shared between host and client. - Local state (tcp_socket, rx and tx thread task_struct ptrs) A valid tcp_socket controls rx and tx thread operations while the device is in exported state. - While the device is exported, device status is marked used and socket, sockfd, and thread pointers are valid. Export sequence (stub-up) includes validating the socket and creating receive (rx) and transmit (tx) threads to talk to the client to provide access to the exported device. rx and tx threads depends on local and shared state to be correct and in sync. Unexport (stub-down) sequence shuts the socket down and stops the rx and tx threads. Stub-down sequence relies on local and shared states to be in sync. There are races in updating the local and shared status in the current stub-up sequence resulting in crashes. These stem from starting rx and tx threads before local and global state is updated correctly to be in sync. 1. Doesn't handle kthread_create() error and saves invalid ptr in local state that drives rx and tx threads. 2. Updates tcp_socket and sockfd, starts stub_rx and stub_tx threads before updating usbip_device status to SDEV_ST_USED. This opens up a race condition between the threads and usbip_sockfd_store() stub up and down handling. Fix the above problems: - Stop using kthread_get_run() macro to create/start threads. - Create threads and get task struct reference. - Add kthread_create() failure handling and bail out. - Hold usbip_device lock to update local and shared states after creating rx and tx threads. - Update usbip_device status to SDEV_ST_USED. - Update usbip_device tcp_socket, sockfd, tcp_rx, and tcp_tx - Start threads after usbip_device (tcp_socket, sockfd, tcp_rx, tcp_tx, and status) is complete. Credit goes to syzbot and Tetsuo Handa for finding and root-causing the kthread_get_run() improper error handling problem and others. This is a hard problem to find and debug since the races aren't seen in a normal case. Fuzzing forces the race window to be small enough for the kthread_get_run() error path bug and starting threads before updating the local and shared state bug in the stub-up sequence. Fixes: 9720b4bc76a83807 ("staging/usbip: convert to kthread") Cc: stable@vger.kernel.org Reported-by: syzbot Reported-by: syzbot Reported-by: syzbot Reported-by: Tetsuo Handa Signed-off-by: Shuah Khan Link: https://lore.kernel.org/r/b1c08b983ffa185449c9f0f7d1021dc8c8454b60.1615171203.git.skhan@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 8a50dda5243ee64264fdb02135e68670b6a330ba Author: Shuah Khan Date: Sun Mar 7 20:53:30 2021 -0700 usbip: fix vhci_hcd attach_store() races leading to gpf commit 718ad9693e3656120064b715fe931f43a6201e67 upstream. attach_store() is invoked when user requests import (attach) a device from usbip host. Attach and detach are governed by local state and shared state - Shared state (usbip device status) - Device status is used to manage the attach and detach operations on import-able devices. - Local state (tcp_socket, rx and tx thread task_struct ptrs) A valid tcp_socket controls rx and tx thread operations while the device is in exported state. - Device has to be in the right state to be attached and detached. Attach sequence includes validating the socket and creating receive (rx) and transmit (tx) threads to talk to the host to get access to the imported device. rx and tx threads depends on local and shared state to be correct and in sync. Detach sequence shuts the socket down and stops the rx and tx threads. Detach sequence relies on local and shared states to be in sync. There are races in updating the local and shared status in the current attach sequence resulting in crashes. These stem from starting rx and tx threads before local and global state is updated correctly to be in sync. 1. Doesn't handle kthread_create() error and saves invalid ptr in local state that drives rx and tx threads. 2. Updates tcp_socket and sockfd, starts stub_rx and stub_tx threads before updating usbip_device status to VDEV_ST_NOTASSIGNED. This opens up a race condition between the threads, port connect, and detach handling. Fix the above problems: - Stop using kthread_get_run() macro to create/start threads. - Create threads and get task struct reference. - Add kthread_create() failure handling and bail out. - Hold vhci and usbip_device locks to update local and shared states after creating rx and tx threads. - Update usbip_device status to VDEV_ST_NOTASSIGNED. - Update usbip_device tcp_socket, sockfd, tcp_rx, and tcp_tx - Start threads after usbip_device (tcp_socket, sockfd, tcp_rx, tcp_tx, and status) is complete. Credit goes to syzbot and Tetsuo Handa for finding and root-causing the kthread_get_run() improper error handling problem and others. This is hard problem to find and debug since the races aren't seen in a normal case. Fuzzing forces the race window to be small enough for the kthread_get_run() error path bug and starting threads before updating the local and shared state bug in the attach sequence. - Update usbip_device tcp_rx and tcp_tx pointers holding vhci and usbip_device locks. Tested with syzbot reproducer: - https://syzkaller.appspot.com/text?tag=ReproC&x=14801034d00000 Fixes: 9720b4bc76a83807 ("staging/usbip: convert to kthread") Cc: stable@vger.kernel.org Reported-by: syzbot Reported-by: syzbot Reported-by: syzbot Reported-by: Tetsuo Handa Signed-off-by: Shuah Khan Link: https://lore.kernel.org/r/bb434bd5d7a64fbec38b5ecfb838a6baef6eb12b.1615171203.git.skhan@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 8698133003cfb67e0f04dd044c954198e421b152 Author: Shuah Khan Date: Sun Mar 7 20:53:29 2021 -0700 usbip: fix stub_dev usbip_sockfd_store() races leading to gpf commit 9380afd6df70e24eacbdbde33afc6a3950965d22 upstream. usbip_sockfd_store() is invoked when user requests attach (import) detach (unimport) usb device from usbip host. vhci_hcd sends import request and usbip_sockfd_store() exports the device if it is free for export. Export and unexport are governed by local state and shared state - Shared state (usbip device status, sockfd) - sockfd and Device status are used to determine if stub should be brought up or shut down. - Local state (tcp_socket, rx and tx thread task_struct ptrs) A valid tcp_socket controls rx and tx thread operations while the device is in exported state. - While the device is exported, device status is marked used and socket, sockfd, and thread pointers are valid. Export sequence (stub-up) includes validating the socket and creating receive (rx) and transmit (tx) threads to talk to the client to provide access to the exported device. rx and tx threads depends on local and shared state to be correct and in sync. Unexport (stub-down) sequence shuts the socket down and stops the rx and tx threads. Stub-down sequence relies on local and shared states to be in sync. There are races in updating the local and shared status in the current stub-up sequence resulting in crashes. These stem from starting rx and tx threads before local and global state is updated correctly to be in sync. 1. Doesn't handle kthread_create() error and saves invalid ptr in local state that drives rx and tx threads. 2. Updates tcp_socket and sockfd, starts stub_rx and stub_tx threads before updating usbip_device status to SDEV_ST_USED. This opens up a race condition between the threads and usbip_sockfd_store() stub up and down handling. Fix the above problems: - Stop using kthread_get_run() macro to create/start threads. - Create threads and get task struct reference. - Add kthread_create() failure handling and bail out. - Hold usbip_device lock to update local and shared states after creating rx and tx threads. - Update usbip_device status to SDEV_ST_USED. - Update usbip_device tcp_socket, sockfd, tcp_rx, and tcp_tx - Start threads after usbip_device (tcp_socket, sockfd, tcp_rx, tcp_tx, and status) is complete. Credit goes to syzbot and Tetsuo Handa for finding and root-causing the kthread_get_run() improper error handling problem and others. This is a hard problem to find and debug since the races aren't seen in a normal case. Fuzzing forces the race window to be small enough for the kthread_get_run() error path bug and starting threads before updating the local and shared state bug in the stub-up sequence. Tested with syzbot reproducer: - https://syzkaller.appspot.com/text?tag=ReproC&x=14801034d00000 Fixes: 9720b4bc76a83807 ("staging/usbip: convert to kthread") Cc: stable@vger.kernel.org Reported-by: syzbot Reported-by: syzbot Reported-by: syzbot Reported-by: Tetsuo Handa Signed-off-by: Shuah Khan Link: https://lore.kernel.org/r/268a0668144d5ff36ec7d87fdfa90faf583b7ccc.1615171203.git.skhan@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 7b76c7a91bf68f5689292756217264c1c1f69057 Author: Shuah Khan Date: Sun Mar 7 20:53:28 2021 -0700 usbip: fix vudc to check for stream socket commit 6801854be94fe8819b3894979875ea31482f5658 upstream. Fix usbip_sockfd_store() to validate the passed in file descriptor is a stream socket. If the file descriptor passed was a SOCK_DGRAM socket, sock_recvmsg() can't detect end of stream. Cc: stable@vger.kernel.org Suggested-by: Tetsuo Handa Signed-off-by: Shuah Khan Link: https://lore.kernel.org/r/387a670316002324113ac7ea1e8b53f4085d0c95.1615171203.git.skhan@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 2e24c093e2640f3eeb38bdec294dde0c1c0a983f Author: Shuah Khan Date: Sun Mar 7 20:53:27 2021 -0700 usbip: fix vhci_hcd to check for stream socket commit f55a0571690c4aae03180e001522538c0927432f upstream. Fix attach_store() to validate the passed in file descriptor is a stream socket. If the file descriptor passed was a SOCK_DGRAM socket, sock_recvmsg() can't detect end of stream. Cc: stable@vger.kernel.org Suggested-by: Tetsuo Handa Signed-off-by: Shuah Khan Link: https://lore.kernel.org/r/52712aa308915bda02cece1589e04ee8b401d1f3.1615171203.git.skhan@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit da1be8e078521252947f11d83f34db363a91f62f Author: Shuah Khan Date: Sun Mar 7 20:53:26 2021 -0700 usbip: fix stub_dev to check for stream socket commit 47ccc8fc2c9c94558b27b6f9e2582df32d29e6e8 upstream. Fix usbip_sockfd_store() to validate the passed in file descriptor is a stream socket. If the file descriptor passed was a SOCK_DGRAM socket, sock_recvmsg() can't detect end of stream. Cc: stable@vger.kernel.org Suggested-by: Tetsuo Handa Signed-off-by: Shuah Khan Link: https://lore.kernel.org/r/e942d2bd03afb8e8552bd2a5d84e18d17670d521.1615171203.git.skhan@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit ec7fb77a37af5579488745608b12e1ed8bec7d3c Author: Sebastian Reichel Date: Tue Feb 23 17:44:18 2021 +0100 USB: serial: cp210x: add some more GE USB IDs commit 42213a0190b535093a604945db05a4225bf43885 upstream. GE CS1000 has some more custom USB IDs for CP2102N; add them to the driver to have working auto-probing. Signed-off-by: Sebastian Reichel Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit b05ac5bcf6236add3656fa4991e57e6acef36870 Author: Karan Singhal Date: Tue Feb 16 11:03:10 2021 -0500 USB: serial: cp210x: add ID for Acuity Brands nLight Air Adapter commit ca667a33207daeaf9c62b106815728718def60ec upstream. IDs of nLight Air Adapter, Acuity Brands, Inc.: vid: 10c4 pid: 88d8 Signed-off-by: Karan Singhal Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 0b7034401f0c34c1a625741fd3230fff3b8753af Author: Niv Sardi Date: Mon Mar 1 17:16:12 2021 -0300 USB: serial: ch341: add new Product ID commit 5563b3b6420362c8a1f468ca04afe6d5f0a8d0a3 upstream. Add PID for CH340 that's found on cheap programmers. The driver works flawlessly as soon as the new PID (0x9986) is added to it. These look like ANU232MI but ship with a ch341 inside. They have no special identifiers (mine only has the string "DB9D20130716" printed on the PCB and nothing identifiable on the packaging. The merchant i bought it from doesn't sell these anymore). the lsusb -v output is: Bus 001 Device 009: ID 9986:7523 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x9986 idProduct 0x7523 bcdDevice 2.54 iManufacturer 0 iProduct 0 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0027 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 96mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 2 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 1 Signed-off-by: Niv Sardi Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 5287c3d62e912a09ba8488b1c7aeac0fe7b68f5e Author: Pavel Skripkin Date: Tue Mar 2 02:01:52 2021 +0300 USB: serial: io_edgeport: fix memory leak in edge_startup commit cfdc67acc785e01a8719eeb7012709d245564701 upstream. sysbot found memory leak in edge_startup(). The problem was that when an error was received from the usb_submit_urb(), nothing was cleaned up. Reported-by: syzbot+59f777bdcbdd7eea5305@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin Fixes: 6e8cf7751f9f ("USB: add EPIC support to the io_edgeport driver") Cc: stable@vger.kernel.org # 2.6.21: c5c0c55598ce Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit c1b20c6fac0549ac5c0a22698dd39ce01850988c Author: Mathias Nyman Date: Thu Mar 11 13:53:53 2021 +0200 xhci: Fix repeated xhci wake after suspend due to uncleared internal wake state commit d26c00e7276fc92b18c253d69e872f6b03832bad upstream. If port terminations are detected in suspend, but link never reaches U0 then xHCI may have an internal uncleared wake state that will cause an immediate wake after suspend. This wake state is normally cleared when driver clears the PORT_CSC bit, which is set after a device is enabled and in U0. Write 1 to clear PORT_CSC for ports that don't have anything connected when suspending. This makes sure any pending internal wake states in xHCI are cleared. Cc: stable@vger.kernel.org Tested-by: Mika Westerberg Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210311115353.2137560-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 3573dea8c17a6da37713bf0501fb70fd78541ec1 Author: Forest Crossman Date: Thu Mar 11 13:53:52 2021 +0200 usb: xhci: Fix ASMedia ASM1042A and ASM3242 DMA addressing commit b71c669ad8390dd1c866298319ff89fe68b45653 upstream. I've confirmed that both the ASMedia ASM1042A and ASM3242 have the same problem as the ASM1142 and ASM2142/ASM3142, where they lose some of the upper bits of 64-bit DMA addresses. As with the other chips, this can cause problems on systems where the upper bits matter, and adding the XHCI_NO_64BIT_SUPPORT quirk completely fixes the issue. Cc: stable@vger.kernel.org Signed-off-by: Forest Crossman Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210311115353.2137560-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 57ab089c09d50f4674aa03ef055d4ad13647ac76 Author: Mathias Nyman Date: Thu Mar 11 13:53:51 2021 +0200 xhci: Improve detection of device initiated wake signal. commit 253f588c70f66184b1f3a9bbb428b49bbda73e80 upstream. A xHC USB 3 port might miss the first wake signal from a USB 3 device if the port LFPS reveiver isn't enabled fast enough after xHC resume. xHC host will anyway be resumed by a PME# signal, but will go back to suspend if no port activity is seen. The device resends the U3 LFPS wake signal after a 100ms delay, but by then host is already suspended, starting all over from the beginning of this issue. USB 3 specs say U3 wake LFPS signal is sent for max 10ms, then device needs to delay 100ms before resending the wake. Don't suspend immediately if port activity isn't detected in resume. Instead add a retry. If there is no port activity then delay for 120ms, and re-check for port activity. Cc: Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210311115353.2137560-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit f4f02f9feb4e576c6e25c6c8503013b4f724a920 Author: Stanislaw Gruszka Date: Thu Mar 11 13:53:50 2021 +0200 usb: xhci: do not perform Soft Retry for some xHCI hosts commit a4a251f8c23518899d2078c320cf9ce2fa459c9f upstream. On some systems rt2800usb and mt7601u devices are unable to operate since commit f8f80be501aa ("xhci: Use soft retry to recover faster from transaction errors") Seems that some xHCI controllers can not perform Soft Retry correctly, affecting those devices. To avoid the problem add xhci->quirks flag that restore pre soft retry xhci behaviour for affected xHCI controllers. Currently those are AMD_PROMONTORYA_4 and AMD_PROMONTORYA_2, since it was confirmed by the users: on those xHCI hosts issue happen and is gone after disabling Soft Retry. [minor commit message rewording for checkpatch -Mathias] Fixes: f8f80be501aa ("xhci: Use soft retry to recover faster from transaction errors") Cc: # 4.20+ Reported-by: Bernhard Tested-by: Bernhard Signed-off-by: Stanislaw Gruszka Signed-off-by: Mathias Nyman Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202541 Link: https://lore.kernel.org/r/20210311115353.2137560-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 45bc1c34b54e787ec0c230912516c4634970c2f1 Author: Yoshihiro Shimoda Date: Mon Mar 8 10:55:38 2021 +0900 usb: renesas_usbhs: Clear PIPECFG for re-enabling pipe with other EPNUM commit b1d25e6ee57c2605845595b6c61340d734253eb3 upstream. According to the datasheet, this controller has a restriction which "set an endpoint number so that combinations of the DIR bit and the EPNUM bits do not overlap.". However, since the udc core driver is possible to assign a bulk pipe as an interrupt endpoint, an endpoint number may not match the pipe number. After that, when user rebinds another gadget driver, this driver broke the restriction because the driver didn't clear any configuration in usb_ep_disable(). Example: # modprobe g_ncm Then, EP3 = pipe 3, EP4 = pipe 4, EP5 = pipe 6 # rmmod g_ncm # modprobe g_hid Then, EP3 = pipe 6, EP4 = pipe 7. So, pipe 3 and pipe 6 are set as EP3. So, clear PIPECFG register in usbhs_pipe_free(). Fixes: dfb87b8bfe09 ("usb: renesas_usbhs: gadget: fix re-enabling pipe without re-connecting") Cc: stable Signed-off-by: Yoshihiro Shimoda Link: https://lore.kernel.org/r/1615168538-26101-1-git-send-email-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Greg Kroah-Hartman commit c9e346234698546be28b5be809930dc879bda416 Author: Pete Zaitcev Date: Wed Mar 3 22:10:53 2021 -0600 USB: usblp: fix a hang in poll() if disconnected commit 9de2c43acf37a17dc4c69ff78bb099b80fb74325 upstream. Apparently an application that opens a device and calls select() on it, will hang if the decice is disconnected. It's a little surprising that we had this bug for 15 years, but apparently nobody ever uses select() with a printer: only write() and read(), and those work fine. Well, you can also select() with a timeout. The fix is modeled after devio.c. A few other drivers check the condition first, then do not add the wait queue in case the device is disconnected. We doubt that's completely race-free. So, this patch adds the process first, then locks properly and checks for the disconnect. Reviewed-by: Zqiang Signed-off-by: Pete Zaitcev Cc: stable Link: https://lore.kernel.org/r/20210303221053.1cf3313e@suzdal.zaitcev.lan Signed-off-by: Greg Kroah-Hartman commit cc495be174661df6f2282b5bb45d09b46e37593d Author: Matthias Kaehlcke Date: Tue Mar 2 10:37:03 2021 -0800 usb: dwc3: qcom: Honor wakeup enabled/disabled state commit 2664deb0930643149d61cddbb66ada527ae180bd upstream. The dwc3-qcom currently enables wakeup interrupts unconditionally when suspending, however this should not be done when wakeup is disabled (e.g. through the sysfs attribute power/wakeup). Only enable wakeup interrupts when device_may_wakeup() returns true. Fixes: a4333c3a6ba9 ("usb: dwc3: Add Qualcomm DWC3 glue driver") Reviewed-by: Bjorn Andersson Signed-off-by: Matthias Kaehlcke Cc: stable Link: https://lore.kernel.org/r/20210302103659.v2.1.I44954d9e1169f2cf5c44e6454d357c75ddfa99a2@changeid Signed-off-by: Greg Kroah-Hartman commit f030e3c6779145b5dab61b0ce482a25519824788 Author: Serge Semin Date: Fri Feb 12 23:55:19 2021 +0300 usb: dwc3: qcom: Add missing DWC3 OF node refcount decrement commit 1cffb1c66499a9db9a735473778abf8427d16287 upstream. of_get_child_by_name() increments the reference counter of the OF node it managed to find. So after the code is done using the device node, the refcount must be decremented. Add missing of_node_put() invocation then to the dwc3_qcom_of_register_core() method, since DWC3 OF node is being used only there. Fixes: a4333c3a6ba9 ("usb: dwc3: Add Qualcomm DWC3 glue driver") Signed-off-by: Serge Semin Link: https://lore.kernel.org/r/20210212205521.14280-1-Sergey.Semin@baikalelectronics.ru Cc: stable Signed-off-by: Greg Kroah-Hartman commit 014e4b616313b0d9219d37ed77d5d888a757362d Author: Ruslan Bilovol Date: Mon Mar 1 13:49:32 2021 +0200 usb: gadget: f_uac1: stop playback on function disable commit cc2ac63d4cf72104e0e7f58bb846121f0f51bb19 upstream. There is missing playback stop/cleanup in case of gadget's ->disable callback that happens on events like USB host resetting or gadget disconnection Fixes: 0591bc236015 ("usb: gadget: add f_uac1 variant based on a new u_audio api") Cc: # 4.13+ Signed-off-by: Ruslan Bilovol Link: https://lore.kernel.org/r/1614599375-8803-3-git-send-email-ruslan.bilovol@gmail.com Signed-off-by: Greg Kroah-Hartman commit 117aadfc06167ea5c24972b75fe123c8d0ddb1d1 Author: Ruslan Bilovol Date: Mon Mar 1 13:49:31 2021 +0200 usb: gadget: f_uac2: always increase endpoint max_packet_size by one audio slot commit 789ea77310f0200c84002884ffd628e2baf3ad8a upstream. As per UAC2 Audio Data Formats spec (2.3.1.1 USB Packets), if the sampling rate is a constant, the allowable variation of number of audio slots per virtual frame is +/- 1 audio slot. It means that endpoint should be able to accept/send +1 audio slot. Previous endpoint max_packet_size calculation code was adding sometimes +1 audio slot due to DIV_ROUND_UP behaviour which was rounding up to closest integer. However this doesn't work if the numbers are divisible. It had no any impact with Linux hosts which ignore this issue, but in case of more strict Windows it caused rejected enumeration Thus always add +1 audio slot to endpoint's max packet size Fixes: 913e4a90b6f9 ("usb: gadget: f_uac2: finalize wMaxPacketSize according to bandwidth") Cc: Peter Chen Cc: #v4.3+ Signed-off-by: Ruslan Bilovol Link: https://lore.kernel.org/r/1614599375-8803-2-git-send-email-ruslan.bilovol@gmail.com Signed-off-by: Greg Kroah-Hartman commit ec7b0ac6653927fd4f85e744e330d9d93208ee55 Author: Dan Carpenter Date: Mon Feb 15 15:57:16 2021 +0000 USB: gadget: u_ether: Fix a configfs return code commit 650bf52208d804ad5ee449c58102f8dc43175573 upstream. If the string is invalid, this should return -EINVAL instead of 0. Fixes: 73517cf49bd4 ("usb: gadget: add RNDIS configfs options for class/subclass/protocol") Cc: stable Acked-by: Lorenzo Colitti Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/YCqZ3P53yyIg5cn7@mwanda Signed-off-by: Greg Kroah-Hartman commit 0ae3101f5cf03a7fc2d138d5d54f37bc894b5305 Author: Yorick de Wid Date: Sat Feb 13 15:49:02 2021 +0100 Goodix Fingerprint device is not a modem commit 4d8654e81db7346f915eca9f1aff18f385cab621 upstream. The CDC ACM driver is false matching the Goodix Fingerprint device against the USB_CDC_ACM_PROTO_AT_V25TER. The Goodix Fingerprint device is a biometrics sensor that should be handled in user-space. libfprint has some support for Goodix fingerprint sensors, although not for this particular one. It is possible that the vendor allocates a PID per OEM (Lenovo, Dell etc). If this happens to be the case then more devices from the same vendor could potentially match the ACM modem module table. Signed-off-by: Yorick de Wid Cc: stable Link: https://lore.kernel.org/r/20210213144901.53199-1-ydewid@gmail.com Signed-off-by: Greg Kroah-Hartman commit b0ea155fa4f70731fc2be599d2404acfe73e98d2 Author: Frank Li Date: Wed Mar 3 11:42:48 2021 -0600 mmc: cqhci: Fix random crash when remove mmc module/card commit f06391c45e83f9a731045deb23df7cc3814fd795 upstream. [ 6684.493350] Unable to handle kernel paging request at virtual address ffff800011c5b0f0 [ 6684.498531] mmc0: card 0001 removed [ 6684.501556] Mem abort info: [ 6684.509681] ESR = 0x96000047 [ 6684.512786] EC = 0x25: DABT (current EL), IL = 32 bits [ 6684.518394] SET = 0, FnV = 0 [ 6684.521707] EA = 0, S1PTW = 0 [ 6684.524998] Data abort info: [ 6684.528236] ISV = 0, ISS = 0x00000047 [ 6684.532986] CM = 0, WnR = 1 [ 6684.536129] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000081b22000 [ 6684.543923] [ffff800011c5b0f0] pgd=00000000bffff003, p4d=00000000bffff003, pud=00000000bfffe003, pmd=00000000900e1003, pte=0000000000000000 [ 6684.557915] Internal error: Oops: 96000047 [#1] PREEMPT SMP [ 6684.564240] Modules linked in: sdhci_esdhc_imx(-) sdhci_pltfm sdhci cqhci mmc_block mmc_core fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine rng_core authenc libdes crct10dif_ce flexcan can_dev caam error [last unloaded: mmc_core] [ 6684.587281] CPU: 0 PID: 79138 Comm: kworker/0:3H Not tainted 5.10.9-01410-g3ba33182767b-dirty #10 [ 6684.596160] Hardware name: Freescale i.MX8DXL EVK (DT) [ 6684.601320] Workqueue: kblockd blk_mq_run_work_fn [ 6684.606094] pstate: 40000005 (nZcv daif -PAN -UAO -TCO BTYPE=--) [ 6684.612286] pc : cqhci_request+0x148/0x4e8 [cqhci] ^GMessage from syslogd@ at Thu Jan 1 01:51:24 1970 ...[ 6684.617085] lr : cqhci_request+0x314/0x4e8 [cqhci] [ 6684.626734] sp : ffff80001243b9f0 [ 6684.630049] x29: ffff80001243b9f0 x28: ffff00002c3dd000 [ 6684.635367] x27: 0000000000000001 x26: 0000000000000001 [ 6684.640690] x25: ffff00002c451000 x24: 000000000000000f [ 6684.646007] x23: ffff000017e71c80 x22: ffff00002c451000 [ 6684.651326] x21: ffff00002c0f3550 x20: ffff00002c0f3550 [ 6684.656651] x19: ffff000017d46880 x18: ffff00002cea1500 [ 6684.661977] x17: 0000000000000000 x16: 0000000000000000 [ 6684.667294] x15: 000001ee628e3ed1 x14: 0000000000000278 [ 6684.672610] x13: 0000000000000001 x12: 0000000000000001 [ 6684.677927] x11: 0000000000000000 x10: 0000000000000000 [ 6684.683243] x9 : 000000000000002b x8 : 0000000000001000 [ 6684.688560] x7 : 0000000000000010 x6 : ffff00002c0f3678 [ 6684.693886] x5 : 000000000000000f x4 : ffff800011c5b000 [ 6684.699211] x3 : 000000000002d988 x2 : 0000000000000008 [ 6684.704537] x1 : 00000000000000f0 x0 : 0002d9880008102f [ 6684.709854] Call trace: [ 6684.712313] cqhci_request+0x148/0x4e8 [cqhci] [ 6684.716803] mmc_cqe_start_req+0x58/0x68 [mmc_core] [ 6684.721698] mmc_blk_mq_issue_rq+0x460/0x810 [mmc_block] [ 6684.727018] mmc_mq_queue_rq+0x118/0x2b0 [mmc_block] The problem occurs when cqhci_request() get called after cqhci_disable() as it leads to access of allocated memory that has already been freed. Let's fix the problem by calling cqhci_disable() a bit later in the remove path. Signed-off-by: Frank Li Diagnosed-by: Adrian Hunter Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/20210303174248.542175-1-Frank.Li@nxp.com Fixes: f690f4409ddd ("mmc: mmc: Enable CQE's") Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 61fadd5f1e4e902b3bd136fcb1b37b79bba721c3 Author: Adrian Hunter Date: Wed Mar 3 11:26:14 2021 +0200 mmc: core: Fix partition switch time for eMMC commit 66fbacccbab91e6e55d9c8f1fc0910a8eb6c81f7 upstream. Avoid the following warning by always defining partition switch time: [ 3.209874] mmc1: unspecified timeout for CMD6 - use generic [ 3.222780] ------------[ cut here ]------------ [ 3.233363] WARNING: CPU: 1 PID: 111 at drivers/mmc/core/mmc_ops.c:575 __mmc_switch+0x200/0x204 Reported-by: Paul Fertser Fixes: 1c447116d017 ("mmc: mmc: Fix partition switch timeout for some eMMCs") Signed-off-by: Adrian Hunter Link: https://lore.kernel.org/r/168bbfd6-0c5b-5ace-ab41-402e7937c46e@intel.com Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 1cb73c82622cced3bec33f54fcb2c8ec242363bd Author: Heikki Krogerus Date: Mon Mar 1 17:30:11 2021 +0300 software node: Fix node registration commit 8891123f9cbb9c1ee531e5a87fa116f0af685c48 upstream. Software node can not be registered before its parent. Fixes: 80488a6b1d3c ("software node: Add support for static node descriptors") Cc: 5.10+ # 5.10+ Signed-off-by: Heikki Krogerus Reviewed-by: Andy Shevchenko Tested-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 3bc266631a9ef92b070383c83de9cc2374ea3201 Author: Stefan Haberland Date: Fri Mar 5 13:54:39 2021 +0100 s390/dasd: fix hanging IO request during DASD driver unbind commit 66f669a272898feb1c69b770e1504aa2ec7723d1 upstream. Prevent that an IO request is build during device shutdown initiated by a driver unbind. This request will never be able to be processed or canceled and will hang forever. This will lead also to a hanging unbind. Fix by checking not only if the device is in READY state but also check that there is no device offline initiated before building a new IO request. Fixes: e443343e509a ("s390/dasd: blk-mq conversion") Cc: # v4.14+ Signed-off-by: Stefan Haberland Tested-by: Bjoern Walk Reviewed-by: Jan Hoeppner Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 87adc240df30bae71068ee7813b59adad922e0eb Author: Stefan Haberland Date: Fri Mar 5 13:54:38 2021 +0100 s390/dasd: fix hanging DASD driver unbind commit 7d365bd0bff3c0310c39ebaffc9a8458e036d666 upstream. In case of an unbind of the DASD device driver the function dasd_generic_remove() is called which shuts down the device. Among others this functions removes the int_handler from the cdev. During shutdown the device cancels all outstanding IO requests and waits for completion of the clear request. Unfortunately the clear interrupt will never be received when there is no interrupt handler connected. Fix by moving the int_handler removal after the call to the state machine where no request or interrupt is outstanding. Cc: stable@vger.kernel.org Signed-off-by: Stefan Haberland Tested-by: Bjoern Walk Reviewed-by: Jan Hoeppner Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 12002aa2e7af76aeb234e0a0189dbaa0406b07f7 Author: Andrey Konovalov Date: Mon Mar 8 17:10:23 2021 +0100 arm64: kasan: fix page_alloc tagging with DEBUG_VIRTUAL commit 86c83365ab76e4b43cedd3ce07a07d32a4dc79ba upstream. When CONFIG_DEBUG_VIRTUAL is enabled, the default page_to_virt() macro implementation from include/linux/mm.h is used. That definition doesn't account for KASAN tags, which leads to no tags on page_alloc allocations. Provide an arm64-specific definition for page_to_virt() when CONFIG_DEBUG_VIRTUAL is enabled that takes care of KASAN tags. Fixes: 2813b9c02962 ("kasan, mm, arm64: tag non slab memory allocated via pagealloc") Cc: Signed-off-by: Andrey Konovalov Reviewed-by: Catalin Marinas Link: https://lore.kernel.org/r/4b55b35202706223d3118230701c6a59749d9b72.1615219501.git.andreyknvl@google.com Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 47a5d1b63f212c7310ce1612caa76964c3f4e681 Author: Eric W. Biederman Date: Fri Mar 12 15:07:09 2021 -0600 Revert 95ebabde382c ("capabilities: Don't allow writing ambiguous v3 file capabilities") commit 3b0c2d3eaa83da259d7726192cf55a137769012f upstream. It turns out that there are in fact userspace implementations that care and this recent change caused a regression. https://github.com/containers/buildah/issues/3071 As the motivation for the original change was future development, and the impact is existing real world code just revert this change and allow the ambiguity in v3 file caps. Cc: stable@vger.kernel.org Fixes: 95ebabde382c ("capabilities: Don't allow writing ambiguous v3 file capabilities") Signed-off-by: Eric W. Biederman Signed-off-by: Greg Kroah-Hartman commit ac85e7d4abb10a54d59fa3de8eaa91c1de026397 Author: Takashi Iwai Date: Thu Mar 4 09:50:09 2021 +0100 ALSA: usb-audio: Apply the control quirk to Plantronics headsets commit 06abcb18b3a021ba1a3f2020cbefb3ed04e59e72 upstream. Other Plantronics headset models seem requiring the same workaround as C320-M to add the 20ms delay for the control messages, too. Apply the workaround generically for devices with the vendor ID 0x047f. Note that the problem didn't surface before 5.11 just with luck. Since 5.11 got a big code rewrite about the stream handling, the parameter setup procedure has changed, and this seemed triggering the problem more often. BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1182552 Cc: Link: https://lore.kernel.org/r/20210304085009.4770-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b1fe755e51df3dfd7ec7241cd35d1c3cffce283a Author: Takashi Iwai Date: Thu Mar 4 09:30:21 2021 +0100 ALSA: usb-audio: Fix "cannot get freq eq" errors on Dell AE515 sound bar commit fec60c3bc5d1713db2727cdffc638d48f9c07dc3 upstream. Dell AE515 sound bar (413c:a506) spews the error messages when the driver tries to read the current sample frequency, hence it needs to be on the list in snd_usb_get_sample_rate_quirk(). BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211551 Cc: Link: https://lore.kernel.org/r/20210304083021.2152-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2b7615c97b0e6ef89eb19c7ca493a04e7da618eb Author: Takashi Iwai Date: Wed Mar 10 12:28:08 2021 +0100 ALSA: hda: Avoid spurious unsol event handling during S3/S4 commit 5ff9dde42e8c72ed8102eb8cb62e03f9dc2103ab upstream. When HD-audio bus receives unsolicited events during its system suspend/resume (S3 and S4) phase, the controller driver may still try to process events although the codec chips are already (or yet) powered down. This might screw up the codec communication, resulting in CORB/RIRB errors. Such events should be rather skipped, as the codec chip status such as the jack status will be fully refreshed at the system resume time. Since we're tracking the system suspend/resume state in codec power.power_state field, let's add the check in the common unsol event handler entry point to filter out such events. BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1182377 Tested-by: Abhishek Sahu Cc: # 183ab39eb0ea: ALSA: hda: Initialize power_state Link: https://lore.kernel.org/r/20210310112809.9215-3-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit bb060148e29f19b151bb49bf126cd4f86890791b Author: Takashi Iwai Date: Wed Mar 10 12:28:07 2021 +0100 ALSA: hda: Flush pending unsolicited events before suspend commit 13661fc48461282e43fe8f76bf5bf449b3d40687 upstream. The HD-audio controller driver processes the unsolicited events via its work asynchronously, and this might be pending when the system goes to suspend. When a lengthy event handling like ELD byte reads is running, this might trigger unexpected accesses among suspend/resume procedure, typically seen with Nvidia driver that still requires the handling via unsolicited event verbs for ELD updates. This patch adds the flush of unsol_work to assure that pending events are processed before going into suspend. Buglink: https://bugzilla.suse.com/show_bug.cgi?id=1182377 Reported-and-tested-by: Abhishek Sahu Cc: Link: https://lore.kernel.org/r/20210310112809.9215-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 09cb42025a462f4c33c364bf7799fa38990c57e8 Author: Takashi Iwai Date: Mon Mar 8 17:07:26 2021 +0100 ALSA: hda: Drop the BATCH workaround for AMD controllers commit 28e96c1693ec1cdc963807611f8b5ad400431e82 upstream. The commit c02f77d32d2c ("ALSA: hda - Workaround for crackled sound on AMD controller (1022:1457)") introduced a few workarounds for the recent AMD HD-audio controller, and one of them is the forced BATCH PCM mode so that PulseAudio avoids the timer-based scheduling. This was thought to cover for some badly working applications, but this actually worsens for more others. In total, this wasn't a good idea to enforce it. This is a partial revert of the commit above for dropping the PCM BATCH enforcement part to recover from the regression again. Fixes: c02f77d32d2c ("ALSA: hda - Workaround for crackled sound on AMD controller (1022:1457)") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195303 Cc: Link: https://lore.kernel.org/r/20210308160726.22930-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e1a92ad57b2c876c28aacae04e83fb685d9572d7 Author: Simeon Simeonoff Date: Mon Mar 8 20:48:35 2021 +0200 ALSA: hda/ca0132: Add Sound BlasterX AE-5 Plus support commit f15c5c11abfbf8909eb30598315ecbec2311cfdc upstream. The new AE-5 Plus model has a different Subsystem ID compared to the non-plus model. Adding the new id to the list of quirks. Signed-off-by: Simeon Simeonoff Cc: Link: https://lore.kernel.org/r/998cafbe10b648f724ee33570553f2d780a38963.camel@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ff2152beb22cfeee6189ecd1e5ed100e7d96b5c1 Author: Takashi Iwai Date: Wed Mar 10 12:28:09 2021 +0100 ALSA: hda/hdmi: Cancel pending works before suspend commit eea46a0879bcca23e15071f9968c0f6e6596e470 upstream. The per_pin->work might be still floating at the suspend, and this may hit the access to the hardware at an unexpected timing. Cancel the work properly at the suspend callback for avoiding the buggy access. Note that the bug doesn't trigger easily in the recent kernels since the work is queued only when the repoll count is set, and usually it's only at the resume callback, but it's still possible to hit in theory. BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1182377 Reported-and-tested-by: Abhishek Sahu Cc: Link: https://lore.kernel.org/r/20210310112809.9215-4-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit dd6d483104bf576174a6a5ed7e46b4a84d6ad40f Author: John Ernberg Date: Wed Mar 3 18:14:39 2021 +0000 ALSA: usb: Add Plantronics C320-M USB ctrl msg delay quirk commit fc7c5c208eb7bc2df3a9f4234f14eca250001cb6 upstream. The microphone in the Plantronics C320-M headset will randomly fail to initialize properly, at least when using Microsoft Teams. Introducing a 20ms delay on the control messages appears to resolve the issue. Link: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/1065 Tested-by: Andreas Kempe Signed-off-by: John Ernberg Cc: Link: https://lore.kernel.org/r/20210303181405.39835-1-john.ernberg@actia.se Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 300fba2b4e11773d85e202636c46f2d645d561b4 Author: Aleksandr Miloserdov Date: Tue Feb 9 10:22:02 2021 +0300 scsi: target: core: Prevent underflow for service actions [ Upstream commit 14d24e2cc77411301e906a8cf41884739de192de ] TCM buffer length doesn't necessarily equal 8 + ADDITIONAL LENGTH which might be considered an underflow in case of Data-In size being greater than 8 + ADDITIONAL LENGTH. So truncate buffer length to prevent underflow. Link: https://lore.kernel.org/r/20210209072202.41154-3-a.miloserdov@yadro.com Reviewed-by: Roman Bolshakov Reviewed-by: Bodo Stroesser Signed-off-by: Aleksandr Miloserdov Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit de2cdbcb4f38df2976b0023e08f59b1a9aa21ab6 Author: Aleksandr Miloserdov Date: Tue Feb 9 10:22:01 2021 +0300 scsi: target: core: Add cmd length set before cmd complete [ Upstream commit 1c73e0c5e54d5f7d77f422a10b03ebe61eaed5ad ] TCM doesn't properly handle underflow case for service actions. One way to prevent it is to always complete command with target_complete_cmd_with_length(), however it requires access to data_sg, which is not always available. This change introduces target_set_cmd_data_length() function which allows to set command data length before completing it. Link: https://lore.kernel.org/r/20210209072202.41154-2-a.miloserdov@yadro.com Reviewed-by: Roman Bolshakov Reviewed-by: Bodo Stroesser Signed-off-by: Aleksandr Miloserdov Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 050e1900d6176ff7f23263151136cf1e68010a80 Author: Mike Christie Date: Sat Feb 6 22:46:00 2021 -0600 scsi: libiscsi: Fix iscsi_prep_scsi_cmd_pdu() error handling [ Upstream commit d28d48c699779973ab9a3bd0e5acfa112bd4fdef ] If iscsi_prep_scsi_cmd_pdu() fails we try to add it back to the cmdqueue, but we leave it partially setup. We don't have functions that can undo the pdu and init task setup. We only have cleanup_task which can clean up both parts. So this has us just fail the cmd and go through the standard cleanup routine and then have the SCSI midlayer retry it like is done when it fails in the queuecommand path. Link: https://lore.kernel.org/r/20210207044608.27585-2-michael.christie@oracle.com Reviewed-by: Lee Duncan Signed-off-by: Mike Christie Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit acf0e7b15f87bde54a9fa2ff60b8f3fa5c136be3 Author: Lin Feng Date: Thu Feb 25 17:20:53 2021 -0800 sysctl.c: fix underflow value setting risk in vm_table [ Upstream commit 3b3376f222e3ab58367d9dd405cafd09d5e37b7c ] Apart from subsystem specific .proc_handler handler, all ctl_tables with extra1 and extra2 members set should use proc_dointvec_minmax instead of proc_dointvec, or the limit set in extra* never work and potentially echo underflow values(negative numbers) is likely make system unstable. Especially vfs_cache_pressure and zone_reclaim_mode, -1 is apparently not a valid value, but we can set to them. And then kernel may crash. # echo -1 > /proc/sys/vm/vfs_cache_pressure Link: https://lkml.kernel.org/r/20201223105535.2875-1-linf@wangsu.com Signed-off-by: Lin Feng Cc: Alexey Dobriyan Cc: "Eric W. Biederman" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 508d56e2c5c3241dca0a9e892a42f05c7b4df07f Author: Heiko Carstens Date: Wed Feb 17 07:13:02 2021 +0100 s390/smp: __smp_rescan_cpus() - move cpumask away from stack [ Upstream commit 62c8dca9e194326802b43c60763f856d782b225c ] Avoid a potentially large stack frame and overflow by making "cpumask_t avail" a static variable. There is no concurrent access due to the existing locking. Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 54fc6a56f72abe8bdcf9e8ed55f2e03cf93fb863 Author: Keita Suzuki Date: Fri Oct 30 07:14:30 2020 +0000 i40e: Fix memory leak in i40e_probe [ Upstream commit 58cab46c622d6324e47bd1c533693c94498e4172 ] Struct i40e_veb is allocated in function i40e_setup_pf_switch, and stored to an array field veb inside struct i40e_pf. However when i40e_setup_misc_vector fails, this memory leaks. Fix this by calling exit and teardown functions. Signed-off-by: Keita Suzuki Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit f95403013744a774b482430e165151b005bc7e13 Author: Geert Uytterhoeven Date: Tue Feb 2 11:03:32 2021 +0100 PCI: Fix pci_register_io_range() memory leak [ Upstream commit f6bda644fa3a7070621c3bf12cd657f69a42f170 ] Kmemleak reports: unreferenced object 0xc328de40 (size 64): comm "kworker/1:1", pid 21, jiffies 4294938212 (age 1484.670s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 e0 d8 fc eb 00 00 00 00 ................ 00 00 10 fe 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] pci_register_io_range+0x3c/0x80 [<2c7f139e>] of_pci_range_to_resource+0x48/0xc0 [] devm_of_pci_get_host_bridge_resources.constprop.0+0x2ac/0x3ac [] devm_of_pci_bridge_init+0x60/0x1b8 [] devm_pci_alloc_host_bridge+0x54/0x64 [] rcar_pcie_probe+0x2c/0x644 In case a PCI host driver's probe is deferred, the same I/O range may be allocated again, and be ignored, causing a memory leak. Fix this by (a) letting logic_pio_register_range() return -EEXIST if the passed range already exists, so pci_register_io_range() will free it, and by (b) making pci_register_io_range() not consider -EEXIST an error condition. Link: https://lore.kernel.org/r/20210202100332.829047-1-geert+renesas@glider.be Signed-off-by: Geert Uytterhoeven Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit e9be5518af2c1cd110824bd8b3327aedd9a80104 Author: Sasha Levin Date: Fri Feb 5 22:50:32 2021 -0500 kbuild: clamp SUBLEVEL to 255 [ Upstream commit 9b82f13e7ef316cdc0a8858f1349f4defce3f9e0 ] Right now if SUBLEVEL becomes larger than 255 it will overflow into the territory of PATCHLEVEL, causing havoc in userspace that tests for specific kernel version. While userspace code tests for MAJOR and PATCHLEVEL, it doesn't test SUBLEVEL at any point as ABI changes don't happen in the context of stable tree. Thus, to avoid overflows, simply clamp SUBLEVEL to it's maximum value in the context of LINUX_VERSION_CODE. This does not affect "make kernelversion" and such. Signed-off-by: Sasha Levin Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit e622e01d44e4fb17a8eb21e5d791400ae789674e Author: Krzysztof Wilczyński Date: Wed Jan 20 18:48:10 2021 +0000 PCI: mediatek: Add missing of_node_put() to fix reference leak [ Upstream commit 42814c438aac79746d310f413a27d5b0b959c5de ] The for_each_available_child_of_node helper internally makes use of the of_get_next_available_child() which performs an of_node_get() on each iteration when searching for next available child node. Should an available child node be found, then it would return a device node pointer with reference count incremented, thus early return from the middle of the loop requires an explicit of_node_put() to prevent reference count leak. To stop the reference leak, explicitly call of_node_put() before returning after an error occurred. Link: https://lore.kernel.org/r/20210120184810.3068794-1-kw@linux.com Signed-off-by: Krzysztof Wilczyński Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin commit d54c77959eceb3704067d874ac64ed660e765ae7 Author: Martin Kaiser Date: Fri Jan 15 22:24:35 2021 +0100 PCI: xgene-msi: Fix race in installing chained irq handler [ Upstream commit a93c00e5f975f23592895b7e83f35de2d36b7633 ] Fix a race where a pending interrupt could be received and the handler called before the handler's data has been setup, by converting to irq_set_chained_handler_and_data(). See also 2cf5a03cb29d ("PCI/keystone: Fix race in installing chained IRQ handler"). Based on the mail discussion, it seems ok to drop the error handling. Link: https://lore.kernel.org/r/20210115212435.19940-3-martin@kaiser.cx Signed-off-by: Martin Kaiser Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin commit 395f24b37fe872260a8d0f3bf4bbd9e86aefe917 Author: Ronald Tschalär Date: Fri Feb 19 11:10:51 2021 -0800 Input: applespi - don't wait for responses to commands indefinitely. [ Upstream commit 0ce1ac23149c6da939a5926c098c270c58c317a0 ] The response to a command may never arrive or it may be corrupted (and hence dropped) for some reason. While exceedingly rare, when it did happen it blocked all further commands. One way to fix this was to do a suspend/resume. However, recovering automatically seems like a nicer option. Hence this puts a time limit (1 sec) on how long we're willing to wait for a response, after which we assume it got lost. Signed-off-by: Ronald Tschalär Link: https://lore.kernel.org/r/20210217190718.11035-1-ronald@innovation.ch Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit ad93777a59c74c0de4d8113c9eb3046647347f98 Author: Khalid Aziz Date: Fri Oct 23 11:56:11 2020 -0600 sparc64: Use arch_validate_flags() to validate ADI flag [ Upstream commit 147d8622f2a26ef34beacc60e1ed8b66c2fa457f ] When userspace calls mprotect() to enable ADI on an address range, do_mprotect_pkey() calls arch_validate_prot() to validate new protection flags. arch_validate_prot() for sparc looks at the first VMA associated with address range to verify if ADI can indeed be enabled on this address range. This has two issues - (1) Address range might cover multiple VMAs while arch_validate_prot() looks at only the first VMA, (2) arch_validate_prot() peeks at VMA without holding mmap lock which can result in race condition. arch_validate_flags() from commit c462ac288f2c ("mm: Introduce arch_validate_flags()") allows for VMA flags to be validated for all VMAs that cover the address range given by user while holding mmap lock. This patch updates sparc code to move the VMA check from arch_validate_prot() to arch_validate_flags() to fix above two issues. Suggested-by: Jann Horn Suggested-by: Christoph Hellwig Suggested-by: Catalin Marinas Signed-off-by: Khalid Aziz Reviewed-by: Catalin Marinas Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit dec0ab3bc3a26685872963534d422ac0258e4e2b Author: Andreas Larsson Date: Fri Feb 5 14:20:31 2021 +0100 sparc32: Limit memblock allocation to low memory [ Upstream commit bda166930c37604ffa93f2425426af6921ec575a ] Commit cca079ef8ac29a7c02192d2bad2ffe4c0c5ffdd0 changed sparc32 to use memblocks instead of bootmem, but also made high memory available via memblock allocation which does not work together with e.g. phys_to_virt and can lead to kernel panic. This changes back to only low memory being allocatable in the early stages, now using memblock allocation. Signed-off-by: Andreas Larsson Acked-by: Mike Rapoport Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f8788ee8544c55a6f9cb605d9dbaa8602bf7d8c7 Author: Suravee Suthikulpanit Date: Mon Feb 8 06:27:12 2021 -0600 iommu/amd: Fix performance counter initialization [ Upstream commit 6778ff5b21bd8e78c8bd547fd66437cf2657fd9b ] Certain AMD platforms enable power gating feature for IOMMU PMC, which prevents the IOMMU driver from updating the counter while trying to validate the PMC functionality in the init_iommu_perf_ctr(). This results in disabling PMC support and the following error message: "AMD-Vi: Unable to read/write to IOMMU perf counter" To workaround this issue, disable power gating temporarily by programming the counter source to non-zero value while validating the counter, and restore the prior state afterward. Signed-off-by: Suravee Suthikulpanit Tested-by: Tj (Elloe Linux) Link: https://lore.kernel.org/r/20210208122712.5048-1-suravee.suthikulpanit@amd.com Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201753 Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit d92afe30a665ce6a3cfd950d5d67ce30cdf682fd Author: Michael Ellerman Date: Wed Feb 10 00:59:20 2021 +1100 powerpc/64: Fix stack trace not displaying final frame [ Upstream commit e3de1e291fa58a1ab0f471a4b458eff2514e4b5f ] In commit bf13718bc57a ("powerpc: show registers when unwinding interrupt frames") we changed our stack dumping logic to show the full registers whenever we find an interrupt frame on the stack. However we didn't notice that on 64-bit this doesn't show the final frame, ie. the interrupt that brought us in from userspace, whereas on 32-bit it does. That is due to confusion about the size of that last frame. The code in show_stack() calls validate_sp(), passing it STACK_INT_FRAME_SIZE to check the sp is at least that far below the top of the stack. However on 64-bit that size is too large for the final frame, because it includes the red zone, but we don't allocate a red zone for the first frame. So add a new define that encodes the correct size for 32-bit and 64-bit, and use it in show_stack(). This results in the full trace being shown on 64-bit, eg: sysrq: Trigger a crash Kernel panic - not syncing: sysrq triggered crash CPU: 0 PID: 83 Comm: sh Not tainted 5.11.0-rc2-gcc-8.2.0-00188-g571abcb96b10-dirty #649 Call Trace: [c00000000a1c3ac0] [c000000000897b70] dump_stack+0xc4/0x114 (unreliable) [c00000000a1c3b00] [c00000000014334c] panic+0x178/0x41c [c00000000a1c3ba0] [c00000000094e600] sysrq_handle_crash+0x40/0x50 [c00000000a1c3c00] [c00000000094ef98] __handle_sysrq+0xd8/0x210 [c00000000a1c3ca0] [c00000000094f820] write_sysrq_trigger+0x100/0x188 [c00000000a1c3ce0] [c0000000005559dc] proc_reg_write+0x10c/0x1b0 [c00000000a1c3d10] [c000000000479950] vfs_write+0xf0/0x360 [c00000000a1c3d60] [c000000000479d9c] ksys_write+0x7c/0x140 [c00000000a1c3db0] [c00000000002bf5c] system_call_exception+0x19c/0x2c0 [c00000000a1c3e10] [c00000000000d35c] system_call_common+0xec/0x278 --- interrupt: c00 at 0x7fff9fbab428 NIP: 00007fff9fbab428 LR: 000000001000b724 CTR: 0000000000000000 REGS: c00000000a1c3e80 TRAP: 0c00 Not tainted (5.11.0-rc2-gcc-8.2.0-00188-g571abcb96b10-dirty) MSR: 900000000280f033 CR: 22002884 XER: 00000000 IRQMASK: 0 GPR00: 0000000000000004 00007fffc3cb8960 00007fff9fc59900 0000000000000001 GPR04: 000000002a4b32d0 0000000000000002 0000000000000063 0000000000000063 GPR08: 000000002a4b32d0 0000000000000000 0000000000000000 0000000000000000 GPR12: 0000000000000000 00007fff9fcca9a0 0000000000000000 0000000000000000 GPR16: 0000000000000000 0000000000000000 0000000000000000 00000000100b8fd0 GPR20: 000000002a4b3485 00000000100b8f90 0000000000000000 0000000000000000 GPR24: 000000002a4b0440 00000000100e77b8 0000000000000020 000000002a4b32d0 GPR28: 0000000000000001 0000000000000002 000000002a4b32d0 0000000000000001 NIP [00007fff9fbab428] 0x7fff9fbab428 LR [000000001000b724] 0x1000b724 --- interrupt: c00 Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210209141627.2898485-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit 61654b5d079dd268e4ac217fb5590a27e47c5ab5 Author: Filipe Laíns Date: Sat Jan 23 18:02:20 2021 +0000 HID: logitech-dj: add support for the new lightspeed connection iteration [ Upstream commit fab3a95654eea01d6b0204995be8b7492a00d001 ] This new connection type is the new iteration of the Lightspeed connection and will probably be used in some of the newer gaming devices. It is currently use in the G Pro X Superlight. This patch should be backported to older versions, as currently the driver will panic when seing the unsupported connection. This isn't an issue when using the receiver that came with the device, as Logitech has been using different PIDs when they change the connection type, but is an issue when using a generic receiver (well, generic Lightspeed receiver), which is the case of the one in the Powerplay mat. Currently, the only generic Ligthspeed receiver we support, and the only one that exists AFAIK, is ther Powerplay. As it stands, the driver will panic when seeing a G Pro X Superlight connected to the Powerplay receiver and won't send any input events to userspace! The kernel will warn about this so the issue should be easy to identify, but it is still very worrying how hard it will fail :( [915977.398471] logitech-djreceiver 0003:046D:C53A.0107: unusable device of type UNKNOWN (0x0f) connected on slot 1 Signed-off-by: Filipe Laíns Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 49e38713faafb204309de8a3d9e16db39af15e1f Author: Athira Rajeev Date: Fri Feb 5 04:14:52 2021 -0500 powerpc/perf: Record counter overflow always if SAMPLE_IP is unset [ Upstream commit d137845c973147a22622cc76c7b0bc16f6206323 ] While sampling for marked events, currently we record the sample only if the SIAR valid bit of Sampled Instruction Event Register (SIER) is set. SIAR_VALID bit is used for fetching the instruction address from Sampled Instruction Address Register(SIAR). But there are some usecases, where the user is interested only in the PMU stats at each counter overflow and the exact IP of the overflow event is not required. Dropping SIAR invalid samples will fail to record some of the counter overflows in such cases. Example of such usecase is dumping the PMU stats (event counts) after some regular amount of instructions/events from the userspace (ex: via ptrace). Here counter overflow is indicated to userspace via signal handler, and captured by monitoring and enabling I/O signaling on the event file descriptor. In these cases, we expect to get sample/overflow indication after each specified sample_period. Perf event attribute will not have PERF_SAMPLE_IP set in the sample_type if exact IP of the overflow event is not requested. So while profiling if SAMPLE_IP is not set, just record the counter overflow irrespective of SIAR_VALID check. Suggested-by: Michael Ellerman Signed-off-by: Athira Rajeev [mpe: Reflow comment and if formatting] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/1612516492-1428-1-git-send-email-atrajeev@linux.vnet.ibm.com Signed-off-by: Sasha Levin commit a54c278fcf8bce6b0e58af110dc5254f323a898f Author: Nicholas Piggin Date: Sat Jan 30 23:08:35 2021 +1000 powerpc: improve handling of unrecoverable system reset [ Upstream commit 11cb0a25f71818ca7ab4856548ecfd83c169aa4d ] If an unrecoverable system reset hits in process context, the system does not have to panic. Similar to machine check, call nmi_exit() before die(). Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210130130852.2952424-26-npiggin@gmail.com Signed-off-by: Sasha Levin commit 7765b5c2c192ecf73d045b6a8093e3dd95e8d6ea Author: Alain Volmat Date: Fri Feb 5 19:59:32 2021 +0100 spi: stm32: make spurious and overrun interrupts visible [ Upstream commit c64e7efe46b7de21937ef4b3594d9b1fc74f07df ] We do not expect to receive spurious interrupts so rise a warning if it happens. RX overrun is an error condition that signals a corrupted RX stream both in dma and in irq modes. Report the error and abort the transfer in either cases. Signed-off-by: Alain Volmat Link: https://lore.kernel.org/r/1612551572-495-9-git-send-email-alain.volmat@foss.st.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 507b9bce21135bfedc43fac7c72335b631cb5598 Author: Oliver O'Halloran Date: Tue Nov 3 15:35:06 2020 +1100 powerpc/pci: Add ppc_md.discover_phbs() [ Upstream commit 5537fcb319d016ce387f818dd774179bc03217f5 ] On many powerpc platforms the discovery and initalisation of pci_controllers (PHBs) happens inside of setup_arch(). This is very early in boot (pre-initcalls) and means that we're initialising the PHB long before many basic kernel services (slab allocator, debugfs, a real ioremap) are available. On PowerNV this causes an additional problem since we map the PHB registers with ioremap(). As of commit d538aadc2718 ("powerpc/ioremap: warn on early use of ioremap()") a warning is printed because we're using the "incorrect" API to setup and MMIO mapping in searly boot. The kernel does provide early_ioremap(), but that is not intended to create long-lived MMIO mappings and a seperate warning is printed by generic code if early_ioremap() mappings are "leaked." This is all fixable with dumb hacks like using early_ioremap() to setup the initial mapping then replacing it with a real ioremap later on in boot, but it does raise the question: Why the hell are we setting up the PHB's this early in boot? The old and wise claim it's due to "hysterical rasins." Aside from amused grapes there doesn't appear to be any real reason to maintain the current behaviour. Already most of the newer embedded platforms perform PHB discovery in an arch_initcall and between the end of setup_arch() and the start of initcalls none of the generic kernel code does anything PCI related. On powerpc scanning PHBs occurs in a subsys_initcall so it should be possible to move the PHB discovery to a core, postcore or arch initcall. This patch adds the ppc_md.discover_phbs hook and a core_initcall stub that calls it. The core_initcalls are the earliest to be called so this will any possibly issues with dependency between initcalls. This isn't just an academic issue either since on pseries and PowerNV EEH init occurs in an arch_initcall and depends on the pci_controllers being available, similarly the creation of pci_dns occurs at core_initcall_sync (i.e. between core and postcore initcalls). These problems need to be addressed seperately. Reported-by: kernel test robot Signed-off-by: Oliver O'Halloran [mpe: Make discover_phbs() static] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20201103043523.916109-1-oohall@gmail.com Signed-off-by: Sasha Levin commit 26d60799d99b1078157f888d00604fe187e0af99 Author: Lubomir Rintel Date: Tue Jan 26 08:37:38 2021 +0100 Platform: OLPC: Fix probe error handling [ Upstream commit cec551ea0d41c679ed11d758e1a386e20285b29d ] Reset ec_priv if probe ends unsuccessfully. Signed-off-by: Lubomir Rintel Link: https://lore.kernel.org/r/20210126073740.10232-2-lkundrak@v3.sk Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit ccad3c70fcd0d40c164c6fa144552b56c478ad50 Author: Chaotian Jing Date: Fri Dec 18 15:16:11 2020 +0800 mmc: mediatek: fix race condition between msdc_request_timeout and irq [ Upstream commit 0354ca6edd464a2cf332f390581977b8699ed081 ] when get request SW timeout, if CMD/DAT xfer done irq coming right now, then there is race between the msdc_request_timeout work and irq handler, and the host->cmd and host->data may set to NULL in irq handler. also, current flow ensure that only one path can go to msdc_request_done(), so no need check the return value of cancel_delayed_work(). Signed-off-by: Chaotian Jing Link: https://lore.kernel.org/r/20201218071611.12276-1-chaotian.jing@mediatek.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit edf05afc9be307e020a56a064558831db404a3b1 Author: Christophe JAILLET Date: Tue Dec 8 21:35:27 2020 +0100 mmc: mxs-mmc: Fix a resource leak in an error handling path in 'mxs_mmc_probe()' [ Upstream commit 0bb7e560f821c7770973a94e346654c4bdccd42c ] If 'mmc_of_parse()' fails, we must undo the previous 'dma_request_chan()' call. Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/20201208203527.49262-1-christophe.jaillet@wanadoo.fr Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit c44d966e9020fbb535706e41639014cc9abe9c13 Author: Steven J. Magnani Date: Thu Jan 7 17:41:16 2021 -0600 udf: fix silent AED tagLocation corruption [ Upstream commit 63c9e47a1642fc817654a1bc18a6ec4bbcc0f056 ] When extending a file, udf_do_extend_file() may enter following empty indirect extent. At the end of udf_do_extend_file() we revert prev_epos to point to the last written extent. However if we end up not adding any further extent in udf_do_extend_file(), the reverting points prev_epos into the header area of the AED and following updates of the extents (in udf_update_extents()) will corrupt the header. Make sure that we do not follow indirect extent if we are not going to add any more extents so that returning back to the last written extent works correctly. Link: https://lore.kernel.org/r/20210107234116.6190-2-magnani@ieee.org Signed-off-by: Steven J. Magnani Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 5f04f970d579b11e11df9856944ddd4a4b2edb9a Author: Wolfram Sang Date: Wed Dec 23 18:21:52 2020 +0100 i2c: rcar: optimize cacheline to minimize HW race condition [ Upstream commit 25c2e0fb5fefb8d7847214cf114d94c7aad8e9ce ] 'flags' and 'io' are needed first, so they should be at the beginning of the private struct. Signed-off-by: Wolfram Sang Reviewed-by: Niklas Söderlund Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 1e1aace4a395e1d9cffc5e843cea06760dfc198e Author: Wolfram Sang Date: Wed Dec 23 18:21:51 2020 +0100 i2c: rcar: faster irq code to minimize HW race condition [ Upstream commit c7b514ec979e23a08c411f3d8ed39c7922751422 ] To avoid the HW race condition on R-Car Gen2 and earlier, we need to write to ICMCR as soon as possible in the interrupt handler. We can improve this by writing a static value instead of masking out bits. Signed-off-by: Wolfram Sang Reviewed-by: Niklas Söderlund Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 2e24fd30c6f00b155eda47265261bd44158892cb Author: Guangbin Huang Date: Sat Feb 27 11:05:58 2021 +0800 net: phy: fix save wrong speed and duplex problem if autoneg is on [ Upstream commit d9032dba5a2b2bbf0fdce67c8795300ec9923b43 ] If phy uses generic driver and autoneg is on, enter command "ethtool -s eth0 speed 50" will not change phy speed actually, but command "ethtool eth0" shows speed is 50Mb/s because phydev->speed has been set to 50 and no update later. And duplex setting has same problem too. However, if autoneg is on, phy only changes speed and duplex according to phydev->advertising, but not phydev->speed and phydev->duplex. So in this case, phydev->speed and phydev->duplex don't need to be set in function phy_ethtool_ksettings_set() if autoneg is on. Fixes: 51e2a3846eab ("PHY: Avoid unnecessary aneg restarts") Signed-off-by: Guangbin Huang Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit aea71e92b9a0e3f4722e60de16ba0e1c099d272b Author: Vladimir Oltean Date: Mon Mar 1 13:18:12 2021 +0200 net: enetc: initialize RFS/RSS memories for unused ports too [ Upstream commit 3222b5b613db558e9a494bbf53f3c984d90f71ea ] Michael reports that since linux-next-20210211, the AER messages for ECC errors have started reappearing, and this time they can be reliably reproduced with the first ping on one of his LS1028A boards. $ ping 1[ 33.258069] pcieport 0000:00:1f.0: AER: Multiple Corrected error received: 0000:00:00.0 72.16.0.1 PING [ 33.267050] pcieport 0000:00:1f.0: AER: can't find device of ID0000 172.16.0.1 (172.16.0.1): 56 data bytes 64 bytes from 172.16.0.1: seq=0 ttl=64 time=17.124 ms 64 bytes from 172.16.0.1: seq=1 ttl=64 time=0.273 ms $ devmem 0x1f8010e10 32 0xC0000006 It isn't clear why this is necessary, but it seems that for the errors to go away, we must clear the entire RFS and RSS memory, not just for the ports in use. Sadly the code is structured in such a way that we can't have unified logic for the used and unused ports. For the minimal initialization of an unused port, we need just to enable and ioremap the PF memory space, and a control buffer descriptor ring. Unused ports must then free the CBDR because the driver will exit, but used ports can not pick up from where that code path left, since the CBDR API does not reinitialize a ring when setting it up, so its producer and consumer indices are out of sync between the software and hardware state. So a separate enetc_init_unused_port function was created, and it gets called right after the PF memory space is enabled. Fixes: 07bf34a50e32 ("net: enetc: initialize the RFS and RSS memories") Reported-by: Michael Walle Cc: Jesse Brandeburg Signed-off-by: Vladimir Oltean Tested-by: Michael Walle Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d1f308174a60ef4e454d42d021b1999faf937b0f Author: Jian Shen Date: Sat Feb 27 15:24:51 2021 +0800 net: hns3: fix error mask definition of flow director [ Upstream commit ae85ddda0f1b341b2d25f5a5e0eff1d42b6ef3df ] Currently, some bit filed definitions of flow director TCAM configuration command are incorrect. Since the wrong MSB is always 0, and these fields are assgined in order, so it still works. Fix it by redefine them. Fixes: 117328680288 ("net: hns3: Add input key and action config support for flow director") Signed-off-by: Jian Shen Signed-off-by: Huazhong Tan Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cb36bf447a0c2237e9d98ae71c38f6a15a06b9e6 Author: Hans Verkuil Date: Fri Feb 26 11:37:47 2021 +0100 media: rc: compile rc-cec.c into rc-core commit f09f9f93afad770a04b35235a0aa465fcc8d6e3d upstream. The rc-cec keymap is unusual in that it can't be built as a module, instead it is registered directly in rc-main.c if CONFIG_MEDIA_CEC_RC is set. This is because it can be called from drm_dp_cec_set_edid() via cec_register_adapter() in an asynchronous context, and it is not allowed to use request_module() to load rc-cec.ko in that case. Trying to do so results in a 'WARN_ON_ONCE(wait && current_is_async())'. Since this keymap is only used if CONFIG_MEDIA_CEC_RC is set, we just compile this keymap into the rc-core module and never as a separate module. Signed-off-by: Hans Verkuil Fixes: 2c6d1fffa1d9 (drm: add support for DisplayPort CEC-Tunneling-over-AUX) Reported-by: Hans de Goede Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 4c0c31572b67e2029b2abb83141ed3a3927b81eb Author: Biju Das Date: Mon Mar 1 13:08:27 2021 +0100 media: v4l: vsp1: Fix bru null pointer access commit ac8d82f586c8692b501cb974604a71ef0e22a04c upstream. RZ/G2L SoC has only BRS. This patch fixes null pointer access,when only BRS is enabled. Fixes: cbb7fa49c7466("media: v4l: vsp1: Rename BRU to BRx") Signed-off-by: Biju Das Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit f56a82844c1fc7ec5f01951c8c8a632fb4663ce0 Author: Biju Das Date: Mon Mar 1 13:08:28 2021 +0100 media: v4l: vsp1: Fix uif null pointer access commit 6732f313938027a910e1f7351951ff52c0329e70 upstream. RZ/G2L SoC has no UIF. This patch fixes null pointer access, when UIF module is not used. Fixes: 5e824f989e6e8("media: v4l: vsp1: Integrate DISCOM in display pipeline") Signed-off-by: Biju Das Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 8cdc0900fc80569c72e5f49f567afec4b5973c8e Author: Maxim Mikityanskiy Date: Fri Feb 5 23:51:39 2021 +0100 media: usbtv: Fix deadlock on suspend commit 8a7e27fd5cd696ba564a3f62cedef7269cfd0723 upstream. usbtv doesn't support power management, so on system suspend the .disconnect callback of the driver is called. The teardown sequence includes a call to snd_card_free. Its implementation waits until the refcount of the sound card device drops to zero, however, if its file is open, snd_card_file_add takes a reference, which can't be dropped during the suspend, because the userspace processes are already frozen at this point. snd_card_free waits for completion forever, leading to a hang on suspend. This commit fixes this deadlock condition by replacing snd_card_free with snd_card_free_when_closed, that doesn't wait until all references are released, allowing suspend to progress. Fixes: 63ddf68de52e ("[media] usbtv: add audio support") Signed-off-by: Maxim Mikityanskiy Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 56b9b2c259054efb83a238507052773b4f2b84cf Author: Sergey Shtylyov Date: Sun Feb 28 23:27:32 2021 +0300 sh_eth: fix TRSCER mask for R7S9210 commit 165bc5a4f30eee4735845aa7dbd6b738643f2603 upstream. According to the RZ/A2M Group User's Manual: Hardware, Rev. 2.00, the TRSCER register has bit 9 reserved, hence we can't use the driver's default TRSCER mask. Add the explicit initializer for sh_eth_cpu_data:: trscer_err_mask for R7S9210. Fixes: 6e0bb04d0e4f ("sh_eth: Add R7S9210 support") Signed-off-by: Sergey Shtylyov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bdec0dd95cc801263f9b13cf1a41f8986be7f3e4 Author: Colin Ian King Date: Thu Mar 4 09:49:28 2021 +0000 qxl: Fix uninitialised struct field head.surface_id commit 738acd49eb018feb873e0fac8f9517493f6ce2c7 upstream. The surface_id struct field in head is not being initialized and static analysis warns that this is being passed through to dev->monitors_config->heads[i] on an assignment. Clear up this warning by initializing it to zero. Addresses-Coverity: ("Uninitialized scalar variable") Fixes: a6d3c4d79822 ("qxl: hook monitors_config updates into crtc, not encoder.") Signed-off-by: Colin Ian King Link: http://patchwork.freedesktop.org/patch/msgid/20210304094928.2280722-1-colin.king@canonical.com Signed-off-by: Gerd Hoffmann Signed-off-by: Maarten Lankhorst Signed-off-by: Greg Kroah-Hartman commit d5fc9c5d64ca3f15b0b6a77b70f41ad5331ca3a8 Author: Wang Qing Date: Mon Mar 1 20:08:21 2021 +0800 s390/crypto: return -EFAULT if copy_to_user() fails commit 942df4be7ab40195e2a839e9de81951a5862bc5b upstream. The copy_to_user() function returns the number of bytes remaining to be copied, but we want to return -EFAULT if the copy doesn't complete. Fixes: e06670c5fe3b ("s390: vfio-ap: implement VFIO_DEVICE_GET_INFO ioctl") Signed-off-by: Wang Qing Reviewed-by: Tony Krowiak Signed-off-by: Heiko Carstens Link: https://lore.kernel.org/r/1614600502-16714-1-git-send-email-wangqing@vivo.com Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 72ba965bf10de9e041820b6a2e23721645853407 Author: Eric Farman Date: Mon Mar 1 19:33:24 2021 +0100 s390/cio: return -EFAULT if copy_to_user() fails commit d9c48a948d29bcb22f4fe61a81b718ef6de561a0 upstream. Fixes: 120e214e504f ("vfio: ccw: realize VFIO_DEVICE_G(S)ET_IRQ_INFO ioctls") Signed-off-by: Eric Farman Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit d2100ef32a8cfd024bad94f4fbc5e53d40d2b3da Author: Artem Lapkin Date: Tue Mar 2 12:22:02 2021 +0800 drm: meson_drv add shutdown function commit fa0c16caf3d73ab4d2e5d6fa2ef2394dbec91791 upstream. Problem: random stucks on reboot stage about 1/20 stuck/reboots // debug kernel log [ 4.496660] reboot: kernel restart prepare CMD:(null) [ 4.498114] meson_ee_pwrc c883c000.system-controller:power-controller: shutdown begin [ 4.503949] meson_ee_pwrc c883c000.system-controller:power-controller: shutdown domain 0:VPU... ...STUCK... Solution: add shutdown function to meson_drm driver // debug kernel log [ 5.231896] reboot: kernel restart prepare CMD:(null) [ 5.246135] [drm:meson_drv_shutdown] ... [ 5.259271] meson_ee_pwrc c883c000.system-controller:power-controller: shutdown begin [ 5.274688] meson_ee_pwrc c883c000.system-controller:power-controller: shutdown domain 0:VPU... [ 5.338331] reboot: Restarting system [ 5.358293] psci: PSCI_0_2_FN_SYSTEM_RESET reboot_mode:0 cmd:(null) bl31 reboot reason: 0xd bl31 reboot reason: 0x0 system cmd 1. ...REBOOT... Tested: on VIM1 VIM2 VIM3 VIM3L khadas sbcs - 1000+ successful reboots and Odroid boards, WeTek Play2 (GXBB) Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller") Signed-off-by: Artem Lapkin Tested-by: Christian Hewitt Acked-by: Neil Armstrong Acked-by: Kevin Hilman Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20210302042202.3728113-1-art@khadas.com Signed-off-by: Maarten Lankhorst Signed-off-by: Greg Kroah-Hartman commit 72c541cc45523cac655c122e050734b89e688db4 Author: Neil Roberts Date: Tue Feb 23 16:51:25 2021 +0100 drm/shmem-helper: Don't remove the offset in vm_area_struct pgoff commit 11d5a4745e00e73745774671dbf2fb07bd6e2363 upstream. When mmapping the shmem, it would previously adjust the pgoff in the vm_area_struct to remove the fake offset that is added to be able to identify the buffer. This patch removes the adjustment and makes the fault handler use the vm_fault address to calculate the page offset instead. Although using this address is apparently discouraged, several DRM drivers seem to be doing it anyway. The problem with removing the pgoff is that it prevents drm_vma_node_unmap from working because that searches the mapping tree by address. That doesn't work because all of the mappings are at offset 0. drm_vma_node_unmap is being used by the shmem helpers when purging the buffer. This fixes a bug in Panfrost which is using drm_gem_shmem_purge. Without this the mapping for the purged buffer can still be accessed which might mean it would access random pages from other buffers v2: Don't check whether the unsigned page_offset is less than 0. Cc: stable@vger.kernel.org Fixes: 17acb9f35ed7 ("drm/shmem: Add madvise state and purge helpers") Signed-off-by: Neil Roberts Reviewed-by: Steven Price Signed-off-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20210223155125.199577-3-nroberts@igalia.com Signed-off-by: Maarten Lankhorst Signed-off-by: Greg Kroah-Hartman commit 0d574fc463c7f8aab3090453dd77bb13696235bd Author: Neil Roberts Date: Tue Feb 23 16:51:24 2021 +0100 drm/shmem-helper: Check for purged buffers in fault handler commit d611b4a0907cece060699f2fd347c492451cd2aa upstream. When a buffer is madvised as not needed and then purged, any attempts to access the buffer from user-space should cause a bus fault. This patch adds a check for that. Cc: stable@vger.kernel.org Fixes: 17acb9f35ed7 ("drm/shmem: Add madvise state and purge helpers") Signed-off-by: Neil Roberts Reviewed-by: Steven Price Signed-off-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20210223155125.199577-2-nroberts@igalia.com Signed-off-by: Maarten Lankhorst Signed-off-by: Greg Kroah-Hartman commit 3b08ea3a548f87a190bef056cbf0c3c708635ca6 Author: Daniel Vetter Date: Mon Feb 22 11:06:43 2021 +0100 drm/compat: Clear bounce structures commit de066e116306baf3a6a62691ac63cfc0b1dabddb upstream. Some of them have gaps, or fields we don't clear. Native ioctl code does full copies plus zero-extends on size mismatch, so nothing can leak. But compat is more hand-rolled so need to be careful. None of these matter for performance, so just memset. Also I didn't fix up the CONFIG_DRM_LEGACY or CONFIG_DRM_AGP ioctl, those are security holes anyway. Acked-by: Maxime Ripard Reported-by: syzbot+620cf21140fc7e772a5d@syzkaller.appspotmail.com # vblank ioctl Cc: syzbot+620cf21140fc7e772a5d@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210222100643.400935-1-daniel.vetter@ffwll.ch (cherry picked from commit e926c474ebee404441c838d18224cd6f246a71b7) Signed-off-by: Maarten Lankhorst Signed-off-by: Greg Kroah-Hartman commit cabbd263c8e8042a3c9e45147edcd546e3ce65da Author: Edwin Peer Date: Fri Feb 26 04:43:10 2021 -0500 bnxt_en: reliably allocate IRQ table on reset to avoid crash commit 20d7d1c5c9b11e9f538ed4a2289be106de970d3e upstream. The following trace excerpt corresponds with a NULL pointer dereference of 'bp->irq_tbl' in bnxt_setup_inta() on an Aarch64 system after many device resets: Unable to handle kernel NULL pointer dereference at ... 000000d ... pc : string+0x3c/0x80 lr : vsnprintf+0x294/0x7e0 sp : ffff00000f61ba70 pstate : 20000145 x29: ffff00000f61ba70 x28: 000000000000000d x27: ffff0000009c8b5a x26: ffff00000f61bb80 x25: ffff0000009c8b5a x24: 0000000000000012 x23: 00000000ffffffe0 x22: ffff000008990428 x21: ffff00000f61bb80 x20: 000000000000000d x19: 000000000000001f x18: 0000000000000000 x17: 0000000000000000 x16: ffff800b6d0fb400 x15: 0000000000000000 x14: ffff800b7fe31ae8 x13: 00001ed16472c920 x12: ffff000008c6b1c9 x11: ffff000008cf0580 x10: ffff00000f61bb80 x9 : 00000000ffffffd8 x8 : 000000000000000c x7 : ffff800b684b8000 x6 : 0000000000000000 x5 : 0000000000000065 x4 : 0000000000000001 x3 : ffff0a00ffffff04 x2 : 000000000000001f x1 : 0000000000000000 x0 : 000000000000000d Call trace: string+0x3c/0x80 vsnprintf+0x294/0x7e0 snprintf+0x44/0x50 __bnxt_open_nic+0x34c/0x928 [bnxt_en] bnxt_open+0xe8/0x238 [bnxt_en] __dev_open+0xbc/0x130 __dev_change_flags+0x12c/0x168 dev_change_flags+0x20/0x60 ... Ordinarily, a call to bnxt_setup_inta() (not in trace due to inlining) would not be expected on a system supporting MSIX at all. However, if bnxt_init_int_mode() does not end up being called after the call to bnxt_clear_int_mode() in bnxt_fw_reset_close(), then the driver will think that only INTA is supported and bp->irq_tbl will be NULL, causing the above crash. In the error recovery scenario, we call bnxt_clear_int_mode() in bnxt_fw_reset_close() early in the sequence. Ordinarily, we will call bnxt_init_int_mode() in bnxt_hwrm_if_change() after we reestablish communication with the firmware after reset. However, if the sequence has to abort before we call bnxt_init_int_mode() and if the user later attempts to re-open the device, then it will cause the crash above. We fix it in 2 ways: 1. Check for bp->irq_tbl in bnxt_setup_int_mode(). If it is NULL, call bnxt_init_init_mode(). 2. If we need to abort in bnxt_hwrm_if_change() and cannot complete the error recovery sequence, set the BNXT_STATE_ABORT_ERR flag. This will cause more drastic recovery at the next attempt to re-open the device, including a call to bnxt_init_int_mode(). Fixes: 3bc7d4a352ef ("bnxt_en: Add BNXT_STATE_IN_FW_RESET state.") Reviewed-by: Scott Branden Signed-off-by: Edwin Peer Signed-off-by: Michael Chan Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit dfa176f374ba0fb9786b96f6883e6aa4f05b717c Author: Wang Qing Date: Mon Mar 1 20:01:33 2021 +0800 s390/cio: return -EFAULT if copy_to_user() fails again commit 51c44babdc19aaf882e1213325a0ba291573308f upstream. The copy_to_user() function returns the number of bytes remaining to be copied, but we want to return -EFAULT if the copy doesn't complete. Fixes: e01bcdd61320 ("vfio: ccw: realize VFIO_DEVICE_GET_REGION_INFO ioctl") Signed-off-by: Wang Qing Signed-off-by: Heiko Carstens Link: https://lore.kernel.org/r/1614600093-13992-1-git-send-email-wangqing@vivo.com Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 05d11eb7bd9de13760f188c44c936853b48b16cf Author: Jian Shen Date: Sat Feb 27 15:24:53 2021 +0800 net: hns3: fix bug when calculating the TCAM table info commit b36fc875bcdee56865c444a2cdae17d354a6d5f5 upstream. The function hclge_fd_convert_tuple() is used to convert tuples and tuples mask to TCAM x and y. But it misuses the source mac as source mac mask when convert INNER_SRC_MAC, which may cause the flow director rule works unexpectedly. So fix it. Fixes: 117328680288 ("net: hns3: Add input key and action config support for flow director") Signed-off-by: Jian Shen Signed-off-by: Huazhong Tan Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 8bbc59bb0556566ce0e7643f90a423cbee2a9b75 Author: Jian Shen Date: Sat Feb 27 15:24:52 2021 +0800 net: hns3: fix query vlan mask value error for flow director commit c75ec148a316e8cf52274d16b9b422703b96f5ce upstream. Currently, the driver returns VLAN_VID_MASK for vlan mask field, when get flow director rule information for rule doesn't use vlan. It may cause the vlan mask value display as 0xf000 in this case, like below: estuary:/$ ethtool -u eth1 50 RX rings available Total 1 rules Filter: 2 Rule Type: TCP over IPv4 Src IP addr: 0.0.0.0 mask: 255.255.255.255 Dest IP addr: 0.0.0.0 mask: 255.255.255.255 TOS: 0x0 mask: 0xff Src port: 0 mask: 0xffff Dest port: 0 mask: 0xffff VLAN EtherType: 0x0 mask: 0xffff VLAN: 0x0 mask: 0xf000 User-defined: 0x1234 mask: 0x0 Action: Direct to queue 3 Fix it by return 0. Fixes: 05c2314fe6a8 ("net: hns3: Add support for rule query of flow director") Signed-off-by: Jian Shen Signed-off-by: Huazhong Tan Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4d0273ab0a796cd1a3b888f47e53a6a75171bd8e Author: Ian Rogers Date: Fri Feb 26 14:14:31 2021 -0800 perf traceevent: Ensure read cmdlines are null terminated. commit 137a5258939aca56558f3a23eb229b9c4b293917 upstream. Issue detected by address sanitizer. Fixes: cd4ceb63438e9e28 ("perf util: Save pid-cmdline mapping into tracing header") Signed-off-by: Ian Rogers Acked-by: Namhyung Kim Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Mark Rutland Cc: Peter Zijlstra Cc: Stephane Eranian Link: http://lore.kernel.org/lkml/20210226221431.1985458-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit ef663d149f8e88a6c153f80d4d3bcdb1fc3d7fef Author: Danielle Ratson Date: Thu Feb 25 18:57:19 2021 +0200 selftests: forwarding: Fix race condition in mirror installation commit edcbf5137f093b5502f5f6b97cce3cbadbde27aa upstream. When mirroring to a gretap in hardware the device expects to be programmed with the egress port and all the encapsulating headers. This requires the driver to resolve the path the packet will take in the software data path and program the device accordingly. If the path cannot be resolved (in this case because of an unresolved neighbor), then mirror installation fails until the path is resolved. This results in a race that causes the test to sometimes fail. Fix this by setting the neighbor's state to permanent, so that it is always valid. Fixes: b5b029399fa6d ("selftests: forwarding: mirror_gre_bridge_1d_vlan: Add STP test") Signed-off-by: Danielle Ratson Reviewed-by: Petr Machata Signed-off-by: Ido Schimmel Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit fcce3cb62c094c1f9fdeec36526be8c87d739f8f Author: Joakim Zhang Date: Thu Feb 25 17:01:11 2021 +0800 net: stmmac: fix watchdog timeout during suspend/resume stress test commit c511819d138de38e1637eedb645c207e09680d0f upstream. stmmac_xmit() call stmmac_tx_timer_arm() at the end to modify tx timer to do the transmission cleanup work. Imagine such a situation, stmmac enters suspend immediately after tx timer modified, it's expire callback stmmac_tx_clean() would not be invoked. This could affect BQL, since netdev_tx_sent_queue() has been called, but netdev_tx_completed_queue() have not been involved, as a result, dql_avail(&dev_queue->dql) finally always return a negative value. __dev_queue_xmit->__dev_xmit_skb->qdisc_run->__qdisc_run->qdisc_restart->dequeue_skb: if ((q->flags & TCQ_F_ONETXQUEUE) && netif_xmit_frozen_or_stopped(txq)) // __QUEUE_STATE_STACK_XOFF is set Net core will stop transmitting any more. Finillay, net watchdong would timeout. To fix this issue, we should call netdev_tx_reset_queue() in stmmac_resume(). Fixes: 54139cf3bb33 ("net: stmmac: adding multiple buffers for rx") Signed-off-by: Joakim Zhang Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit d31ae9ec5a03bbf3a221949b52c93c4f3bc9cce7 Author: Joakim Zhang Date: Thu Feb 25 17:01:10 2021 +0800 net: stmmac: stop each tx channel independently commit a3e860a83397bf761ec1128a3f0ba186445992c6 upstream. If clear GMAC_CONFIG_TE bit, it would stop all tx channels, but users may only want to stop specific tx channel. Fixes: 48863ce5940f ("stmmac: add DMA support for GMAC 4.xx") Signed-off-by: Joakim Zhang Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 86ea605518d786c13f0939f6dcbc1fc1f2516472 Author: Antony Antony Date: Wed Oct 14 16:17:48 2020 +0200 ixgbe: fail to create xfrm offload of IPsec tunnel mode SA commit d785e1fec60179f534fbe8d006c890e5ad186e51 upstream. Based on talks and indirect references ixgbe IPsec offlod do not support IPsec tunnel mode offload. It can only support IPsec transport mode offload. Now explicitly fail when creating non transport mode SA with offload to avoid false performance expectations. Fixes: 63a67fe229ea ("ixgbe: add ipsec offload add and remove SA") Signed-off-by: Antony Antony Acked-by: Shannon Nelson Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit e8b6c1d7ced2b728ae9b978da9578efc9ef6c5f0 Author: Jia-Ju Bai Date: Mon Mar 8 01:13:55 2021 -0800 net: qrtr: fix error return code of qrtr_sendmsg() commit 179d0ba0c454057a65929c46af0d6ad986754781 upstream. When sock_alloc_send_skb() returns NULL to skb, no error return code of qrtr_sendmsg() is assigned. To fix this bug, rc is assigned with -ENOMEM in this case. Fixes: 194ccc88297a ("net: qrtr: Support decoding incoming v2 packets") Reported-by: TOTE Robot Signed-off-by: Jia-Ju Bai Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d28e783c20033b90a64d4e1307bafb56085d8184 Author: Paul Cercueil Date: Sun Mar 7 13:17:48 2021 +0000 net: davicom: Fix regulator not turned off on driver removal commit cf9e60aa69ae6c40d3e3e4c94dd6c8de31674e9b upstream. We must disable the regulator that was enabled in the probe function. Fixes: 7994fe55a4a2 ("dm9000: Add regulator and reset support to dm9000") Signed-off-by: Paul Cercueil Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 05517de4188b0a8e47c90b017261abbc85f25690 Author: Paul Cercueil Date: Sun Mar 7 13:17:47 2021 +0000 net: davicom: Fix regulator not turned off on failed probe commit ac88c531a5b38877eba2365a3f28f0c8b513dc33 upstream. When the probe fails or requests to be defered, we must disable the regulator that was previously enabled. Fixes: 7994fe55a4a2 ("dm9000: Add regulator and reset support to dm9000") Signed-off-by: Paul Cercueil Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 11a589205119b7466245ccd6815a8bf3180adae0 Author: Xie He Date: Sun Mar 7 03:33:07 2021 -0800 net: lapbether: Remove netif_start_queue / netif_stop_queue commit f7d9d4854519fdf4d45c70a4d953438cd88e7e58 upstream. For the devices in this driver, the default qdisc is "noqueue", because their "tx_queue_len" is 0. In function "__dev_queue_xmit" in "net/core/dev.c", devices with the "noqueue" qdisc are specially handled. Packets are transmitted without being queued after a "dev->flags & IFF_UP" check. However, it's possible that even if this check succeeds, "ops->ndo_stop" may still have already been called. This is because in "__dev_close_many", "ops->ndo_stop" is called before clearing the "IFF_UP" flag. If we call "netif_stop_queue" in "ops->ndo_stop", then it's possible in "__dev_queue_xmit", it sees the "IFF_UP" flag is present, and then it checks "netif_xmit_stopped" and finds that the queue is already stopped. In this case, it will complain that: "Virtual device ... asks to queue packet!" To prevent "__dev_queue_xmit" from generating this complaint, we should not call "netif_stop_queue" in "ops->ndo_stop". We also don't need to call "netif_start_queue" in "ops->ndo_open", because after a netdev is allocated and registered, the "__QUEUE_STATE_DRV_XOFF" flag is initially not set, so there is no need to call "netif_start_queue" to clear it. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Xie He Acked-by: Martin Schiller Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b4800e7a1c9f80a1a0e417ab36a1da4959f8b399 Author: Paul Moore Date: Thu Mar 4 16:29:51 2021 -0500 cipso,calipso: resolve a number of problems with the DOI refcounts commit ad5d07f4a9cd671233ae20983848874731102c08 upstream. The current CIPSO and CALIPSO refcounting scheme for the DOI definitions is a bit flawed in that we: 1. Don't correctly match gets/puts in netlbl_cipsov4_list(). 2. Decrement the refcount on each attempt to remove the DOI from the DOI list, only removing it from the list once the refcount drops to zero. This patch fixes these problems by adding the missing "puts" to netlbl_cipsov4_list() and introduces a more conventional, i.e. not-buggy, refcounting mechanism to the DOI definitions. Upon the addition of a DOI to the DOI list, it is initialized with a refcount of one, removing a DOI from the list removes it from the list and drops the refcount by one; "gets" and "puts" behave as expected with respect to refcounts, increasing and decreasing the DOI's refcount by one. Fixes: b1edeb102397 ("netlabel: Replace protocol/NetLabel linking with refrerence counts") Fixes: d7cce01504a0 ("netlabel: Add support for removing a CALIPSO DOI.") Reported-by: syzbot+9ec037722d2603a9f52e@syzkaller.appspotmail.com Signed-off-by: Paul Moore Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6d599697e9a8958ea4ba1428e9dfebd7d0c560e0 Author: Hillf Danton Date: Thu Mar 4 10:30:09 2021 -0800 netdevsim: init u64 stats for 32bit hardware commit 863a42b289c22df63db62b10fc2c2ffc237e2125 upstream. Init the u64 stats in order to avoid the lockdep prints on the 32bit hardware like INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 0 PID: 4695 Comm: syz-executor.0 Not tainted 5.11.0-rc5-syzkaller #0 Hardware name: ARM-Versatile Express Backtrace: [<826fc5b8>] (dump_backtrace) from [<826fc82c>] (show_stack+0x18/0x1c arch/arm/kernel/traps.c:252) [<826fc814>] (show_stack) from [<8270d1f8>] (__dump_stack lib/dump_stack.c:79 [inline]) [<826fc814>] (show_stack) from [<8270d1f8>] (dump_stack+0xa8/0xc8 lib/dump_stack.c:120) [<8270d150>] (dump_stack) from [<802bf9c0>] (assign_lock_key kernel/locking/lockdep.c:935 [inline]) [<8270d150>] (dump_stack) from [<802bf9c0>] (register_lock_class+0xabc/0xb68 kernel/locking/lockdep.c:1247) [<802bef04>] (register_lock_class) from [<802baa2c>] (__lock_acquire+0x84/0x32d4 kernel/locking/lockdep.c:4711) [<802ba9a8>] (__lock_acquire) from [<802be840>] (lock_acquire.part.0+0xf0/0x554 kernel/locking/lockdep.c:5442) [<802be750>] (lock_acquire.part.0) from [<802bed10>] (lock_acquire+0x6c/0x74 kernel/locking/lockdep.c:5415) [<802beca4>] (lock_acquire) from [<81560548>] (seqcount_lockdep_reader_access include/linux/seqlock.h:103 [inline]) [<802beca4>] (lock_acquire) from [<81560548>] (__u64_stats_fetch_begin include/linux/u64_stats_sync.h:164 [inline]) [<802beca4>] (lock_acquire) from [<81560548>] (u64_stats_fetch_begin include/linux/u64_stats_sync.h:175 [inline]) [<802beca4>] (lock_acquire) from [<81560548>] (nsim_get_stats64+0xdc/0xf0 drivers/net/netdevsim/netdev.c:70) [<8156046c>] (nsim_get_stats64) from [<81e2efa0>] (dev_get_stats+0x44/0xd0 net/core/dev.c:10405) [<81e2ef5c>] (dev_get_stats) from [<81e53204>] (rtnl_fill_stats+0x38/0x120 net/core/rtnetlink.c:1211) [<81e531cc>] (rtnl_fill_stats) from [<81e59d58>] (rtnl_fill_ifinfo+0x6d4/0x148c net/core/rtnetlink.c:1783) [<81e59684>] (rtnl_fill_ifinfo) from [<81e5ceb4>] (rtmsg_ifinfo_build_skb+0x9c/0x108 net/core/rtnetlink.c:3798) [<81e5ce18>] (rtmsg_ifinfo_build_skb) from [<81e5d0ac>] (rtmsg_ifinfo_event net/core/rtnetlink.c:3830 [inline]) [<81e5ce18>] (rtmsg_ifinfo_build_skb) from [<81e5d0ac>] (rtmsg_ifinfo_event net/core/rtnetlink.c:3821 [inline]) [<81e5ce18>] (rtmsg_ifinfo_build_skb) from [<81e5d0ac>] (rtmsg_ifinfo+0x44/0x70 net/core/rtnetlink.c:3839) [<81e5d068>] (rtmsg_ifinfo) from [<81e45c2c>] (register_netdevice+0x664/0x68c net/core/dev.c:10103) [<81e455c8>] (register_netdevice) from [<815608bc>] (nsim_create+0xf8/0x124 drivers/net/netdevsim/netdev.c:317) [<815607c4>] (nsim_create) from [<81561184>] (__nsim_dev_port_add+0x108/0x188 drivers/net/netdevsim/dev.c:941) [<8156107c>] (__nsim_dev_port_add) from [<815620d8>] (nsim_dev_port_add_all drivers/net/netdevsim/dev.c:990 [inline]) [<8156107c>] (__nsim_dev_port_add) from [<815620d8>] (nsim_dev_probe+0x5cc/0x750 drivers/net/netdevsim/dev.c:1119) [<81561b0c>] (nsim_dev_probe) from [<815661dc>] (nsim_bus_probe+0x10/0x14 drivers/net/netdevsim/bus.c:287) [<815661cc>] (nsim_bus_probe) from [<811724c0>] (really_probe+0x100/0x50c drivers/base/dd.c:554) [<811723c0>] (really_probe) from [<811729c4>] (driver_probe_device+0xf8/0x1c8 drivers/base/dd.c:740) [<811728cc>] (driver_probe_device) from [<81172fe4>] (__device_attach_driver+0x8c/0xf0 drivers/base/dd.c:846) [<81172f58>] (__device_attach_driver) from [<8116fee0>] (bus_for_each_drv+0x88/0xd8 drivers/base/bus.c:431) [<8116fe58>] (bus_for_each_drv) from [<81172c6c>] (__device_attach+0xdc/0x1d0 drivers/base/dd.c:914) [<81172b90>] (__device_attach) from [<8117305c>] (device_initial_probe+0x14/0x18 drivers/base/dd.c:961) [<81173048>] (device_initial_probe) from [<81171358>] (bus_probe_device+0x90/0x98 drivers/base/bus.c:491) [<811712c8>] (bus_probe_device) from [<8116e77c>] (device_add+0x320/0x824 drivers/base/core.c:3109) [<8116e45c>] (device_add) from [<8116ec9c>] (device_register+0x1c/0x20 drivers/base/core.c:3182) [<8116ec80>] (device_register) from [<81566710>] (nsim_bus_dev_new drivers/net/netdevsim/bus.c:336 [inline]) [<8116ec80>] (device_register) from [<81566710>] (new_device_store+0x178/0x208 drivers/net/netdevsim/bus.c:215) [<81566598>] (new_device_store) from [<8116fcb4>] (bus_attr_store+0x2c/0x38 drivers/base/bus.c:122) [<8116fc88>] (bus_attr_store) from [<805b4b8c>] (sysfs_kf_write+0x48/0x54 fs/sysfs/file.c:139) [<805b4b44>] (sysfs_kf_write) from [<805b3c90>] (kernfs_fop_write_iter+0x128/0x1ec fs/kernfs/file.c:296) [<805b3b68>] (kernfs_fop_write_iter) from [<804d22fc>] (call_write_iter include/linux/fs.h:1901 [inline]) [<805b3b68>] (kernfs_fop_write_iter) from [<804d22fc>] (new_sync_write fs/read_write.c:518 [inline]) [<805b3b68>] (kernfs_fop_write_iter) from [<804d22fc>] (vfs_write+0x3dc/0x57c fs/read_write.c:605) [<804d1f20>] (vfs_write) from [<804d2604>] (ksys_write+0x68/0xec fs/read_write.c:658) [<804d259c>] (ksys_write) from [<804d2698>] (__do_sys_write fs/read_write.c:670 [inline]) [<804d259c>] (ksys_write) from [<804d2698>] (sys_write+0x10/0x14 fs/read_write.c:667) [<804d2688>] (sys_write) from [<80200060>] (ret_fast_syscall+0x0/0x2c arch/arm/mm/proc-v7.S:64) Fixes: 83c9e13aa39a ("netdevsim: add software driver for testing offloads") Reported-by: syzbot+e74a6857f2d0efe3ad81@syzkaller.appspotmail.com Tested-by: Dmitry Vyukov Signed-off-by: Hillf Danton Signed-off-by: Jakub Kicinski Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8e365b61bda7699eb516213d7751c8f0b46b6598 Author: Daniele Palmas Date: Thu Mar 4 14:15:13 2021 +0100 net: usb: qmi_wwan: allow qmimux add/del with master up commit 6c59cff38e66584ae3ac6c2f0cbd8d039c710ba7 upstream. There's no reason for preventing the creation and removal of qmimux network interfaces when the underlying interface is up. This makes qmi_wwan mux implementation more similar to the rmnet one, simplifying userspace management of the same logical interfaces. Fixes: c6adf77953bc ("net: usb: qmi_wwan: add qmap mux protocol support") Reported-by: Aleksander Morgado Signed-off-by: Daniele Palmas Acked-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 392f34cce2b0467aba179d2a0a07016ef3e2b45e Author: Maximilian Heyne Date: Thu Mar 4 14:43:17 2021 +0000 net: sched: avoid duplicates in classes dump commit bfc2560563586372212b0a8aeca7428975fa91fe upstream. This is a follow up of commit ea3274695353 ("net: sched: avoid duplicates in qdisc dump") which has fixed the issue only for the qdisc dump. The duplicate printing also occurs when dumping the classes via tc class show dev eth0 Fixes: 59cc1f61f09c ("net: sched: convert qdisc linked list to hashtable") Signed-off-by: Maximilian Heyne Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3e66c16388f5e59ba73dd05e0667c10bc04ac29b Author: Ido Schimmel Date: Thu Mar 4 10:57:53 2021 +0200 nexthop: Do not flush blackhole nexthops when loopback goes down commit 76c03bf8e2624076b88d93542d78e22d5345c88e upstream. As far as user space is concerned, blackhole nexthops do not have a nexthop device and therefore should not be affected by the administrative or carrier state of any netdev. However, when the loopback netdev goes down all the blackhole nexthops are flushed. This happens because internally the kernel associates blackhole nexthops with the loopback netdev. This behavior is both confusing to those not familiar with kernel internals and also diverges from the legacy API where blackhole IPv4 routes are not flushed when the loopback netdev goes down: # ip route add blackhole 198.51.100.0/24 # ip link set dev lo down # ip route show 198.51.100.0/24 blackhole 198.51.100.0/24 Blackhole IPv6 routes are flushed, but at least user space knows that they are associated with the loopback netdev: # ip -6 route show 2001:db8:1::/64 blackhole 2001:db8:1::/64 dev lo metric 1024 pref medium Fix this by only flushing blackhole nexthops when the loopback netdev is unregistered. Fixes: ab84be7e54fc ("net: Initial nexthop code") Signed-off-by: Ido Schimmel Reported-by: Donald Sharp Reviewed-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7f101d035deb1fdc71e6e433ea798017cee4b085 Author: Ong Boon Leong Date: Wed Mar 3 20:38:40 2021 +0530 net: stmmac: fix incorrect DMA channel intr enable setting of EQoS v4.10 commit 879c348c35bb5fb758dd881d8a97409c1862dae8 upstream. We introduce dwmac410_dma_init_channel() here for both EQoS v4.10 and above which use different DMA_CH(n)_Interrupt_Enable bit definitions for NIE and AIE. Fixes: 48863ce5940f ("stmmac: add DMA support for GMAC 4.xx") Signed-off-by: Ong Boon Leong Signed-off-by: Ramesh Babu B Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0fbbcf797e9c365939eb78f6afa1656d40004581 Author: Kevin(Yudong) Yang Date: Wed Mar 3 09:43:54 2021 -0500 net/mlx4_en: update moderation when config reset commit 00ff801bb8ce6711e919af4530b6ffa14a22390a upstream. This patch fixes a bug that the moderation config will not be applied when calling mlx4_en_reset_config. For example, when turning on rx timestamping, mlx4_en_reset_config() will be called, causing the NIC to forget previous moderation config. This fix is in phase with a previous fix: commit 79c54b6bbf06 ("net/mlx4_en: Fix TX moderation info loss after set_ringparam is called") Tested: Before this patch, on a host with NIC using mlx4, run netserver and stream TCP to the host at full utilization. $ sar -I SUM 1 INTR intr/s 14:03:56 sum 48758.00 After rx hwtstamp is enabled: $ sar -I SUM 1 14:10:38 sum 317771.00 We see the moderation is not working properly and issued 7x more interrupts. After the patch, and turned on rx hwtstamp, the rate of interrupts is as expected: $ sar -I SUM 1 14:52:11 sum 49332.00 Fixes: 79c54b6bbf06 ("net/mlx4_en: Fix TX moderation info loss after set_ringparam is called") Signed-off-by: Kevin(Yudong) Yang Reviewed-by: Eric Dumazet Reviewed-by: Neal Cardwell CC: Tariq Toukan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 78cbd0a4749dbb0f87b77bf80cc6607bb50e5935 Author: Vladimir Oltean Date: Mon Mar 1 13:18:11 2021 +0200 net: enetc: don't overwrite the RSS indirection table when initializing commit c646d10dda2dcde82c6ce5a474522621ab2b8b19 upstream. After the blamed patch, all RX traffic gets hashed to CPU 0 because the hashing indirection table set up in: enetc_pf_probe -> enetc_alloc_si_resources -> enetc_configure_si -> enetc_setup_default_rss_table is overwritten later in: enetc_pf_probe -> enetc_init_port_rss_memory which zero-initializes the entire port RSS table in order to avoid ECC errors. The trouble really is that enetc_init_port_rss_memory really neads enetc_alloc_si_resources to be called, because it depends upon enetc_alloc_cbdr and enetc_setup_cbdr. But that whole enetc_configure_si thing could have been better thought out, it has nothing to do in a function called "alloc_si_resources", especially since its counterpart, "free_si_resources", does nothing to unwind the configuration of the SI. The point is, we need to pull out enetc_configure_si out of enetc_alloc_resources, and move it after enetc_init_port_rss_memory. This allows us to set up the default RSS indirection table after initializing the memory. Fixes: 07bf34a50e32 ("net: enetc: initialize the RFS and RSS memories") Cc: Jesse Brandeburg Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6547ec42861983b4a66344426f0bcb24264f9256 Author: Linus Torvalds Date: Wed Mar 10 10:18:04 2021 -0800 Revert "mm, slub: consider rest of partial list if acquire_slab() fails" commit 9b1ea29bc0d7b94d420f96a0f4121403efc3dd85 upstream. This reverts commit 8ff60eb052eeba95cfb3efe16b08c9199f8121cf. The kernel test robot reports a huge performance regression due to the commit, and the reason seems fairly straightforward: when there is contention on the page list (which is what causes acquire_slab() to fail), we do _not_ want to just loop and try again, because that will transfer the contention to the 'n->list_lock' spinlock we hold, and just make things even worse. This is admittedly likely a problem only on big machines - the kernel test robot report comes from a 96-thread dual socket Intel Xeon Gold 6252 setup, but the regression there really is quite noticeable: -47.9% regression of stress-ng.rawpkt.ops_per_sec and the commit that was marked as being fixed (7ced37197196: "slub: Acquire_slab() avoid loop") actually did the loop exit early very intentionally (the hint being that "avoid loop" part of that commit message), exactly to avoid this issue. The correct thing to do may be to pick some kind of reasonable middle ground: instead of breaking out of the loop on the very first sign of contention, or trying over and over and over again, the right thing may be to re-try _once_, and then give up on the second failure (or pick your favorite value for "once"..). Reported-by: kernel test robot Link: https://lore.kernel.org/lkml/20210301080404.GF12822@xsang-OptiPlex-9020/ Cc: Jann Horn Cc: David Rientjes Cc: Joonsoo Kim Acked-by: Christoph Lameter Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 55e6ede3b9354076f099c41f3b29aa569f42478a Author: Paulo Alcantara Date: Mon Mar 8 12:00:49 2021 -0300 cifs: return proper error code in statfs(2) commit 14302ee3301b3a77b331cc14efb95bf7184c73cc upstream. In cifs_statfs(), if server->ops->queryfs is not NULL, then we should use its return value rather than always returning 0. Instead, use rc variable as it is properly set to 0 in case there is no server->ops->queryfs. Signed-off-by: Paulo Alcantara (SUSE) Reviewed-by: Aurelien Aptel Reviewed-by: Ronnie Sahlberg CC: Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit a1ff418d3eda0cf300bdbcda70e67314233adb5d Author: Christian Brauner Date: Sat Mar 6 11:10:10 2021 +0100 mount: fix mounting of detached mounts onto targets that reside on shared mounts commit ee2e3f50629f17b0752b55b2566c15ce8dafb557 upstream. Creating a series of detached mounts, attaching them to the filesystem, and unmounting them can be used to trigger an integer overflow in ns->mounts causing the kernel to block any new mounts in count_mounts() and returning ENOSPC because it falsely assumes that the maximum number of mounts in the mount namespace has been reached, i.e. it thinks it can't fit the new mounts into the mount namespace anymore. Depending on the number of mounts in your system, this can be reproduced on any kernel that supportes open_tree() and move_mount() by compiling and running the following program: /* SPDX-License-Identifier: LGPL-2.1+ */ #define _GNU_SOURCE #include #include #include #include #include #include #include #include #include #include #include #include #include /* open_tree() */ #ifndef OPEN_TREE_CLONE #define OPEN_TREE_CLONE 1 #endif #ifndef OPEN_TREE_CLOEXEC #define OPEN_TREE_CLOEXEC O_CLOEXEC #endif #ifndef __NR_open_tree #if defined __alpha__ #define __NR_open_tree 538 #elif defined _MIPS_SIM #if _MIPS_SIM == _MIPS_SIM_ABI32 /* o32 */ #define __NR_open_tree 4428 #endif #if _MIPS_SIM == _MIPS_SIM_NABI32 /* n32 */ #define __NR_open_tree 6428 #endif #if _MIPS_SIM == _MIPS_SIM_ABI64 /* n64 */ #define __NR_open_tree 5428 #endif #elif defined __ia64__ #define __NR_open_tree (428 + 1024) #else #define __NR_open_tree 428 #endif #endif /* move_mount() */ #ifndef MOVE_MOUNT_F_EMPTY_PATH #define MOVE_MOUNT_F_EMPTY_PATH 0x00000004 /* Empty from path permitted */ #endif #ifndef __NR_move_mount #if defined __alpha__ #define __NR_move_mount 539 #elif defined _MIPS_SIM #if _MIPS_SIM == _MIPS_SIM_ABI32 /* o32 */ #define __NR_move_mount 4429 #endif #if _MIPS_SIM == _MIPS_SIM_NABI32 /* n32 */ #define __NR_move_mount 6429 #endif #if _MIPS_SIM == _MIPS_SIM_ABI64 /* n64 */ #define __NR_move_mount 5429 #endif #elif defined __ia64__ #define __NR_move_mount (428 + 1024) #else #define __NR_move_mount 429 #endif #endif static inline int sys_open_tree(int dfd, const char *filename, unsigned int flags) { return syscall(__NR_open_tree, dfd, filename, flags); } static inline int sys_move_mount(int from_dfd, const char *from_pathname, int to_dfd, const char *to_pathname, unsigned int flags) { return syscall(__NR_move_mount, from_dfd, from_pathname, to_dfd, to_pathname, flags); } static bool is_shared_mountpoint(const char *path) { bool shared = false; FILE *f = NULL; char *line = NULL; int i; size_t len = 0; f = fopen("/proc/self/mountinfo", "re"); if (!f) return 0; while (getline(&line, &len, f) > 0) { char *slider1, *slider2; for (slider1 = line, i = 0; slider1 && i < 4; i++) slider1 = strchr(slider1 + 1, ' '); if (!slider1) continue; slider2 = strchr(slider1 + 1, ' '); if (!slider2) continue; *slider2 = '\0'; if (strcmp(slider1 + 1, path) == 0) { /* This is the path. Is it shared? */ slider1 = strchr(slider2 + 1, ' '); if (slider1 && strstr(slider1, "shared:")) { shared = true; break; } } } fclose(f); free(line); return shared; } static void usage(void) { const char *text = "mount-new [--recursive] \n"; fprintf(stderr, "%s", text); _exit(EXIT_SUCCESS); } #define exit_usage(format, ...) \ ({ \ fprintf(stderr, format "\n", ##__VA_ARGS__); \ usage(); \ }) #define exit_log(format, ...) \ ({ \ fprintf(stderr, format "\n", ##__VA_ARGS__); \ exit(EXIT_FAILURE); \ }) static const struct option longopts[] = { {"help", no_argument, 0, 'a'}, { NULL, no_argument, 0, 0 }, }; int main(int argc, char *argv[]) { int exit_code = EXIT_SUCCESS, index = 0; int dfd, fd_tree, new_argc, ret; char *base_dir; char *const *new_argv; char target[PATH_MAX]; while ((ret = getopt_long_only(argc, argv, "", longopts, &index)) != -1) { switch (ret) { case 'a': /* fallthrough */ default: usage(); } } new_argv = &argv[optind]; new_argc = argc - optind; if (new_argc < 1) exit_usage("Missing base directory\n"); base_dir = new_argv[0]; if (*base_dir != '/') exit_log("Please specify an absolute path"); /* Ensure that target is a shared mountpoint. */ if (!is_shared_mountpoint(base_dir)) exit_log("Please ensure that \"%s\" is a shared mountpoint", base_dir); dfd = open(base_dir, O_RDONLY | O_DIRECTORY | O_CLOEXEC); if (dfd < 0) exit_log("%m - Failed to open base directory \"%s\"", base_dir); ret = mkdirat(dfd, "detached-move-mount", 0755); if (ret < 0) exit_log("%m - Failed to create required temporary directories"); ret = snprintf(target, sizeof(target), "%s/detached-move-mount", base_dir); if (ret < 0 || (size_t)ret >= sizeof(target)) exit_log("%m - Failed to assemble target path"); /* * Having a mount table with 10000 mounts is already quite excessive * and shoult account even for weird test systems. */ for (size_t i = 0; i < 10000; i++) { fd_tree = sys_open_tree(dfd, "detached-move-mount", OPEN_TREE_CLONE | OPEN_TREE_CLOEXEC | AT_EMPTY_PATH); if (fd_tree < 0) { fprintf(stderr, "%m - Failed to open %d(detached-move-mount)", dfd); exit_code = EXIT_FAILURE; break; } ret = sys_move_mount(fd_tree, "", dfd, "detached-move-mount", MOVE_MOUNT_F_EMPTY_PATH); if (ret < 0) { if (errno == ENOSPC) fprintf(stderr, "%m - Buggy mount counting"); else fprintf(stderr, "%m - Failed to attach mount to %d(detached-move-mount)", dfd); exit_code = EXIT_FAILURE; break; } close(fd_tree); ret = umount2(target, MNT_DETACH); if (ret < 0) { fprintf(stderr, "%m - Failed to unmount %s", target); exit_code = EXIT_FAILURE; break; } } (void)unlinkat(dfd, "detached-move-mount", AT_REMOVEDIR); close(dfd); exit(exit_code); } and wait for the kernel to refuse any new mounts by returning ENOSPC. How many iterations are needed depends on the number of mounts in your system. Assuming you have something like 50 mounts on a standard system it should be almost instantaneous. The root cause of this is that detached mounts aren't handled correctly when source and target mount are identical and reside on a shared mount causing a broken mount tree where the detached source itself is propagated which propagation prevents for regular bind-mounts and new mounts. This ultimately leads to a miscalculation of the number of mounts in the mount namespace. Detached mounts created via open_tree(fd, path, OPEN_TREE_CLONE) are essentially like an unattached new mount, or an unattached bind-mount. They can then later on be attached to the filesystem via move_mount() which calls into attach_recursive_mount(). Part of attaching it to the filesystem is making sure that mounts get correctly propagated in case the destination mountpoint is MS_SHARED, i.e. is a shared mountpoint. This is done by calling into propagate_mnt() which walks the list of peers calling propagate_one() on each mount in this list making sure it receives the propagation event. The propagate_one() functions thereby skips both new mounts and bind mounts to not propagate them "into themselves". Both are identified by checking whether the mount is already attached to any mount namespace in mnt->mnt_ns. The is what the IS_MNT_NEW() helper is responsible for. However, detached mounts have an anonymous mount namespace attached to them stashed in mnt->mnt_ns which means that IS_MNT_NEW() doesn't realize they need to be skipped causing the mount to propagate "into itself" breaking the mount table and causing a disconnect between the number of mounts recorded as being beneath or reachable from the target mountpoint and the number of mounts actually recorded/counted in ns->mounts ultimately causing an overflow which in turn prevents any new mounts via the ENOSPC issue. So teach propagation to handle detached mounts by making it aware of them. I've been tracking this issue down for the last couple of days and then verifying that the fix is correct by unmounting everything in my current mount table leaving only /proc and /sys mounted and running the reproducer above overnight verifying the number of mounts counted in ns->mounts. With this fix the counts are correct and the ENOSPC issue can't be reproduced. This change will only have an effect on mounts created with the new mount API since detached mounts cannot be created with the old mount API so regressions are extremely unlikely. Link: https://lore.kernel.org/r/20210306101010.243666-1-christian.brauner@ubuntu.com Fixes: 2db154b3ea8e ("vfs: syscall: Add move_mount(2) to move mounts around") Cc: David Howells Cc: Al Viro Cc: linux-fsdevel@vger.kernel.org Cc: Reviewed-by: Christoph Hellwig Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit 59a057a891553cb5b4c298b0193135d832bfbc6c Author: Christophe Leroy Date: Mon Feb 1 06:29:50 2021 +0000 powerpc/603: Fix protection of user pages mapped with PROT_NONE commit c119565a15a628efdfa51352f9f6c5186e506a1c upstream. On book3s/32, page protection is defined by the PP bits in the PTE which provide the following protection depending on the access keys defined in the matching segment register: - PP 00 means RW with key 0 and N/A with key 1. - PP 01 means RW with key 0 and RO with key 1. - PP 10 means RW with both key 0 and key 1. - PP 11 means RO with both key 0 and key 1. Since the implementation of kernel userspace access protection, PP bits have been set as follows: - PP00 for pages without _PAGE_USER - PP01 for pages with _PAGE_USER and _PAGE_RW - PP11 for pages with _PAGE_USER and without _PAGE_RW For kernelspace segments, kernel accesses are performed with key 0 and user accesses are performed with key 1. As PP00 is used for non _PAGE_USER pages, user can't access kernel pages not flagged _PAGE_USER while kernel can. For userspace segments, both kernel and user accesses are performed with key 0, therefore pages not flagged _PAGE_USER are still accessible to the user. This shouldn't be an issue, because userspace is expected to be accessible to the user. But unlike most other architectures, powerpc implements PROT_NONE protection by removing _PAGE_USER flag instead of flagging the page as not valid. This means that pages in userspace that are not flagged _PAGE_USER shall remain inaccessible. To get the expected behaviour, just mimic other architectures in the TLB miss handler by checking _PAGE_USER permission on userspace accesses as if it was the _PAGE_PRESENT bit. Note that this problem only is only for 603 cores. The 604+ have an hash table, and hash_page() function already implement the verification of _PAGE_USER permission on userspace pages. Fixes: f342adca3afc ("powerpc/32s: Prepare Kernel Userspace Access Protection") Cc: stable@vger.kernel.org # v5.2+ Reported-by: Christoph Plattner Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/4a0c6e3bb8f0c162457bf54d9bc6fd8d7b55129f.1612160907.git.christophe.leroy@csgroup.eu Signed-off-by: Greg Kroah-Hartman commit da9f2219f66c54e56be803c57dfc21bcc0d70340 Author: Lorenzo Bianconi Date: Sun Feb 7 12:48:31 2021 +0100 mt76: dma: do not report truncated frames to mac80211 commit d0bd52c591a1070c54dc428e926660eb4f981099 upstream. Commit b102f0c522cf6 ("mt76: fix array overflow on receiving too many fragments for a packet") fixes a possible OOB access but it introduces a memory leak since the pending frame is not released to page_frag_cache if the frag array of skb_shared_info is full. Commit 93a1d4791c10 ("mt76: dma: fix a possible memory leak in mt76_add_fragment()") fixes the issue but does not free the truncated skb that is forwarded to mac80211 layer. Fix the leftover issue discarding even truncated skbs. Fixes: 93a1d4791c10 ("mt76: dma: fix a possible memory leak in mt76_add_fragment()") Signed-off-by: Lorenzo Bianconi Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/a03166fcc8214644333c68674a781836e0f57576.1612697217.git.lorenzo@kernel.org Signed-off-by: Greg Kroah-Hartman commit 95b0a3b09094ddede160b5ffde6154c7acb40e41 Author: Jiri Wiesner Date: Thu Mar 4 17:18:28 2021 +0100 ibmvnic: always store valid MAC address commit 67eb211487f0c993d9f402d1c196ef159fd6a3b5 upstream. The last change to ibmvnic_set_mac(), 8fc3672a8ad3, meant to prevent users from setting an invalid MAC address on an ibmvnic interface that has not been brought up yet. The change also prevented the requested MAC address from being stored by the adapter object for an ibmvnic interface when the state of the ibmvnic interface is VNIC_PROBED - that is after probing has finished but before the ibmvnic interface is brought up. The MAC address stored by the adapter object is used and sent to the hypervisor for checking when an ibmvnic interface is brought up. The ibmvnic driver ignoring the requested MAC address when in VNIC_PROBED state caused LACP bonds (bonds in 802.3ad mode) with more than one slave to malfunction. The bonding code must be able to change the MAC address of its slaves before they are brought up during enslaving. The inability of kernels with 8fc3672a8ad3 to set the MAC addresses of bonding slaves is observable in the output of "ip address show". The MAC addresses of the slaves are the same as the MAC address of the bond on a working system whereas the slaves retain their original MAC addresses on a system with a malfunctioning LACP bond. Fixes: 8fc3672a8ad3 ("ibmvnic: fix ibmvnic_set_mac") Signed-off-by: Jiri Wiesner Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3e8ab75f3301aa32d9a61c0971a4a8120b5d950a Author: Maciej Fijalkowski Date: Wed Mar 3 19:56:35 2021 +0100 samples, bpf: Add missing munmap in xdpsock commit 6bc6699881012b5bd5d49fa861a69a37fc01b49c upstream. We mmap the umem region, but we never munmap it. Add the missing call at the end of the cleanup. Fixes: 3945b37a975d ("samples/bpf: use hugepages in xdpsock app") Signed-off-by: Maciej Fijalkowski Signed-off-by: Daniel Borkmann Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/20210303185636.18070-3-maciej.fijalkowski@intel.com Signed-off-by: Greg Kroah-Hartman commit c2c3a85ab01f1689805759c03137bbef296de50f Author: Yauheni Kaliuta Date: Sun Feb 28 12:30:17 2021 +0200 selftests/bpf: Mask bpf_csum_diff() return value to 16 bits in test_verifier commit 6185266c5a853bb0f2a459e3ff594546f277609b upstream. The verifier test labelled "valid read map access into a read-only array 2" calls the bpf_csum_diff() helper and checks its return value. However, architecture implementations of csum_partial() (which is what the helper uses) differ in whether they fold the return value to 16 bit or not. For example, x86 version has ... if (unlikely(odd)) { result = from32to16(result); result = ((result >> 8) & 0xff) | ((result & 0xff) << 8); } ... while generic lib/checksum.c does: result = from32to16(result); if (odd) result = ((result >> 8) & 0xff) | ((result & 0xff) << 8); This makes the helper return different values on different architectures, breaking the test on non-x86. To fix this, add an additional instruction to always mask the return value to 16 bits, and update the expected return value accordingly. Fixes: fb2abb73e575 ("bpf, selftest: test {rd, wr}only flags and direct value access") Signed-off-by: Yauheni Kaliuta Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20210228103017.320240-1-yauheni.kaliuta@redhat.com Signed-off-by: Greg Kroah-Hartman commit 57b9f13e8aaa61a5ba0218e8eb99fc7320f8e822 Author: Hangbin Liu Date: Wed Feb 24 16:14:03 2021 +0800 selftests/bpf: No need to drop the packet when there is no geneve opt commit 557c223b643a35effec9654958d8edc62fd2603a upstream. In bpf geneve tunnel test we set geneve option on tx side. On rx side we only call bpf_skb_get_tunnel_opt(). Since commit 9c2e14b48119 ("ip_tunnels: Set tunnel option flag when tunnel metadata is present") geneve_rx() will not add TUNNEL_GENEVE_OPT flag if there is no geneve option, which cause bpf_skb_get_tunnel_opt() return ENOENT and _geneve_get_tunnel() in test_tunnel_kern.c drop the packet. As it should be valid that bpf_skb_get_tunnel_opt() return error when there is not tunnel option, there is no need to drop the packet and break all geneve rx traffic. Just set opt_class to 0 in this test and keep returning TC_ACT_OK. Fixes: 933a741e3b82 ("selftests/bpf: bpf tunnel test.") Signed-off-by: Hangbin Liu Signed-off-by: Daniel Borkmann Acked-by: William Tu Link: https://lore.kernel.org/bpf/20210224081403.1425474-1-liuhangbin@gmail.com Signed-off-by: Greg Kroah-Hartman commit 82e85c0e7f34d1a667e420926c8c94aaa5d7aa8c Author: Vasily Averin Date: Sat Feb 27 11:27:45 2021 +0300 netfilter: x_tables: gpf inside xt_find_revision() commit 8e24edddad152b998b37a7f583175137ed2e04a5 upstream. nested target/match_revfn() calls work with xt[NFPROTO_UNSPEC] lists without taking xt[NFPROTO_UNSPEC].mutex. This can race with module unload and cause host to crash: general protection fault: 0000 [#1] Modules linked in: ... [last unloaded: xt_cluster] CPU: 0 PID: 542455 Comm: iptables RIP: 0010:[] [] strcmp+0x18/0x40 RDX: 0000000000000003 RSI: ffff9a5a5d9abe10 RDI: dead000000000111 R13: ffff9a5a5d9abe10 R14: ffff9a5a5d9abd8c R15: dead000000000100 (VvS: %R15 -- &xt_match, %RDI -- &xt_match.name, xt_cluster unregister match in xt[NFPROTO_UNSPEC].match list) Call Trace: [] match_revfn+0x54/0xc0 [] match_revfn+0xaf/0xc0 [] xt_find_revision+0x6e/0xf0 [] do_ipt_get_ctl+0x100/0x420 [ip_tables] [] nf_getsockopt+0x4f/0x70 [] ip_getsockopt+0xde/0x100 [] raw_getsockopt+0x25/0x50 [] sock_common_getsockopt+0x1a/0x20 [] SyS_getsockopt+0x7d/0xf0 [] system_call_fastpath+0x25/0x2a Fixes: 656caff20e1 ("netfilter 04/09: x_tables: fix match/target revision lookup") Signed-off-by: Vasily Averin Reviewed-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit f66b8e738140e92ef305964216f6c0524c39f664 Author: Florian Westphal Date: Wed Feb 24 17:23:19 2021 +0100 netfilter: nf_nat: undo erroneous tcp edemux lookup commit 03a3ca37e4c6478e3a84f04c8429dd5889e107fd upstream. Under extremely rare conditions TCP early demux will retrieve the wrong socket. 1. local machine establishes a connection to a remote server, S, on port p. This gives: laddr:lport -> S:p ... both in tcp and conntrack. 2. local machine establishes a connection to host H, on port p2. 2a. TCP stack choses same laddr:lport, so we have laddr:lport -> H:p2 from TCP point of view. 2b). There is a destination NAT rewrite in place, translating H:p2 to S:p. This results in following conntrack entries: I) laddr:lport -> S:p (origin) S:p -> laddr:lport (reply) II) laddr:lport -> H:p2 (origin) S:p -> laddr:lport2 (reply) NAT engine has rewritten laddr:lport to laddr:lport2 to map the reply packet to the correct origin. When server sends SYN/ACK to laddr:lport2, the PREROUTING hook will undo-the SNAT transformation, rewriting IP header to S:p -> laddr:lport This causes TCP early demux to associate the skb with the TCP socket of the first connection. The INPUT hook will then reverse the DNAT transformation, rewriting the IP header to H:p2 -> laddr:lport. Because packet ends up with the wrong socket, the new connection never completes: originator stays in SYN_SENT and conntrack entry remains in SYN_RECV until timeout, and responder retransmits SYN/ACK until it gives up. To resolve this, orphan the skb after the input rewrite: Because the source IP address changed, the socket must be incorrect. We can't move the DNAT undo to prerouting due to backwards compatibility, doing so will make iptables/nftables rules to no longer match the way they did. After orphan, the packet will be handed to the next protocol layer (tcp, udp, ...) and that will repeat the socket lookup just like as if early demux was disabled. Fixes: 41063e9dd1195 ("ipv4: Early TCP socket demux.") Closes: https://bugzilla.netfilter.org/show_bug.cgi?id=1427 Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 3bf899438c123c444f6b644a57784dfbb6b15ad6 Author: Eric Dumazet Date: Mon Mar 1 10:29:17 2021 -0800 tcp: add sanity tests to TCP_QUEUE_SEQ commit 8811f4a9836e31c14ecdf79d9f3cb7c5d463265d upstream. Qingyu Li reported a syzkaller bug where the repro changes RCV SEQ _after_ restoring data in the receive queue. mprotect(0x4aa000, 12288, PROT_READ) = 0 mmap(0x1ffff000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x1ffff000 mmap(0x20000000, 16777216, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x20000000 mmap(0x21000000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x21000000 socket(AF_INET6, SOCK_STREAM, IPPROTO_IP) = 3 setsockopt(3, SOL_TCP, TCP_REPAIR, [1], 4) = 0 connect(3, {sa_family=AF_INET6, sin6_port=htons(0), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_scope_id=0}, 28) = 0 setsockopt(3, SOL_TCP, TCP_REPAIR_QUEUE, [1], 4) = 0 sendmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="0x0000000000000003\0\0", iov_len=20}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 20 setsockopt(3, SOL_TCP, TCP_REPAIR, [0], 4) = 0 setsockopt(3, SOL_TCP, TCP_QUEUE_SEQ, [128], 4) = 0 recvfrom(3, NULL, 20, 0, NULL, NULL) = -1 ECONNRESET (Connection reset by peer) syslog shows: [ 111.205099] TCP recvmsg seq # bug 2: copied 80, seq 0, rcvnxt 80, fl 0 [ 111.207894] WARNING: CPU: 1 PID: 356 at net/ipv4/tcp.c:2343 tcp_recvmsg_locked+0x90e/0x29a0 This should not be allowed. TCP_QUEUE_SEQ should only be used when queues are empty. This patch fixes this case, and the tx path as well. Fixes: ee9952831cfd ("tcp: Initial repair mode") Signed-off-by: Eric Dumazet Cc: Pavel Emelyanov Link: https://bugzilla.kernel.org/show_bug.cgi?id=212005 Reported-by: Qingyu Li Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b7049b6156ce417dff30bb411bb56b534534ce79 Author: Torin Cooper-Bennun Date: Fri Feb 26 16:34:41 2021 +0000 can: tcan4x5x: tcan4x5x_init(): fix initialization - clear MRAM before entering Normal Mode commit 2712625200ed69c642b9abc3a403830c4643364c upstream. This patch prevents a potentially destructive race condition. The device is fully operational on the bus after entering Normal Mode, so zeroing the MRAM after entering this mode may lead to loss of information, e.g. new received messages. This patch fixes the problem by first initializing the MRAM, then bringing the device into Normale Mode. Fixes: 5443c226ba91 ("can: tcan4x5x: Add tcan4x5x driver to the kernel") Link: https://lore.kernel.org/r/20210226163440.313628-1-torin@maxiluxsystems.com Suggested-by: Marc Kleine-Budde Signed-off-by: Torin Cooper-Bennun Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit a7e187a87e8e0a7654d6e877cfc44d90730bc913 Author: Joakim Zhang Date: Thu Feb 18 19:00:37 2021 +0800 can: flexcan: invoke flexcan_chip_freeze() to enter freeze mode commit c63820045e2000f05657467a08715c18c9f490d9 upstream. Invoke flexcan_chip_freeze() to enter freeze mode, since need poll freeze mode acknowledge. Fixes: e955cead03117 ("CAN: Add Flexcan CAN controller driver") Link: https://lore.kernel.org/r/20210218110037.16591-4-qiangqing.zhang@nxp.com Signed-off-by: Joakim Zhang Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit e0eccdfc5c0e6da42d47e2405f01f0aeb075cf3e Author: Joakim Zhang Date: Thu Feb 18 19:00:36 2021 +0800 can: flexcan: enable RX FIFO after FRZ/HALT valid commit ec15e27cc8904605846a354bb1f808ea1432f853 upstream. RX FIFO enable failed could happen when do system reboot stress test: [ 0.303958] flexcan 5a8d0000.can: 5a8d0000.can supply xceiver not found, using dummy regulator [ 0.304281] flexcan 5a8d0000.can (unnamed net_device) (uninitialized): Could not enable RX FIFO, unsupported core [ 0.314640] flexcan 5a8d0000.can: registering netdev failed [ 0.320728] flexcan 5a8e0000.can: 5a8e0000.can supply xceiver not found, using dummy regulator [ 0.320991] flexcan 5a8e0000.can (unnamed net_device) (uninitialized): Could not enable RX FIFO, unsupported core [ 0.331360] flexcan 5a8e0000.can: registering netdev failed [ 0.337444] flexcan 5a8f0000.can: 5a8f0000.can supply xceiver not found, using dummy regulator [ 0.337716] flexcan 5a8f0000.can (unnamed net_device) (uninitialized): Could not enable RX FIFO, unsupported core [ 0.348117] flexcan 5a8f0000.can: registering netdev failed RX FIFO should be enabled after the FRZ/HALT are valid. But the current code enable RX FIFO and FRZ/HALT at the same time. Fixes: e955cead03117 ("CAN: Add Flexcan CAN controller driver") Link: https://lore.kernel.org/r/20210218110037.16591-3-qiangqing.zhang@nxp.com Signed-off-by: Joakim Zhang Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit ca483b872d20a9d9ab2d6b46a9a197735af387fc Author: Joakim Zhang Date: Thu Feb 18 19:00:35 2021 +0800 can: flexcan: assert FRZ bit in flexcan_chip_freeze() commit 449052cfebf624b670faa040245d3feed770d22f upstream. Assert HALT bit to enter freeze mode, there is a premise that FRZ bit is asserted. This patch asserts FRZ bit in flexcan_chip_freeze, although the reset value is 1b'1. This is a prepare patch, later patch will invoke flexcan_chip_freeze() to enter freeze mode, which polling freeze mode acknowledge. Fixes: b1aa1c7a2165b ("can: flexcan: fix transition from and to freeze mode in chip_{,un}freeze") Link: https://lore.kernel.org/r/20210218110037.16591-2-qiangqing.zhang@nxp.com Signed-off-by: Joakim Zhang Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 6676e510d1a9c6f5ae0031705ef6020dfe63372b Author: Oleksij Rempel Date: Fri Feb 26 10:24:56 2021 +0100 can: skb: can_skb_set_owner(): fix ref counting if socket was closed before setting skb ownership commit e940e0895a82c6fbaa259f2615eb52b57ee91a7e upstream. There are two ref count variables controlling the free()ing of a socket: - struct sock::sk_refcnt - which is changed by sock_hold()/sock_put() - struct sock::sk_wmem_alloc - which accounts the memory allocated by the skbs in the send path. In case there are still TX skbs on the fly and the socket() is closed, the struct sock::sk_refcnt reaches 0. In the TX-path the CAN stack clones an "echo" skb, calls sock_hold() on the original socket and references it. This produces the following back trace: | WARNING: CPU: 0 PID: 280 at lib/refcount.c:25 refcount_warn_saturate+0x114/0x134 | refcount_t: addition on 0; use-after-free. | Modules linked in: coda_vpu(E) v4l2_jpeg(E) videobuf2_vmalloc(E) imx_vdoa(E) | CPU: 0 PID: 280 Comm: test_can.sh Tainted: G E 5.11.0-04577-gf8ff6603c617 #203 | Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) | Backtrace: | [<80bafea4>] (dump_backtrace) from [<80bb0280>] (show_stack+0x20/0x24) r7:00000000 r6:600f0113 r5:00000000 r4:81441220 | [<80bb0260>] (show_stack) from [<80bb593c>] (dump_stack+0xa0/0xc8) | [<80bb589c>] (dump_stack) from [<8012b268>] (__warn+0xd4/0x114) r9:00000019 r8:80f4a8c2 r7:83e4150c r6:00000000 r5:00000009 r4:80528f90 | [<8012b194>] (__warn) from [<80bb09c4>] (warn_slowpath_fmt+0x88/0xc8) r9:83f26400 r8:80f4a8d1 r7:00000009 r6:80528f90 r5:00000019 r4:80f4a8c2 | [<80bb0940>] (warn_slowpath_fmt) from [<80528f90>] (refcount_warn_saturate+0x114/0x134) r8:00000000 r7:00000000 r6:82b44000 r5:834e5600 r4:83f4d540 | [<80528e7c>] (refcount_warn_saturate) from [<8079a4c8>] (__refcount_add.constprop.0+0x4c/0x50) | [<8079a47c>] (__refcount_add.constprop.0) from [<8079a57c>] (can_put_echo_skb+0xb0/0x13c) | [<8079a4cc>] (can_put_echo_skb) from [<8079ba98>] (flexcan_start_xmit+0x1c4/0x230) r9:00000010 r8:83f48610 r7:0fdc0000 r6:0c080000 r5:82b44000 r4:834e5600 | [<8079b8d4>] (flexcan_start_xmit) from [<80969078>] (netdev_start_xmit+0x44/0x70) r9:814c0ba0 r8:80c8790c r7:00000000 r6:834e5600 r5:82b44000 r4:82ab1f00 | [<80969034>] (netdev_start_xmit) from [<809725a4>] (dev_hard_start_xmit+0x19c/0x318) r9:814c0ba0 r8:00000000 r7:82ab1f00 r6:82b44000 r5:00000000 r4:834e5600 | [<80972408>] (dev_hard_start_xmit) from [<809c6584>] (sch_direct_xmit+0xcc/0x264) r10:834e5600 r9:00000000 r8:00000000 r7:82b44000 r6:82ab1f00 r5:834e5600 r4:83f27400 | [<809c64b8>] (sch_direct_xmit) from [<809c6c0c>] (__qdisc_run+0x4f0/0x534) To fix this problem, only set skb ownership to sockets which have still a ref count > 0. Fixes: 0ae89beb283a ("can: add destructor for self generated skbs") Cc: Oliver Hartkopp Cc: Andre Naujoks Link: https://lore.kernel.org/r/20210226092456.27126-1-o.rempel@pengutronix.de Suggested-by: Eric Dumazet Signed-off-by: Oleksij Rempel Reviewed-by: Oliver Hartkopp Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 718769eb1bbe35ba6f01532095e43f7ef81dfbfb Author: Sergey Shtylyov Date: Sun Feb 28 23:25:43 2021 +0300 sh_eth: fix TRSCER mask for SH771x commit 8c91bc3d44dfef8284af384877fbe61117e8b7d1 upstream. According to the SH7710, SH7712, SH7713 Group User's Manual: Hardware, Rev. 3.00, the TRSCER register actually has only bit 7 valid (and named differently), with all the other bits reserved. Apparently, this was not the case with some early revisions of the manual as we have the other bits declared (and set) in the original driver. Follow the suit and add the explicit sh_eth_cpu_data::trscer_err_mask initializer for SH771x... Fixes: 86a74ff21a7a ("net: sh_eth: add support for Renesas SuperH Ethernet") Signed-off-by: Sergey Shtylyov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8baa52f26b3e3817ab25955653930590e6e6b6c9 Author: Balazs Nemeth Date: Tue Mar 9 12:31:01 2021 +0100 net: avoid infinite loop in mpls_gso_segment when mpls_hlen == 0 commit d348ede32e99d3a04863e9f9b28d224456118c27 upstream. A packet with skb_inner_network_header(skb) == skb_network_header(skb) and ETH_P_MPLS_UC will prevent mpls_gso_segment from pulling any headers from the packet. Subsequently, the call to skb_mac_gso_segment will again call mpls_gso_segment with the same packet leading to an infinite loop. In addition, ensure that the header length is a multiple of four, which should hold irrespective of the number of stacked labels. Signed-off-by: Balazs Nemeth Acked-by: Willem de Bruijn Reviewed-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ca278267d6cd9544645731732455b6b20cb0e895 Author: Balazs Nemeth Date: Tue Mar 9 12:31:00 2021 +0100 net: check if protocol extracted by virtio_net_hdr_set_proto is correct commit 924a9bc362a5223cd448ca08c3dde21235adc310 upstream. For gso packets, virtio_net_hdr_set_proto sets the protocol (if it isn't set) based on the type in the virtio net hdr, but the skb could contain anything since it could come from packet_snd through a raw socket. If there is a mismatch between what virtio_net_hdr_set_proto sets and the actual protocol, then the skb could be handled incorrectly later on. An example where this poses an issue is with the subsequent call to skb_flow_dissect_flow_keys_basic which relies on skb->protocol being set correctly. A specially crafted packet could fool skb_flow_dissect_flow_keys_basic preventing EINVAL to be returned. Avoid blindly trusting the information provided by the virtio net header by checking that the protocol in the packet actually matches the protocol set by virtio_net_hdr_set_proto. Note that since the protocol is only checked if skb->dev implements header_ops->parse_protocol, packets from devices without the implementation are not checked at this stage. Fixes: 9274124f023b ("net: stricter validation of untrusted gso packets") Signed-off-by: Balazs Nemeth Acked-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f2d78bbbca42e55e96b415f6f232b22844beb7c7 Author: Daniel Borkmann Date: Fri Feb 26 22:22:48 2021 +0100 net: Fix gro aggregation for udp encaps with zero csum commit 89e5c58fc1e2857ccdaae506fb8bc5fed57ee063 upstream. We noticed a GRO issue for UDP-based encaps such as vxlan/geneve when the csum for the UDP header itself is 0. In that case, GRO aggregation does not take place on the phys dev, but instead is deferred to the vxlan/geneve driver (see trace below). The reason is essentially that GRO aggregation bails out in udp_gro_receive() for such case when drivers marked the skb with CHECKSUM_UNNECESSARY (ice, i40e, others) where for non-zero csums 2abb7cdc0dc8 ("udp: Add support for doing checksum unnecessary conversion") promotes those skbs to CHECKSUM_COMPLETE and napi context has csum_valid set. This is however not the case for zero UDP csum (here: csum_cnt is still 0 and csum_valid continues to be false). At the same time 57c67ff4bd92 ("udp: additional GRO support") added matches on !uh->check ^ !uh2->check as part to determine candidates for aggregation, so it certainly is expected to handle zero csums in udp_gro_receive(). The purpose of the check added via 662880f44203 ("net: Allow GRO to use and set levels of checksum unnecessary") seems to catch bad csum and stop aggregation right away. One way to fix aggregation in the zero case is to only perform the !csum_valid check in udp_gro_receive() if uh->check is infact non-zero. Before: [...] swapper 0 [008] 731.946506: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497100400 len=1500 (1) swapper 0 [008] 731.946507: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497100200 len=1500 swapper 0 [008] 731.946507: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497101100 len=1500 swapper 0 [008] 731.946508: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497101700 len=1500 swapper 0 [008] 731.946508: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497101b00 len=1500 swapper 0 [008] 731.946508: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497100600 len=1500 swapper 0 [008] 731.946508: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497100f00 len=1500 swapper 0 [008] 731.946509: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497100a00 len=1500 swapper 0 [008] 731.946516: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497100500 len=1500 swapper 0 [008] 731.946516: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497100700 len=1500 swapper 0 [008] 731.946516: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497101d00 len=1500 (2) swapper 0 [008] 731.946517: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497101000 len=1500 swapper 0 [008] 731.946517: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497101c00 len=1500 swapper 0 [008] 731.946517: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497101400 len=1500 swapper 0 [008] 731.946518: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497100e00 len=1500 swapper 0 [008] 731.946518: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497101600 len=1500 swapper 0 [008] 731.946521: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497100800 len=774 swapper 0 [008] 731.946530: net:netif_receive_skb: dev=test_vxlan skbaddr=0xffff966497100400 len=14032 (1) swapper 0 [008] 731.946530: net:netif_receive_skb: dev=test_vxlan skbaddr=0xffff966497101d00 len=9112 (2) [...] # netperf -H 10.55.10.4 -t TCP_STREAM -l 20 MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.55.10.4 () port 0 AF_INET : demo Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 87380 16384 16384 20.01 13129.24 After: [...] swapper 0 [026] 521.862641: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff93ab0d479000 len=11286 (1) swapper 0 [026] 521.862643: net:netif_receive_skb: dev=test_vxlan skbaddr=0xffff93ab0d479000 len=11236 (1) swapper 0 [026] 521.862650: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff93ab0d478500 len=2898 (2) swapper 0 [026] 521.862650: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff93ab0d479f00 len=8490 (3) swapper 0 [026] 521.862653: net:netif_receive_skb: dev=test_vxlan skbaddr=0xffff93ab0d478500 len=2848 (2) swapper 0 [026] 521.862653: net:netif_receive_skb: dev=test_vxlan skbaddr=0xffff93ab0d479f00 len=8440 (3) [...] # netperf -H 10.55.10.4 -t TCP_STREAM -l 20 MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.55.10.4 () port 0 AF_INET : demo Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 87380 16384 16384 20.01 24576.53 Fixes: 57c67ff4bd92 ("udp: additional GRO support") Fixes: 662880f44203 ("net: Allow GRO to use and set levels of checksum unnecessary") Signed-off-by: Daniel Borkmann Cc: Eric Dumazet Cc: Jesse Brandeburg Cc: Tom Herbert Acked-by: Willem de Bruijn Acked-by: John Fastabend Link: https://lore.kernel.org/r/20210226212248.8300-1-daniel@iogearbox.net Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 9be76916119284f9f5648c78680056237becbaed Author: Felix Fietkau Date: Sun Feb 14 19:49:11 2021 +0100 ath9k: fix transmitting to stations in dynamic SMPS mode commit 3b9ea7206d7e1fdd7419cbd10badd3b2c80d04b4 upstream. When transmitting to a receiver in dynamic SMPS mode, all transmissions that use multiple spatial streams need to be sent using CTS-to-self or RTS/CTS to give the receiver's extra chains some time to wake up. This fixes the tx rate getting stuck at <= MCS7 for some clients, especially Intel ones, which make aggressive use of SMPS. Cc: stable@vger.kernel.org Reported-by: Martin Kennedy Signed-off-by: Felix Fietkau Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210214184911.96702-1-nbd@nbd.name Signed-off-by: Greg Kroah-Hartman commit 5555ee33b6cc1b05c0ed6e91767c6fef93feb663 Author: Jakub Kicinski Date: Fri Mar 5 14:17:29 2021 -0800 ethernet: alx: fix order of calls on resume commit a4dcfbc4ee2218abd567d81d795082d8d4afcdf6 upstream. netif_device_attach() will unpause the queues so we can't call it before __alx_open(). This went undetected until commit b0999223f224 ("alx: add ability to allocate and free alx_napi structures") but now if stack tries to xmit immediately on resume before __alx_open() we'll crash on the NAPI being null: BUG: kernel NULL pointer dereference, address: 0000000000000198 CPU: 0 PID: 12 Comm: ksoftirqd/0 Tainted: G OE 5.10.0-3-amd64 #1 Debian 5.10.13-1 Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./H77-D3H, BIOS F15 11/14/2013 RIP: 0010:alx_start_xmit+0x34/0x650 [alx] Code: 41 56 41 55 41 54 55 53 48 83 ec 20 0f b7 57 7c 8b 8e b0 0b 00 00 39 ca 72 06 89 d0 31 d2 f7 f1 89 d2 48 8b 84 df RSP: 0018:ffffb09240083d28 EFLAGS: 00010297 RAX: 0000000000000000 RBX: ffffa04d80ae7800 RCX: 0000000000000004 RDX: 0000000000000000 RSI: ffffa04d80afa000 RDI: ffffa04e92e92a00 RBP: 0000000000000042 R08: 0000000000000100 R09: ffffa04ea3146700 R10: 0000000000000014 R11: 0000000000000000 R12: ffffa04e92e92100 R13: 0000000000000001 R14: ffffa04e92e92a00 R15: ffffa04e92e92a00 FS: 0000000000000000(0000) GS:ffffa0508f600000(0000) knlGS:0000000000000000 i915 0000:00:02.0: vblank wait timed out on crtc 0 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000198 CR3: 000000004460a001 CR4: 00000000001706f0 Call Trace: dev_hard_start_xmit+0xc7/0x1e0 sch_direct_xmit+0x10f/0x310 Cc: # 4.9+ Fixes: bc2bebe8de8e ("alx: remove WoL support") Reported-by: Zbynek Michl Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983595 Signed-off-by: Jakub Kicinski Tested-by: Zbynek Michl Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit dcb95790821be97445116760556466d77f802aca Author: Greg Kurz Date: Mon Feb 15 10:45:06 2021 +0100 powerpc/pseries: Don't enforce MSI affinity with kdump commit f9619d5e5174867536b7e558683bc4408eab833f upstream. Depending on the number of online CPUs in the original kernel, it is likely for CPU #0 to be offline in a kdump kernel. The associated IRQs in the affinity mappings provided by irq_create_affinity_masks() are thus not started by irq_startup(), as per-design with managed IRQs. This can be a problem with multi-queue block devices driven by blk-mq : such a non-started IRQ is very likely paired with the single queue enforced by blk-mq during kdump (see blk_mq_alloc_tag_set()). This causes the device to remain silent and likely hangs the guest at some point. This is a regression caused by commit 9ea69a55b3b9 ("powerpc/pseries: Pass MSI affinity to irq_create_mapping()"). Note that this only happens with the XIVE interrupt controller because XICS has a workaround to bypass affinity, which is activated during kdump with the "noirqdistrib" kernel parameter. The issue comes from a combination of factors: - discrepancy between the number of queues detected by the multi-queue block driver, that was used to create the MSI vectors, and the single queue mode enforced later on by blk-mq because of kdump (i.e. keeping all queues fixes the issue) - CPU#0 offline (i.e. kdump always succeed with CPU#0) Given that I couldn't reproduce on x86, which seems to always have CPU#0 online even during kdump, I'm not sure where this should be fixed. Hence going for another approach : fine-grained affinity is for performance and we don't really care about that during kdump. Simply revert to the previous working behavior of ignoring affinity masks in this case only. Fixes: 9ea69a55b3b9 ("powerpc/pseries: Pass MSI affinity to irq_create_mapping()") Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Greg Kurz Reviewed-by: Laurent Vivier Reviewed-by: Cédric Le Goater Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210215094506.1196119-1-groug@kaod.org Signed-off-by: Greg Kroah-Hartman commit fd1824bf963aa6968a6d45e164c574e8da25a934 Author: Dmitry V. Levin Date: Mon Feb 22 08:00:00 2021 +0000 uapi: nfnetlink_cthelper.h: fix userspace compilation error commit c33cb0020ee6dd96cc9976d6085a7d8422f6dbed upstream. Apparently, and could not be included into the same compilation unit because of a cut-and-paste typo in the former header. Fixes: 12f7a505331e6 ("netfilter: add user-space connection tracking helper infrastructure") Cc: # v3.6 Signed-off-by: Dmitry V. Levin Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit ce615a08404c821bcb3c6f358b8f34307bfe30c9 Author: Greg Kroah-Hartman Date: Thu Mar 11 14:06:51 2021 +0100 Linux 5.4.105 Tested-by: Shuah Khan Tested-by: Guenter Roeck Tested-by: Jason Self Tested-by: Ross Schmidt Tested-by: Linux Kernel Functional Testing Tested-by: Jon Hunter Tested-by: Hulk Robot Link: https://lore.kernel.org/r/20210310132320.550932445@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit d17cf4cb1928898fae7e8bd11c0dc0af6c93812e Author: Pascal Terjan Date: Tue Feb 23 22:10:46 2021 +0000 nvme-pci: add quirks for Lexar 256GB SSD [ Upstream commit 6e6a6828c517fb6819479bf5187df5f39084eb9e ] Add the NVME_QUIRK_NO_NS_DESC_LIST and NVME_QUIRK_IGNORE_DEV_SUBNQN quirks for this buggy device. Reported and tested in https://bugs.mageia.org/show_bug.cgi?id=28417 Signed-off-by: Pascal Terjan Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 1d08ff8464849be7b2054650b027d7eafc9bad93 Author: Julian Einwag Date: Tue Feb 16 13:25:43 2021 +0100 nvme-pci: mark Seagate Nytro XM1440 as QUIRK_NO_NS_DESC_LIST. [ Upstream commit 5e112d3fb89703a4981ded60561b5647db3693bf ] The kernel fails to fully detect these SSDs, only the character devices are present: [ 10.785605] nvme nvme0: pci function 0000:04:00.0 [ 10.876787] nvme nvme1: pci function 0000:81:00.0 [ 13.198614] nvme nvme0: missing or invalid SUBNQN field. [ 13.198658] nvme nvme1: missing or invalid SUBNQN field. [ 13.206896] nvme nvme0: Shutdown timeout set to 20 seconds [ 13.215035] nvme nvme1: Shutdown timeout set to 20 seconds [ 13.225407] nvme nvme0: 16/0/0 default/read/poll queues [ 13.233602] nvme nvme1: 16/0/0 default/read/poll queues [ 13.239627] nvme nvme0: Identify Descriptors failed (8194) [ 13.246315] nvme nvme1: Identify Descriptors failed (8194) Adding the NVME_QUIRK_NO_NS_DESC_LIST fixes this problem. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205679 Signed-off-by: Julian Einwag Signed-off-by: Christoph Hellwig Reviewed-by: Keith Busch Signed-off-by: Sasha Levin commit 9106a7844efb5dc32f6569ae83160500837a088e Author: Hans de Goede Date: Sat Jan 30 21:33:23 2021 +0100 HID: i2c-hid: Add I2C_HID_QUIRK_NO_IRQ_AFTER_RESET for ITE8568 EC on Voyo Winpad A15 [ Upstream commit fc6a31b00739356809dd566e16f2c4325a63285d ] The ITE8568 EC on the Voyo Winpad A15 presents itself as an I2C-HID attached keyboard and mouse (which seems to never send any events). This needs the I2C_HID_QUIRK_NO_IRQ_AFTER_RESET quirk, otherwise we get the following errors: [ 3688.770850] i2c_hid i2c-ITE8568:00: failed to reset device. [ 3694.915865] i2c_hid i2c-ITE8568:00: failed to reset device. [ 3701.059717] i2c_hid i2c-ITE8568:00: failed to reset device. [ 3707.205944] i2c_hid i2c-ITE8568:00: failed to reset device. [ 3708.227940] i2c_hid i2c-ITE8568:00: can't add hid device: -61 [ 3708.236518] i2c_hid: probe of i2c-ITE8568:00 failed with error -61 Which leads to a significant boot delay. Signed-off-by: Hans de Goede Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit b5e10e9b30471679ee1612d34209a2aea669c6fd Author: Jisheng Zhang Date: Thu Dec 10 16:55:10 2020 +0800 mmc: sdhci-of-dwcmshc: set SDHCI_QUIRK2_PRESET_VALUE_BROKEN [ Upstream commit 5f7dfda4f2cec580c135fd81d96a05006651c128 ] The SDHCI_PRESET_FOR_* registers are not set(all read as zeros), so set the quirk. Signed-off-by: Jisheng Zhang Link: https://lore.kernel.org/r/20201210165510.76b917e5@xhacker.debian Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 21f3fb36b5a213328d6000e73f9da357c6632d70 Author: AngeloGioacchino Del Regno Date: Wed Jan 13 19:33:33 2021 +0100 drm/msm/a5xx: Remove overwriting A5XX_PC_DBG_ECO_CNTL register [ Upstream commit 8f03c30cb814213e36032084a01f49a9e604a3e3 ] The PC_DBG_ECO_CNTL register on the Adreno A5xx family gets programmed to some different values on a per-model basis. At least, this is what we intend to do here; Unfortunately, though, this register is being overwritten with a static magic number, right after applying the GPU-specific configuration (including the GPU-specific quirks) and that is effectively nullifying the efforts. Let's remove the redundant and wrong write to the PC_DBG_ECO_CNTL register in order to retain the wanted configuration for the target GPU. Signed-off-by: AngeloGioacchino Del Regno Reviewed-by: Jordan Crouse Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 1d113893ff9d1215b88e6ad4be43c5a4c428afa7 Author: Aswath Govindraju Date: Tue Jan 5 16:28:12 2021 +0530 misc: eeprom_93xx46: Add quirk to support Microchip 93LC46B eeprom [ Upstream commit f6f1f8e6e3eea25f539105d48166e91f0ab46dd1 ] A dummy zero bit is sent preceding the data during a read transfer by the Microchip 93LC46B eeprom (section 2.7 of[1]). This results in right shift of data during a read. In order to ignore this bit a quirk can be added to send an extra zero bit after the read address. Add a quirk to ignore the zero bit sent before data by adding a zero bit after the read address. [1] - https://www.mouser.com/datasheet/2/268/20001749K-277859.pdf Signed-off-by: Aswath Govindraju Link: https://lore.kernel.org/r/20210105105817.17644-3-a-govindraju@ti.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9f1f09887551e876693a6341b97aadd4f7d4e769 Author: Bjorn Helgaas Date: Tue Nov 10 16:00:57 2020 -0600 PCI: Add function 1 DMA alias quirk for Marvell 9215 SATA controller [ Upstream commit 059983790a4c963d92943e55a61fca55be427d55 ] Add function 1 DMA alias quirk for Marvell 88SS9215 PCIe SSD Controller. Link: https://bugzilla.kernel.org/show_bug.cgi?id=42679#c135 Link: https://lore.kernel.org/r/20201110220516.697934-1-helgaas@kernel.org Reported-by: John Smith Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit f40fdcb7ca294946fa58f5fe9b8f8ac9acf14997 Author: Chris Chiu Date: Tue Dec 8 14:04:14 2020 +0800 ASoC: Intel: bytcr_rt5640: Add quirk for ARCHOS Cesium 140 [ Upstream commit 1bea2256aa96a2d7b1b576eb74e29d79edc9bea8 ] Tha ARCHOS Cesium 140 tablet has problem with the jack-sensing, thus the heaset functions are not working. Add quirk for this model to select the correct input map, jack-detect options and channel map to enable jack sensing and headset microphone. This device uses IN1 for its internal MIC and JD2 for jack-detect. Signed-off-by: Chris Chiu Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20201208060414.27646-1-chiu@endlessos.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 242be7cddd258cec518f9d2ff790b2bf75713a1e Author: Jasper St. Pierre Date: Wed Dec 2 14:39:42 2020 +0800 ACPI: video: Add DMI quirk for GIGABYTE GB-BXBT-2807 [ Upstream commit 25417185e9b5ff90746d50769d2a3fcd1629e254 ] The GIGABYTE GB-BXBT-2807 is a mini-PC which uses off the shelf components, like an Intel GPU which is meant for mobile systems. As such, it, by default, has a backlight controller exposed. Unfortunately, the backlight controller only confuses userspace, which sees the existence of a backlight device node and has the unrealistic belief that there is actually a backlight there! Add a DMI quirk to force the backlight off on this system. Signed-off-by: Jasper St. Pierre Reviewed-by: Chris Chiu Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 86c8848d680adfc9877d022f2cfb10a65718c67a Author: Daniel Lee Kruse Date: Wed Sep 30 05:36:35 2020 +0200 media: cx23885: add more quirks for reset DMA on some AMD IOMMU [ Upstream commit dbf0b3a7b719eb3f72cb53c2ce7d34a012a9c261 ] On AMD Family 15h (Models 30h-3fh), I/O Memory Management Unit RiSC engine sometimes stalls, requiring a reset. As result, MythTV and w-scan won't scan channels on the AMD Kaveri APU with the Hauppauge QuadHD TV tuner card. For the solution I added the Input/Output Memory Management Unit's PCI Identity of 0x1423 to the broken_dev_id[] array, which is used by a quirks logic meant to fix similar problems with other AMD chipsets. Signed-off-by: Daniel Lee Kruse Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit fd476c6d4e1a6988920def9cbbebb92ea9e2273f Author: Ethan Warth Date: Tue Nov 17 09:48:00 2020 +0100 HID: mf: add support for 0079:1846 Mayflash/Dragonrise USB Gamecube Adapter [ Upstream commit 1008230f2abeb624f6d71b2e1c424fa4eeebbf84 ] Mayflash/Dragonrise seems to have yet another device ID for one of their Gamecube controller adapters. Previous to this commit, the adapter registered only one /dev/input/js* device, and all controller inputs (from any controller) were mapped to this device. This patch defines the 1846 USB device ID and enables the HID_QUIRK_MULTI_INPUT quirk for it, which fixes that (with the patch, four /dev/input/js* devices are created, one for each of the four controller ports). Signed-off-by: Ethan Warth Tested-by: Wladimir J. van der Laan Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit ef9fa6bb858221a426a099b8965444ee7ff65703 Author: Hans de Goede Date: Mon Nov 23 16:16:25 2020 +0100 platform/x86: acer-wmi: Add ACER_CAP_KBD_DOCK quirk for the Aspire Switch 10E SW3-016 [ Upstream commit bf753400280d1384abb783efc0b42c491d6deec3 ] Add the Acer Aspire Switch 10E SW3-016 to the list of models which use the Acer Switch WMI interface for reporting SW_TABLET_MODE. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20201123151625.5530-1-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 3a8eb20cb87b609dce6853bb5fd7324dac9cb718 Author: Hans de Goede Date: Mon Oct 19 20:56:28 2020 +0200 platform/x86: acer-wmi: Add support for SW_TABLET_MODE on Switch devices [ Upstream commit 5c54cb6c627e8f50f490e6b5656051a5ac29eab4 ] Add support for SW_TABLET_MODE on the Acer Switch 10 (SW5-012) and the acer Switch 10 (S1003) models. There is no way to detect if this is supported, so this uses DMI based quirks setting force_caps to ACER_CAP_KBD_DOCK (these devices have no other acer-wmi based functionality). The new SW_TABLET_MODE functionality can be tested on devices which are not in the DMI table by passing acer_wmi.force_caps=0x40 on the kernel commandline. Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20201019185628.264473-6-hdegoede@redhat.com Signed-off-by: Sasha Levin commit e3a3a69da1778dcd4c9144b836329bd6b41430f1 Author: Hans de Goede Date: Mon Oct 19 20:56:27 2020 +0200 platform/x86: acer-wmi: Add ACER_CAP_SET_FUNCTION_MODE capability flag [ Upstream commit 82cb8a5c395ea5be20e0fe31a8fe84380a502ca5 ] Not all devices supporting WMID_GUID3 support the wmid3_set_function_mode() call, leading to errors like these: [ 60.138358] acer_wmi: Enabling RF Button failed: 0x1 - 0xff [ 60.140036] acer_wmi: Enabling Launch Manager failed: 0x1 - 0xff Add an ACER_CAP_SET_FUNCTION_MODE capability flag, so that these calls can be disabled through the new force_caps mechanism. Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20201019185628.264473-5-hdegoede@redhat.com Signed-off-by: Sasha Levin commit b734af305c781c8bfde3ef8b5789937bd7a797d4 Author: Hans de Goede Date: Mon Oct 19 20:56:26 2020 +0200 platform/x86: acer-wmi: Add new force_caps module parameter [ Upstream commit 39aa009bb66f9d5fbd1e58ca4aa03d6e6f2c9915 ] Add a new force_caps module parameter to allow overriding the drivers builtin capability detection mechanism. This can be used to for example: -Disable rfkill functionality on devices where there is an AA OEM DMI record advertising non functional rfkill switches -Force loading of the driver on devices with a missing AA OEM DMI record Note that force_caps is -1 when unset, this allows forcing the capability field to 0, which results in acer-wmi only providing WMI hotkey handling while disabling all other (led, rfkill, backlight) functionality. Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20201019185628.264473-4-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 02518024425190aecdae9356a6b6a52b0109fde5 Author: Hans de Goede Date: Mon Oct 19 20:56:25 2020 +0200 platform/x86: acer-wmi: Cleanup accelerometer device handling [ Upstream commit 9feb0763e4985ccfae632de3bb2f029cc8389842 ] Cleanup accelerometer device handling: -Drop acer_wmi_accel_destroy instead directly call input_unregister_device. -The information tracked by the CAP_ACCEL flag mirrors acer_wmi_accel_dev being NULL. Drop the CAP flag, this is a preparation change for allowing users to override the capability flags. Dropping the flag stops users from causing a NULL pointer dereference by forcing the capability. Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20201019185628.264473-3-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 37b4324cb78e3766be8ee5c98c41ac7d8bade7fe Author: Hans de Goede Date: Mon Oct 19 20:56:24 2020 +0200 platform/x86: acer-wmi: Cleanup ACER_CAP_FOO defines [ Upstream commit 7c936d8d26afbc74deac0651d613dead2f76e81c ] Cleanup the ACER_CAP_FOO defines: -Switch to using BIT() macro. -The ACER_CAP_RFBTN flag is set, but it is never checked anywhere, drop it. -Drop the unused ACER_CAP_ANY define. Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20201019185628.264473-2-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 200e14759da5fed9e4b89390cecab4f428e17b12 Author: Tsuchiya Yuto Date: Wed Oct 28 23:23:46 2020 +0900 mwifiex: pcie: skip cancel_work_sync() on reset failure path [ Upstream commit 4add4d988f95f47493500a7a19c623827061589b ] If a reset is performed, but even the reset fails for some reasons (e.g., on Surface devices, the fw reset requires another quirks), cancel_work_sync() hangs in mwifiex_cleanup_pcie(). # firmware went into a bad state [...] [ 1608.281690] mwifiex_pcie 0000:03:00.0: info: shutdown mwifiex... [ 1608.282724] mwifiex_pcie 0000:03:00.0: rx_pending=0, tx_pending=1, cmd_pending=0 [ 1608.292400] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed [ 1608.292405] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed # reset performed after firmware went into a bad state [ 1609.394320] mwifiex_pcie 0000:03:00.0: WLAN FW already running! Skip FW dnld [ 1609.394335] mwifiex_pcie 0000:03:00.0: WLAN FW is active # but even the reset failed [ 1619.499049] mwifiex_pcie 0000:03:00.0: mwifiex_cmd_timeout_func: Timeout cmd id = 0xfa, act = 0xe000 [ 1619.499094] mwifiex_pcie 0000:03:00.0: num_data_h2c_failure = 0 [ 1619.499103] mwifiex_pcie 0000:03:00.0: num_cmd_h2c_failure = 0 [ 1619.499110] mwifiex_pcie 0000:03:00.0: is_cmd_timedout = 1 [ 1619.499117] mwifiex_pcie 0000:03:00.0: num_tx_timeout = 0 [ 1619.499124] mwifiex_pcie 0000:03:00.0: last_cmd_index = 0 [ 1619.499133] mwifiex_pcie 0000:03:00.0: last_cmd_id: fa 00 07 01 07 01 07 01 07 01 [ 1619.499140] mwifiex_pcie 0000:03:00.0: last_cmd_act: 00 e0 00 00 00 00 00 00 00 00 [ 1619.499147] mwifiex_pcie 0000:03:00.0: last_cmd_resp_index = 3 [ 1619.499155] mwifiex_pcie 0000:03:00.0: last_cmd_resp_id: 07 81 07 81 07 81 07 81 07 81 [ 1619.499162] mwifiex_pcie 0000:03:00.0: last_event_index = 2 [ 1619.499169] mwifiex_pcie 0000:03:00.0: last_event: 58 00 58 00 58 00 58 00 58 00 [ 1619.499177] mwifiex_pcie 0000:03:00.0: data_sent=0 cmd_sent=1 [ 1619.499185] mwifiex_pcie 0000:03:00.0: ps_mode=0 ps_state=0 [ 1619.499215] mwifiex_pcie 0000:03:00.0: info: _mwifiex_fw_dpc: unregister device # mwifiex_pcie_work hang happening [ 1823.233923] INFO: task kworker/3:1:44 blocked for more than 122 seconds. [ 1823.233932] Tainted: G WC OE 5.10.0-rc1-1-mainline #1 [ 1823.233935] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1823.233940] task:kworker/3:1 state:D stack: 0 pid: 44 ppid: 2 flags:0x00004000 [ 1823.233960] Workqueue: events mwifiex_pcie_work [mwifiex_pcie] [ 1823.233965] Call Trace: [ 1823.233981] __schedule+0x292/0x820 [ 1823.233990] schedule+0x45/0xe0 [ 1823.233995] schedule_timeout+0x11c/0x160 [ 1823.234003] wait_for_completion+0x9e/0x100 [ 1823.234012] __flush_work.isra.0+0x156/0x210 [ 1823.234018] ? flush_workqueue_prep_pwqs+0x130/0x130 [ 1823.234026] __cancel_work_timer+0x11e/0x1a0 [ 1823.234035] mwifiex_cleanup_pcie+0x28/0xd0 [mwifiex_pcie] [ 1823.234049] mwifiex_free_adapter+0x24/0xe0 [mwifiex] [ 1823.234060] _mwifiex_fw_dpc+0x294/0x560 [mwifiex] [ 1823.234074] mwifiex_reinit_sw+0x15d/0x300 [mwifiex] [ 1823.234080] mwifiex_pcie_reset_done+0x50/0x80 [mwifiex_pcie] [ 1823.234087] pci_try_reset_function+0x5c/0x90 [ 1823.234094] process_one_work+0x1d6/0x3a0 [ 1823.234100] worker_thread+0x4d/0x3d0 [ 1823.234107] ? rescuer_thread+0x410/0x410 [ 1823.234112] kthread+0x142/0x160 [ 1823.234117] ? __kthread_bind_mask+0x60/0x60 [ 1823.234124] ret_from_fork+0x22/0x30 [...] This is a deadlock caused by calling cancel_work_sync() in mwifiex_cleanup_pcie(): - Device resets are done via mwifiex_pcie_card_reset() - which schedules card->work to call mwifiex_pcie_card_reset_work() - which calls pci_try_reset_function(). - This leads to mwifiex_pcie_reset_done() be called on the same workqueue, which in turn calls - mwifiex_reinit_sw() and that calls - _mwifiex_fw_dpc(). The problem is now that _mwifiex_fw_dpc() calls mwifiex_free_adapter() in case firmware initialization fails. That ends up calling mwifiex_cleanup_pcie(). Note that all those calls are still running on the workqueue. So when mwifiex_cleanup_pcie() now calls cancel_work_sync(), it's really waiting on itself to complete, causing a deadlock. This commit fixes the deadlock by skipping cancel_work_sync() on a reset failure path. After this commit, when reset fails, the following output is expected to be shown: kernel: mwifiex_pcie 0000:03:00.0: info: _mwifiex_fw_dpc: unregister device kernel: mwifiex: Failed to bring up adapter: -5 kernel: mwifiex_pcie 0000:03:00.0: reinit failed: -5 To reproduce this issue, for example, try putting the root port of wifi into D3 (replace "00:1d.3" with your setup). # put into D3 (root port) sudo setpci -v -s 00:1d.3 CAP_PM+4.b=0b Cc: Maximilian Luz Signed-off-by: Tsuchiya Yuto Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20201028142346.18355-1-kitakar@gmail.com Signed-off-by: Sasha Levin commit c699a89d385ca0119135182073d4f224c027a1e3 Author: Andrey Ryabinin Date: Wed Feb 17 17:30:04 2021 +0300 iommu/amd: Fix sleeping in atomic in increase_address_space() commit 140456f994195b568ecd7fc2287a34eadffef3ca upstream. increase_address_space() calls get_zeroed_page(gfp) under spin_lock with disabled interrupts. gfp flags passed to increase_address_space() may allow sleeping, so it comes to this: BUG: sleeping function called from invalid context at mm/page_alloc.c:4342 in_atomic(): 1, irqs_disabled(): 1, pid: 21555, name: epdcbbf1qnhbsd8 Call Trace: dump_stack+0x66/0x8b ___might_sleep+0xec/0x110 __alloc_pages_nodemask+0x104/0x300 get_zeroed_page+0x15/0x40 iommu_map_page+0xdd/0x3e0 amd_iommu_map+0x50/0x70 iommu_map+0x106/0x220 vfio_iommu_type1_ioctl+0x76e/0x950 [vfio_iommu_type1] do_vfs_ioctl+0xa3/0x6f0 ksys_ioctl+0x66/0x70 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x4e/0x100 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fix this by moving get_zeroed_page() out of spin_lock/unlock section. Fixes: 754265bcab ("iommu/amd: Fix race in increase_address_space()") Signed-off-by: Andrey Ryabinin Acked-by: Will Deacon Cc: Link: https://lore.kernel.org/r/20210217143004.19165-1-arbn@yandex-team.com Signed-off-by: Joerg Roedel Signed-off-by: Andrey Ryabinin Signed-off-by: Greg Kroah-Hartman commit fa56bf637eac0c77e3a41f66113270340cabc419 Author: Hans de Goede Date: Thu Feb 18 15:17:07 2021 -0800 ACPICA: Fix race in generic_serial_bus (I2C) and GPIO op_region parameter handling commit c27f3d011b08540e68233cf56274fdc34bebb9b5 upstream. ACPICA commit c9e0116952363b0fa815143dca7e9a2eb4fefa61 The handling of the generic_serial_bus (I2C) and GPIO op_regions in acpi_ev_address_space_dispatch() passes a number of extra parameters to the address-space handler through the address-space Context pointer (instead of using more function parameters). The Context is shared between threads, so if multiple threads try to call the handler for the same address-space at the same time, then a second thread could change the parameters of a first thread while the handler is running for the first thread. An example of this race hitting is the Lenovo Yoga Tablet2 1015L, where there are both attrib_bytes accesses and attrib_byte accesses to the same address-space. The attrib_bytes access stores the number of bytes to transfer in Context->access_length. Where as for the attrib_byte access the number of bytes to transfer is always 1 and field_obj->Field.access_length is unused (so 0). Both types of accesses racing from different threads leads to the following problem: 1. Thread a. starts an attrib_bytes access, stores a non 0 value from field_obj->Field.access_length in Context->access_length 2. Thread b. starts an attrib_byte access, stores 0 in Context->access_length 3. Thread a. calls i2c_acpi_space_handler() (under Linux). Which sees that the access-type is ACPI_GSB_ACCESS_ATTRIB_MULTIBYTE and calls acpi_gsb_i2c_read_bytes(..., Context->access_length) 4. At this point Context->access_length is 0 (set by thread b.) rather then the field_obj->Field.access_length value from thread a. This 0 length reads leads to the following errors being logged: i2c i2c-0: adapter quirk: no zero length (addr 0x0078, size 0, read) i2c i2c-0: i2c read 0 bytes from client@0x78 starting at reg 0x0 failed, error: -95 Note this is just an example of the problems which this race can cause. There are likely many more (sporadic) problems caused by this race. This commit adds a new context_mutex to struct acpi_object_addr_handler and makes acpi_ev_address_space_dispatch() take that mutex when using the shared Context to pass extra parameters to an address-space handler, fixing this race. Note the new mutex must be taken *after* exiting the interpreter, therefor the existing acpi_ex_exit_interpreter() call is moved to above the code which stores the extra parameters in the Context. Link: https://github.com/acpica/acpica/commit/c9e01169 Signed-off-by: Hans de Goede Signed-off-by: Bob Moore Signed-off-by: Erik Kaneda Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit f27765adb3f67ba2542f3dfe147257be5a5549e5 Author: Jeffle Xu Date: Mon Feb 8 22:46:38 2021 -0500 dm table: fix zoned iterate_devices based device capability checks commit 24f6b6036c9eec21191646930ad42808e6180510 upstream. Fix dm_table_supports_zoned_model() and invert logic of both iterate_devices_callout_fn so that all devices' zoned capabilities are properly checked. Add one more parameter to dm_table_any_dev_attr(), which is actually used as the @data parameter of iterate_devices_callout_fn, so that dm_table_matches_zone_sectors() can be replaced by dm_table_any_dev_attr(). Fixes: dd88d313bef02 ("dm table: add zoned block devices validation") Cc: stable@vger.kernel.org Signed-off-by: Jeffle Xu Signed-off-by: Mike Snitzer [jeffle: also convert partial completion check] Signed-off-by: Greg Kroah-Hartman commit 06ef17b886762e4f921d755453f349d84f51ca60 Author: Jeffle Xu Date: Mon Feb 8 22:34:36 2021 -0500 dm table: fix DAX iterate_devices based device capability checks commit 5b0fab508992c2e120971da658ce80027acbc405 upstream. Fix dm_table_supports_dax() and invert logic of both iterate_devices_callout_fn so that all devices' DAX capabilities are properly checked. Fixes: 545ed20e6df6 ("dm: add infrastructure for DAX support") Cc: stable@vger.kernel.org Signed-off-by: Jeffle Xu Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit b8aedc65db40cdb2393a9ae1b6193c6c297ae5c8 Author: Jeffle Xu Date: Tue Feb 2 11:35:28 2021 +0800 dm table: fix iterate_devices based device capability checks commit a4c8dd9c2d0987cf542a2a0c42684c9c6d78a04e upstream. According to the definition of dm_iterate_devices_fn: * This function must iterate through each section of device used by the * target until it encounters a non-zero return code, which it then returns. * Returns zero if no callout returned non-zero. For some target type (e.g. dm-stripe), one call of iterate_devices() may iterate multiple underlying devices internally, in which case a non-zero return code returned by iterate_devices_callout_fn will stop the iteration in advance. No iterate_devices_callout_fn should return non-zero unless device iteration should stop. Rename dm_table_requires_stable_pages() to dm_table_any_dev_attr() and elevate it for reuse to stop iterating (and return non-zero) on the first device that causes iterate_devices_callout_fn to return non-zero. Use dm_table_any_dev_attr() to properly iterate through devices. Rename device_is_nonrot() to device_is_rotational() and invert logic accordingly to fix improper disposition. Fixes: c3c4555edd10 ("dm table: clear add_random unless all devices have it set") Fixes: 4693c9668fdc ("dm table: propagate non rotational flag") Cc: stable@vger.kernel.org Signed-off-by: Jeffle Xu Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit c1f5fc082beb8653f814711b838b51186cc696e2 Author: Alexander Lobakin Date: Tue Apr 21 16:41:08 2020 +0300 net: dsa: add GRO support via gro_cells commit e131a5634830047923c694b4ce0c3b31745ff01b upstream. gro_cells lib is used by different encapsulating netdevices, such as geneve, macsec, vxlan etc. to speed up decapsulated traffic processing. CPU tag is a sort of "encapsulation", and we can use the same mechs to greatly improve overall DSA performance. skbs are passed to the GRO layer after removing CPU tags, so we don't need any new packet offload types as it was firstly proposed by me in the first GRO-over-DSA variant [1]. The size of struct gro_cells is sizeof(void *), so hot struct dsa_slave_priv becomes only 4/8 bytes bigger, and all critical fields remain in one 32-byte cacheline. The other positive side effect is that drivers for network devices that can be shipped as CPU ports of DSA-driven switches can now use napi_gro_frags() to pass skbs to kernel. Packets built that way are completely non-linear and are likely being dropped without GRO. This was tested on to-be-mainlined-soon Ethernet driver that uses napi_gro_frags(), and the overall performance was on par with the variant from [1], sometimes even better due to minimal overhead. net.core.gro_normal_batch tuning may help to push it to the limit on particular setups and platforms. iperf3 IPoE VLAN NAT TCP forwarding (port1.218 -> port0) setup on 1.2 GHz MIPS board: 5.7-rc2 baseline: [ID] Interval Transfer Bitrate Retr [ 5] 0.00-120.01 sec 9.00 GBytes 644 Mbits/sec 413 sender [ 5] 0.00-120.00 sec 8.99 GBytes 644 Mbits/sec receiver Iface RX packets TX packets eth0 7097731 7097702 port0 426050 6671829 port1 6671681 425862 port1.218 6671677 425851 With this patch: [ID] Interval Transfer Bitrate Retr [ 5] 0.00-120.01 sec 12.2 GBytes 870 Mbits/sec 122 sender [ 5] 0.00-120.00 sec 12.2 GBytes 870 Mbits/sec receiver Iface RX packets TX packets eth0 9474792 9474777 port0 455200 353288 port1 9019592 455035 port1.218 353144 455024 v2: - Add some performance examples in the commit message; - No functional changes. [1] https://lore.kernel.org/netdev/20191230143028.27313-1-alobakin@dlink.ru/ Signed-off-by: Alexander Lobakin Signed-off-by: David S. Miller Cc: Pali Rohár Signed-off-by: Greg Kroah-Hartman commit 84d5d3c9d3fbcee10bc16d3a3316af9a924c91c6 Author: Greg Kroah-Hartman Date: Tue Mar 9 11:09:39 2021 +0100 Linux 5.4.104 Tested-by: Florian Fainelli Tested-by: Jon Hunter Tested-by: Jason Self Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Link: https://lore.kernel.org/r/20210308122714.391917404@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit d859388ea25a32ec1bbe60a0e40fd60c9a17353b Author: Heiner Kallweit Date: Sun Feb 14 17:38:30 2021 +0100 r8169: fix resuming from suspend on RTL8105e if machine runs on battery commit d2a04370817fc7b0172dad2ef2decf907e1a304e upstream. Armin reported that after referenced commit his RTL8105e is dead when resuming from suspend and machine runs on battery. This patch has been confirmed to fix the issue. Fixes: e80bd76fbf56 ("r8169: work around power-saving bug on some chip versions") Reported-by: Armin Wolf Tested-by: Armin Wolf Signed-off-by: Heiner Kallweit Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1fba84f3c4913a8065cf51f909c1cc09fb2c6c71 Author: Dan Carpenter Date: Wed Mar 3 13:59:12 2021 +0300 rsxx: Return -EFAULT if copy_to_user() fails [ Upstream commit 77516d25f54912a7baedeeac1b1b828b6f285152 ] The copy_to_user() function returns the number of bytes remaining but we want to return -EFAULT to the user if it can't complete the copy. The "st" variable only holds zero on success or negative error codes on failure so the type should be int. Fixes: 36f988e978f8 ("rsxx: Adding in debugfs entries.") Signed-off-by: Dan Carpenter Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 77a81b10f894f5e41f519ed1721c381ee24e3507 Author: Chen Jun Date: Mon Feb 22 13:58:40 2021 +0000 ftrace: Have recordmcount use w8 to read relp->r_info in arm64_is_fake_mcount [ Upstream commit 999340d51174ce4141dd723105d4cef872b13ee9 ] On little endian system, Use aarch64_be(gcc v7.3) downloaded from linaro.org to build image with CONFIG_CPU_BIG_ENDIAN = y, CONFIG_FTRACE = y, CONFIG_DYNAMIC_FTRACE = y. gcc will create symbols of _mcount but recordmcount can not create mcount_loc for *.o. aarch64_be-linux-gnu-objdump -r fs/namei.o | grep mcount 00000000000000d0 R_AARCH64_CALL26 _mcount ... 0000000000007190 R_AARCH64_CALL26 _mcount The reason is than funciton arm64_is_fake_mcount can not work correctly. A symbol of _mcount in *.o compiled with big endian compiler likes: 00 00 00 2d 00 00 01 1b w(rp->r_info) will return 0x2d instead of 0x011b. Because w() takes uint32_t as parameter, which truncates rp->r_info. Use w8() instead w() to read relp->r_info Link: https://lkml.kernel.org/r/20210222135840.56250-1-chenjun102@huawei.com Fixes: ea0eada45632 ("recordmcount: only record relocation of type R_AARCH64_CALL26 on arm64.") Acked-by: Will Deacon Signed-off-by: Chen Jun Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 9a20e5782d2dff78683f5871cbae55f67451290d Author: Pierre-Louis Bossart Date: Mon Mar 1 18:01:46 2021 -0600 ALSA: hda: intel-nhlt: verify config type [ Upstream commit a864e8f159b13babf552aff14a5fbe11abc017e4 ] Multiple bug reports report issues with the SOF and SST drivers when dealing with single microphone cases. We currently read the DMIC array information unconditionally but we don't check that the configuration type is actually a mic array. When the DMIC link does not rely on a mic array configuration, the recommendation is to check the format information to infer the maximum number of channels, and map this to the number of microphones. This leaves a potential for a mismatch between actual microphones available in hardware and what the ACPI table contains, but we have no other source of information. Note that single microphone configurations can alternatively be handled with a 'mic array' configuration along with a 'vendor-defined' geometry. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201251 BugLink: https://github.com/thesofproject/linux/issues/2725 Fixes: 7a33ea70e1868 ('ALSA: hda: intel-nhlt: handle NHLT VENDOR_DEFINED DMIC geometry') Signed-off-by: Pierre-Louis Bossart Reviewed-by: Guennadi Liakhovetski Reviewed-by: Rander Wang Reviewed-by: Kai Vehmanen Link: https://lore.kernel.org/r/20210302000146.1177770-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 86b3b62b81c569f4d2bf8363a2db894c5e57ed99 Author: YueHaibing Date: Mon Feb 22 20:23:43 2021 +0800 IB/mlx5: Add missing error code [ Upstream commit 3a9b3d4536e0c25bd3906a28c1f584177e49dd0f ] Set err to -ENOMEM if kzalloc fails instead of 0. Fixes: 759738537142 ("IB/mlx5: Enable subscription for device events over DEVX") Link: https://lore.kernel.org/r/20210222122343.19720-1-yuehaibing@huawei.com Signed-off-by: YueHaibing Acked-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 809ef2660c1be0b581d14d1aa6cf194a4ce709f0 Author: Julian Braha Date: Fri Feb 19 18:32:26 2021 -0500 RDMA/rxe: Fix missing kconfig dependency on CRYPTO [ Upstream commit 475f23b8c66d2892ad6acbf90ed757cafab13de7 ] When RDMA_RXE is enabled and CRYPTO is disabled, Kbuild gives the following warning: WARNING: unmet direct dependencies detected for CRYPTO_CRC32 Depends on [n]: CRYPTO [=n] Selected by [y]: - RDMA_RXE [=y] && (INFINIBAND_USER_ACCESS [=y] || !INFINIBAND_USER_ACCESS [=y]) && INET [=y] && PCI [=y] && INFINIBAND [=y] && INFINIBAND_VIRT_DMA [=y] This is because RDMA_RXE selects CRYPTO_CRC32, without depending on or selecting CRYPTO, despite that config option being subordinate to CRYPTO. Fixes: cee2688e3cd6 ("IB/rxe: Offload CRC calculation when possible") Signed-off-by: Julian Braha Link: https://lore.kernel.org/r/21525878.NYvzQUHefP@ubuntu-mate-laptop Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 26a1af33c9cdd6c70c6e2e211e6778ead65d7918 Author: Colin Ian King Date: Sat Feb 27 00:15:27 2021 +0000 ALSA: ctxfi: cthw20k2: fix mask on conf to allow 4 bits [ Upstream commit 26a9630c72ebac7c564db305a6aee54a8edde70e ] Currently the mask operation on variable conf is just 3 bits so the switch statement case value of 8 is unreachable dead code. The function daio_mgr_dao_init can be passed a 4 bit value, function dao_rsc_init calls it with conf set to: conf = (desc->msr & 0x7) | (desc->passthru << 3); so clearly when desc->passthru is set to 1 then conf can be at least 8. Fix this by changing the mask to 0xf. Fixes: 8cc72361481f ("ALSA: SB X-Fi driver merge") Signed-off-by: Colin Ian King Link: https://lore.kernel.org/r/20210227001527.1077484-1-colin.king@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 6827415290abaebdb1313894b2262bbaad0496cd Author: Antonio Borneo Date: Thu Jun 18 02:08:44 2020 +0200 usbip: tools: fix build error for multiple definition commit d5efc2e6b98fe661dbd8dd0d5d5bfb961728e57a upstream. With GCC 10, building usbip triggers error for multiple definition of 'udev_context', in: - libsrc/vhci_driver.c:18 and - libsrc/usbip_host_common.c:27. Declare as extern the definition in libsrc/usbip_host_common.c. Signed-off-by: Antonio Borneo Acked-by: Shuah Khan Link: https://lore.kernel.org/r/20200618000844.1048309-1-borneo.antonio@gmail.com Cc: Petr Štetiar Signed-off-by: Greg Kroah-Hartman commit 078170924d84fe8f695eece167541f642da629c5 Author: Ard Biesheuvel Date: Wed Jan 13 10:11:35 2021 +0100 crypto - shash: reduce minimum alignment of shash_desc structure commit 660d2062190db131d2feaf19914e90f868fe285c upstream. Unlike many other structure types defined in the crypto API, the 'shash_desc' structure is permitted to live on the stack, which implies its contents may not be accessed by DMA masters. (This is due to the fact that the stack may be located in the vmalloc area, which requires a different virtual-to-physical translation than the one implemented by the DMA subsystem) Our definition of CRYPTO_MINALIGN_ATTR is based on ARCH_KMALLOC_MINALIGN, which may take DMA constraints into account on architectures that support non-cache coherent DMA such as ARM and arm64. In this case, the value is chosen to reflect the largest cacheline size in the system, in order to ensure that explicit cache maintenance as required by non-coherent DMA masters does not affect adjacent, unrelated slab allocations. On arm64, this value is currently set at 128 bytes. This means that applying CRYPTO_MINALIGN_ATTR to struct shash_desc is both unnecessary (as it is never used for DMA), and undesirable, given that it wastes stack space (on arm64, performing the alignment costs 112 bytes in the worst case, and the hole between the 'tfm' and '__ctx' members takes up another 120 bytes, resulting in an increased stack footprint of up to 232 bytes.) So instead, let's switch to the minimum SLAB alignment, which does not take DMA constraints into account. Note that this is a no-op for x86. Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 1f8884d044809086b55bbc598b6ad324d4330237 Author: Timothy E Baldwin Date: Sat Jan 16 15:18:54 2021 +0000 arm64: ptrace: Fix seccomp of traced syscall -1 (NO_SYSCALL) commit df84fe94708985cdfb78a83148322bcd0a699472 upstream. Since commit f086f67485c5 ("arm64: ptrace: add support for syscall emulation"), if system call number -1 is called and the process is being traced with PTRACE_SYSCALL, for example by strace, the seccomp check is skipped and -ENOSYS is returned unconditionally (unless altered by the tracer) rather than carrying out action specified in the seccomp filter. The consequence of this is that it is not possible to reliably strace a seccomp based implementation of a foreign system call interface in which r7/x8 is permitted to be -1 on entry to a system call. Also trace_sys_enter and audit_syscall_entry are skipped if a system call is skipped. Fix by removing the in_syscall(regs) check restoring the previous behaviour which is like AArch32, x86 (which uses generic code) and everything else. Cc: Oleg Nesterov Cc: Catalin Marinas Cc: Fixes: f086f67485c5 ("arm64: ptrace: add support for syscall emulation") Reviewed-by: Kees Cook Reviewed-by: Sudeep Holla Tested-by: Sudeep Holla Signed-off-by: Timothy E Baldwin Link: https://lore.kernel.org/r/90edd33b-6353-1228-791f-0336d94d5f8c@majoroak.me.uk Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 9e15b43fdaf3fe1882ad84397208cb9b6817a18f Author: Kevin Wang Date: Tue Mar 2 15:54:00 2021 +0800 drm/amdgpu: fix parameter error of RREG32_PCIE() in amdgpu_regs_pcie commit 1aa46901ee51c1c5779b3b239ea0374a50c6d9ff upstream. the register offset isn't needed division by 4 to pass RREG32_PCIE() Signed-off-by: Kevin Wang Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit b367201430dd6f02202b217d9768ca329dbe7bc9 Author: Milan Broz Date: Tue Feb 23 21:21:21 2021 +0100 dm verity: fix FEC for RS roots unaligned to block size commit df7b59ba9245c4a3115ebaa905e3e5719a3810da upstream. Optional Forward Error Correction (FEC) code in dm-verity uses Reed-Solomon code and should support roots from 2 to 24. The error correction parity bytes (of roots lengths per RS block) are stored on a separate device in sequence without any padding. Currently, to access FEC device, the dm-verity-fec code uses dm-bufio client with block size set to verity data block (usually 4096 or 512 bytes). Because this block size is not divisible by some (most!) of the roots supported lengths, data repair cannot work for partially stored parity bytes. This fix changes FEC device dm-bufio block size to "roots << SECTOR_SHIFT" where we can be sure that the full parity data is always available. (There cannot be partial FEC blocks because parity must cover whole sectors.) Because the optional FEC starting offset could be unaligned to this new block size, we have to use dm_bufio_set_sector_offset() to configure it. The problem is easily reproduced using veritysetup, e.g. for roots=13: # create verity device with RS FEC dd if=/dev/urandom of=data.img bs=4096 count=8 status=none veritysetup format data.img hash.img --fec-device=fec.img --fec-roots=13 | awk '/^Root hash/{ print $3 }' >roothash # create an erasure that should be always repairable with this roots setting dd if=/dev/zero of=data.img conv=notrunc bs=1 count=8 seek=4088 status=none # try to read it through dm-verity veritysetup open data.img test hash.img --fec-device=fec.img --fec-roots=13 $(cat roothash) dd if=/dev/mapper/test of=/dev/null bs=4096 status=noxfer # wait for possible recursive recovery in kernel udevadm settle veritysetup close test With this fix, errors are properly repaired. device-mapper: verity-fec: 7:1: FEC 0: corrected 8 errors ... Without it, FEC code usually ends on unrecoverable failure in RS decoder: device-mapper: verity-fec: 7:1: FEC 0: failed to correct: -74 ... This problem is present in all kernels since the FEC code's introduction (kernel 4.5). It is thought that this problem is not visible in Android ecosystem because it always uses a default RS roots=2. Depends-on: a14e5ec66a7a ("dm bufio: subtract the number of initial sectors in dm_bufio_get_device_size") Signed-off-by: Milan Broz Tested-by: Jérôme Carretero Reviewed-by: Sami Tolvanen Cc: stable@vger.kernel.org # 4.5+ Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 1a4182923144cef912633a02f0ccdf25498949bc Author: Mikulas Patocka Date: Tue Feb 23 21:21:20 2021 +0100 dm bufio: subtract the number of initial sectors in dm_bufio_get_device_size commit a14e5ec66a7a66e57b24e2469f9212a78460207e upstream. dm_bufio_get_device_size returns the device size in blocks. Before returning the value, we must subtract the nubmer of starting sectors. The number of starting sectors may not be divisible by block size. Note that currently, no target is using dm_bufio_set_sector_offset and dm_bufio_get_device_size simultaneously, so this change has no effect. However, an upcoming dm-verity-fec fix needs this change. Signed-off-by: Mikulas Patocka Reviewed-by: Milan Broz Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 52a6436801652d1ec4e77b47d78be92256a7692f Author: Rafael J. Wysocki Date: Thu Feb 25 19:23:27 2021 +0100 PM: runtime: Update device status before letting suppliers suspend commit 44cc89f764646b2f1f2ea5d1a08b230131707851 upstream. Because the PM-runtime status of the device is not updated in __rpm_callback(), attempts to suspend the suppliers of the given device triggered by rpm_put_suppliers() called by it may fail. Fix this by making __rpm_callback() update the device's status to RPM_SUSPENDED before calling rpm_put_suppliers() if the current status of the device is RPM_SUSPENDING and the callback just invoked by it has returned 0 (success). While at it, modify the code in __rpm_callback() to always check the device's PM-runtime status under its PM lock. Link: https://lore.kernel.org/linux-pm/CAPDyKFqm06KDw_p8WXsM4dijDbho4bb6T4k50UqqvR1_COsp8g@mail.gmail.com/ Fixes: 21d5c57b3726 ("PM / runtime: Use device links") Reported-by: Elaine Zhang Diagnosed-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki Tested-by: Elaine Zhang Reviewed-by: Ulf Hansson Cc: 4.10+ # 4.10+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit e49baccfe29907cb26a82e29ded6797c638fed92 Author: Filipe Manana Date: Fri Feb 26 17:51:44 2021 +0000 btrfs: fix warning when creating a directory with smack enabled commit fd57a98d6f0c98fa295813087f13afb26c224e73 upstream. When we have smack enabled, during the creation of a directory smack may attempt to add a "smack transmute" xattr on the inode, which results in the following warning and trace: WARNING: CPU: 3 PID: 2548 at fs/btrfs/transaction.c:537 start_transaction+0x489/0x4f0 Modules linked in: nft_objref nf_conntrack_netbios_ns (...) CPU: 3 PID: 2548 Comm: mkdir Not tainted 5.9.0-rc2smack+ #81 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 RIP: 0010:start_transaction+0x489/0x4f0 Code: e9 be fc ff ff (...) RSP: 0018:ffffc90001887d10 EFLAGS: 00010202 RAX: ffff88816f1e0000 RBX: 0000000000000201 RCX: 0000000000000003 RDX: 0000000000000201 RSI: 0000000000000002 RDI: ffff888177849000 RBP: ffff888177849000 R08: 0000000000000001 R09: 0000000000000004 R10: ffffffff825e8f7a R11: 0000000000000003 R12: ffffffffffffffe2 R13: 0000000000000000 R14: ffff88803d884270 R15: ffff8881680d8000 FS: 00007f67317b8440(0000) GS:ffff88817bcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f67247a22a8 CR3: 000000004bfbc002 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? slab_free_freelist_hook+0xea/0x1b0 ? trace_hardirqs_on+0x1c/0xe0 btrfs_setxattr_trans+0x3c/0xf0 __vfs_setxattr+0x63/0x80 smack_d_instantiate+0x2d3/0x360 security_d_instantiate+0x29/0x40 d_instantiate_new+0x38/0x90 btrfs_mkdir+0x1cf/0x1e0 vfs_mkdir+0x14f/0x200 do_mkdirat+0x6d/0x110 do_syscall_64+0x2d/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f673196ae6b Code: 8b 05 11 (...) RSP: 002b:00007ffc3c679b18 EFLAGS: 00000246 ORIG_RAX: 0000000000000053 RAX: ffffffffffffffda RBX: 00000000000001ff RCX: 00007f673196ae6b RDX: 0000000000000000 RSI: 00000000000001ff RDI: 00007ffc3c67a30d RBP: 00007ffc3c67a30d R08: 00000000000001ff R09: 0000000000000000 R10: 000055d3e39fe930 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffc3c679cd8 R14: 00007ffc3c67a30d R15: 00007ffc3c679ce0 irq event stamp: 11029 hardirqs last enabled at (11037): [] console_unlock+0x486/0x670 hardirqs last disabled at (11044): [] console_unlock+0xa1/0x670 softirqs last enabled at (8864): [] asm_call_on_stack+0xf/0x20 softirqs last disabled at (8851): [] asm_call_on_stack+0xf/0x20 This happens because at btrfs_mkdir() we call d_instantiate_new() while holding a transaction handle, which results in the following call chain: btrfs_mkdir() trans = btrfs_start_transaction(root, 5); d_instantiate_new() smack_d_instantiate() __vfs_setxattr() btrfs_setxattr_trans() btrfs_start_transaction() start_transaction() WARN_ON() --> a tansaction start has TRANS_EXTWRITERS set in its type h->orig_rsv = h->block_rsv h->block_rsv = NULL btrfs_end_transaction(trans) Besides the warning triggered at start_transaction, we set the handle's block_rsv to NULL which may cause some surprises later on. So fix this by making btrfs_setxattr_trans() not start a transaction when we already have a handle on one, stored in current->journal_info, and use that handle. We are good to use the handle because at btrfs_mkdir() we did reserve space for the xattr and the inode item. Reported-by: Casey Schaufler CC: stable@vger.kernel.org # 5.4+ Acked-by: Casey Schaufler Tested-by: Casey Schaufler Link: https://lore.kernel.org/linux-btrfs/434d856f-bd7b-4889-a6ec-e81aaebfa735@schaufler-ca.com/ Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit a87911c26a1c98868f19642e324e863d81ca8cfd Author: Nikolay Borisov Date: Tue Feb 23 15:20:42 2021 +0200 btrfs: unlock extents in btrfs_zero_range in case of quota reservation errors commit 4f6a49de64fd1b1dba5229c02047376da7cf24fd upstream. If btrfs_qgroup_reserve_data returns an error (i.e quota limit reached) the handling logic directly goes to the 'out' label without first unlocking the extent range between lockstart, lockend. This results in deadlocks as other processes try to lock the same extent. Fixes: a7f8b1c2ac21 ("btrfs: file: reserve qgroup space after the hole punch range is locked") CC: stable@vger.kernel.org # 5.10+ Reviewed-by: Qu Wenruo Signed-off-by: Nikolay Borisov Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 91bc3296bffb978d834b087daf6be022a9a06785 Author: Nikolay Borisov Date: Mon Feb 22 18:40:42 2021 +0200 btrfs: free correct amount of space in btrfs_delayed_inode_reserve_metadata commit 0f9c03d824f6f522d3bc43629635c9765546ebc5 upstream. Following commit f218ea6c4792 ("btrfs: delayed-inode: Remove wrong qgroup meta reservation calls") this function now reserves num_bytes, rather than the fixed amount of nodesize. As such this requires the same amount to be freed in case of failure. Fix this by adjusting the amount we are freeing. Fixes: f218ea6c4792 ("btrfs: delayed-inode: Remove wrong qgroup meta reservation calls") CC: stable@vger.kernel.org # 4.19+ Reviewed-by: Qu Wenruo Signed-off-by: Nikolay Borisov Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 8674c1a72a693224f5e9520df419d600691c524a Author: Dan Carpenter Date: Wed Feb 17 09:04:34 2021 +0300 btrfs: validate qgroup inherit for SNAP_CREATE_V2 ioctl commit 5011c5a663b9c6d6aff3d394f11049b371199627 upstream. The problem is we're copying "inherit" from user space but we don't necessarily know that we're copying enough data for a 64 byte struct. Then the next problem is that 'inherit' has a variable size array at the end, and we have to verify that array is the size we expected. Fixes: 6f72c7e20dba ("Btrfs: add qgroup inheritance") CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Dan Carpenter Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 0c740d2b8c614a80cea4c0fd722191bb482053d8 Author: Ira Weiny Date: Wed Jan 27 22:15:03 2021 -0800 btrfs: fix raid6 qstripe kmap commit d70cef0d46729808dc53f145372c02b145c92604 upstream. When a qstripe is required an extra page is allocated and mapped. There were 3 problems: 1) There is no corresponding call of kunmap() for the qstripe page. 2) There is no reason to map the qstripe page more than once if the number of bits set in rbio->dbitmap is greater than one. 3) There is no reason to map the parity page and unmap it each time through the loop. The page memory can continue to be reused with a single mapping on each iteration by raid6_call.gen_syndrome() without remapping. So map the page for the duration of the loop. Similarly, improve the algorithm by mapping the parity page just 1 time. Fixes: 5a6ac9eacb49 ("Btrfs, raid56: support parity scrub on raid56") CC: stable@vger.kernel.org # 4.4.x: c17af96554a8: btrfs: raid56: simplify tracking of Q stripe presence CC: stable@vger.kernel.org # 4.4.x Signed-off-by: Ira Weiny Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 909a8d2b1e7bb30711bb6c1504a656ee288adebc Author: David Sterba Date: Wed Feb 19 15:17:20 2020 +0100 btrfs: raid56: simplify tracking of Q stripe presence commit c17af96554a8a8777cbb0fd53b8497250e548b43 upstream. There are temporary variables tracking the index of P and Q stripes, but none of them is really used as such, merely for determining if the Q stripe is present. This leads to compiler warnings with -Wunused-but-set-variable and has been reported several times. fs/btrfs/raid56.c: In function ‘finish_rmw’: fs/btrfs/raid56.c:1199:6: warning: variable ‘p_stripe’ set but not used [-Wunused-but-set-variable] 1199 | int p_stripe = -1; | ^~~~~~~~ fs/btrfs/raid56.c: In function ‘finish_parity_scrub’: fs/btrfs/raid56.c:2356:6: warning: variable ‘p_stripe’ set but not used [-Wunused-but-set-variable] 2356 | int p_stripe = -1; | ^~~~~~~~ Replace the two variables with one that has a clear meaning and also get rid of the warnings. The logic that verifies that there are only 2 valid cases is unchanged. Reviewed-by: Johannes Thumshirn Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 15726df8c09ad324d26f603ab724e31dc19d70a5 Author: Jarkko Sakkinen Date: Sat Feb 20 00:55:59 2021 +0200 tpm, tpm_tis: Decorate tpm_get_timeouts() with request_locality() commit a5665ec2affdba21bff3b0d4d3aed83b3951e8ff upstream. This is shown with Samsung Chromebook Pro (Caroline) with TPM 1.2 (SLB 9670): [ 4.324298] TPM returned invalid status [ 4.324806] WARNING: CPU: 2 PID: 1 at drivers/char/tpm/tpm_tis_core.c:275 tpm_tis_status+0x86/0x8f Background ========== TCG PC Client Platform TPM Profile (PTP) Specification, paragraph 6.1 FIFO Interface Locality Usage per Register, Table 39 Register Behavior Based on Locality Setting for FIFO - a read attempt to TPM_STS_x Registers returns 0xFF in case of lack of locality. The fix ======= Decorate tpm_get_timeouts() with request_locality() and release_locality(). Fixes: a3fbfae82b4c ("tpm: take TPM chip power gating out of tpm_transmit()") Cc: James Bottomley Cc: Guenter Roeck Cc: Laurent Bigonville Cc: stable@vger.kernel.org Reported-by: Lukasz Majczak Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 6d71cbc911047254ed4bc9ae36f3273cfa3944fd Author: Lukasz Majczak Date: Tue Feb 16 10:17:49 2021 +0200 tpm, tpm_tis: Decorate tpm_tis_gen_interrupt() with request_locality() commit d53a6adfb553969809eb2b736a976ebb5146cd95 upstream. This is shown with Samsung Chromebook Pro (Caroline) with TPM 1.2 (SLB 9670): [ 4.324298] TPM returned invalid status [ 4.324806] WARNING: CPU: 2 PID: 1 at drivers/char/tpm/tpm_tis_core.c:275 tpm_tis_status+0x86/0x8f Background ========== TCG PC Client Platform TPM Profile (PTP) Specification, paragraph 6.1 FIFO Interface Locality Usage per Register, Table 39 Register Behavior Based on Locality Setting for FIFO - a read attempt to TPM_STS_x Registers returns 0xFF in case of lack of locality. The fix ======= Decorate tpm_tis_gen_interrupt() with request_locality() and release_locality(). Cc: Laurent Bigonville Cc: James Bottomley Cc: Guenter Roeck Cc: stable@vger.kernel.org Fixes: a3fbfae82b4c ("tpm: take TPM chip power gating out of tpm_transmit()") Signed-off-by: Lukasz Majczak Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit c4ca4659678e07f0a14b3b143f6fb746efe11f88 Author: Greg Kroah-Hartman Date: Sun Mar 7 12:20:50 2021 +0100 Linux 5.4.103 Tested-by: Jon Hunter Tested-by: Jason Self Tested-by: Florian Fainelli Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Link: https://lore.kernel.org/r/20210305120857.341630346@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 47478db9ad2193c43ef0a8232b21eca524a06d4d Author: Takashi Iwai Date: Wed Mar 3 15:23:46 2021 +0100 ALSA: hda/realtek: Apply dual codec quirks for MSI Godlike X570 board commit 26af17722a07597d3e556eda92c6fce8d528bc9f upstream. There is another MSI board (1462:cc34) that has dual Realtek codecs, and we need to apply the existing quirk for fixing the conflicts of Master control. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211743 Cc: Link: https://lore.kernel.org/r/20210303142346.28182-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4cf2434764632a3c4b87ad5232dbcb5eddc884b3 Author: Werner Sembach Date: Tue Mar 2 19:04:14 2021 +0100 ALSA: hda/realtek: Add quirk for Intel NUC 10 commit 73e7161eab5dee98114987239ec9c87fe8034ddb upstream. This adds a new SND_PCI_QUIRK(...) and applies it to the Intel NUC 10 devices. This fixes the issue of the devices not having audio input and output on the headset jack because the kernel does not recognize when something is plugged in. The new quirk was inspired by the quirk for the Intel NUC 8 devices, but it turned out that the NUC 10 uses another pin. This information was acquired by black box testing likely pins. Co-developed-by: Eckhart Mohr Signed-off-by: Eckhart Mohr Signed-off-by: Werner Sembach Cc: Link: https://lore.kernel.org/r/20210302180414.23194-1-wse@tuxedocomputers.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2254dfa684284047b6e2704adfbce69ec6c0a43b Author: Eckhart Mohr Date: Tue Mar 2 17:25:22 2021 +0100 ALSA: hda/realtek: Add quirk for Clevo NH55RZQ commit 48698c973e6b4dde94d87cd1ded56d9436e9c97d upstream. This applies a SND_PCI_QUIRK(...) to the Clevo NH55RZQ barebone. This fixes the issue of the device not recognizing a pluged in microphone. The device has both, a microphone only jack, and a speaker + microphone combo jack. The combo jack already works. The microphone-only jack does not recognize when a device is pluged in without this patch. Signed-off-by: Eckhart Mohr Co-developed-by: Werner Sembach Signed-off-by: Werner Sembach Cc: Link: https://lore.kernel.org/r/0eee6545-5169-ef08-6cfa-5def8cd48c86@tuxedocomputers.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 027ddd67f68583a178a9bd65220611e9f978f014 Author: Sakari Ailus Date: Sat Dec 19 23:29:58 2020 +0100 media: v4l: ioctl: Fix memory leak in video_usercopy commit fb18802a338b36f675a388fc03d2aa504a0d0899 upstream. When an IOCTL with argument size larger than 128 that also used array arguments were handled, two memory allocations were made but alas, only the latter one of them was released. This happened because there was only a single local variable to hold such a temporary allocation. Fix this by adding separate variables to hold the pointers to the temporary allocations. Reported-by: Arnd Bergmann Reported-by: syzbot+1115e79c8df6472c612b@syzkaller.appspotmail.com Fixes: d14e6d76ebf7 ("[media] v4l: Add multi-planar ioctl handling code") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Acked-by: Arnd Bergmann Acked-by: Hans Verkuil Reviewed-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 60fdceaa91ad3bd7d7171b7280492d7438492d5c Author: Jens Axboe Date: Tue Mar 2 14:53:21 2021 -0700 swap: fix swapfile read/write offset commit caf6912f3f4af7232340d500a4a2008f81b93f14 upstream. We're not factoring in the start of the file for where to write and read the swapfile, which leads to very unfortunate side effects of writing where we should not be... Fixes: dd6bd0d9c7db ("swap: use bdev_read_page() / bdev_write_page()") Signed-off-by: Jens Axboe Cc: Anthony Iliopoulos Signed-off-by: Greg Kroah-Hartman commit bebf5e8327799cfb27c5c0c361b943b0f0e0a2d7 Author: Rokudo Yan Date: Thu Feb 25 17:18:31 2021 -0800 zsmalloc: account the number of compacted pages correctly commit 2395928158059b8f9858365fce7713ce7fef62e4 upstream. There exists multiple path may do zram compaction concurrently. 1. auto-compaction triggered during memory reclaim 2. userspace utils write zram/compaction node So, multiple threads may call zs_shrinker_scan/zs_compact concurrently. But pages_compacted is a per zsmalloc pool variable and modification of the variable is not serialized(through under class->lock). There are two issues here: 1. the pages_compacted may not equal to total number of pages freed(due to concurrently add). 2. zs_shrinker_scan may not return the correct number of pages freed(issued by current shrinker). The fix is simple: 1. account the number of pages freed in zs_compact locally. 2. use actomic variable pages_compacted to accumulate total number. Link: https://lkml.kernel.org/r/20210202122235.26885-1-wu-yan@tcl.com Fixes: 860c707dca155a56 ("zsmalloc: account the number of compacted pages") Signed-off-by: Rokudo Yan Cc: Minchan Kim Cc: Sergey Senozhatsky Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f038a22632a4cb6b4db521b945469270c994f75b Author: Jan Beulich Date: Thu Feb 25 16:35:15 2021 +0100 xen-netback: respect gnttab_map_refs()'s return value commit 2991397d23ec597405b116d96de3813420bdcbc3 upstream. Commit 3194a1746e8a ("xen-netback: don't "handle" error by BUG()") dropped respective a BUG_ON() without noticing that with this the variable's value wouldn't be consumed anymore. With gnttab_set_map_op() setting all status fields to a non-zero value, in case of an error no slot should have a status of GNTST_okay (zero). This is part of XSA-367. Cc: Reported-by: kernel test robot Signed-off-by: Jan Beulich Reviewed-by: Juergen Gross Link: https://lore.kernel.org/r/d933f495-619a-0086-5fb4-1ec3cf81a8fc@suse.com Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 474773c42ffd89f7606b54443990ccf5086a4734 Author: Jan Beulich Date: Thu Feb 25 16:34:43 2021 +0100 Xen/gnttab: handle p2m update errors on a per-slot basis commit 8310b77b48c5558c140e7a57a702e7819e62f04e upstream. Bailing immediately from set_foreign_p2m_mapping() upon a p2m updating error leaves the full batch in an ambiguous state as far as the caller is concerned. Instead flags respective slots as bad, unmapping what was mapped there right away. HYPERVISOR_grant_table_op()'s return value and the individual unmap slots' status fields get used only for a one-time - there's not much we can do in case of a failure. Note that there's no GNTST_enomem or alike, so GNTST_general_error gets used. The map ops' handle fields get overwritten just to be on the safe side. This is part of XSA-367. Cc: Signed-off-by: Jan Beulich Reviewed-by: Juergen Gross Link: https://lore.kernel.org/r/96cccf5d-e756-5f53-b91a-ea269bfb9be0@suse.com Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit def70c33c478259057486c3c7798737b34797b0d Author: Chris Leech Date: Tue Feb 23 21:39:01 2021 -0800 scsi: iscsi: Verify lengths on passthrough PDUs commit f9dbdf97a5bd92b1a49cee3d591b55b11fd7a6d5 upstream. Open-iSCSI sends passthrough PDUs over netlink, but the kernel should be verifying that the provided PDU header and data lengths fall within the netlink message to prevent accessing beyond that in memory. Cc: stable@vger.kernel.org Reported-by: Adam Nichols Reviewed-by: Lee Duncan Reviewed-by: Mike Christie Signed-off-by: Chris Leech Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 567a234a231db16a99067db3d31d351d9e770a82 Author: Chris Leech Date: Tue Feb 23 18:00:17 2021 -0800 scsi: iscsi: Ensure sysfs attributes are limited to PAGE_SIZE commit ec98ea7070e94cc25a422ec97d1421e28d97b7ee upstream. As the iSCSI parameters are exported back through sysfs, it should be enforcing that they never are more than PAGE_SIZE (which should be more than enough) before accepting updates through netlink. Change all iSCSI sysfs attributes to use sysfs_emit(). Cc: stable@vger.kernel.org Reported-by: Adam Nichols Reviewed-by: Lee Duncan Reviewed-by: Greg Kroah-Hartman Reviewed-by: Mike Christie Signed-off-by: Chris Leech Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 5f4243642873c6fccc1f7382a9ea256c4d830a69 Author: Joe Perches Date: Wed Sep 16 13:40:38 2020 -0700 sysfs: Add sysfs_emit and sysfs_emit_at to format sysfs output commit 2efc459d06f1630001e3984854848a5647086232 upstream. Output defects can exist in sysfs content using sprintf and snprintf. sprintf does not know the PAGE_SIZE maximum of the temporary buffer used for outputting sysfs content and it's possible to overrun the PAGE_SIZE buffer length. Add a generic sysfs_emit function that knows that the size of the temporary buffer and ensures that no overrun is done. Add a generic sysfs_emit_at function that can be used in multiple call situations that also ensures that no overrun is done. Validate the output buffer argument to be page aligned. Validate the offset len argument to be within the PAGE_SIZE buf. Signed-off-by: Joe Perches Link: https://lore.kernel.org/r/884235202216d464d61ee975f7465332c86f76b2.1600285923.git.joe@perches.com Signed-off-by: Greg Kroah-Hartman commit ca3afdd0377379f5031f376aec4b0c1b0285b556 Author: Lee Duncan Date: Tue Feb 23 13:06:24 2021 -0800 scsi: iscsi: Restrict sessions and handles to admin capabilities commit 688e8128b7a92df982709a4137ea4588d16f24aa upstream. Protect the iSCSI transport handle, available in sysfs, by requiring CAP_SYS_ADMIN to read it. Also protect the netlink socket by restricting reception of messages to ones sent with CAP_SYS_ADMIN. This disables normal users from being able to end arbitrary iSCSI sessions. Cc: stable@vger.kernel.org Reported-by: Adam Nichols Reviewed-by: Chris Leech Reviewed-by: Mike Christie Signed-off-by: Lee Duncan Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit fdaec40526b4e7cf8f2b802297f85fd5768d297e Author: Hans de Goede Date: Tue Feb 16 22:35:55 2021 +0100 ASoC: Intel: bytcr_rt5640: Add quirk for the Acer One S1002 tablet [ Upstream commit c58947af08aedbdee0fce5ea6e6bf3e488ae0e2c ] The Acer One S1002 tablet is using an analog mic on IN1 and has its jack-detect connected to JD2_IN4N, instead of using the default IN3 for its internal mic and JD1_IN4P for jack-detect. Note it is also using AIF2 instead of AIF1 which is somewhat unusual, this is correctly advertised in the ACPI CHAN package, so the speakers do work without the quirk. Add a quirk for the mic and jack-detect settings. Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210216213555.36555-5-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 68b15ca91add8596c87793815ea1f49ae1263584 Author: Hans de Goede Date: Tue Feb 16 22:35:54 2021 +0100 ASoC: Intel: bytcr_rt5651: Add quirk for the Jumper EZpad 7 tablet [ Upstream commit df8359c512fa770ffa6b0b0309807d9b9825a47f ] Add a DMI quirk for the Jumper EZpad 7 tablet, this tablet has a jack-detect switch which reads 1/high when a jack is inserted, rather then using the standard active-low setup which most jack-detect switches use. All other settings are using the defaults. Add a DMI-quirk setting the defaults + the BYT_RT5651_JD_NOT_INV flags for this. Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210216213555.36555-4-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit db0e94615263c049f7f893ccedf15baf9b3affb8 Author: Hans de Goede Date: Tue Feb 16 22:35:53 2021 +0100 ASoC: Intel: bytcr_rt5640: Add quirk for the Voyo Winpad A15 tablet [ Upstream commit e1317cc9ca4ac20262895fddb065ffda4fc29cfb ] The Voyo Winpad A15 tablet uses a Bay Trail (non CR) SoC, so it is using SSP2 (AIF1) and it mostly works with the defaults. But instead of using DMIC1 it is using an analog mic on IN1, add a quirk for this. Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210216213555.36555-3-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 925ae8148535326c486f7fa55d9cf62b01ca2888 Author: Hans de Goede Date: Tue Feb 16 22:35:52 2021 +0100 ASoC: Intel: bytcr_rt5640: Add quirk for the Estar Beauty HD MID 7316R tablet [ Upstream commit bdea43fc0436c9e98fdfe151c2ed8a3fc7277404 ] The Estar Beauty HD MID 7316R tablet almost fully works with out default settings. The only problem is that it has only 1 speaker so any sounds only playing on the right channel get lost. Add a quirk for this model using the default settings + MONO_SPEAKER. Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210216213555.36555-2-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 99d2926531ac2cfa95cb1b0ed9302c5e2c62be46 Author: Juri Lelli Date: Mon Feb 8 08:35:53 2021 +0100 sched/features: Fix hrtick reprogramming [ Upstream commit 156ec6f42b8d300dbbf382738ff35c8bad8f4c3a ] Hung tasks and RCU stall cases were reported on systems which were not 100% busy. Investigation of such unexpected cases (no sign of potential starvation caused by tasks hogging the system) pointed out that the periodic sched tick timer wasn't serviced anymore after a certain point and that caused all machinery that depends on it (timers, RCU, etc.) to stop working as well. This issues was however only reproducible if HRTICK was enabled. Looking at core dumps it was found that the rbtree of the hrtimer base used also for the hrtick was corrupted (i.e. next as seen from the base root and actual leftmost obtained by traversing the tree are different). Same base is also used for periodic tick hrtimer, which might get "lost" if the rbtree gets corrupted. Much alike what described in commit 1f71addd34f4c ("tick/sched: Do not mess with an enqueued hrtimer") there is a race window between hrtimer_set_expires() in hrtick_start and hrtimer_start_expires() in __hrtick_restart() in which the former might be operating on an already queued hrtick hrtimer, which might lead to corruption of the base. Use hrtick_start() (which removes the timer before enqueuing it back) to ensure hrtick hrtimer reprogramming is entirely guarded by the base lock, so that no race conditions can occur. Signed-off-by: Juri Lelli Signed-off-by: Luis Claudio R. Goncalves Signed-off-by: Daniel Bristot de Oliveira Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://lkml.kernel.org/r/20210208073554.14629-2-juri.lelli@redhat.com Signed-off-by: Sasha Levin commit 4a3f4feeb62276c5cdc76ec88873c396aa8f5b05 Author: John David Anglin Date: Thu Jan 28 18:12:30 2021 -0500 parisc: Bump 64-bit IRQ stack size to 64 KB [ Upstream commit 31680c1d1595a59e17c14ec036b192a95f8e5f4a ] Bump 64-bit IRQ stack size to 64 KB. I had a kernel IRQ stack overflow on the mx3210 debian buildd machine. This patch increases the 64-bit IRQ stack size to 64 KB. The 64-bit stack size needs to be larger than the 32-bit stack size since registers are twice as big. Signed-off-by: John David Anglin Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit f41ed21643644ec56f3e193336feb61358460339 Author: Jim Mattson Date: Fri Feb 5 11:13:24 2021 -0800 perf/x86/kvm: Add Cascade Lake Xeon steppings to isolation_ucodes[] [ Upstream commit b3c3361fe325074d4144c29d46daae4fc5a268d5 ] Cascade Lake Xeon parts have the same model number as Skylake Xeon parts, so they are tagged with the intel_pebs_isolation quirk. However, as with Skylake Xeon H0 stepping parts, the PEBS isolation issue is fixed in all microcode versions. Add the Cascade Lake Xeon steppings (5, 6, and 7) to the isolation_ucodes[] table so that these parts benefit from Andi's optimization in commit 9b545c04abd4f ("perf/x86/kvm: Avoid unnecessary work in guest filtering"). Signed-off-by: Jim Mattson Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Andi Kleen Link: https://lkml.kernel.org/r/20210205191324.2889006-1-jmattson@google.com Signed-off-by: Sasha Levin commit 2b130871e20ad7a3148aecc0e81af2b0fc8c2df7 Author: Josef Bacik Date: Tue Dec 1 09:53:23 2020 -0500 btrfs: fix error handling in commit_fs_roots [ Upstream commit 4f4317c13a40194940acf4a71670179c4faca2b5 ] While doing error injection I would sometimes get a corrupt file system. This is because I was injecting errors at btrfs_search_slot, but would only do it one time per stack. This uncovered a problem in commit_fs_roots, where if we get an error we would just break. However we're in a nested loop, the first loop being a loop to find all the dirty fs roots, and then subsequent root updates would succeed clearing the error value. This isn't likely to happen in real scenarios, however we could potentially get a random ENOMEM once and then not again, and we'd end up with a corrupted file system. Fix this by moving the error checking around a bit to the main loop, as this is the only place where something will fail, and return the error as soon as it occurs. With this patch my reproducer no longer corrupts the file system. Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 9bf519ca55c40c6466b8d965dcb1da52263fa499 Author: Hans de Goede Date: Wed Jan 20 22:49:56 2021 +0100 ASoC: Intel: Add DMI quirk table to soc_intel_is_byt_cr() [ Upstream commit 8ade6d8b02b1ead741bd4f6c42921035caab6560 ] Some Bay Trail systems: 1. Use a non CR version of the Bay Trail SoC 2. Contain at least 6 interrupt resources so that the platform_get_resource(pdev, IORESOURCE_IRQ, 5) check to workaround non CR systems which list their IPC IRQ at index 0 despite being non CR does not work 3. Despite 1. and 2. still have their IPC IRQ at index 0 rather then 5 Add a DMI quirk table to check for the few known models with this issue, so that the right IPC IRQ index is used on these systems. Reviewed-by: Andy Shevchenko Acked-by: Pierre-Louis Bossart Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210120214957.140232-5-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7702b331861bb031ba903cbf11325d2809baa0ed Author: Chao Leng Date: Thu Jan 21 11:32:38 2021 +0800 nvme-tcp: add clean action for failed reconnection [ Upstream commit 70a99574a79f1cd4dc7ad56ea37be40844bfb97b ] If reconnect failed after start io queues, the queues will be unquiesced and new requests continue to be delivered. Reconnection error handling process directly free queues without cancel suspend requests. The suppend request will time out, and then crash due to use the queue after free. Add sync queues and cancel suppend requests for reconnection error handling. Signed-off-by: Chao Leng Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit a9ea34d2717a8c8892d3c5677329de9485e325ac Author: Chao Leng Date: Thu Jan 21 11:32:37 2021 +0800 nvme-rdma: add clean action for failed reconnection [ Upstream commit 958dc1d32c80566f58d18f05ef1f05bd32d172c1 ] A crash happens when inject failed reconnection. If reconnect failed after start io queues, the queues will be unquiesced and new requests continue to be delivered. Reconnection error handling process directly free queues without cancel suspend requests. The suppend request will time out, and then crash due to use the queue after free. Add sync queues and cancel suppend requests for reconnection error handling. Signed-off-by: Chao Leng Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 4bf6c84c9ad326016c179de5ba4f6e868e07acc7 Author: Chao Leng Date: Thu Jan 21 11:32:36 2021 +0800 nvme-core: add cancel tagset helpers [ Upstream commit 2547906982e2e6a0d42f8957f55af5bb51a7e55f ] Add nvme_cancel_tagset and nvme_cancel_admin_tagset for tear down and reconnection error handling. Signed-off-by: Chao Leng Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 8253cc11abb2baae408a2ac40e88c7910d1eb549 Author: Chao Yu Date: Tue Jan 12 09:55:09 2021 +0800 f2fs: fix to set/clear I_LINKABLE under i_lock [ Upstream commit 46085f37fc9e12d5c3539fb768b5ad7951e72acf ] fsstress + fault injection test case reports a warning message as below: WARNING: CPU: 13 PID: 6226 at fs/inode.c:361 inc_nlink+0x32/0x40 Call Trace: f2fs_init_inode_metadata+0x25c/0x4a0 [f2fs] f2fs_add_inline_entry+0x153/0x3b0 [f2fs] f2fs_add_dentry+0x75/0x80 [f2fs] f2fs_do_add_link+0x108/0x160 [f2fs] f2fs_rename2+0x6ab/0x14f0 [f2fs] vfs_rename+0x70c/0x940 do_renameat2+0x4d8/0x4f0 __x64_sys_renameat2+0x4b/0x60 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Following race case can cause this: Thread A Kworker - f2fs_rename - f2fs_create_whiteout - __f2fs_tmpfile - f2fs_i_links_write - f2fs_mark_inode_dirty_sync - mark_inode_dirty_sync - writeback_single_inode - __writeback_single_inode - spin_lock(&inode->i_lock) - inode->i_state |= I_LINKABLE - inode->i_state &= ~dirty - spin_unlock(&inode->i_lock) - f2fs_add_link - f2fs_do_add_link - f2fs_add_dentry - f2fs_add_inline_entry - f2fs_init_inode_metadata - f2fs_i_links_write - inc_nlink - WARN_ON(!(inode->i_state & I_LINKABLE)) Fix to add i_lock to avoid i_state update race condition. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 77dc257b4feb05c9e92d57d2021428a4f38a19e4 Author: Jaegeuk Kim Date: Wed Dec 23 11:44:25 2020 -0800 f2fs: handle unallocated section and zone on pinned/atgc [ Upstream commit 632faca72938f9f63049e48a8c438913828ac7a9 ] If we have large section/zone, unallocated segment makes them corrupted. E.g., - Pinned file: -1 119304647 119304647 - ATGC data: -1 119304647 119304647 Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit aa1362606059ade437a901fe7c33b24901683c14 Author: Ricardo Ribalda Date: Wed Dec 23 14:35:19 2020 +0100 media: uvcvideo: Allow entities with no pads [ Upstream commit 7532dad6634031d083df7af606fac655b8d08b5c ] Avoid an underflow while calculating the number of inputs for entities with zero pads. Signed-off-by: Ricardo Ribalda Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 0e9d7902764a751086407b3bdb2ed5ac26638e62 Author: Nicholas Kazlauskas Date: Fri Dec 18 12:14:00 2020 -0500 drm/amd/display: Guard against NULL pointer deref when get_i2c_info fails [ Upstream commit 44a09e3d95bd2b7b0c224100f78f335859c4e193 ] [Why] If the BIOS table is invalid or corrupt then get_i2c_info can fail and we dereference a NULL pointer. [How] Check that ddc_pin is not NULL before using it and log an error if it is because this is unexpected. Tested-by: Daniel Wheeler Signed-off-by: Nicholas Kazlauskas Reviewed-by: Eric Yang Acked-by: Anson Jacob Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f1fef55a3f1a59b751fd58e287cbdb4defa18fba Author: Nirmoy Das Date: Thu Jan 7 12:26:55 2021 +0100 PCI: Add a REBAR size quirk for Sapphire RX 5600 XT Pulse [ Upstream commit 907830b0fc9e374d00f3c83de5e426157b482c01 ] RX 5600 XT Pulse advertises support for BAR 0 being 256MB, 512MB, or 1GB, but it also supports 2GB, 4GB, and 8GB. Add a rebar size quirk so that the BAR 0 is big enough to cover complete VARM. Signed-off-by: Christian König Signed-off-by: Nirmoy Das Acked-by: Bjorn Helgaas Link: https://patchwork.kernel.org/project/dri-devel/patch/20210107175017.15893-5-nirmoy.das@amd.com Signed-off-by: Sasha Levin commit b252cdd9c6503dac6a2c4f52f825ee3112e3fd69 Author: Defang Bo Date: Wed Jan 6 00:06:39 2021 +0800 drm/amdgpu: Add check to prevent IH overflow [ Upstream commit e4180c4253f3f2da09047f5139959227f5cf1173 ] Similar to commit ("drm/amdgpu: fix IH overflow on Vega10 v2"). When an ring buffer overflow happens the appropriate bit is set in the WPTR register which is also written back to memory. But clearing the bit in the WPTR doesn't trigger another memory writeback. So what can happen is that we end up processing the buffer overflow over and over again because the bit is never cleared. Resulting in a random system lockup because of an infinite loop in an interrupt handler. Reviewed-by: Christian König Signed-off-by: Defang Bo Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a8d46a3feb024c449fc920d76a1f7ec1cfd53f1e Author: Ard Biesheuvel Date: Tue Dec 8 15:34:41 2020 +0100 crypto: tcrypt - avoid signed overflow in byte count [ Upstream commit 303fd3e1c771077e32e96e5788817f025f0067e2 ] The signed long type used for printing the number of bytes processed in tcrypt benchmarks limits the range to -/+ 2 GiB, which is not sufficient to cover the performance of common accelerated ciphers such as AES-NI when benchmarked with sec=1. So switch to u64 instead. While at it, fix up a missing printk->pr_cont conversion in the AEAD benchmark. Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 9f8d3e4b8ad85c6388574425d3d906dc6ebc5ae9 Author: Tian Tao Date: Mon Dec 14 18:32:53 2020 +0800 drm/hisilicon: Fix use-after-free [ Upstream commit c855af2f9c5c60760fd1bed7889a81bc37d2591d ] Fix the problem of dev being released twice. ------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 75 PID: 15700 at lib/refcount.c:28 refcount_warn_saturate+0xd4/0x150 CPU: 75 PID: 15700 Comm: rmmod Tainted: G E 5.10.0-rc3+ #3 Hardware name: Huawei TaiShan 200 (Model 2280)/BC82AMDDA, BIOS 0.88 07/24/2019 pstate: 40400009 (nZcv daif +PAN -UAO -TCO BTYPE=--) pc : refcount_warn_saturate+0xd4/0x150 lr : refcount_warn_saturate+0xd4/0x150 sp : ffff2028150cbc00 x29: ffff2028150cbc00 x28: ffff2028150121c0 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000003 x23: 0000000000000000 x22: ffff2028150cbc90 x21: ffff2020038a30a8 x20: ffff2028150cbc90 x19: ffff0020cd938020 x18: 0000000000000010 x17: 0000000000000000 x16: 0000000000000000 x15: ffffffffffffffff x14: ffff2028950cb88f x13: ffff2028150cb89d x12: 0000000000000000 x11: 0000000005f5e0ff x10: ffff2028150cb800 x9 : 00000000ffffffd0 x8 : 75203b776f6c6672 x7 : ffff800011a6f7c8 x6 : 0000000000000001 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff202ffe2f9dc0 x1 : ffffa02fecf40000 x0 : 0000000000000026 Call trace: refcount_warn_saturate+0xd4/0x150 devm_drm_dev_init_release+0x50/0x70 devm_action_release+0x20/0x30 release_nodes+0x13c/0x218 devres_release_all+0x80/0x170 device_release_driver_internal+0x128/0x1f0 driver_detach+0x6c/0xe0 bus_remove_driver+0x74/0x100 driver_unregister+0x34/0x60 pci_unregister_driver+0x24/0xd8 hibmc_pci_driver_exit+0x14/0xe858 [hibmc_drm] __arm64_sys_delete_module+0x1fc/0x2d0 el0_svc_common.constprop.3+0xa8/0x188 do_el0_svc+0x80/0xa0 el0_sync_handler+0x8c/0xb0 el0_sync+0x15c/0x180 CPU: 75 PID: 15700 Comm: rmmod Tainted: G E 5.10.0-rc3+ #3 Hardware name: Huawei TaiShan 200 (Model 2280)/BC82AMDDA, BIOS 0.88 07/24/2019 Call trace: dump_backtrace+0x0/0x208 show_stack+0x2c/0x40 dump_stack+0xd8/0x10c __warn+0xac/0x128 report_bug+0xcc/0x180 bug_handler+0x24/0x78 call_break_hook+0x80/0xa0 brk_handler+0x28/0x68 do_debug_exception+0x9c/0x148 el1_sync_handler+0x7c/0x128 el1_sync+0x80/0x100 refcount_warn_saturate+0xd4/0x150 devm_drm_dev_init_release+0x50/0x70 devm_action_release+0x20/0x30 release_nodes+0x13c/0x218 devres_release_all+0x80/0x170 device_release_driver_internal+0x128/0x1f0 driver_detach+0x6c/0xe0 bus_remove_driver+0x74/0x100 driver_unregister+0x34/0x60 pci_unregister_driver+0x24/0xd8 hibmc_pci_driver_exit+0x14/0xe858 [hibmc_drm] __arm64_sys_delete_module+0x1fc/0x2d0 el0_svc_common.constprop.3+0xa8/0x188 do_el0_svc+0x80/0xa0 el0_sync_handler+0x8c/0xb0 el0_sync+0x15c/0x180 ---[ end trace 00718630d6e5ff18 ]--- Signed-off-by: Tian Tao Acked-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/1607941973-32287-1-git-send-email-tiantao6@hisilicon.com Signed-off-by: Sasha Levin commit e1b9c1c9dbb01b647ad8505e6dd1a96e10c76297 Author: Hans de Goede Date: Fri Jan 29 18:14:13 2021 +0100 brcmfmac: Add DMI nvram filename quirk for Voyo winpad A15 tablet [ Upstream commit a338c874d3d9d2463f031e89ae14942929b93db6 ] The Voyo winpad A15 tablet contains quite generic names in the sys_vendor and product_name DMI strings, without this patch brcmfmac will try to load: rcmfmac4330-sdio.To be filled by O.E.M.-To be filled by O.E.M..txt as nvram file which is a bit too generic. Add a DMI quirk so that a unique and clearly identifiable nvram file name is used on the Voyo winpad A15 tablet. While preparing a matching linux-firmware update I noticed that the nvram is identical to the nvram used on the Prowise-PT301 tablet, so the new DMI quirk entry simply points to the already existing Prowise-PT301 nvram file. Signed-off-by: Hans de Goede Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210129171413.139880-2-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 3c099c272eb5e8149ab418ad904a9474a8638559 Author: Hans de Goede Date: Fri Jan 29 18:14:12 2021 +0100 brcmfmac: Add DMI nvram filename quirk for Predia Basic tablet [ Upstream commit af4b3a6f36d6c2fc5fca026bccf45e0fdcabddd9 ] The Predia Basic tablet contains quite generic names in the sys_vendor and product_name DMI strings, without this patch brcmfmac will try to load: brcmfmac43340-sdio.Insyde-CherryTrail.txt as nvram file which is a bit too generic. Add a DMI quirk so that a unique and clearly identifiable nvram file name is used on the Predia Basic tablet. Signed-off-by: Hans de Goede Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210129171413.139880-1-hdegoede@redhat.com Signed-off-by: Sasha Levin commit d1f2625619930882352b79f0b84eb6d9b5f7fdbb Author: Juerg Haefliger Date: Fri Feb 5 08:25:02 2021 +0100 staging: bcm2835-audio: Replace unsafe strcpy() with strscpy() [ Upstream commit 4964a4300660d27907ceb655f219ac47e5941534 ] Replace strcpy() with strscpy() in bcm2835-audio/bcm2835.c to prevent the following when loading snd-bcm2835: [ 58.480634] ------------[ cut here ]------------ [ 58.485321] kernel BUG at lib/string.c:1149! [ 58.489650] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 58.495214] Modules linked in: snd_bcm2835(COE+) snd_pcm snd_timer snd dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua btsdio bluetooth ecdh_generic ecc bcm2835_v4l2(CE) bcm2835_codec(CE) brcmfmac bcm2835_isp(CE) bcm2835_mmal_vchiq(CE) brcmutil cfg80211 v4l2_mem2mem videobuf2_vmalloc videobuf2_dma_contig videobuf2_memops raspberrypi_hwmon videobuf2_v4l2 videobuf2_common videodev bcm2835_gpiomem mc vc_sm_cma(CE) rpivid_mem uio_pdrv_genirq uio sch_fq_codel drm ip_tables x_tables autofs4 btrfs blake2b_generic raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor xor_neon raid6_pq libcrc32c raid1 raid0 multipath linear dwc2 roles spidev udc_core crct10dif_ce xhci_pci xhci_pci_renesas phy_generic aes_neon_bs aes_neon_blk crypto_simd cryptd [ 58.563787] CPU: 3 PID: 1959 Comm: insmod Tainted: G C OE 5.11.0-1001-raspi #1 [ 58.572172] Hardware name: Raspberry Pi 4 Model B Rev 1.2 (DT) [ 58.578086] pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--) [ 58.584178] pc : fortify_panic+0x20/0x24 [ 58.588161] lr : fortify_panic+0x20/0x24 [ 58.592136] sp : ffff800010a83990 [ 58.595491] x29: ffff800010a83990 x28: 0000000000000002 [ 58.600879] x27: ffffb0b07cb72928 x26: 0000000000000000 [ 58.606268] x25: ffff39e884973838 x24: ffffb0b07cb74190 [ 58.611655] x23: ffffb0b07cb72030 x22: 0000000000000000 [ 58.617042] x21: ffff39e884973014 x20: ffff39e88b793010 [ 58.622428] x19: ffffb0b07cb72670 x18: 0000000000000030 [ 58.627814] x17: 0000000000000000 x16: ffffb0b092ce2c1c [ 58.633200] x15: ffff39e88b901500 x14: 0720072007200720 [ 58.638588] x13: 0720072007200720 x12: 0720072007200720 [ 58.643979] x11: ffffb0b0936cbdf0 x10: 00000000fffff000 [ 58.649366] x9 : ffffb0b09220cfa8 x8 : 0000000000000000 [ 58.654752] x7 : ffffb0b093673df0 x6 : ffffb0b09364e000 [ 58.660140] x5 : 0000000000000000 x4 : ffff39e93b7db948 [ 58.665526] x3 : ffff39e93b7ebcf0 x2 : 0000000000000000 [ 58.670913] x1 : 0000000000000000 x0 : 0000000000000022 [ 58.676299] Call trace: [ 58.678775] fortify_panic+0x20/0x24 [ 58.682402] snd_bcm2835_alsa_probe+0x5b8/0x7d8 [snd_bcm2835] [ 58.688247] platform_probe+0x74/0xe4 [ 58.691963] really_probe+0xf0/0x510 [ 58.695585] driver_probe_device+0xe0/0x100 [ 58.699826] device_driver_attach+0xcc/0xd4 [ 58.704068] __driver_attach+0xb0/0x17c [ 58.707956] bus_for_each_dev+0x7c/0xd4 [ 58.711843] driver_attach+0x30/0x40 [ 58.715467] bus_add_driver+0x154/0x250 [ 58.719354] driver_register+0x84/0x140 [ 58.723242] __platform_driver_register+0x34/0x40 [ 58.728013] bcm2835_alsa_driver_init+0x30/0x1000 [snd_bcm2835] [ 58.734024] do_one_initcall+0x54/0x300 [ 58.737914] do_init_module+0x60/0x280 [ 58.741719] load_module+0x680/0x770 [ 58.745344] __do_sys_finit_module+0xbc/0x130 [ 58.749761] __arm64_sys_finit_module+0x2c/0x40 [ 58.754356] el0_svc_common.constprop.0+0x88/0x220 [ 58.759216] do_el0_svc+0x30/0xa0 [ 58.762575] el0_svc+0x28/0x70 [ 58.765669] el0_sync_handler+0x1a4/0x1b0 [ 58.769732] el0_sync+0x178/0x180 [ 58.773095] Code: aa0003e1 91366040 910003fd 97ffee21 (d4210000) [ 58.779275] ---[ end trace 29be5b17497bd898 ]--- [ 58.783955] note: insmod[1959] exited with preempt_count 1 [ 58.791921] ------------[ cut here ]------------ For the sake of it, replace all the other occurences of strcpy() under bcm2835-audio/ as well. Signed-off-by: Juerg Haefliger Link: https://lore.kernel.org/r/20210205072502.10907-1-juergh@canonical.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e3ec4af5064212641b72e4316dacb6ae0b9ee0d6 Author: Christian Gromm Date: Tue Feb 2 17:21:05 2021 +0100 staging: most: sound: add sanity check for function argument [ Upstream commit 45b754ae5b82949dca2b6e74fa680313cefdc813 ] This patch checks the function parameter 'bytes' before doing the subtraction to prevent memory corruption. Signed-off-by: Christian Gromm Reported-by: Dan Carpenter Link: https://lore.kernel.org/r/1612282865-21846-1-git-send-email-christian.gromm@microchip.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7d16e7c1615d91e98b295769a32608e1f5ce632b Author: Gopal Tiwari Date: Tue Feb 2 15:12:30 2021 +0530 Bluetooth: Fix null pointer dereference in amp_read_loc_assoc_final_data [ Upstream commit e8bd76ede155fd54d8c41d045dda43cd3174d506 ] kernel panic trace looks like: #5 [ffffb9e08698fc80] do_page_fault at ffffffffb666e0d7 #6 [ffffb9e08698fcb0] page_fault at ffffffffb70010fe [exception RIP: amp_read_loc_assoc_final_data+63] RIP: ffffffffc06ab54f RSP: ffffb9e08698fd68 RFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8c8845a5a000 RCX: 0000000000000004 RDX: 0000000000000000 RSI: ffff8c8b9153d000 RDI: ffff8c8845a5a000 RBP: ffffb9e08698fe40 R8: 00000000000330e0 R9: ffffffffc0675c94 R10: ffffb9e08698fe58 R11: 0000000000000001 R12: ffff8c8b9cbf6200 R13: 0000000000000000 R14: 0000000000000000 R15: ffff8c8b2026da0b ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffb9e08698fda8] hci_event_packet at ffffffffc0676904 [bluetooth] #8 [ffffb9e08698fe50] hci_rx_work at ffffffffc06629ac [bluetooth] #9 [ffffb9e08698fe98] process_one_work at ffffffffb66f95e7 hcon->amp_mgr seems NULL triggered kernel panic in following line inside function amp_read_loc_assoc_final_data set_bit(READ_LOC_AMP_ASSOC_FINAL, &mgr->state); Fixed by checking NULL for mgr. Signed-off-by: Gopal Tiwari Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit bba1995325b5ed317c8583a1cdb74fd09278b39e Author: Fangrui Song Date: Wed Jan 27 12:56:00 2021 -0800 x86/build: Treat R_386_PLT32 relocation as R_386_PC32 [ Upstream commit bb73d07148c405c293e576b40af37737faf23a6a ] This is similar to commit b21ebf2fb4cd ("x86: Treat R_X86_64_PLT32 as R_X86_64_PC32") but for i386. As far as the kernel is concerned, R_386_PLT32 can be treated the same as R_386_PC32. R_386_PLT32/R_X86_64_PLT32 are PC-relative relocation types which can only be used by branches. If the referenced symbol is defined externally, a PLT will be used. R_386_PC32/R_X86_64_PC32 are PC-relative relocation types which can be used by address taking operations and branches. If the referenced symbol is defined externally, a copy relocation/canonical PLT entry will be created in the executable. On x86-64, there is no PIC vs non-PIC PLT distinction and an R_X86_64_PLT32 relocation is produced for both `call/jmp foo` and `call/jmp foo@PLT` with newer (2018) GNU as/LLVM integrated assembler. This avoids canonical PLT entries (st_shndx=0, st_value!=0). On i386, there are 2 types of PLTs, PIC and non-PIC. Currently, the GCC/GNU as convention is to use R_386_PC32 for non-PIC PLT and R_386_PLT32 for PIC PLT. Copy relocations/canonical PLT entries are possible ABI issues but GCC/GNU as will likely keep the status quo because (1) the ABI is legacy (2) the change will drop a GNU ld diagnostic for non-default visibility ifunc in shared objects. clang-12 -fno-pic (since [1]) can emit R_386_PLT32 for compiler generated function declarations, because preventing canonical PLT entries is weighed over the rare ifunc diagnostic. Further info for the more interested: https://github.com/ClangBuiltLinux/linux/issues/1210 https://sourceware.org/bugzilla/show_bug.cgi?id=27169 https://github.com/llvm/llvm-project/commit/a084c0388e2a59b9556f2de0083333232da3f1d6 [1] [ bp: Massage commit message. ] Reported-by: Arnd Bergmann Signed-off-by: Fangrui Song Signed-off-by: Borislav Petkov Reviewed-by: Nick Desaulniers Reviewed-by: Nathan Chancellor Tested-by: Nick Desaulniers Tested-by: Nathan Chancellor Tested-by: Sedat Dilek Link: https://lkml.kernel.org/r/20210127205600.1227437-1-maskray@google.com Signed-off-by: Sasha Levin commit e37674e1a48ddc5d5962fcec87aee7827a1bbe6c Author: Miaoqing Pan Date: Tue Dec 22 14:34:47 2020 +0800 ath10k: fix wmi mgmt tx queue full due to race condition [ Upstream commit b55379e343a3472c35f4a1245906db5158cab453 ] Failed to transmit wmi management frames: [84977.840894] ath10k_snoc a000000.wifi: wmi mgmt tx queue is full [84977.840913] ath10k_snoc a000000.wifi: failed to transmit packet, dropping: -28 [84977.840924] ath10k_snoc a000000.wifi: failed to submit frame: -28 [84977.840932] ath10k_snoc a000000.wifi: failed to transmit frame: -28 This issue is caused by race condition between skb_dequeue and __skb_queue_tail. The queue of ‘wmi_mgmt_tx_queue’ is protected by a different lock: ar->data_lock vs list->lock, the result is no protection. So when ath10k_mgmt_over_wmi_tx_work() and ath10k_mac_tx_wmi_mgmt() running concurrently on different CPUs, there appear to be a rare corner cases when the queue length is 1, CPUx (skb_deuque) CPUy (__skb_queue_tail) next=list prev=list struct sk_buff *skb = skb_peek(list); WRITE_ONCE(newsk->next, next); WRITE_ONCE(list->qlen, list->qlen - 1);WRITE_ONCE(newsk->prev, prev); next = skb->next; WRITE_ONCE(next->prev, newsk); prev = skb->prev; WRITE_ONCE(prev->next, newsk); skb->next = skb->prev = NULL; list->qlen++; WRITE_ONCE(next->prev, prev); WRITE_ONCE(prev->next, next); If the instruction ‘next = skb->next’ is executed before ‘WRITE_ONCE(prev->next, newsk)’, newsk will be lost, as CPUx get the old ‘next’ pointer, but the length is still added by one. The final result is the length of the queue will reach the maximum value but the queue is empty. So remove ar->data_lock, and use 'skb_queue_tail' instead of '__skb_queue_tail' to prevent the potential race condition. Also switch to use skb_queue_len_lockless, in case we queue a few SKBs simultaneously. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.1.c2-00033-QCAHLSWMTPLZ-1 Signed-off-by: Miaoqing Pan Reviewed-by: Brian Norris Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1608618887-8857-1-git-send-email-miaoqing@codeaurora.org Signed-off-by: Sasha Levin commit 46813e4a7caa280f6a0e478b8882e2c56aa8b9be Author: Di Zhu Date: Mon Jan 25 20:42:29 2021 +0800 pktgen: fix misuse of BUG_ON() in pktgen_thread_worker() [ Upstream commit 275b1e88cabb34dbcbe99756b67e9939d34a99b6 ] pktgen create threads for all online cpus and bond these threads to relevant cpu repecivtily. when this thread firstly be woken up, it will compare cpu currently running with the cpu specified at the time of creation and if the two cpus are not equal, BUG_ON() will take effect causing panic on the system. Notice that these threads could be migrated to other cpus before start running because of the cpu hotplug after these threads have created. so the BUG_ON() used here seems unreasonable and we can replace it with WARN_ON() to just printf a warning other than panic the system. Signed-off-by: Di Zhu Link: https://lore.kernel.org/r/20210125124229.19334-1-zhudi21@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b074e7e20cc92ce4bd1b1ae0340c4330e3b5daa8 Author: Claire Chang Date: Tue Jan 19 19:47:00 2021 +0800 Bluetooth: hci_h5: Set HCI_QUIRK_SIMULTANEOUS_DISCOVERY for btrtl [ Upstream commit 7f9f2c3f7d99b8ae773459c74ac5e99a0dd46db9 ] Realtek Bluetooth controllers can do both LE scan and BR/EDR inquiry at once, need to set HCI_QUIRK_SIMULTANEOUS_DISCOVERY quirk. Signed-off-by: Claire Chang Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 5a8bbefd00746afe00226fe1dca165b5ba19b9c6 Author: Tony Lindgren Date: Fri Jan 15 08:56:13 2021 +0200 wlcore: Fix command execute failure 19 for wl12xx [ Upstream commit cb88d01b67383a095e3f7caeb4cdade5a6cf0417 ] We can currently get a "command execute failure 19" error on beacon loss if the signal is weak: wlcore: Beacon loss detected. roles:0xff wlcore: Connection loss work (role_id: 0). ... wlcore: ERROR command execute failure 19 ... WARNING: CPU: 0 PID: 1552 at drivers/net/wireless/ti/wlcore/main.c:803 ... (wl12xx_queue_recovery_work.part.0 [wlcore]) (wl12xx_cmd_role_start_sta [wlcore]) (wl1271_op_bss_info_changed [wlcore]) (ieee80211_prep_connection [mac80211]) Error 19 is defined as CMD_STATUS_WRONG_NESTING from the wlcore firmware, and seems to mean that the firmware no longer wants to see the quirk handling for WLCORE_QUIRK_START_STA_FAILS done. This quirk got added with commit 18eab430700d ("wlcore: workaround start_sta problem in wl12xx fw"), and it seems that this already got fixed in the firmware long time ago back in 2012 as wl18xx never had this quirk in place to start with. As we no longer even support firmware that early, to me it seems that it's safe to just drop WLCORE_QUIRK_START_STA_FAILS to fix the error. Looks like earlier firmware got disabled back in 2013 with commit 0e284c074ef9 ("wl12xx: increase minimum singlerole firmware version required"). If it turns out we still need WLCORE_QUIRK_START_STA_FAILS with any firmware that the driver works with, we can simply revert this patch and add extra checks for firmware version used. With this fix wlcore reconnects properly after a beacon loss. Cc: Raz Bouganim Signed-off-by: Tony Lindgren Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210115065613.7731-1-tony@atomide.com Signed-off-by: Sasha Levin commit 48549db10dbe3ef5a765a920b8fa11e83a741270 Author: Jiri Slaby Date: Tue Jan 5 13:02:34 2021 +0100 vt/consolemap: do font sum unsigned [ Upstream commit 9777f8e60e718f7b022a94f2524f967d8def1931 ] The constant 20 makes the font sum computation signed which can lead to sign extensions and signed wraps. It's not much of a problem as we build with -fno-strict-overflow. But if we ever decide not to, be ready, so switch the constant to unsigned. Signed-off-by: Jiri Slaby Link: https://lore.kernel.org/r/20210105120239.28031-7-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit de00b8f037ca683c8ddd4cd52a7cf1f157afa3eb Author: Heiner Kallweit Date: Tue Dec 1 12:39:57 2020 +0100 x86/reboot: Add Zotac ZBOX CI327 nano PCI reboot quirk [ Upstream commit 4b2d8ca9208be636b30e924b1cbcb267b0740c93 ] On this system the M.2 PCIe WiFi card isn't detected after reboot, only after cold boot. reboot=pci fixes this behavior. In [0] the same issue is described, although on another system and with another Intel WiFi card. In case it's relevant, both systems have Celeron CPUs. Add a PCI reboot quirk on affected systems until a more generic fix is available. [0] https://bugzilla.kernel.org/show_bug.cgi?id=202399 [ bp: Massage commit message. ] Signed-off-by: Heiner Kallweit Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/1524eafd-f89c-cfa4-ed70-0bde9e45eec9@gmail.com Signed-off-by: Sasha Levin commit 48f6c1a89487d7c497317a1df517d3972011673f Author: Dinghao Liu Date: Mon Dec 21 20:24:35 2020 +0800 staging: fwserial: Fix error handling in fwserial_create [ Upstream commit f31559af97a0eabd467e4719253675b7dccb8a46 ] When fw_core_add_address_handler() fails, we need to destroy the port by tty_port_destroy(). Also we need to unregister the address handler by fw_core_remove_address_handler() on failure. Signed-off-by: Dinghao Liu Link: https://lore.kernel.org/r/20201221122437.10274-1-dinghao.liu@zju.edu.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ce2b4b9c86b7c2caa85a8cd842ba3c46fedb7773 Author: Marek Vasut Date: Tue Nov 3 19:09:40 2020 +0100 rsi: Move card interrupt handling to RX thread [ Upstream commit 287431463e786766e05e4dc26d0a11d5f8ac8815 ] The interrupt handling of the RS911x is particularly heavy. For each RX packet, the card does three SDIO transactions, one to read interrupt status register, one to RX buffer length, one to read the RX packet(s). This translates to ~330 uS per one cycle of interrupt handler. In case there is more incoming traffic, this will be more. The drivers/mmc/core/sdio_irq.c has the following comment, quote "Just like traditional hard IRQ handlers, we expect SDIO IRQ handlers to be quick and to the point, so that the holding of the host lock does not cover too much work that doesn't require that lock to be held." The RS911x interrupt handler does not fit that. This patch therefore changes it such that the entire IRQ handler is moved to the RX thread instead, and the interrupt handler only wakes the RX thread. This is OK, because the interrupt handler only does things which can also be done in the RX thread, that is, it checks for firmware loading error(s), it checks buffer status, it checks whether a packet arrived and if so, reads out the packet and passes it to network stack. Moreover, this change permits removal of a code which allocated an skbuff only to get 4-byte-aligned buffer, read up to 8kiB of data into the skbuff, queue this skbuff into local private queue, then in RX thread, this buffer is dequeued, the data in the skbuff as passed to the RSI driver core, and the skbuff is deallocated. All this is replaced by directly calling the RSI driver core with local buffer. Signed-off-by: Marek Vasut Cc: Angus Ainslie Cc: David S. Miller Cc: Jakub Kicinski Cc: Kalle Valo Cc: Lee Jones Cc: Martin Kepplinger Cc: Sebastian Krzyszkowiak Cc: Siva Rebbagondla Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Tested-by: Martin Kepplinger Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20201103180941.443528-1-marex@denx.de Signed-off-by: Sasha Levin commit 133b0b1aa5c4490d8a01e70c0e92969378378368 Author: Marek Vasut Date: Thu Oct 15 13:16:16 2020 +0200 rsi: Fix TX EAPOL packet handling against iwlwifi AP [ Upstream commit 65277100caa2f2c62b6f3c4648b90d6f0435f3bc ] In case RSI9116 SDIO WiFi operates in STA mode against Intel 9260 in AP mode, the association fails. The former is using wpa_supplicant during association, the later is set up using hostapd: iwl$ cat hostapd.conf interface=wlp1s0 ssid=test country_code=DE hw_mode=g channel=1 wpa=2 wpa_passphrase=test wpa_key_mgmt=WPA-PSK iwl$ hostapd -d hostapd.conf rsi$ wpa_supplicant -i wlan0 -c <(wpa_passphrase test test) The problem is that the TX EAPOL data descriptor RSI_DESC_REQUIRE_CFM_TO_HOST flag and extended descriptor EAPOL4_CONFIRM frame type are not set in case the AP is iwlwifi, because in that case the TX EAPOL packet is 2 bytes shorter. The downstream vendor driver has this change in place already [1], however there is no explanation for it, neither is there any commit history from which such explanation could be obtained. [1] https://github.com/SiliconLabs/RS911X-nLink-OSD/blob/master/rsi/rsi_91x_hal.c#L238 Signed-off-by: Marek Vasut Cc: Angus Ainslie Cc: David S. Miller Cc: Jakub Kicinski Cc: Kalle Valo Cc: Lee Jones Cc: Martin Kepplinger Cc: Sebastian Krzyszkowiak Cc: Siva Rebbagondla Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20201015111616.429220-1-marex@denx.de Signed-off-by: Sasha Levin commit c8c3088a90c304d27c3d146bf60b57ec2ef148d8 Author: Sergey Senozhatsky Date: Thu Nov 5 10:47:44 2020 +0900 drm/virtio: use kvmalloc for large allocations commit ea86f3defd55f141a44146e66cbf8ffb683d60da upstream. We observed that some of virtio_gpu_object_shmem_init() allocations can be rather costly - order 6 - which can be difficult to fulfill under memory pressure conditions. Switch to kvmalloc_array() in virtio_gpu_object_shmem_init() and let the kernel vmalloc the entries array. Signed-off-by: Sergey Senozhatsky Link: http://patchwork.freedesktop.org/patch/msgid/20201105014744.1662226-1-senozhatsky@chromium.org Signed-off-by: Gerd Hoffmann Signed-off-by: Doug Horn Signed-off-by: Greg Kroah-Hartman commit 584149c771ec0110da184445bfdfb42beeb39bd9 Author: Paul Burton Date: Tue Oct 8 19:46:01 2019 +0000 MIPS: Drop 32-bit asm string functions commit 3c0be5849259b729580c23549330973a2dd513a2 upstream. We have assembly implementations of strcpy(), strncpy(), strcmp() & strncmp() which: - Are simple byte-at-a-time loops with no particular optimizations. As a comment in the code describes, they're "rather naive". - Offer no clear performance advantage over the generic C implementations - in microbenchmarks performed by Alexander Lobakin the asm functions sometimes win & sometimes lose, but generally not by large margins in either direction. - Don't support 64-bit kernels, where we already make use of the generic C implementations. - Tend to bloat kernel code size due to inlining. - Don't support CONFIG_FORTIFY_SOURCE. - Won't support nanoMIPS without rework. For all of these reasons, delete the asm implementations & make use of the generic C implementations for 32-bit kernels just like we already do for 64-bit kernels. Signed-off-by: Paul Burton URL: https://lore.kernel.org/linux-mips/a2a35f1cf58d6db19eb4af9b4ae21e35@dlink.ru/ Cc: Alexander Lobakin Reviewed-by: Philippe Mathieu-Daudé Cc: linux-mips@vger.kernel.org Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman commit 648c5b1b24d00fe37554e7e5239d844ff1aae7a3 Author: Geert Uytterhoeven Date: Thu Jan 14 14:13:33 2021 +0100 dt-bindings: net: btusb: DT fix s/interrupt-name/interrupt-names/ commit f288988930e93857e0375bdf88bb670c312b82eb upstream. The standard DT property name is "interrupt-names". Fixes: fd913ef7ce619467 ("Bluetooth: btusb: Add out-of-band wakeup support") Signed-off-by: Geert Uytterhoeven Acked-by: Rob Herring Reviewed-by: Brian Norris Acked-by: Rajat Jain Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 823e6524e1f320f286a4bcb72820b2a0d094902a Author: Russell King Date: Mon Feb 1 10:02:20 2021 +0000 dt-bindings: ethernet-controller: fix fixed-link specification commit 322322d15b9b912bc8710c367a95a7de62220a72 upstream. The original fixed-link.txt allowed a pause property for fixed link. This has been missed in the conversion to yaml format. Fixes: 9d3de3c58347 ("dt-bindings: net: Add YAML schemas for the generic Ethernet options") Signed-off-by: Russell King Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/E1l6W2G-0002Ga-0O@rmk-PC.armlinux.org.uk Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman commit 176188cff67ec1aa55103647b61d02315cc38e98 Author: Cong Wang Date: Thu Feb 11 11:34:10 2021 -0800 net: fix dev_ifsioc_locked() race condition commit 3b23a32a63219f51a5298bc55a65ecee866e79d0 upstream. dev_ifsioc_locked() is called with only RCU read lock, so when there is a parallel writer changing the mac address, it could get a partially updated mac address, as shown below: Thread 1 Thread 2 // eth_commit_mac_addr_change() memcpy(dev->dev_addr, addr->sa_data, ETH_ALEN); // dev_ifsioc_locked() memcpy(ifr->ifr_hwaddr.sa_data, dev->dev_addr,...); Close this race condition by guarding them with a RW semaphore, like netdev_get_name(). We can not use seqlock here as it does not allow blocking. The writers already take RTNL anyway, so this does not affect the slow path. To avoid bothering existing dev_set_mac_address() callers in drivers, introduce a new wrapper just for user-facing callers on ioctl and rtnetlink paths. Note, bonding also changes slave mac addresses but that requires a separate patch due to the complexity of bonding code. Fixes: 3710becf8a58 ("net: RCU locking for simple ioctl()") Reported-by: "Gong, Sishuai" Cc: Eric Dumazet Cc: Jakub Kicinski Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e4fc812e3577f3673c59a8983f901761fdae6726 Author: DENG Qingfang Date: Thu Feb 18 11:45:14 2021 +0800 net: ag71xx: remove unnecessary MTU reservation commit 04b385f325080157ab1b5f8ce1b1de07ce0d9e27 upstream. 2 bytes of the MTU are reserved for Atheros DSA tag, but DSA core has already handled that since commit dc0fe7d47f9f. Remove the unnecessary reservation. Fixes: d51b6ce441d3 ("net: ethernet: add ag71xx driver") Signed-off-by: DENG Qingfang Reviewed-by: Oleksij Rempel Link: https://lore.kernel.org/r/20210218034514.3421-1-dqfext@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ad112654e21d77bc3709798fce0cf477f65e7845 Author: Vladimir Oltean Date: Sun Feb 7 21:47:33 2021 +0200 net: bridge: use switchdev for port flags set through sysfs too commit 8043c845b63a2dd88daf2d2d268a33e1872800f0 upstream. Looking through patchwork I don't see that there was any consensus to use switchdev notifiers only in case of netlink provided port flags but not sysfs (as a sort of deprecation, punishment or anything like that), so we should probably keep the user interface consistent in terms of functionality. http://patchwork.ozlabs.org/project/netdev/patch/20170605092043.3523-3-jiri@resnulli.us/ http://patchwork.ozlabs.org/project/netdev/patch/20170608064428.4785-3-jiri@resnulli.us/ Fixes: 3922285d96e7 ("net: bridge: Add support for offloading port attributes") Signed-off-by: Vladimir Oltean Acked-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2e235c3a95183c27754930b1c1af130fa66186fb Author: Li Xinhai Date: Wed Feb 24 12:06:54 2021 -0800 mm/hugetlb.c: fix unnecessary address expansion of pmd sharing commit a1ba9da8f0f9a37d900ff7eff66482cf7de8015e upstream. The current code would unnecessarily expand the address range. Consider one example, (start, end) = (1G-2M, 3G+2M), and (vm_start, vm_end) = (1G-4M, 3G+4M), the expected adjustment should be keep (1G-2M, 3G+2M) without expand. But the current result will be (1G-4M, 3G+4M). Actually, the range (1G-4M, 1G) and (3G, 3G+4M) would never been involved in pmd sharing. After this patch, we will check that the vma span at least one PUD aligned size and the start,end range overlap the aligned range of vma. With above example, the aligned vma range is (1G, 3G), so if (start, end) range is within (1G-4M, 1G), or within (3G, 3G+4M), then no adjustment to both start and end. Otherwise, we will have chance to adjust start downwards or end upwards without exceeding (vm_start, vm_end). Mike: : The 'adjusted range' is used for calls to mmu notifiers and cache(tlb) : flushing. Since the current code unnecessarily expands the range in some : cases, more entries than necessary would be flushed. This would/could : result in performance degradation. However, this is highly dependent on : the user runtime. Is there a combination of vma layout and calls to : actually hit this issue? If the issue is hit, will those entries : unnecessarily flushed be used again and need to be unnecessarily reloaded? Link: https://lkml.kernel.org/r/20210104081631.2921415-1-lixinhai.lxh@gmail.com Fixes: 75802ca66354 ("mm/hugetlb: fix calculation of adjust_range_if_pmd_sharing_possible") Signed-off-by: Li Xinhai Suggested-by: Mike Kravetz Reviewed-by: Mike Kravetz Cc: Peter Xu Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4ed3162e92bf74d4d918a99fae5f224300db470f Author: Josef Bacik Date: Mon Feb 22 15:09:53 2021 -0500 nbd: handle device refs for DESTROY_ON_DISCONNECT properly commit c9a2f90f4d6b9d42b9912f7aaf68e8d748acfffd upstream. There exists a race where we can be attempting to create a new nbd configuration while a previous configuration is going down, both configured with DESTROY_ON_DISCONNECT. Normally devices all have a reference of 1, as they won't be cleaned up until the module is torn down. However with DESTROY_ON_DISCONNECT we'll make sure that there is only 1 reference (generally) on the device for the config itself, and then once the config is dropped, the device is torn down. The race that exists looks like this TASK1 TASK2 nbd_genl_connect() idr_find() refcount_inc_not_zero(nbd) * count is 2 here ^^ nbd_config_put() nbd_put(nbd) (count is 1) setup new config check DESTROY_ON_DISCONNECT put_dev = true if (put_dev) nbd_put(nbd) * free'd here ^^ In nbd_genl_connect() we assume that the nbd ref count will be 2, however clearly that won't be true if the nbd device had been setup as DESTROY_ON_DISCONNECT with its prior configuration. Fix this by getting rid of the runtime flag to check if we need to mess with the nbd device refcount, and use the device NBD_DESTROY_ON_DISCONNECT flag to check if we need to adjust the ref counts. This was reported by syzkaller with the following kasan dump BUG: KASAN: use-after-free in instrument_atomic_read include/linux/instrumented.h:71 [inline] BUG: KASAN: use-after-free in atomic_read include/asm-generic/atomic-instrumented.h:27 [inline] BUG: KASAN: use-after-free in refcount_dec_not_one+0x71/0x1e0 lib/refcount.c:76 Read of size 4 at addr ffff888143bf71a0 by task systemd-udevd/8451 CPU: 0 PID: 8451 Comm: systemd-udevd Not tainted 5.11.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x107/0x163 lib/dump_stack.c:120 print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:230 __kasan_report mm/kasan/report.c:396 [inline] kasan_report.cold+0x79/0xd5 mm/kasan/report.c:413 check_memory_region_inline mm/kasan/generic.c:179 [inline] check_memory_region+0x13d/0x180 mm/kasan/generic.c:185 instrument_atomic_read include/linux/instrumented.h:71 [inline] atomic_read include/asm-generic/atomic-instrumented.h:27 [inline] refcount_dec_not_one+0x71/0x1e0 lib/refcount.c:76 refcount_dec_and_mutex_lock+0x19/0x140 lib/refcount.c:115 nbd_put drivers/block/nbd.c:248 [inline] nbd_release+0x116/0x190 drivers/block/nbd.c:1508 __blkdev_put+0x548/0x800 fs/block_dev.c:1579 blkdev_put+0x92/0x570 fs/block_dev.c:1632 blkdev_close+0x8c/0xb0 fs/block_dev.c:1640 __fput+0x283/0x920 fs/file_table.c:280 task_work_run+0xdd/0x190 kernel/task_work.c:140 tracehook_notify_resume include/linux/tracehook.h:189 [inline] exit_to_user_mode_loop kernel/entry/common.c:174 [inline] exit_to_user_mode_prepare+0x249/0x250 kernel/entry/common.c:201 __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline] syscall_exit_to_user_mode+0x19/0x50 kernel/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fc1e92b5270 Code: 73 01 c3 48 8b 0d 38 7d 20 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 59 c1 20 00 00 75 10 b8 03 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 ee fb ff ff 48 89 04 24 RSP: 002b:00007ffe8beb2d18 EFLAGS: 00000246 ORIG_RAX: 0000000000000003 RAX: 0000000000000000 RBX: 0000000000000007 RCX: 00007fc1e92b5270 RDX: 000000000aba9500 RSI: 0000000000000000 RDI: 0000000000000007 RBP: 00007fc1ea16f710 R08: 000000000000004a R09: 0000000000000008 R10: 0000562f8cb0b2a8 R11: 0000000000000246 R12: 0000000000000000 R13: 0000562f8cb0afd0 R14: 0000000000000003 R15: 000000000000000e Allocated by task 1: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:46 [inline] set_alloc_info mm/kasan/common.c:401 [inline] ____kasan_kmalloc.constprop.0+0x82/0xa0 mm/kasan/common.c:429 kmalloc include/linux/slab.h:552 [inline] kzalloc include/linux/slab.h:682 [inline] nbd_dev_add+0x44/0x8e0 drivers/block/nbd.c:1673 nbd_init+0x250/0x271 drivers/block/nbd.c:2394 do_one_initcall+0x103/0x650 init/main.c:1223 do_initcall_level init/main.c:1296 [inline] do_initcalls init/main.c:1312 [inline] do_basic_setup init/main.c:1332 [inline] kernel_init_freeable+0x605/0x689 init/main.c:1533 kernel_init+0xd/0x1b8 init/main.c:1421 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 Freed by task 8451: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38 kasan_set_track+0x1c/0x30 mm/kasan/common.c:46 kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:356 ____kasan_slab_free+0xe1/0x110 mm/kasan/common.c:362 kasan_slab_free include/linux/kasan.h:192 [inline] slab_free_hook mm/slub.c:1547 [inline] slab_free_freelist_hook+0x5d/0x150 mm/slub.c:1580 slab_free mm/slub.c:3143 [inline] kfree+0xdb/0x3b0 mm/slub.c:4139 nbd_dev_remove drivers/block/nbd.c:243 [inline] nbd_put.part.0+0x180/0x1d0 drivers/block/nbd.c:251 nbd_put drivers/block/nbd.c:295 [inline] nbd_config_put+0x6dd/0x8c0 drivers/block/nbd.c:1242 nbd_release+0x103/0x190 drivers/block/nbd.c:1507 __blkdev_put+0x548/0x800 fs/block_dev.c:1579 blkdev_put+0x92/0x570 fs/block_dev.c:1632 blkdev_close+0x8c/0xb0 fs/block_dev.c:1640 __fput+0x283/0x920 fs/file_table.c:280 task_work_run+0xdd/0x190 kernel/task_work.c:140 tracehook_notify_resume include/linux/tracehook.h:189 [inline] exit_to_user_mode_loop kernel/entry/common.c:174 [inline] exit_to_user_mode_prepare+0x249/0x250 kernel/entry/common.c:201 __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline] syscall_exit_to_user_mode+0x19/0x50 kernel/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The buggy address belongs to the object at ffff888143bf7000 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 416 bytes inside of 1024-byte region [ffff888143bf7000, ffff888143bf7400) The buggy address belongs to the page: page:000000005238f4ce refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x143bf0 head:000000005238f4ce order:3 compound_mapcount:0 compound_pincount:0 flags: 0x57ff00000010200(slab|head) raw: 057ff00000010200 ffffea00004b1400 0000000300000003 ffff888010c41140 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888143bf7080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888143bf7100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888143bf7180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888143bf7200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb Reported-and-tested-by: syzbot+429d3f82d757c211bff3@syzkaller.appspotmail.com Signed-off-by: Josef Bacik Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit e6af7cb64b7b37b8a371acdbe33a636496ffb5a4 Author: Marco Elver Date: Mon Feb 1 17:04:20 2021 +0100 net: fix up truesize of cloned skb in skb_prepare_for_shift() commit 097b9146c0e26aabaa6ff3e5ea536a53f5254a79 upstream. Avoid the assumption that ksize(kmalloc(S)) == ksize(kmalloc(S)): when cloning an skb, save and restore truesize after pskb_expand_head(). This can occur if the allocator decides to service an allocation of the same size differently (e.g. use a different size class, or pass the allocation on to KFENCE). Because truesize is used for bookkeeping (such as sk_wmem_queued), a modified truesize of a cloned skb may result in corrupt bookkeeping and relevant warnings (such as in sk_stream_kill_queues()). Link: https://lkml.kernel.org/r/X9JR/J6dMMOy1obu@elver.google.com Reported-by: syzbot+7b99aafdcc2eedea6178@syzkaller.appspotmail.com Suggested-by: Eric Dumazet Signed-off-by: Marco Elver Signed-off-by: Eric Dumazet Link: https://lore.kernel.org/r/20210201160420.2826895-1-elver@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4ceb5ca9e626a8912efb45c924713121b9fc0655 Author: Sabyrzhan Tasbolatov Date: Thu Jan 28 17:58:01 2021 +0600 smackfs: restrict bytes count in smackfs write functions commit 7ef4c19d245f3dc233fd4be5acea436edd1d83d8 upstream. syzbot found WARNINGs in several smackfs write operations where bytes count is passed to memdup_user_nul which exceeds GFP MAX_ORDER. Check count size if bigger than PAGE_SIZE. Per smackfs doc, smk_write_net4addr accepts any label or -CIPSO, smk_write_net6addr accepts any label or -DELETE. I couldn't find any general rule for other label lengths except SMK_LABELLEN, SMK_LONGLABEL, SMK_CIPSOMAX which are documented. Let's constrain, in general, smackfs label lengths for PAGE_SIZE. Although fuzzer crashes write to smackfs/netlabel on 0x400000 length. Here is a quick way to reproduce the WARNING: python -c "print('A' * 0x400000)" > /sys/fs/smackfs/netlabel Reported-by: syzbot+a71a442385a0b2815497@syzkaller.appspotmail.com Signed-off-by: Sabyrzhan Tasbolatov Signed-off-by: Casey Schaufler Signed-off-by: Greg Kroah-Hartman commit 5fe244620e74b4862168a44db7fed328443b386c Author: Alexander Egorenkov Date: Thu Jan 28 12:41:04 2021 +0100 net/af_iucv: remove WARN_ONCE on malformed RX packets commit 27e9c1de529919d8dd7d072415d3bcae77709300 upstream. syzbot reported the following finding: AF_IUCV failed to receive skb, len=0 WARNING: CPU: 0 PID: 522 at net/iucv/af_iucv.c:2039 afiucv_hs_rcv+0x174/0x190 net/iucv/af_iucv.c:2039 CPU: 0 PID: 522 Comm: syz-executor091 Not tainted 5.10.0-rc1-syzkaller-07082-g55027a88ec9f #0 Hardware name: IBM 3906 M04 701 (KVM/Linux) Call Trace: [<00000000b87ea538>] afiucv_hs_rcv+0x178/0x190 net/iucv/af_iucv.c:2039 ([<00000000b87ea534>] afiucv_hs_rcv+0x174/0x190 net/iucv/af_iucv.c:2039) [<00000000b796533e>] __netif_receive_skb_one_core+0x13e/0x188 net/core/dev.c:5315 [<00000000b79653ce>] __netif_receive_skb+0x46/0x1c0 net/core/dev.c:5429 [<00000000b79655fe>] netif_receive_skb_internal+0xb6/0x220 net/core/dev.c:5534 [<00000000b796ac3a>] netif_receive_skb+0x42/0x318 net/core/dev.c:5593 [<00000000b6fd45f4>] tun_rx_batched.isra.0+0x6fc/0x860 drivers/net/tun.c:1485 [<00000000b6fddc4e>] tun_get_user+0x1c26/0x27f0 drivers/net/tun.c:1939 [<00000000b6fe0f00>] tun_chr_write_iter+0x158/0x248 drivers/net/tun.c:1968 [<00000000b4f22bfa>] call_write_iter include/linux/fs.h:1887 [inline] [<00000000b4f22bfa>] new_sync_write+0x442/0x648 fs/read_write.c:518 [<00000000b4f238fe>] vfs_write.part.0+0x36e/0x5d8 fs/read_write.c:605 [<00000000b4f2984e>] vfs_write+0x10e/0x148 fs/read_write.c:615 [<00000000b4f29d0e>] ksys_write+0x166/0x290 fs/read_write.c:658 [<00000000b8dc4ab4>] system_call+0xe0/0x28c arch/s390/kernel/entry.S:415 Last Breaking-Event-Address: [<00000000b8dc64d4>] __s390_indirect_jump_r14+0x0/0xc Malformed RX packets shouldn't generate any warnings because debugging info already flows to dropmon via the kfree_skb(). Signed-off-by: Alexander Egorenkov Reviewed-by: Julian Wiedmann Signed-off-by: Julian Wiedmann Acked-by: Willem de Bruijn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 09e47dc27ed5c233c20dd278886ac23a9927fb06 Author: Yumei Huang Date: Fri Jan 22 16:48:19 2021 -0800 xfs: Fix assert failure in xfs_setattr_size() commit 88a9e03beef22cc5fabea344f54b9a0dfe63de08 upstream. An assert failure is triggered by syzkaller test due to ATTR_KILL_PRIV is not cleared before xfs_setattr_size. As ATTR_KILL_PRIV is not checked/used by xfs_setattr_size, just remove it from the assert. Signed-off-by: Yumei Huang Reviewed-by: Brian Foster Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman commit a72c45f4ee33988ff2db4cba91b9daa75869e047 Author: Hans Verkuil Date: Wed Jan 20 09:28:02 2021 +0100 media: v4l2-ctrls.c: fix shift-out-of-bounds in std_validate commit 048c96e28674f15c0403deba2104ffba64544a06 upstream. If a menu has more than 64 items, then don't check menu_skip_mask for items 65 and up. Signed-off-by: Hans Verkuil Reported-by: syzbot+42d8c7c3d3e594b34346@syzkaller.appspotmail.com Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit edaa0a0aab6e63b2ea7747f14daa68808ea4f36b Author: Gao Xiang Date: Wed Jan 20 09:30:16 2021 +0800 erofs: fix shift-out-of-bounds of blkszbits commit bde545295b710bdd13a0fcd4b9fddd2383eeeb3a upstream. syzbot generated a crafted bitszbits which can be shifted out-of-bounds[1]. So directly print unsupported blkszbits instead of blksize. [1] https://lore.kernel.org/r/000000000000c72ddd05b9444d2f@google.com Link: https://lore.kernel.org/r/20210120013016.14071-1-hsiangkao@aol.com Reported-by: syzbot+c68f467cd7c45860e8d4@syzkaller.appspotmail.com Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Signed-off-by: Greg Kroah-Hartman commit 706068d0811a6bce6e324d1a1c11fcd4d0047c60 Author: Sean Young Date: Tue Jan 19 14:53:50 2021 +0100 media: mceusb: sanity check for prescaler value commit 9dec0f48a75e0dadca498002d25ef4e143e60194 upstream. prescaler larger than 8 would mean the carrier is at most 152Hz, which does not make sense for IR carriers. Reported-by: syzbot+6d31bf169a8265204b8d@syzkaller.appspotmail.com Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 64677f10e560e931bd477f461f7f28921f3a3823 Author: Zqiang Date: Tue Dec 15 14:30:22 2020 +0800 udlfb: Fix memory leak in dlfb_usb_probe commit 5c0e4110f751934e748a66887c61f8e73805f0f9 upstream. The dlfb_alloc_urb_list function is called in dlfb_usb_probe function, after that if an error occurs, the dlfb_free_urb_list function need to be called. BUG: memory leak unreferenced object 0xffff88810adde100 (size 32): comm "kworker/1:0", pid 17, jiffies 4294947788 (age 19.520s) hex dump (first 32 bytes): 10 30 c3 0d 81 88 ff ff c0 fa 63 12 81 88 ff ff .0........c..... 00 30 c3 0d 81 88 ff ff 80 d1 3a 08 81 88 ff ff .0........:..... backtrace: [<0000000019512953>] kmalloc include/linux/slab.h:552 [inline] [<0000000019512953>] kzalloc include/linux/slab.h:664 [inline] [<0000000019512953>] dlfb_alloc_urb_list drivers/video/fbdev/udlfb.c:1892 [inline] [<0000000019512953>] dlfb_usb_probe.cold+0x289/0x988 drivers/video/fbdev/udlfb.c:1704 [<0000000072160152>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396 [<00000000a8d6726f>] really_probe+0x159/0x480 drivers/base/dd.c:554 [<00000000c3ce4b0e>] driver_probe_device+0x84/0x100 drivers/base/dd.c:738 [<00000000e942e01c>] __device_attach_driver+0xee/0x110 drivers/base/dd.c:844 [<00000000de0a5a5c>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:431 [<00000000463fbcb4>] __device_attach+0x122/0x250 drivers/base/dd.c:912 [<00000000b881a711>] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:491 [<00000000364bbda5>] device_add+0x5ac/0xc30 drivers/base/core.c:2936 [<00000000eecca418>] usb_set_configuration+0x9de/0xb90 drivers/usb/core/message.c:2159 [<00000000edfeca2d>] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238 [<000000001830872b>] usb_probe_device+0x5c/0x140 drivers/usb/core/driver.c:293 [<00000000a8d6726f>] really_probe+0x159/0x480 drivers/base/dd.c:554 [<00000000c3ce4b0e>] driver_probe_device+0x84/0x100 drivers/base/dd.c:738 [<00000000e942e01c>] __device_attach_driver+0xee/0x110 drivers/base/dd.c:844 [<00000000de0a5a5c>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:431 Reported-by: syzbot+c9e365d7f450e8aa615d@syzkaller.appspotmail.com Signed-off-by: Zqiang Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20201215063022.16746-1-qiang.zhang@windriver.com Signed-off-by: Greg Kroah-Hartman commit 4e3b08cfe619433d4acd42cbeeeca77ff3cd368a Author: Randy Dunlap Date: Fri Dec 18 12:17:16 2020 -0800 JFS: more checks for invalid superblock commit 3bef198f1b17d1bb89260bad947ef084c0a2d1a6 upstream. syzbot is feeding invalid superblock data to JFS for mount testing. JFS does not check several of the fields -- just assumes that they are good since the JFS_MAGIC and version fields are good. In this case (syzbot reproducer), we have s_l2bsize == 0xda0c, pad == 0xf045, and s_state == 0x50, all of which are invalid IMO. Having s_l2bsize == 0xda0c causes this UBSAN warning: UBSAN: shift-out-of-bounds in fs/jfs/jfs_mount.c:373:25 shift exponent -9716 is negative s_l2bsize can be tested for correctness. pad can be tested for non-0 and punted. s_state can be tested for its valid values and punted. Do those 3 tests and if any of them fails, report the superblock as invalid/corrupt and let fsck handle it. With this patch, chkSuper() says this when JFS_DEBUG is enabled: jfs_mount: Mount Failure: superblock is corrupt! Mount JFS Failure: -22 jfs_mount failed w/return code = -22 The obvious problem with this method is that next week there could be another syzbot test that uses different fields for invalid values, this making this like a game of whack-a-mole. syzkaller link: https://syzkaller.appspot.com/bug?extid=36315852ece4132ec193 Reported-by: syzbot+36315852ece4132ec193@syzkaller.appspotmail.com Reported-by: kernel test robot # v2 Signed-off-by: Randy Dunlap Signed-off-by: Dave Kleikamp Cc: jfs-discussion@lists.sourceforge.net Signed-off-by: Greg Kroah-Hartman commit 86d7c693670e49b7635b42b9e763eedb52497de5 Author: Nathan Chancellor Date: Fri Jan 15 12:26:22 2021 -0700 MIPS: VDSO: Use CLANG_FLAGS instead of filtering out '--target=' commit 76d7fff22be3e4185ee5f9da2eecbd8188e76b2c upstream. Commit ee67855ecd9d ("MIPS: vdso: Allow clang's --target flag in VDSO cflags") allowed the '--target=' flag from the main Makefile to filter through to the vDSO. However, it did not bring any of the other clang specific flags for controlling the integrated assembler and the GNU tools locations (--prefix=, --gcc-toolchain=, and -no-integrated-as). Without these, we will get a warning (visible with tinyconfig): arch/mips/vdso/elf.S:14:1: warning: DWARF2 only supports one section per compilation unit .pushsection .note.Linux, "a",@note ; .balign 4 ; .long 2f - 1f ; .long 4484f - 3f ; .long 0 ; 1:.asciz "Linux" ; 2:.balign 4 ; 3: ^ arch/mips/vdso/elf.S:34:2: warning: DWARF2 only supports one section per compilation unit .section .mips_abiflags, "a" ^ All of these flags are bundled up under CLANG_FLAGS in the main Makefile and exported so that they can be added to Makefiles that set their own CFLAGS. Use this value instead of filtering out '--target=' so there is no warning and all of the tools are properly used. Cc: stable@vger.kernel.org Fixes: ee67855ecd9d ("MIPS: vdso: Allow clang's --target flag in VDSO cflags") Link: https://github.com/ClangBuiltLinux/linux/issues/1256 Reported-by: Anders Roxell Signed-off-by: Nathan Chancellor Tested-by: Anders Roxell Signed-off-by: Thomas Bogendoerfer [nc: Fix conflict due to lack of 99570c3da96a in 5.4] Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit 9757d5c4fc3f7e4ab8cab07c4642194f57c551fc Author: Shaoying Xu Date: Tue Feb 16 18:32:34 2021 +0000 arm64 module: set plt* section addresses to 0x0 commit f5c6d0fcf90ce07ee0d686d465b19b247ebd5ed7 upstream. These plt* and .text.ftrace_trampoline sections specified for arm64 have non-zero addressses. Non-zero section addresses in a relocatable ELF would confuse GDB when it tries to compute the section offsets and it ends up printing wrong symbol addresses. Therefore, set them to zero, which mirrors the change in commit 5d8591bc0fba ("module: set ksymtab/kcrctab* section addresses to 0x0"). Reported-by: Frank van der Linden Signed-off-by: Shaoying Xu Cc: Link: https://lore.kernel.org/r/20210216183234.GA23876@amazon.com Signed-off-by: Will Deacon [shaoyi@amazon.com: made same changes in arch/arm64/kernel/module.lds for 5.4] Signed-off-by: Shaoying Xu Signed-off-by: Greg Kroah-Hartman commit 69861dcc78c2a838ebb5e6371d9c0e7b7f304f2c Author: Christoph Hellwig Date: Tue Mar 2 17:39:11 2021 +0000 nvme-pci: fix error unwind in nvme_map_data commit fa0732168fa1369dd089e5b06d6158a68229f7b7 upstream. Properly unwind step by step using refactored helpers from nvme_unmap_data to avoid a potential double dma_unmap on a mapping failure. Fixes: 7fe07d14f71f ("nvme-pci: merge nvme_free_iod into nvme_unmap_data") Reported-by: Marc Orr Signed-off-by: Christoph Hellwig Reviewed-by: Keith Busch Reviewed-by: Marc Orr Signed-off-by: Marc Orr Signed-off-by: Greg Kroah-Hartman commit 744073c5c79c7dce746a351b7da249f20141f8fa Author: Christoph Hellwig Date: Tue Mar 2 17:39:10 2021 +0000 nvme-pci: refactor nvme_unmap_data commit 9275c206f88e5c49cb3e71932c81c8561083db9e upstream. Split out three helpers from nvme_unmap_data that will allow finer grained unwinding from nvme_map_data. Signed-off-by: Christoph Hellwig Reviewed-by: Keith Busch Reviewed-by: Marc Orr Signed-off-by: Marc Orr Signed-off-by: Greg Kroah-Hartman commit 9e4815cf178561104881e5d687ef69396aca1c8d Author: jingle.wu Date: Thu Dec 10 23:49:16 2020 -0800 Input: elantech - fix protocol errors for some trackpoints in SMBus mode commit e4c9062717feda88900b566463228d1c4910af6d upstream. There are some version of Elan trackpads that send incorrect data when in SMbus mode, unless they are switched to use 0x5f reports instead of standard 0x5e. This patch implements querying device to retrieve chips identifying data, and switching it, when needed to the alternative report. Signed-off-by: Jingle Wu Link: https://lore.kernel.org/r/20201211071531.32413-1-jingle.wu@emc.com.tw Signed-off-by: Dmitry Torokhov Cc: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman commit a1d010346e482dba374cd09ec41b53896b820952 Author: Lech Perczak Date: Tue Feb 23 19:34:56 2021 +0100 net: usb: qmi_wwan: support ZTE P685M modem commit 88eee9b7b42e69fb622ddb3ff6f37e8e4347f5b2 upstream. Now that interface 3 in "option" driver is no longer mapped, add device ID matching it to qmi_wwan. The modem is used inside ZTE MF283+ router and carriers identify it as such. Interface mapping is: 0: QCDM, 1: AT (PCUI), 2: AT (Modem), 3: QMI, 4: ADB T: Bus=02 Lev=02 Prnt=02 Port=05 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=19d2 ProdID=1275 Rev=f0.00 S: Manufacturer=ZTE,Incorporated S: Product=ZTE Technologies MSM S: SerialNumber=P685M510ZTED0000CP&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&0 C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan E: Ad=87(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Acked-by: Bjørn Mork Signed-off-by: Lech Perczak Link: https://lore.kernel.org/r/20210223183456.6377-1-lech.perczak@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman