commit 51e0ec114db9a48433cbe46fc62311fdfd62da4e Author: Alexandre Frade Date: Thu Aug 26 16:23:43 2021 +0000 Linux 5.13.13-xanmod1-cacule Signed-off-by: Alexandre Frade commit 7687be7403514a5dfc2e88a2e48b64009ef5abd3 Author: Alexey Avramov Date: Tue Aug 24 03:09:24 2021 +0900 mm/vmscan: add sysctl knobs for protecting the working set The kernel does not provide a way to protect the working set under memory pressure. A certain amount of anonymous and clean file pages is required by the userspace for normal operation. First of all, the userspace needs a cache of shared libraries and executable binaries. If the amount of the clean file pages falls below a certain level, then thrashing and even livelock can take place. The patch provides sysctl knobs for protecting the working set (anonymous and clean file pages) under memory pressure. The vm.anon_min_kbytes sysctl knob provides *hard* protection of anonymous pages. The anonymous pages on the current node won't be reclaimed under any conditions when their amount is below vm.anon_min_kbytes. This knob may be used to prevent excessive swap thrashing when anonymous memory is low (for example, when memory is going to be overfilled by compressed data of zram module). The default value is defined by CONFIG_ANON_MIN_KBYTES (suggested 0 in Kconfig). The vm.clean_low_kbytes sysctl knob provides *best-effort* protection of clean file pages. The file pages on the current node won't be reclaimed under memory pressure when the amount of clean file pages is below vm.clean_low_kbytes *unless* we threaten to OOM. Protection of clean file pages using this knob may be used when swapping is still possible to - prevent disk I/O thrashing under memory pressure; - improve performance in disk cache-bound tasks under memory pressure. The default value is defined by CONFIG_CLEAN_LOW_KBYTES (suggested 0 in Kconfig). The vm.clean_min_kbytes sysctl knob provides *hard* protection of clean file pages. The file pages on the current node won't be reclaimed under memory pressure when the amount of clean file pages is below vm.clean_min_kbytes. Hard protection of clean file pages using this knob may be used to - prevent disk I/O thrashing under memory pressure even with no free swap space; - improve performance in disk cache-bound tasks under memory pressure; - avoid high latency and prevent livelock in near-OOM conditions. The default value is defined by CONFIG_CLEAN_MIN_KBYTES (suggested 0 in Kconfig). Signed-off-by: Alexey Avramov commit 04a41b31f37ac256bd5e8fc09e4ec5ba50d1d5c8 Author: Alexandre Frade Date: Thu Aug 26 15:53:58 2021 +0000 Revert "mm/vmscan: add sysctl knobs for protecting clean cache" This reverts commit 2dd74f9c3c8b458741a8b2f8a29fe971ef66777f. commit 51ffbf53436fd2a88eac38b272be2b2e12c02287 Merge: cfb566f03ec8 bc18751f31c6 Author: Alexandre Frade Date: Thu Aug 26 12:50:40 2021 -0300 Merge pull request #191 from hamadmarri/xanmod-cacule-5.13 Disable RDB by default commit cfb566f03ec8c45f7c01b6ecc2d771b58ad65483 Merge: d580df6e0790 7aeadb5bb82a Author: Alexandre Frade Date: Thu Aug 26 15:48:31 2021 +0000 Merge tag 'v5.13.13' into 5.13-cacule Linux 5.13.13 commit 7aeadb5bb82ad21ffbcd54c81d77727b7a05e6c1 Author: Sasha Levin Date: Thu Aug 26 08:48:43 2021 -0400 Linux 5.13.13 Tested-by: Linux Kernel Functional Testing Tested-by: Guenter Roeck Tested-by: Shuah Khan Signed-off-by: Sasha Levin commit 2ff626b1400369e5b24be9482e0fbeac91b385f6 Author: Jeff Layton Date: Fri Aug 20 09:29:50 2021 -0400 fs: warn about impending deprecation of mandatory locks [ Upstream commit fdd92b64d15bc4aec973caa25899afd782402e68 ] We've had CONFIG_MANDATORY_FILE_LOCKING since 2015 and a lot of distros have disabled it. Warn the stragglers that still use "-o mand" that we'll be dropping support for that mount option. Cc: stable@vger.kernel.org Signed-off-by: Jeff Layton Signed-off-by: Sasha Levin commit a57b2a703e4440b9490cc8888618af9b05f2b457 Author: Jens Axboe Date: Fri Aug 20 14:53:59 2021 -0600 io_uring: fix xa_alloc_cycle() error return value check [ Upstream commit a30f895ad3239f45012e860d4f94c1a388b36d14 ] We currently check for ret != 0 to indicate error, but '1' is a valid return and just indicates that the allocation succeeded with a wrap. Correct the check to be for < 0, like it was before the xarray conversion. Cc: stable@vger.kernel.org Fixes: 61cf93700fe6 ("io_uring: Convert personality_idr to XArray") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 515b6124df6a84c957c5cc6bb6e8309dae7b1e9c Author: Mike Kravetz Date: Thu Aug 19 19:04:33 2021 -0700 hugetlb: don't pass page cache pages to restore_reserve_on_error [ Upstream commit c7b1850dfb41d0b4154aca8dbc04777fbd75616f ] syzbot hit kernel BUG at fs/hugetlbfs/inode.c:532 as described in [1]. This BUG triggers if the HPageRestoreReserve flag is set on a page in the page cache. It should never be set, as the routine huge_add_to_page_cache explicitly clears the flag after adding a page to the cache. The only code other than huge page allocation which sets the flag is restore_reserve_on_error. It will potentially set the flag in rare out of memory conditions. syzbot was injecting errors to cause memory allocation errors which exercised this specific path. The code in restore_reserve_on_error is doing the right thing. However, there are instances where pages in the page cache were being passed to restore_reserve_on_error. This is incorrect, as once a page goes into the cache reservation information will not be modified for the page until it is removed from the cache. Error paths do not remove pages from the cache, so even in the case of error, the page will remain in the cache and no reservation adjustment is needed. Modify routines that potentially call restore_reserve_on_error with a page cache page to no longer do so. Note on fixes tag: Prior to commit 846be08578ed ("mm/hugetlb: expand restore_reserve_on_error functionality") the routine would not process page cache pages because the HPageRestoreReserve flag is not set on such pages. Therefore, this issue could not be trigggered. The code added by commit 846be08578ed ("mm/hugetlb: expand restore_reserve_on_error functionality") is needed and correct. It exposed incorrect calls to restore_reserve_on_error which is the root cause addressed by this commit. [1] https://lore.kernel.org/linux-mm/00000000000050776d05c9b7c7f0@google.com/ Link: https://lkml.kernel.org/r/20210818213304.37038-1-mike.kravetz@oracle.com Fixes: 846be08578ed ("mm/hugetlb: expand restore_reserve_on_error functionality") Signed-off-by: Mike Kravetz Reported-by: Cc: Mina Almasry Cc: Axel Rasmussen Cc: Peter Xu Cc: Muchun Song Cc: Michal Hocko Cc: Naoya Horiguchi Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 371fb63d0926cd6f8584683ae0ef436e31f0637b Author: Marco Elver Date: Thu Aug 19 19:04:30 2021 -0700 kfence: fix is_kfence_address() for addresses below KFENCE_POOL_SIZE [ Upstream commit a7cb5d23eaea148f8582229846f8dfff192f05c3 ] Originally the addr != NULL check was meant to take care of the case where __kfence_pool == NULL (KFENCE is disabled). However, this does not work for addresses where addr > 0 && addr < KFENCE_POOL_SIZE. This can be the case on NULL-deref where addr > 0 && addr < PAGE_SIZE or any other faulting access with addr < KFENCE_POOL_SIZE. While the kernel would likely crash, the stack traces and report might be confusing due to double faults upon KFENCE's attempt to unprotect such an address. Fix it by just checking that __kfence_pool != NULL instead. Link: https://lkml.kernel.org/r/20210818130300.2482437-1-elver@google.com Fixes: 0ce20dd84089 ("mm: add Kernel Electric-Fence infrastructure") Signed-off-by: Marco Elver Reported-by: Kuan-Ying Lee Acked-by: Alexander Potapenko Cc: Dmitry Vyukov Cc: [5.12+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 9690e6ffac0b1a8bf865097de7d195ef6870b8f4 Author: Naoya Horiguchi Date: Thu Aug 19 19:04:24 2021 -0700 mm/hwpoison: retry with shake_page() for unhandlable pages [ Upstream commit fcc00621d88b274b5dffd8daeea71d0e4c28b84e ] HWPoisonHandlable() sometimes returns false for typical user pages due to races with average memory events like transfers over LRU lists. This causes failures in hwpoison handling. There's retry code for such a case but does not work because the retry loop reaches the retry limit too quickly before the page settles down to handlable state. Let get_any_page() call shake_page() to fix it. [naoya.horiguchi@nec.com: get_any_page(): return -EIO when retry limit reached] Link: https://lkml.kernel.org/r/20210819001958.2365157-1-naoya.horiguchi@linux.dev Link: https://lkml.kernel.org/r/20210817053703.2267588-1-naoya.horiguchi@linux.dev Fixes: 25182f05ffed ("mm,hwpoison: fix race with hugetlb page allocation") Signed-off-by: Naoya Horiguchi Reported-by: Tony Luck Reviewed-by: Yang Shi Cc: Oscar Salvador Cc: Muchun Song Cc: Mike Kravetz Cc: Michal Hocko Cc: [5.13+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 59e5c9ecdeb0919ff8490ff9aeb7f6dc2dbef982 Author: Naoya Horiguchi Date: Mon Jun 28 19:43:17 2021 -0700 mm,hwpoison: make get_hwpoison_page() call get_any_page() [ Upstream commit 0ed950d1f28142ccd9a9453c60df87853530d778 ] __get_hwpoison_page() could fail to grab refcount by some race condition, so it's helpful if we can handle it by retrying. We already have retry logic, so make get_hwpoison_page() call get_any_page() when called from memory_failure(). As a result, get_hwpoison_page() can return negative values (i.e. error code), so some callers are also changed to handle error cases. soft_offline_page() does nothing for -EBUSY because that's enough and users in userspace can easily handle it. unpoison_memory() is also unchanged because it's broken and need thorough fixes (will be done later). Link: https://lkml.kernel.org/r/20210603233632.2964832-3-nao.horiguchi@gmail.com Signed-off-by: Naoya Horiguchi Cc: Oscar Salvador Cc: Muchun Song Cc: Mike Kravetz Cc: Michal Hocko Cc: Tony Luck Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit e4e8c58cc78eb6e3cd801f8e7658e1c2459d88c9 Author: Johannes Weiner Date: Thu Aug 19 19:04:21 2021 -0700 mm: memcontrol: fix occasional OOMs due to proportional memory.low reclaim [ Upstream commit f56ce412a59d7d938b81de8878faef128812482c ] We've noticed occasional OOM killing when memory.low settings are in effect for cgroups. This is unexpected and undesirable as memory.low is supposed to express non-OOMing memory priorities between cgroups. The reason for this is proportional memory.low reclaim. When cgroups are below their memory.low threshold, reclaim passes them over in the first round, and then retries if it couldn't find pages anywhere else. But when cgroups are slightly above their memory.low setting, page scan force is scaled down and diminished in proportion to the overage, to the point where it can cause reclaim to fail as well - only in that case we currently don't retry, and instead trigger OOM. To fix this, hook proportional reclaim into the same retry logic we have in place for when cgroups are skipped entirely. This way if reclaim fails and some cgroups were scanned with diminished pressure, we'll try another full-force cycle before giving up and OOMing. [akpm@linux-foundation.org: coding-style fixes] Link: https://lkml.kernel.org/r/20210817180506.220056-1-hannes@cmpxchg.org Fixes: 9783aa9917f8 ("mm, memcg: proportional memory.{low,min} reclaim") Signed-off-by: Johannes Weiner Reported-by: Leon Yang Reviewed-by: Rik van Riel Reviewed-by: Shakeel Butt Acked-by: Roman Gushchin Acked-by: Chris Down Acked-by: Michal Hocko Cc: [5.4+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 2d1704c3fe301972c8e139f37561eaed8153cdf8 Author: Petr Pavlu Date: Sat Aug 7 19:54:50 2021 +0200 riscv: Fix a number of free'd resources in init_resources() [ Upstream commit aa3e1ba32e553e611a58145c2eb349802feaa6eb ] Function init_resources() allocates a boot memory block to hold an array of resources which it adds to iomem_resource. The array is filled in from its end and the function then attempts to free any unused memory at the beginning. The problem is that size of the unused memory is incorrectly calculated and this can result in releasing memory which is in use by active resources. Their data then gets corrupted later when the memory is reused by a different part of the system. Fix the size of the released memory to correctly match the number of unused resource entries. Fixes: ffe0e5261268 ("RISC-V: Improve init_resources()") Signed-off-by: Petr Pavlu Reviewed-by: Sunil V L Acked-by: Nick Kossifidis Tested-by: Sunil V L Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 8c5beac92d0e8f477226d2d7869764931458e71d Author: Takashi Iwai Date: Thu Aug 19 17:29:45 2021 +0200 ASoC: intel: atom: Fix breakage for PCM buffer address setup [ Upstream commit 65ca89c2b12cca0d473f3dd54267568ad3af55cc ] The commit 2e6b836312a4 ("ASoC: intel: atom: Fix reference to PCM buffer address") changed the reference of PCM buffer address to substream->runtime->dma_addr as the buffer address may change dynamically. However, I forgot that the dma_addr field is still not set up for the CONTINUOUS buffer type (that this driver uses) yet in 5.14 and earlier kernels, and it resulted in garbage I/O. The problem will be fixed in 5.15, but we need to address it quickly for now. The fix is to deduce the address again from the DMA pointer with virt_to_phys(), but from the right one, substream->runtime->dma_area. Fixes: 2e6b836312a4 ("ASoC: intel: atom: Fix reference to PCM buffer address") Reported-and-tested-by: Hans de Goede Cc: Acked-by: Mark Brown Link: https://lore.kernel.org/r/2048c6aa-2187-46bd-6772-36a4fb3c5aeb@redhat.com Link: https://lore.kernel.org/r/20210819152945.8510-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 8f4eb032a019cc6f6bdda5f78e1c50cebfb86c37 Author: Kai-Heng Feng Date: Wed Aug 18 22:41:18 2021 +0800 ALSA: hda/realtek: Limit mic boost on HP ProBook 445 G8 [ Upstream commit 8903376dc69949199301b290cc22dc64ae5d8a6d ] The mic has lots of noises if mic boost is enabled. So disable mic boost to get crystal clear audio capture. Signed-off-by: Kai-Heng Feng Cc: Link: https://lore.kernel.org/r/20210818144119.121738-1-kai.heng.feng@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 59734f7eaaa447bcb8cd2b96d1d6b88ebb757c44 Author: Marcin Bachry Date: Wed Jul 21 22:58:58 2021 -0400 PCI: Increase D3 delay for AMD Renoir/Cezanne XHCI [ Upstream commit e0bff43220925b7e527f9d3bc9f5c624177c959e ] The Renoir XHCI controller apparently doesn't resume reliably with the standard D3hot-to-D0 delay. Increase it to 20ms. [Alex: I talked to the AMD USB hardware team and the AMD Windows team and they are not aware of any HW errata or specific issues. The HW works fine in Windows. I was told Windows uses a rather generous default delay of 100ms for PCI state transitions.] Link: https://lore.kernel.org/r/20210722025858.220064-1-alexander.deucher@amd.com Signed-off-by: Marcin Bachry Signed-off-by: Alex Deucher Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Cc: Mario Limonciello Cc: Prike Liang Cc: Shyam Sundar S K Signed-off-by: Sasha Levin commit 00609919ec4d3559bfbf4b6022603b6285bddaeb Author: Christophe Leroy Date: Wed Aug 18 06:49:29 2021 +0000 powerpc/32s: Fix random crashes by adding isync() after locking/unlocking KUEP [ Upstream commit ef486bf448a057a6e2d50e40ae879f7add6585da ] Commit b5efec00b671 ("powerpc/32s: Move KUEP locking/unlocking in C") removed the 'isync' instruction after adding/removing NX bit in user segments. The reasoning behind this change was that when setting the NX bit we don't mind it taking effect with delay as the kernel never executes text from userspace, and when clearing the NX bit this is to return to userspace and then the 'rfi' should synchronise the context. However, it looks like on book3s/32 having a hash page table, at least on the G3 processor, we get an unexpected fault from userspace, then this is followed by something wrong in the verification of MSR_PR at end of another interrupt. This is fixed by adding back the removed isync() following update of NX bit in user segment registers. Only do it for cores with an hash table, as 603 cores don't exhibit that problem and the two isync increase ./null_syscall selftest by 6 cycles on an MPC 832x. First problem: unexpected WARN_ON() for mysterious PROTFAULT WARNING: CPU: 0 PID: 1660 at arch/powerpc/mm/fault.c:354 do_page_fault+0x6c/0x5b0 Modules linked in: CPU: 0 PID: 1660 Comm: Xorg Not tainted 5.13.0-pmac-00028-gb3c15b60339a #40 NIP: c001b5c8 LR: c001b6f8 CTR: 00000000 REGS: e2d09e40 TRAP: 0700 Not tainted (5.13.0-pmac-00028-gb3c15b60339a) MSR: 00021032 CR: 42d04f30 XER: 20000000 GPR00: c000424c e2d09f00 c301b680 e2d09f40 0000001e 42000000 00cba028 00000000 GPR08: 08000000 48000010 c301b680 e2d09f30 22d09f30 00c1fff0 00cba000 a7b7ba4c GPR16: 00000031 00000000 00000000 00000000 00000000 00000000 a7b7b0d0 00c5c010 GPR24: a7b7b64c a7b7d2f0 00000004 00000000 c1efa6c0 00cba02c 00000300 e2d09f40 NIP [c001b5c8] do_page_fault+0x6c/0x5b0 LR [c001b6f8] do_page_fault+0x19c/0x5b0 Call Trace: [e2d09f00] [e2d09f04] 0xe2d09f04 (unreliable) [e2d09f30] [c000424c] DataAccess_virt+0xd4/0xe4 --- interrupt: 300 at 0xa7a261dc NIP: a7a261dc LR: a7a253bc CTR: 00000000 REGS: e2d09f40 TRAP: 0300 Not tainted (5.13.0-pmac-00028-gb3c15b60339a) MSR: 0000d032 CR: 228428e2 XER: 20000000 DAR: 00cba02c DSISR: 42000000 GPR00: a7a27448 afa6b0e0 a74c35c0 a7b7b614 0000001e a7b7b614 00cba028 00000000 GPR08: 00020fd9 00000031 00cb9ff8 a7a273b0 220028e2 00c1fff0 00cba000 a7b7ba4c GPR16: 00000031 00000000 00000000 00000000 00000000 00000000 a7b7b0d0 00c5c010 GPR24: a7b7b64c a7b7d2f0 00000004 00000002 0000001e a7b7b614 a7b7aff4 00000030 NIP [a7a261dc] 0xa7a261dc LR [a7a253bc] 0xa7a253bc --- interrupt: 300 Instruction dump: 7c4a1378 810300a0 75278410 83820298 83a300a4 553b018c 551e0036 4082038c 2e1b0000 40920228 75280800 41820220 <0fe00000> 3b600000 41920214 81420594 Second problem: MSR PR is seen unset allthough the interrupt frame shows it set kernel BUG at arch/powerpc/kernel/interrupt.c:458! Oops: Exception in kernel mode, sig: 5 [#1] BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 PowerMac Modules linked in: CPU: 0 PID: 1660 Comm: Xorg Tainted: G W 5.13.0-pmac-00028-gb3c15b60339a #40 NIP: c0011434 LR: c001629c CTR: 00000000 REGS: e2d09e70 TRAP: 0700 Tainted: G W (5.13.0-pmac-00028-gb3c15b60339a) MSR: 00029032 CR: 42d09f30 XER: 00000000 GPR00: 00000000 e2d09f30 c301b680 e2d09f40 83440000 c44d0e68 e2d09e8c 00000000 GPR08: 00000002 00dc228a 00004000 e2d09f30 22d09f30 00c1fff0 afa6ceb4 00c26144 GPR16: 00c25fb8 00c26140 afa6ceb8 90000000 00c944d8 0000001c 00000000 00200000 GPR24: 00000000 000001fb afa6d1b4 00000001 00000000 a539a2a0 a530fd80 00000089 NIP [c0011434] interrupt_exit_kernel_prepare+0x10/0x70 LR [c001629c] interrupt_return+0x9c/0x144 Call Trace: [e2d09f30] [c000424c] DataAccess_virt+0xd4/0xe4 (unreliable) --- interrupt: 300 at 0xa09be008 NIP: a09be008 LR: a09bdfe8 CTR: a09bdfc0 REGS: e2d09f40 TRAP: 0300 Tainted: G W (5.13.0-pmac-00028-gb3c15b60339a) MSR: 0000d032 CR: 420028e2 XER: 20000000 DAR: a539a308 DSISR: 0a000000 GPR00: a7b90d50 afa6b2d0 a74c35c0 a0a8b690 a0a8b698 a5365d70 a4fa82a8 00000004 GPR08: 00000000 a09bdfc0 00000000 a5360000 a09bde7c 00c1fff0 afa6ceb4 00c26144 GPR16: 00c25fb8 00c26140 afa6ceb8 90000000 00c944d8 0000001c 00000000 00200000 GPR24: 00000000 000001fb afa6d1b4 00000001 00000000 a539a2a0 a530fd80 00000089 NIP [a09be008] 0xa09be008 LR [a09bdfe8] 0xa09bdfe8 --- interrupt: 300 Instruction dump: 80010024 83e1001c 7c0803a6 4bffff80 3bc00800 4bffffd0 486b42fd 4bffffcc 81430084 71480002 41820038 554a0462 <0f0a0000> 80620060 74630001 40820034 Fixes: b5efec00b671 ("powerpc/32s: Move KUEP locking/unlocking in C") Cc: stable@vger.kernel.org # v5.13+ Reported-by: Stan Johnson Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/4856f5574906e2aec0522be17bf3848a22b2cd0b.1629269345.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit 33bd5804ac669962f4eada670ee72f519be9f555 Author: Christophe Leroy Date: Thu Jun 3 08:41:37 2021 +0000 powerpc/32s: Refactor update of user segment registers [ Upstream commit 91bb30822a2e1d7900f9f42e9e92647a9015f979 ] KUEP implements the update of user segment registers. Move it into mmu-hash.h in order to use it from other places. And inline kuep_lock() and kuep_unlock(). Inlining kuep_lock() is important for system_call_exception(), otherwise system_call_exception() has to save into stack the system call parameters that are used just after, and doing that takes more instructions than kuep_lock() itself. Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/24591ca480d14a62ef910e38a5273d551262c4a2.1622708530.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit efe40fdb6d304959d65d9bccf0499b34f9604485 Author: Christophe Leroy Date: Thu Jun 3 08:41:36 2021 +0000 powerpc/32s: Move setup_{kuep/kuap}() into {kuep/kuap}.c [ Upstream commit 91ec66719d4c5c0e7b4e32585b01881660d1bc53 ] Avoids the #ifdef in mmu.c Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/0b7a13d414837e58264edc336b89c2fe9f35f9bc.1622708530.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit 534a0bc7c87a028e16100b06ac2969fd36cb65b2 Author: Hans de Goede Date: Mon Aug 16 17:46:32 2021 +0200 usb: typec: tcpm: Fix VDMs sometimes not being forwarded to alt-mode drivers [ Upstream commit 5571ea3117ca22849072adb58074fb5a2fd12c00 ] Commit a20dcf53ea98 ("usb: typec: tcpm: Respond Not_Supported if no snk_vdo"), stops tcpm_pd_data_request() calling tcpm_handle_vdm_request() when port->nr_snk_vdo is not set. But the VDM might be intended for an altmode-driver, in which case nr_snk_vdo does not matter. This change breaks the forwarding of connector hotplug (HPD) events for displayport altmode on devices which don't set nr_snk_vdo. tcpm_pd_data_request() is the only caller of tcpm_handle_vdm_request(), so we can move the nr_snk_vdo check to inside it, at which point we have already looked up the altmode device so we can check for this too. Doing this check here also ensures that vdm_state gets set to VDM_STATE_DONE if it was VDM_STATE_BUSY, even if we end up with responding with PD_MSG_CTRL_NOT_SUPP later. Note that tcpm_handle_vdm_request() was already sending PD_MSG_CTRL_NOT_SUPP in some circumstances, after moving the nr_snk_vdo check the same error-path is now taken when that check fails. So that we have only one error-path for this and not two. Replace the tcpm_queue_message(PD_MSG_CTRL_NOT_SUPP) used by the existing error-path with the more robust tcpm_pd_handle_msg() from the (now removed) second error-path. Fixes: a20dcf53ea98 ("usb: typec: tcpm: Respond Not_Supported if no snk_vdo") Cc: stable Cc: Kyle Tso Acked-by: Heikki Krogerus Acked-by: Kyle Tso Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210816154632.381968-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 21d6e237bcc2127446876c4456db797f976cd7bb Author: Niklas Schnelle Date: Fri Aug 6 12:11:16 2021 +0200 s390/pci: fix use after free of zpci_dev [ Upstream commit 2a671f77ee49f3e78997b77fdee139467ff6a598 ] The struct pci_dev uses reference counting but zPCI assumed erroneously that the last reference would always be the local reference after calling pci_stop_and_remove_bus_device(). This is usually the case but not how reference counting works and thus inherently fragile. In fact one case where this causes a NULL pointer dereference when on an SRIOV device the function 0 was hot unplugged before another function of the same multi-function device. In this case the second function's pdev->sriov->dev reference keeps the struct pci_dev of function 0 alive even after the unplug. This bug was previously hidden by the fact that we were leaking the struct pci_dev which in turn means that it always outlived the struct zpci_dev. This was fixed in commit 0b13525c20fe ("s390/pci: fix leak of PCI device structure") exposing the broken behavior. Fix this by accounting for the long living reference a struct pci_dev has to its underlying struct zpci_dev via the zbus->function[] array and only release that in pcibios_release_device() ensuring that the struct pci_dev is not left with a dangling reference. This is a minimal fix in the future it would probably better to use fine grained reference counting for struct zpci_dev. Fixes: 05bc1be6db4b2 ("s390/pci: create zPCI bus") Cc: stable@vger.kernel.org Reviewed-by: Matthew Rosato Signed-off-by: Niklas Schnelle Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit fe2edb82e5be48077bcfcec37e389f7c7018a0ce Author: Takashi Iwai Date: Tue Aug 17 07:24:32 2021 +0200 ALSA: hda/via: Apply runtime PM workaround for ASUS B23E [ Upstream commit 4bf61ad5f0204b67ba570da6e5c052c2095e29df ] ASUS B23E requires the same workaround like other machines with VT1802, otherwise it looses the codec power on a few nodes and the sound kept silence. Fixes: a0645daf1610 ("ALSA: HDA: Early Forbid of runtime PM") Link: https://lore.kernel.org/r/ac2232f142efcd67fe6ac38897f704f7176bd200.camel@gmail.com Cc: Link: https://lore.kernel.org/r/20210817052432.14751-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 41f0262ffb44c20f2baf07de3bfc3454ad0385d1 Author: Pingfan Liu Date: Sat Aug 14 11:45:38 2021 +0800 tracing: Apply trace filters on all output channels [ Upstream commit 6c34df6f350df9579ce99d887a2b5fa14cc13b32 ] The event filters are not applied on all of the output, which results in the flood of printk when using tp_printk. Unfolding event_trigger_unlock_commit_regs() into trace_event_buffer_commit(), so the filters can be applied on every output. Link: https://lkml.kernel.org/r/20210814034538.8428-1-kernelfans@gmail.com Cc: stable@vger.kernel.org Fixes: 0daa2302968c1 ("tracing: Add tp_printk cmdline to have tracepoints go to printk()") Signed-off-by: Pingfan Liu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit f7c707f8ec1848b698b097cc214a9bea3767ea71 Author: NeilBrown Date: Fri Aug 6 14:26:24 2021 +1000 btrfs: prevent rename2 from exchanging a subvol with a directory from different parents [ Upstream commit 3f79f6f6247c83f448c8026c3ee16d4636ef8d4f ] Cross-rename lacks a check when that would prevent exchanging a directory and subvolume from different parent subvolume. This causes data inconsistencies and is caught before commit by tree-checker, turning the filesystem to read-only. Calling the renameat2 with RENAME_EXCHANGE flags like renameat2(AT_FDCWD, namesrc, AT_FDCWD, namedest, (1 << 1)) on two paths: namesrc = dir1/subvol1/dir2 namedest = subvol2/subvol3 will cause key order problem with following write time tree-checker report: [1194842.307890] BTRFS critical (device loop1): corrupt leaf: root=5 block=27574272 slot=10 ino=258, invalid previous key objectid, have 257 expect 258 [1194842.322221] BTRFS info (device loop1): leaf 27574272 gen 8 total ptrs 11 free space 15444 owner 5 [1194842.331562] BTRFS info (device loop1): refs 2 lock_owner 0 current 26561 [1194842.338772] item 0 key (256 1 0) itemoff 16123 itemsize 160 [1194842.338793] inode generation 3 size 16 mode 40755 [1194842.338801] item 1 key (256 12 256) itemoff 16111 itemsize 12 [1194842.338809] item 2 key (256 84 2248503653) itemoff 16077 itemsize 34 [1194842.338817] dir oid 258 type 2 [1194842.338823] item 3 key (256 84 2363071922) itemoff 16043 itemsize 34 [1194842.338830] dir oid 257 type 2 [1194842.338836] item 4 key (256 96 2) itemoff 16009 itemsize 34 [1194842.338843] item 5 key (256 96 3) itemoff 15975 itemsize 34 [1194842.338852] item 6 key (257 1 0) itemoff 15815 itemsize 160 [1194842.338863] inode generation 6 size 8 mode 40755 [1194842.338869] item 7 key (257 12 256) itemoff 15801 itemsize 14 [1194842.338876] item 8 key (257 84 2505409169) itemoff 15767 itemsize 34 [1194842.338883] dir oid 256 type 2 [1194842.338888] item 9 key (257 96 2) itemoff 15733 itemsize 34 [1194842.338895] item 10 key (258 12 256) itemoff 15719 itemsize 14 [1194842.339163] BTRFS error (device loop1): block=27574272 write time tree block corruption detected [1194842.339245] ------------[ cut here ]------------ [1194842.443422] WARNING: CPU: 6 PID: 26561 at fs/btrfs/disk-io.c:449 csum_one_extent_buffer+0xed/0x100 [btrfs] [1194842.511863] CPU: 6 PID: 26561 Comm: kworker/u17:2 Not tainted 5.14.0-rc3-git+ #793 [1194842.511870] Hardware name: empty empty/S3993, BIOS PAQEX0-3 02/24/2008 [1194842.511876] Workqueue: btrfs-worker-high btrfs_work_helper [btrfs] [1194842.511976] RIP: 0010:csum_one_extent_buffer+0xed/0x100 [btrfs] [1194842.512068] RSP: 0018:ffffa2c284d77da0 EFLAGS: 00010282 [1194842.512074] RAX: 0000000000000000 RBX: 0000000000001000 RCX: ffff928867bd9978 [1194842.512078] RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff928867bd9970 [1194842.512081] RBP: ffff92876b958000 R08: 0000000000000001 R09: 00000000000c0003 [1194842.512085] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000 [1194842.512088] R13: ffff92875f989f98 R14: 0000000000000000 R15: 0000000000000000 [1194842.512092] FS: 0000000000000000(0000) GS:ffff928867a00000(0000) knlGS:0000000000000000 [1194842.512095] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1194842.512099] CR2: 000055f5384da1f0 CR3: 0000000102fe4000 CR4: 00000000000006e0 [1194842.512103] Call Trace: [1194842.512128] ? run_one_async_free+0x10/0x10 [btrfs] [1194842.631729] btree_csum_one_bio+0x1ac/0x1d0 [btrfs] [1194842.631837] run_one_async_start+0x18/0x30 [btrfs] [1194842.631938] btrfs_work_helper+0xd5/0x1d0 [btrfs] [1194842.647482] process_one_work+0x262/0x5e0 [1194842.647520] worker_thread+0x4c/0x320 [1194842.655935] ? process_one_work+0x5e0/0x5e0 [1194842.655946] kthread+0x135/0x160 [1194842.655953] ? set_kthread_struct+0x40/0x40 [1194842.655965] ret_from_fork+0x1f/0x30 [1194842.672465] irq event stamp: 1729 [1194842.672469] hardirqs last enabled at (1735): [] console_trylock_spinning+0x185/0x1a0 [1194842.672477] hardirqs last disabled at (1740): [] console_trylock_spinning+0x15c/0x1a0 [1194842.672482] softirqs last enabled at (1666): [] __do_softirq+0x2e1/0x50a [1194842.672491] softirqs last disabled at (1651): [] __irq_exit_rcu+0xa7/0xd0 The corrupted data will not be written, and filesystem can be unmounted and mounted again (all changes since the last commit will be lost). Add the missing check for new_ino so that all non-subvolumes must reside under the same parent subvolume. There's an exception allowing to exchange two subvolumes from any parents as the directory representing a subvolume is only a logical link and does not have any other structures related to the parent subvolume, unlike files, directories etc, that are always in the inode namespace of the parent subvolume. Fixes: cdd1fedf8261 ("btrfs: add support for RENAME_EXCHANGE and RENAME_WHITEOUT") CC: stable@vger.kernel.org # 4.7+ Reviewed-by: Nikolay Borisov Signed-off-by: NeilBrown Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit ddd7fff18986f29511e78d3d061936f23ee535c7 Author: Nicolas Saenz Julienne Date: Sat Aug 7 13:06:36 2021 +0200 mmc: sdhci-iproc: Set SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN on BCM2711 [ Upstream commit 419dd626e357e89fc9c4e3863592c8b38cfe1571 ] The controller doesn't seem to pick-up on clock changes, so set the SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN flag to query the clock frequency directly from the clock. Fixes: f84e411c85be ("mmc: sdhci-iproc: Add support for emmc2 of the BCM2711") Signed-off-by: Nicolas Saenz Julienne Signed-off-by: Stefan Wahren Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/1628334401-6577-6-git-send-email-stefan.wahren@i2se.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit f41b4c30fb73422043bdced329450ec5e08399ae Author: Nicolas Saenz Julienne Date: Sat Aug 7 13:06:35 2021 +0200 mmc: sdhci-iproc: Cap min clock frequency on BCM2711 [ Upstream commit c9107dd0b851777d7e134420baf13a5c5343bc16 ] There is a known bug on BCM2711's SDHCI core integration where the controller will hang when the difference between the core clock and the bus clock is too great. Specifically this can be reproduced under the following conditions: - No SD card plugged in, polling thread is running, probing cards at 100 kHz. - BCM2711's core clock configured at 500MHz or more. So set 200 kHz as the minimum clock frequency available for that board. For more information on the issue see this: https://lore.kernel.org/linux-mmc/20210322185816.27582-1-nsaenz@kernel.org/T/#m11f2783a09b581da6b8a15f302625b43a6ecdeca Fixes: f84e411c85be ("mmc: sdhci-iproc: Add support for emmc2 of the BCM2711") Signed-off-by: Nicolas Saenz Julienne Signed-off-by: Stefan Wahren Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/1628334401-6577-5-git-send-email-stefan.wahren@i2se.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 70063522ee9037ae58e266d08f27290a3d0fe409 Author: Dmitry Osipenko Date: Sun Aug 15 19:43:44 2021 +0300 opp: Drop empty-table checks from _put functions [ Upstream commit c3ddfe66d2bb511f7fbcdc8e64952c7859e7e69d ] The current_opp is released only when whole OPP table is released, otherwise it's only marked as removed by dev_pm_opp_remove_table(). Functions like dev_pm_opp_put_clkname() and dev_pm_opp_put_supported_hw() are checking whether OPP table is empty and it's not if current_opp is set since it holds the refcount of OPP, this produces a noisy warning from these functions about busy OPP table. Remove the checks to fix it. Cc: stable@vger.kernel.org Fixes: 81c4d8a3c414 ("opp: Keep track of currently programmed OPP") Signed-off-by: Dmitry Osipenko Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 30392f88dacea22d9ae3b0a53da0d17ddb7c4200 Author: Kristin Paget Date: Sat Aug 14 15:46:05 2021 -0700 ALSA: hda/realtek: Enable 4-speaker output for Dell XPS 15 9510 laptop [ Upstream commit da94692001ea45ffa1f5e9f17ecdef7aecd90c27 ] The 2021-model XPS 15 appears to use the same 4-speakers-on-ALC289 audio setup as the Precision models, so requires the same quirk to enable woofer output. Tested on my own 9510. Signed-off-by: Kristin Paget Cc: Link: https://lore.kernel.org/r/e1fc95c5-c10a-1f98-a5c2-dd6e336157e1@tombom.co.uk Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit da8495661fe9e1ea26de67fa8505f7805c6725f4 Author: Jens Axboe Date: Sat Aug 14 09:04:40 2021 -0600 io_uring: only assign io_uring_enter() SQPOLL error in actual error case [ Upstream commit 21f965221e7c42609521342403e8fb91b8b3e76e ] If an SQPOLL based ring is newly created and an application issues an io_uring_enter(2) system call on it, then we can return a spurious -EOWNERDEAD error. This happens because there's nothing to submit, and if the caller doesn't specify any other action, the initial error assignment of -EOWNERDEAD never gets overwritten. This causes us to return it directly, even if it isn't valid. Move the error assignment into the actual failure case instead. Cc: stable@vger.kernel.org Fixes: d9d05217cb69 ("io_uring: stop SQPOLL submit on creator's death") Reported-by: Sherlock Holo sherlockya@gmail.com Link: https://github.com/axboe/liburing/issues/413 Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 501449420a42c3fb945ea89cf2aa4914fd7bccc6 Author: Pavel Begunkov Date: Thu Jun 24 15:09:57 2021 +0100 io_uring: fix code style problems [ Upstream commit fe7e325750299126b9cc86d3071af594b46c4518 ] Fix a bunch of problems mostly found by checkpatch.pl Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/cfaf9a2f27b43934144fe9422a916bd327099f44.1624543113.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 606f36948a9a06f0a7683165ef60984738b18982 Author: Dongliang Mu Date: Tue Aug 10 18:03:19 2021 +0800 ipack: tpci200: fix memory leak in the tpci200_register [ Upstream commit 50f05bd114a46a74726e432bf81079d3f13a55b7 ] The error handling code in tpci200_register does not free interface_regs allocated by ioremap and the current version of error handling code is problematic. Fix this by refactoring the error handling code and free interface_regs when necessary. Fixes: 43986798fd50 ("ipack: add error handling for ioremap_nocache") Cc: stable@vger.kernel.org Reported-by: Dongliang Mu Signed-off-by: Dongliang Mu Link: https://lore.kernel.org/r/20210810100323.3938492-2-mudongliangabcd@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d09bfebbdf22ca04ae2773f7c286d3029101dd89 Author: Dongliang Mu Date: Tue Aug 10 18:03:18 2021 +0800 ipack: tpci200: fix many double free issues in tpci200_pci_probe [ Upstream commit 57a1681095f912239c7fb4d66683ab0425973838 ] The function tpci200_register called by tpci200_install and tpci200_unregister called by tpci200_uninstall are in pair. However, tpci200_unregister has some cleanup operations not in the tpci200_register. So the error handling code of tpci200_pci_probe has many different double free issues. Fix this problem by moving those cleanup operations out of tpci200_unregister, into tpci200_pci_remove and reverting the previous commit 9272e5d0028d ("ipack/carriers/tpci200: Fix a double free in tpci200_pci_probe"). Fixes: 9272e5d0028d ("ipack/carriers/tpci200: Fix a double free in tpci200_pci_probe") Cc: stable@vger.kernel.org Reported-by: Dongliang Mu Signed-off-by: Dongliang Mu Link: https://lore.kernel.org/r/20210810100323.3938492-1-mudongliangabcd@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c1001de019ef18366a2f3338855661b4ea560b13 Author: Srinivas Kandagatla Date: Mon Aug 9 09:24:28 2021 +0100 slimbus: ngd: reset dma setup during runtime pm [ Upstream commit d77772538f00b7265deace6e77e555ee18365ad0 ] During suspend/resume NGD remote instance is power cycled along with remotely controlled bam dma engine. So Reset the dma configuration during this suspend resume path so that we are not dealing with any stale dma setup. Without this transactions timeout after first suspend resume path. Fixes: 917809e2280b ("slimbus: ngd: Add qcom SLIMBus NGD driver") Cc: Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20210809082428.11236-5-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c8f6e68a95c25557987e5a4f27ccbb74e561226e Author: Srinivas Kandagatla Date: Mon Aug 9 09:24:27 2021 +0100 slimbus: ngd: set correct device for pm [ Upstream commit c0e38eaa8d5102c138e4f16658ea762417d42a8f ] For some reason we ended up using wrong device in some places for pm_runtime calls. Fix this so that NGG driver can do runtime pm correctly. Fixes: 917809e2280b ("slimbus: ngd: Add qcom SLIMBus NGD driver") Cc: Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20210809082428.11236-4-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 28b55e58b86496fae5576006c8206c115082ccfd Author: Srinivas Kandagatla Date: Mon Aug 9 09:24:26 2021 +0100 slimbus: messaging: check for valid transaction id [ Upstream commit a263c1ff6abe0e66712f40d595bbddc7a35907f8 ] In some usecases transaction ids are dynamically allocated inside the controller driver after sending the messages which have generic acknowledge responses. So check for this before refcounting pm_runtime. Without this we would end up imbalancing runtime pm count by doing pm_runtime_put() in both slim_do_transfer() and slim_msg_response() for a single pm_runtime_get() in slim_do_transfer() Fixes: d3062a210930 ("slimbus: messaging: add slim_alloc/free_txn_tid()") Cc: Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20210809082428.11236-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e0e46e209e9dbaa51c69d31ec926207a4e7eecaf Author: Srinivas Kandagatla Date: Mon Aug 9 09:24:25 2021 +0100 slimbus: messaging: start transaction ids from 1 instead of zero [ Upstream commit 9659281ce78de0f15a4aa124da8f7450b1399c09 ] As tid is unsigned its hard to figure out if the tid is valid or invalid. So Start the transaction ids from 1 instead of zero so that we could differentiate between a valid tid and invalid tids This is useful in cases where controller would add a tid for controller specific transfers. Fixes: d3062a210930 ("slimbus: messaging: add slim_alloc/free_txn_tid()") Cc: Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20210809082428.11236-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 65a4722bb93102ca1bc9781022d547da2d743e4e Author: Steven Rostedt (VMware) Date: Sun Aug 8 00:30:11 2021 -0400 tracing / histogram: Fix NULL pointer dereference on strcmp() on NULL event name [ Upstream commit 5acce0bff2a0420ce87d4591daeb867f47d552c2 ] The following commands: # echo 'read_max u64 size;' > synthetic_events # echo 'hist:keys=common_pid:count=count:onmax($count).trace(read_max,count)' > events/syscalls/sys_enter_read/trigger Causes: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP CPU: 4 PID: 1763 Comm: bash Not tainted 5.14.0-rc2-test+ #155 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 07/14/2016 RIP: 0010:strcmp+0xc/0x20 Code: 75 f7 31 c0 0f b6 0c 06 88 0c 02 48 83 c0 01 84 c9 75 f1 4c 89 c0 c3 0f 1f 80 00 00 00 00 31 c0 eb 08 48 83 c0 01 84 d2 74 0f <0f> b6 14 07 3a 14 06 74 ef 19 c0 83 c8 01 c3 31 c0 c3 66 90 48 89 RSP: 0018:ffffb5fdc0963ca8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffffffb3a4e040 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff9714c0d0b640 RDI: 0000000000000000 RBP: 0000000000000000 R08: 00000022986b7cde R09: ffffffffb3a4dff8 R10: 0000000000000000 R11: 0000000000000000 R12: ffff9714c50603c8 R13: 0000000000000000 R14: ffff97143fdf9e48 R15: ffff9714c01a2210 FS: 00007f1fa6785740(0000) GS:ffff9714da400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000002d863004 CR4: 00000000001706e0 Call Trace: __find_event_file+0x4e/0x80 action_create+0x6b7/0xeb0 ? kstrdup+0x44/0x60 event_hist_trigger_func+0x1a07/0x2130 trigger_process_regex+0xbd/0x110 event_trigger_write+0x71/0xd0 vfs_write+0xe9/0x310 ksys_write+0x68/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f1fa6879e87 The problem was the "trace(read_max,count)" where the "count" should be "$count" as "onmax()" only handles variables (although it really should be able to figure out that "count" is a field of sys_enter_read). But there's a path that does not find the variable and ends up passing a NULL for the event, which ends up getting passed to "strcmp()". Add a check for NULL to return and error on the command with: # cat error_log hist:syscalls:sys_enter_read: error: Couldn't create or find variable Command: hist:keys=common_pid:count=count:onmax($count).trace(read_max,count) ^ Link: https://lkml.kernel.org/r/20210808003011.4037f8d0@oasis.local.home Cc: Masami Hiramatsu Cc: stable@vger.kernel.org Fixes: 50450603ec9cb tracing: Add 'onmax' hist trigger action support Reviewed-by: Tom Zanussi Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 0ce48083d843b00bdc04c820a051981336c17efd Author: Lukas Bulwahn Date: Fri Aug 6 21:50:27 2021 +0200 tracing: define needed config DYNAMIC_FTRACE_WITH_ARGS [ Upstream commit 12f9951d3f311acb1d4ffe8e839bc2c07983546f ] Commit 2860cd8a2353 ("livepatch: Use the default ftrace_ops instead of REGS when ARGS is available") intends to enable config LIVEPATCH when ftrace with ARGS is available. However, the chain of configs to enable LIVEPATCH is incomplete, as HAVE_DYNAMIC_FTRACE_WITH_ARGS is available, but the definition of DYNAMIC_FTRACE_WITH_ARGS, combining DYNAMIC_FTRACE and HAVE_DYNAMIC_FTRACE_WITH_ARGS, needed to enable LIVEPATCH, is missing in the commit. Fortunately, ./scripts/checkkconfigsymbols.py detects this and warns: DYNAMIC_FTRACE_WITH_ARGS Referencing files: kernel/livepatch/Kconfig So, define the config DYNAMIC_FTRACE_WITH_ARGS analogously to the already existing similar configs, DYNAMIC_FTRACE_WITH_REGS and DYNAMIC_FTRACE_WITH_DIRECT_CALLS, in ./kernel/trace/Kconfig to connect the chain of configs. Link: https://lore.kernel.org/kernel-janitors/CAKXUXMwT2zS9fgyQHKUUiqo8ynZBdx2UEUu1WnV_q0OCmknqhw@mail.gmail.com/ Link: https://lkml.kernel.org/r/20210806195027.16808-1-lukas.bulwahn@gmail.com Cc: Josh Poimboeuf Cc: Jiri Kosina Cc: Peter Zijlstra Cc: Miroslav Benes Cc: stable@vger.kernel.org Fixes: 2860cd8a2353 ("livepatch: Use the default ftrace_ops instead of REGS when ARGS is available") Signed-off-by: Lukas Bulwahn Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 2152ee71c164422a15b3026f9c36292cb1152fb4 Author: Jaroslav Kysela Date: Wed Aug 11 18:14:41 2021 +0200 ALSA: hda - fix the 'Capture Switch' value change notifications [ Upstream commit a2befe9380dd04ee76c871568deca00eedf89134 ] The original code in the cap_put_caller() function does not handle correctly the positive values returned from the passed function for multiple iterations. It means that the change notifications may be lost. Fixes: 352f7f914ebb ("ALSA: hda - Merge Realtek parser code to generic parser") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=213851 Cc: Signed-off-by: Jaroslav Kysela Link: https://lore.kernel.org/r/20210811161441.1325250-1-perex@perex.cz Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 8681e95da50b129619c7f57c89c2d9b719331b8a Author: Elliot Berman Date: Wed Aug 11 08:59:14 2021 -0700 cfi: Use rcu_read_{un}lock_sched_notrace [ Upstream commit 14c4c8e41511aa8fba7fb239b20b6539b5bce201 ] If rcu_read_lock_sched tracing is enabled, the tracing subsystem can perform a jump which needs to be checked by CFI. For example, stm_ftrace source is enabled as a module and hooks into enabled ftrace events. This can cause an recursive loop where find_shadow_check_fn -> rcu_read_lock_sched -> (call to stm_ftrace generates cfi slowpath) -> find_shadow_check_fn -> rcu_read_lock_sched -> ... To avoid the recursion, either the ftrace codes needs to be marked with __no_cfi or CFI should not trace. Use the "_notrace" in CFI to avoid tracing so that CFI can guard ftrace. Signed-off-by: Elliot Berman Reviewed-by: Sami Tolvanen Cc: stable@vger.kernel.org Fixes: cf68fffb66d6 ("add support for Clang CFI") Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20210811155914.19550-1-quic_eberman@quicinc.com Signed-off-by: Sasha Levin commit 82d1ea87b9d57434bc534fcbc7844a1112be3c8e Author: Andrew Delgadillo Date: Tue Aug 10 23:17:55 2021 +0000 arm64: clean vdso & vdso32 files [ Upstream commit 017f5fb9ce793e3558db94ee72068622bc0b79db ] commit a5b8ca97fbf8 ("arm64: do not descend to vdso directories twice") changes the cleaning behavior of arm64's vdso files, in that vdso.lds, vdso.so, and vdso.so.dbg are not removed upon a 'make clean/mrproper': $ make defconfig ARCH=arm64 $ make ARCH=arm64 $ make mrproper ARCH=arm64 $ git clean -nxdf Would remove arch/arm64/kernel/vdso/vdso.lds Would remove arch/arm64/kernel/vdso/vdso.so Would remove arch/arm64/kernel/vdso/vdso.so.dbg To remedy this, manually descend into arch/arm64/kernel/vdso upon cleaning. After this commit: $ make defconfig ARCH=arm64 $ make ARCH=arm64 $ make mrproper ARCH=arm64 $ git clean -nxdf Similar results are obtained for the vdso32 equivalent. Signed-off-by: Andrew Delgadillo Cc: stable@vger.kernel.org Fixes: a5b8ca97fbf8 ("arm64: do not descend to vdso directories twice") Link: https://lore.kernel.org/r/20210810231755.1743524-1-adelg@google.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 03c33905ee8882997d0ce0d6ece9c217844f84ea Author: Bjorn Andersson Date: Wed Jul 21 15:40:56 2021 -0700 clk: qcom: gdsc: Ensure regulator init state matches GDSC state [ Upstream commit 9711759a87a041705148161b937ec847048d882e ] As GDSCs are registered and found to be already enabled gdsc_init() ensures that 1) the kernel state matches the hardware state, and 2) votable GDSCs are properly enabled from this master as well. But as the (optional) supply regulator is enabled deep into gdsc_toggle_logic(), which is only executed for votable GDSCs, the kernel's state of the regulator might not match the hardware. The regulator might be automatically turned off if no other users are present or the next call to gdsc_disable() would cause an unbalanced regulator_disable(). Given that the votable case deals with an already enabled GDSC, most of gdsc_enable() and gdsc_toggle_logic() can be skipped. Reduce it to just clearing the SW_COLLAPSE_MASK and enabling hardware control to simply call regulator_enable() in both cases. The enablement of hardware control seems to be an independent property from the GDSC being enabled, so this is moved outside that conditional segment. Lastly, as the propagation of ALWAYS_ON to GENPD_FLAG_ALWAYS_ON needs to happen regardless of the initial state this is grouped together with the other sc->pd updates at the end of the function. Cc: stable@vger.kernel.org Fixes: 37416e554961 ("clk: qcom: gdsc: Handle GDSC regulator supplies") Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20210721224056.3035016-1-bjorn.andersson@linaro.org [sboyd@kernel.org: Rephrase commit text] Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 95e5238a2fbadd97415687c22638d2c5ad9cb8ce Author: Dong Aisheng Date: Fri Jul 2 16:54:38 2021 +0800 clk: imx6q: fix uart earlycon unwork [ Upstream commit 283f1b9a0401859c53fdd6483ab66f1c4fadaea5 ] The earlycon depends on the bootloader setup UART clocks being retained. There're actually two uart clocks (ipg, per) on MX6QDL, but the 'Fixes' commit change to register only one which means another clock may be disabled during booting phase and result in the earlycon unwork. Cc: stable@vger.kernel.org # v5.10+ Fixes: 379c9a24cc23 ("clk: imx: Fix reparenting of UARTs not associated with stdout") Signed-off-by: Dong Aisheng Link: https://lore.kernel.org/r/20210702085438.1988087-1-aisheng.dong@nxp.com Reviewed-by: Abel Vesa Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 2fcb62673120bda941728b39fda3f2aec824005f Author: Shaik Sajida Bhanu Date: Fri Jul 16 17:16:14 2021 +0530 mmc: sdhci-msm: Update the software timeout value for sdhc [ Upstream commit 67b13f3e221ed81b46a657e2b499bf8b20162476 ] Whenever SDHC run at clock rate 50MHZ or below, the hardware data timeout value will be 21.47secs, which is approx. 22secs and we have a current software timeout value as 10secs. We have to set software timeout value more than the hardware data timeout value to avioid seeing the below register dumps. [ 332.953670] mmc2: Timeout waiting for hardware interrupt. [ 332.959608] mmc2: sdhci: ============ SDHCI REGISTER DUMP =========== [ 332.966450] mmc2: sdhci: Sys addr: 0x00000000 | Version: 0x00007202 [ 332.973256] mmc2: sdhci: Blk size: 0x00000200 | Blk cnt: 0x00000001 [ 332.980054] mmc2: sdhci: Argument: 0x00000000 | Trn mode: 0x00000027 [ 332.986864] mmc2: sdhci: Present: 0x01f801f6 | Host ctl: 0x0000001f [ 332.993671] mmc2: sdhci: Power: 0x00000001 | Blk gap: 0x00000000 [ 333.000583] mmc2: sdhci: Wake-up: 0x00000000 | Clock: 0x00000007 [ 333.007386] mmc2: sdhci: Timeout: 0x0000000e | Int stat: 0x00000000 [ 333.014182] mmc2: sdhci: Int enab: 0x03ff100b | Sig enab: 0x03ff100b [ 333.020976] mmc2: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000 [ 333.027771] mmc2: sdhci: Caps: 0x322dc8b2 | Caps_1: 0x0000808f [ 333.034561] mmc2: sdhci: Cmd: 0x0000183a | Max curr: 0x00000000 [ 333.041359] mmc2: sdhci: Resp[0]: 0x00000900 | Resp[1]: 0x00000000 [ 333.048157] mmc2: sdhci: Resp[2]: 0x00000000 | Resp[3]: 0x00000000 [ 333.054945] mmc2: sdhci: Host ctl2: 0x00000000 [ 333.059657] mmc2: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x0000000ffffff218 [ 333.067178] mmc2: sdhci_msm: ----------- VENDOR REGISTER DUMP ----------- [ 333.074343] mmc2: sdhci_msm: DLL sts: 0x00000000 | DLL cfg: 0x6000642c | DLL cfg2: 0x0020a000 [ 333.083417] mmc2: sdhci_msm: DLL cfg3: 0x00000000 | DLL usr ctl: 0x00000000 | DDR cfg: 0x80040873 [ 333.092850] mmc2: sdhci_msm: Vndr func: 0x00008a9c | Vndr func2 : 0xf88218a8 Vndr func3: 0x02626040 [ 333.102371] mmc2: sdhci: ============================================ So, set software timeout value more than hardware timeout value. Signed-off-by: Shaik Sajida Bhanu Acked-by: Adrian Hunter Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/1626435974-14462-1-git-send-email-sbhanu@codeaurora.org Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 87762c77c39ff3f7ac73eafdf2e9a71c7a33573d Author: Christophe Kerello Date: Thu Jul 1 16:33:53 2021 +0200 mmc: mmci: stm32: Check when the voltage switch procedure should be done [ Upstream commit d8e193f13b07e6c0ffaa1a999386f1989f2b4c5e ] If the card has not been power cycled, it may still be using 1.8V signaling. This situation is detected in mmc_sd_init_card function and should be handled in mmci stm32 variant. The host->pwr_reg variable is also correctly protected with spin locks. Fixes: 94b94a93e355 ("mmc: mmci_sdmmc: Implement signal voltage callbacks") Signed-off-by: Christophe Kerello Signed-off-by: Yann Gautier Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210701143353.13188-1-yann.gautier@foss.st.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit fffcf7fc898a1b7a65e5440c263f95130c15457b Author: Vincent Whitchurch Date: Wed Jun 30 12:22:32 2021 +0200 mmc: dw_mmc: Fix hang on data CRC error [ Upstream commit 25f8203b4be1937c4939bb98623e67dcfd7da4d1 ] When a Data CRC interrupt is received, the driver disables the DMA, then sends the stop/abort command and then waits for Data Transfer Over. However, sometimes, when a data CRC error is received in the middle of a multi-block write transfer, the Data Transfer Over interrupt is never received, and the driver hangs and never completes the request. The driver sets the BMOD.SWR bit (SDMMC_IDMAC_SWRESET) when stopping the DMA, but according to the manual CMD.STOP_ABORT_CMD should be programmed "before assertion of SWR". Do these operations in the recommended order. With this change the Data Transfer Over is always received correctly in my tests. Signed-off-by: Vincent Whitchurch Reviewed-by: Jaehoon Chung Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210630102232.16011-1-vincent.whitchurch@axis.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 7179eac5556ea1cde58ba62df282fcd5d52f430a Author: Ezequiel Garcia Date: Thu Jul 22 22:05:52 2021 -0300 iommu/dma: Fix leak in non-contiguous API [ Upstream commit 0fbea680540108b09db7b26d9f4d24236d58a6ad ] Currently, iommu_dma_alloc_noncontiguous() allocates a struct dma_sgt_handle object to hold some state needed for iommu_dma_free_noncontiguous(). However, the handle is neither freed nor returned explicitly by the ->alloc_noncontiguous method, and therefore seems leaked. This was found by code inspection, so please review carefully and test. As a side note, it appears the struct dma_sgt_handle type is exposed to users of the DMA-API by linux/dma-map-ops.h, but is has no users or functions returning the type explicitly. This may indicate it's a good idea to move the struct dma_sgt_handle type to drivers/iommu/dma-iommu.c. The decision is left to maintainers :-) Cc: stable@vger.kernel.org Fixes: e817ee5f2f95c ("dma-iommu: implement ->alloc_noncontiguous") Signed-off-by: Ezequiel Garcia Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20210723010552.50969-1-ezequiel@collabora.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit b89542f4a60b3e702bc0831da4aa619fbbfaa82d Author: Vladimir Oltean Date: Thu Aug 19 17:17:55 2021 +0300 net: dpaa2-switch: disable the control interface on error path [ Upstream commit cd0a719fbd702eb4b455a6ad986483750125588a ] Currently dpaa2_switch_takedown has a funny name and does not do the opposite of dpaa2_switch_init, which makes probing fail when we need to handle an -EPROBE_DEFER. A sketch of what dpaa2_switch_init does: dpsw_open dpaa2_switch_detect_features dpsw_reset for (i = 0; i < ethsw->sw_attr.num_ifs; i++) { dpsw_if_disable dpsw_if_set_stp dpsw_vlan_remove_if_untagged dpsw_if_set_tci dpsw_vlan_remove_if } dpsw_vlan_remove alloc_ordered_workqueue dpsw_fdb_remove dpaa2_switch_ctrl_if_setup When dpaa2_switch_takedown is called from the error path of dpaa2_switch_probe(), the control interface, enabled by dpaa2_switch_ctrl_if_setup from dpaa2_switch_init, remains enabled, because dpaa2_switch_takedown does not call dpaa2_switch_ctrl_if_teardown. Since dpaa2_switch_probe might fail due to EPROBE_DEFER of a PHY, this means that a second probe of the driver will happen with the control interface directly enabled. This will trigger a second error: [ 93.273528] fsl_dpaa2_switch dpsw.0: dpsw_ctrl_if_set_pools() failed [ 93.281966] fsl_dpaa2_switch dpsw.0: fsl_mc_driver_probe failed: -13 [ 93.288323] fsl_dpaa2_switch: probe of dpsw.0 failed with error -13 Which if we investigate the /dev/dpaa2_mc_console log, we find out is caused by: [E, ctrl_if_set_pools:2211, DPMNG] ctrl_if must be disabled So make dpaa2_switch_takedown do the opposite of dpaa2_switch_init (in reasonable limits, no reason to change STP state, re-add VLANs etc), and rename it to something more conventional, like dpaa2_switch_teardown. Fixes: 613c0a5810b7 ("staging: dpaa2-switch: enable the control interface") Signed-off-by: Vladimir Oltean Reviewed-by: Ioana Ciornei Link: https://lore.kernel.org/r/20210819141755.1931423-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5d547d83abb2570f3136a4155a911b2a63d007a1 Author: Ido Schimmel Date: Thu Aug 19 13:58:42 2021 +0300 Revert "flow_offload: action should not be NULL when it is referenced" [ Upstream commit fa05bdb89b01b098aad19ec0ebc4d1cc7b11177e ] This reverts commit 9ea3e52c5bc8bb4a084938dc1e3160643438927a. Cited commit added a check to make sure 'action' is not NULL, but 'action' is already dereferenced before the check, when calling flow_offload_has_one_action(). Therefore, the check does not make any sense and results in a smatch warning: include/net/flow_offload.h:322 flow_action_mixed_hw_stats_check() warn: variable dereferenced before check 'action' (see line 319) Fix by reverting this commit. Cc: gushengxian Fixes: 9ea3e52c5bc8 ("flow_offload: action should not be NULL when it is referenced") Signed-off-by: Ido Schimmel Acked-by: Jamal Hadi Salim Link: https://lore.kernel.org/r/20210819105842.1315705-1-idosch@idosch.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 260b1eb312a0b0684a962ab825e91ba16ba1982d Author: Sylwester Dziedziuch Date: Wed Aug 18 10:42:17 2021 -0700 iavf: Fix ping is lost after untrusted VF had tried to change MAC [ Upstream commit 8da80c9d50220a8e4190a4eaa0dd6aeefcbbb5bf ] Make changes to MAC address dependent on the response of PF. Disallow changes to HW MAC address and MAC filter from untrusted VF, thanks to that ping is not lost if VF tries to change MAC. Add a new field in iavf_mac_filter, to indicate whether there was response from PF for given filter. Based on this field pass or discard the filter. If untrusted VF tried to change it's address, it's not changed. Still filter was changed, because of that ping couldn't go through. Fixes: c5c922b3e09b ("iavf: fix MAC address setting for VFs when filter is rejected") Signed-off-by: Przemyslaw Patynowski Signed-off-by: Sylwester Dziedziuch Signed-off-by: Mateusz Palczewski Tested-by: Gurucharan G Signed-off-by: Tony Nguyen Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ea1cf8a6d9660405e7f2f907767deb81731f4f36 Author: Arkadiusz Kubalewski Date: Wed Aug 18 10:42:16 2021 -0700 i40e: Fix ATR queue selection [ Upstream commit a222be597e316389f9f8c26033352c124ce93056 ] Without this patch, ATR does not work. Receive/transmit uses queue selection based on SW DCB hashing method. If traffic classes are not configured for PF, then use netdev_pick_tx function for selecting queue for packet transmission. Instead of calling i40e_swdcb_skb_tx_hash, call netdev_pick_tx, which ensures that packet is transmitted/received from CPU that is running the application. Reproduction steps: 1. Load i40e driver 2. Map each MSI interrupt of i40e port for each CPU 3. Disable ntuple, enable ATR i.e.: ethtool -K $interface ntuple off ethtool --set-priv-flags $interface flow-director-atr 4. Run application that is generating traffic and is bound to a single CPU, i.e.: taskset -c 9 netperf -H 1.1.1.1 -t TCP_RR -l 10 5. Observe behavior: Application's traffic should be restricted to the CPU provided in taskset. Fixes: 89ec1f0886c1 ("i40e: Fix queue-to-TC mapping on Tx") Signed-off-by: Przemyslaw Patynowski Signed-off-by: Arkadiusz Kubalewski Tested-by: Dave Switzer Signed-off-by: Tony Nguyen Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1d9d64cad2fe68f08a7b32ce5c3b69a9dd8a3d61 Author: Krzysztof Wilczyński Date: Thu Aug 12 13:21:44 2021 +0000 PCI/sysfs: Use correct variable for the legacy_mem sysfs object [ Upstream commit 045a9277b5615846c7b662ffaba84e781f08a172 ] Two legacy PCI sysfs objects "legacy_io" and "legacy_mem" were updated to use an unified address space in the commit 636b21b50152 ("PCI: Revoke mappings like devmem"). This allows for revocations to be managed from a single place when drivers want to take over and mmap() a /dev/mem range. Following the update, both of the sysfs objects should leverage the iomem_get_mapping() function to get an appropriate address range, but only the "legacy_io" has been correctly updated - the second attribute seems to be using a wrong variable to pass the iomem_get_mapping() function to. Thus, correct the variable name used so that the "legacy_mem" sysfs object would also correctly call the iomem_get_mapping() function. Fixes: 636b21b50152 ("PCI: Revoke mappings like devmem") Link: https://lore.kernel.org/r/20210812132144.791268-1-kw@linux.com Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Reviewed-by: Daniel Vetter Signed-off-by: Sasha Levin commit f21adfddafdf496b2bcebbc9e0fd53591868372d Author: Hayes Wang Date: Thu Aug 19 11:05:37 2021 +0800 r8152: fix the maximum number of PLA bp for RTL8153C [ Upstream commit 6633fb83f1faddbfcac09e35edcae96bd0468335 ] The maximum PLA bp number of RTL8153C is 16, not 8. That is, the bp 0 ~ 15 are at 0xfc28 ~ 0xfc46, and the bp_en is at 0xfc48. Fixes: 195aae321c82 ("r8152: support new chips") Signed-off-by: Hayes Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5809f8d9b7c06875ab42fa402ed301871e7d05fb Author: Hayes Wang Date: Thu Aug 19 11:05:36 2021 +0800 r8152: fix writing USB_BP2_EN [ Upstream commit a876a33d2a1102f99fc782fefb784f4dd4841d8c ] The register of USB_BP2_EN is 16 bits, so we should use ocp_write_word(), not ocp_write_byte(). Fixes: 9370f2d05a2a ("support request_firmware for RTL8153") Signed-off-by: Hayes Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit dedbf29c6b3667392fe09f3c05b728c8fc8f45cc Author: Matthieu Baerts Date: Wed Aug 18 16:42:37 2021 -0700 mptcp: full fully established support after ADD_ADDR [ Upstream commit 67b12f792d5eaeb8b4fca3b2053e6b819eb3bf0f ] If directly after an MP_CAPABLE 3WHS, the client receives an ADD_ADDR with HMAC from the server, it is enough to switch to a "fully established" mode because it has received more MPTCP options. It was then OK to enable the "fully_established" flag on the MPTCP socket. Still, best to check if the ADD_ADDR looks valid by looking if it contains an HMAC (no 'echo' bit). If an ADD_ADDR echo is received while we are not in "fully established" mode, it is strange and then we should not switch to this mode now. But that is not enough. On one hand, the path-manager has be notified the state has changed. On the other hand, the "fully_established" flag on the subflow socket should be turned on as well not to re-send the MP_CAPABLE 3rd ACK content with the next ACK. Fixes: 84dfe3677a6f ("mptcp: send out dedicated ADD_ADDR packet") Signed-off-by: Matthieu Baerts Signed-off-by: Mat Martineau Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 828c3a32238c8e38427c0a53a49f1877c0fec5e4 Author: Paolo Abeni Date: Wed Aug 18 16:42:36 2021 -0700 mptcp: fix memory leak on address flush [ Upstream commit a0eea5f10eeb5180d115452b0d77afa6603dfe18 ] The endpoint cleanup path is prone to a memory leak, as reported by syzkaller: BUG: memory leak unreferenced object 0xffff88810680ea00 (size 64): comm "syz-executor.6", pid 6191, jiffies 4295756280 (age 24.138s) hex dump (first 32 bytes): 58 75 7d 3c 80 88 ff ff 22 01 00 00 00 00 ad de Xu}<...."....... 01 00 02 00 00 00 00 00 ac 1e 00 07 00 00 00 00 ................ backtrace: [<0000000072a9f72a>] kmalloc include/linux/slab.h:591 [inline] [<0000000072a9f72a>] mptcp_nl_cmd_add_addr+0x287/0x9f0 net/mptcp/pm_netlink.c:1170 [<00000000f6e931bf>] genl_family_rcv_msg_doit.isra.0+0x225/0x340 net/netlink/genetlink.c:731 [<00000000f1504a2c>] genl_family_rcv_msg net/netlink/genetlink.c:775 [inline] [<00000000f1504a2c>] genl_rcv_msg+0x341/0x5b0 net/netlink/genetlink.c:792 [<0000000097e76f6a>] netlink_rcv_skb+0x148/0x430 net/netlink/af_netlink.c:2504 [<00000000ceefa2b8>] genl_rcv+0x24/0x40 net/netlink/genetlink.c:803 [<000000008ff91aec>] netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline] [<000000008ff91aec>] netlink_unicast+0x537/0x750 net/netlink/af_netlink.c:1340 [<0000000041682c35>] netlink_sendmsg+0x846/0xd80 net/netlink/af_netlink.c:1929 [<00000000df3aa8e7>] sock_sendmsg_nosec net/socket.c:704 [inline] [<00000000df3aa8e7>] sock_sendmsg+0x14e/0x190 net/socket.c:724 [<000000002154c54c>] ____sys_sendmsg+0x709/0x870 net/socket.c:2403 [<000000001aab01d7>] ___sys_sendmsg+0xff/0x170 net/socket.c:2457 [<00000000fa3b1446>] __sys_sendmsg+0xe5/0x1b0 net/socket.c:2486 [<00000000db2ee9c7>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<00000000db2ee9c7>] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80 [<000000005873517d>] entry_SYSCALL_64_after_hwframe+0x44/0xae We should not require an allocation to cleanup stuff. Rework the code a bit so that the additional RCU work is no more needed. Fixes: 1729cf186d8a ("mptcp: create the listening socket for new port") Signed-off-by: Paolo Abeni Signed-off-by: Mat Martineau Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 11c79e1615a4deed7f8f4e74cc2adbfae781393d Author: Vladimir Oltean Date: Tue Aug 17 19:04:25 2021 +0300 net: mscc: ocelot: allow forwarding from bridge ports to the tag_8021q CPU port [ Upstream commit c1930148a3941f891ddbd76fceaa4e10a957ccf2 ] Currently we are unable to ping a bridge on top of a felix switch which uses the ocelot-8021q tagger. The packets are dropped on the ingress of the user port and the 'drop_local' counter increments (the counter which denotes drops due to no valid destinations). Dumping the PGID tables, it becomes clear that the PGID_SRC of the user port is zero, so it has no valid destinations. But looking at the code, the cpu_fwd_mask (the bit mask of DSA tag_8021q ports) is clearly missing from the forwarding mask of ports that are under a bridge. So this has always been broken. Looking at the version history of the patch, in v7 https://patchwork.kernel.org/project/netdevbpf/patch/20210125220333.1004365-12-olteanv@gmail.com/ the code looked like this: /* Standalone ports forward only to DSA tag_8021q CPU ports */ unsigned long mask = cpu_fwd_mask; (...) } else if (ocelot->bridge_fwd_mask & BIT(port)) { mask |= ocelot->bridge_fwd_mask & ~BIT(port); while in v8 (the merged version) https://patchwork.kernel.org/project/netdevbpf/patch/20210129010009.3959398-12-olteanv@gmail.com/ it looked like this: unsigned long mask; (...) } else if (ocelot->bridge_fwd_mask & BIT(port)) { mask = ocelot->bridge_fwd_mask & ~BIT(port); So the breakage was introduced between v7 and v8 of the patch. Fixes: e21268efbe26 ("net: dsa: felix: perform switch setup for tag_8021q") Signed-off-by: Vladimir Oltean Link: https://lore.kernel.org/r/20210817160425.3702809-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 751f4b539afb21dbd11a390938c55296e8302efc Author: Zhan Liu Date: Fri Aug 13 08:31:04 2021 -0700 drm/amd/display: Use DCN30 watermark calc for DCN301 [ Upstream commit 37717b8c9f0e8c4dd73fc522769cc14649b4f657 ] [why] dcn301_calculate_wm_and_dl() causes flickering when external monitor is connected. This issue has been fixed before by commit 0e4c0ae59d7e ("drm/amdgpu/display: drop dcn301_calculate_wm_and_dl for now"), however part of the fix was gone after commit 2cbcb78c9ee5 ("Merge tag 'amd-drm-next-5.13-2021-03-23' of https://gitlab.freedesktop.org/agd5f/linux into drm-next"). [how] Use dcn30_calculate_wm_and_dlg() instead as in the original fix. Fixes: 2cbcb78c9ee5 ("Merge tag 'amd-drm-next-5.13-2021-03-23' of https://gitlab.freedesktop.org/agd5f/linux into drm-next") Signed-off-by: Nikola Cornij Reviewed-by: Zhan Liu Tested-by: Zhan Liu Tested-by: Oliver Logush Signed-off-by: Zhan Liu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit e0f2d91e08690a85872c1c021fc49132a1f9c31b Author: Anshuman Gupta Date: Tue Aug 10 17:01:12 2021 +0530 drm/i915: Tweaked Wa_14010685332 for all PCHs [ Upstream commit b8441b288d6031eac21390891ba36487b2cb398b ] dispcnlunit1_cp_xosc_clkreq clock observed to be active on TGL-H platform despite Wa_14010685332 original sequence, thus blocks entry to deeper s0ix state. The Tweaked Wa_14010685332 sequence fixes this issue, therefore use tweaked Wa_14010685332 sequence for every PCH since PCH_CNP. v2: - removed RKL from comment and simplified condition. [Rodrigo] Fixes: b896898c7369 ("drm/i915: Tweaked Wa_14010685332 for PCHs used on gen11 platforms") Cc: Matt Roper Cc: Rodrigo Vivi Cc: Imre Deak Signed-off-by: Anshuman Gupta Reviewed-by: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/20210810113112.31739-2-anshuman.gupta@intel.com (cherry picked from commit 8b46cc6577f4bbef7e5909bb926da31d705f350f) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 678b67771cefd32ff595d3d04cfbce915ed7bccd Author: José Roberto de Souza Date: Thu Apr 8 13:31:48 2021 -0700 drm/i915: Skip display interruption setup when display is not available [ Upstream commit a844cfbe648d15d9f1031c45508c194f2d61c917 ] Return ealier in the functions doing interruption setup for GEN8+ also adding a warning in gen8_de_irq_handler() to let us know that something else is still missing. Reviewed-by: Radhakrishna Sripada Cc: Ville Syrjälä Cc: Lucas De Marchi Signed-off-by: José Roberto de Souza Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20210408203150.237947-1-jose.souza@intel.com Signed-off-by: Sasha Levin commit 936eca018feeb86ef4c39e638cc4d279b72e29c1 Author: Liu Yi L Date: Tue Aug 17 20:43:21 2021 +0800 iommu/vt-d: Fix incomplete cache flush in intel_pasid_tear_down_entry() [ Upstream commit 8798d36411196da86e70b994725349c16c1119f6 ] This fixes improper iotlb invalidation in intel_pasid_tear_down_entry(). When a PASID was used as nested mode, released and reused, the following error message will appear: [ 180.187556] Unexpected page request in Privilege Mode [ 180.187565] Unexpected page request in Privilege Mode [ 180.279933] Unexpected page request in Privilege Mode [ 180.279937] Unexpected page request in Privilege Mode Per chapter 6.5.3.3 of VT-d spec 3.3, when tear down a pasid entry, the software should use Domain selective IOTLB flush if the PGTT of the pasid entry is SL only or Nested, while for the pasid entries whose PGTT is FL only or PT using PASID-based IOTLB flush is enough. Fixes: 2cd1311a26673 ("iommu/vt-d: Add set domain DOMAIN_ATTR_NESTING attr") Signed-off-by: Kumar Sanjay K Signed-off-by: Liu Yi L Tested-by: Yi Sun Link: https://lore.kernel.org/r/20210817042425.1784279-1-yi.l.liu@intel.com Signed-off-by: Lu Baolu Link: https://lore.kernel.org/r/20210817124321.1517985-3-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 4e4f3cb41d687bd64cd03358862b23c84d82329e Author: Oleksij Rempel Date: Mon Jun 7 10:27:21 2021 +0200 net: usb: asix: refactor asix_read_phy_addr() and handle errors on return [ Upstream commit 7e88b11a862afe59ee0c365123ea5fb96a26cb3b ] Refactor asix_read_phy_addr() to return usable error value directly and make sure all callers handle this error. Signed-off-by: Oleksij Rempel Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit cf4c1661c40ecf0db2db121999f7adbcb0b65c7f Author: kaixi.fan Date: Wed Aug 18 10:22:15 2021 +0800 ovs: clear skb->tstamp in forwarding path [ Upstream commit 01634047bf0d5c2d9b7d8095bb4de1663dbeedeb ] fq qdisc requires tstamp to be cleared in the forwarding path. Now ovs doesn't clear skb->tstamp. We encountered a problem with linux version 5.4.56 and ovs version 2.14.1, and packets failed to dequeue from qdisc when fq qdisc was attached to ovs port. Fixes: fb420d5d91c1 ("tcp/fq: move back to CLOCK_MONOTONIC") Signed-off-by: kaixi.fan Signed-off-by: xiexiaohui Reviewed-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9581895b37fe3a8c83e102cc491c6c7996df2934 Author: Saravana Kannan Date: Tue Aug 17 20:38:03 2021 -0700 net: mdio-mux: Handle -EPROBE_DEFER correctly [ Upstream commit 7bd0cef5dac685f09ef8b0b2a7748ff42d284dc7 ] When registering mdiobus children, if we get an -EPROBE_DEFER, we shouldn't ignore it and continue registering the rest of the mdiobus children. This would permanently prevent the deferring child mdiobus from working instead of reattempting it in the future. So, if a child mdiobus needs to be reattempted in the future, defer the entire mdio-mux initialization. This fixes the issue where PHYs sitting under the mdio-mux aren't initialized correctly if the PHY's interrupt controller is not yet ready when the mdio-mux is being probed. Additional context in the link below. Fixes: 0ca2997d1452 ("netdev/of/phy: Add MDIO bus multiplexer support.") Link: https://lore.kernel.org/lkml/CAGETcx95kHrv8wA-O+-JtfH7H9biJEGJtijuPVN0V5dUKUAB3A@mail.gmail.com/#t Signed-off-by: Saravana Kannan Reviewed-by: Andrew Lunn Acked-by: Marc Zyngier Tested-by: Marc Zyngier Acked-by: Kevin Hilman Tested-by: Kevin Hilman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b2973b87ba11ede34bd7713e4c76ee6cfb89b3fb Author: Saravana Kannan Date: Tue Aug 17 20:38:02 2021 -0700 net: mdio-mux: Don't ignore memory allocation errors [ Upstream commit 99d81e942474cc7677d12f673f42a7ea699e2589 ] If we are seeing memory allocation errors, don't try to continue registering child mdiobus devices. It's unlikely they'll succeed. Fixes: 342fa1964439 ("mdio: mux: make child bus walking more permissive and errors more verbose") Signed-off-by: Saravana Kannan Reviewed-by: Andrew Lunn Acked-by: Marc Zyngier Tested-by: Marc Zyngier Acked-by: Kevin Hilman Tested-by: Kevin Hilman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0e805b74cd139e4ad42580cc8a60a8d9cb83f358 Author: Toke Høiland-Jørgensen Date: Mon Aug 16 13:59:17 2021 +0200 sch_cake: fix srchost/dsthost hashing mode [ Upstream commit 86b9bbd332d0510679c7fedcee3e3bd278be5756 ] When adding support for using the skb->hash value as the flow hash in CAKE, I accidentally introduced a logic error that broke the host-only isolation modes of CAKE (srchost and dsthost keywords). Specifically, the flow_hash variable should stay initialised to 0 in cake_hash() in pure host-based hashing mode. Add a check for this before using the skb->hash value as flow_hash. Fixes: b0c19ed6088a ("sch_cake: Take advantage of skb->hash where appropriate") Reported-by: Pete Heist Tested-by: Pete Heist Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ac161cf77818dc0de7cb9c6a9847d33ca28ea34f Author: Wang Hai Date: Tue Aug 17 13:37:36 2021 -0700 ixgbe, xsk: clean up the resources in ixgbe_xsk_pool_enable error path [ Upstream commit 1b80fec7b043552e01609bae7d0aad07aa742adc ] In ixgbe_xsk_pool_enable(), if ixgbe_xsk_wakeup() fails, We should restore the previous state and clean up the resources. Add the missing clear af_xdp_zc_qps and unmap dma to fix this bug. Fixes: d49e286d354e ("ixgbe: add tracking of AF_XDP zero-copy state for each queue pair") Fixes: 4a9b32f30f80 ("ixgbe: fix potential RX buffer starvation for AF_XDP") Signed-off-by: Wang Hai Acked-by: Magnus Karlsson Tested-by: Sandeep Penigalapati Signed-off-by: Tony Nguyen Link: https://lore.kernel.org/r/20210817203736.3529939-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7af09aeddbaefa61d6d9431b9f0af9c47b4a8da6 Author: Dinghao Liu Date: Mon Aug 16 21:14:04 2021 +0800 net: qlcnic: add missed unlock in qlcnic_83xx_flash_read32 [ Upstream commit 0a298d133893c72c96e2156ed7cb0f0c4a306a3e ] qlcnic_83xx_unlock_flash() is called on all paths after we call qlcnic_83xx_lock_flash(), except for one error path on failure of QLCRD32(), which may cause a deadlock. This bug is suggested by a static analysis tool, please advise. Fixes: 81d0aeb0a4fff ("qlcnic: flash template based firmware reset recovery") Signed-off-by: Dinghao Liu Link: https://lore.kernel.org/r/20210816131405.24024-1-dinghao.liu@zju.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 39af3583c8fb28cf65a6272b9e85a0400ea8b99a Author: Johannes Berg Date: Tue Aug 17 12:12:22 2021 +0200 mac80211: fix locking in ieee80211_restart_work() [ Upstream commit 276e189f8e4e3cce1634d6bac4ed0d9ca242441b ] Ilan's change to move locking around accidentally lost the wiphy_lock() during some porting, add it back. Fixes: 45daaa131841 ("mac80211: Properly WARN on HW scan before restart") Signed-off-by: Johannes Berg Link: https://lore.kernel.org/r/20210817121210.47bdb177064f.Ib1ef79440cd27f318c028ddfc0c642406917f512@changeid Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0de9c4de5ca1e337f70a651be6d90fe16ae086e5 Author: Jason Wang Date: Tue Aug 17 16:06:59 2021 +0800 virtio-net: use NETIF_F_GRO_HW instead of NETIF_F_LRO [ Upstream commit dbcf24d153884439dad30484a0e3f02350692e4c ] Commit a02e8964eaf92 ("virtio-net: ethtool configurable LRO") maps LRO to virtio guest offloading features and allows the administrator to enable and disable those features via ethtool. This leads to several issues: - For a device that doesn't support control guest offloads, the "LRO" can't be disabled triggering WARN in dev_disable_lro() when turning off LRO or when enabling forwarding bridging etc. - For a device that supports control guest offloads, the guest offloads are disabled in cases of bridging, forwarding etc slowing down the traffic. Fix this by using NETIF_F_GRO_HW instead. Though the spec does not guarantee packets to be re-segmented as the original ones, we can add that to the spec, possibly with a flag for devices to differentiate between GRO and LRO. Further, we never advertised LRO historically before a02e8964eaf92 ("virtio-net: ethtool configurable LRO") and so bridged/forwarded configs effectively always relied on virtio receive offloads behaving like GRO - thus even if this breaks any configs it is at least not a regression. Fixes: a02e8964eaf92 ("virtio-net: ethtool configurable LRO") Acked-by: Michael S. Tsirkin Reported-by: Ivan Tested-by: Ivan Signed-off-by: Jason Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9213ce6672582bc12f02c1530726fe97030d2cfe Author: Lahav Schlesinger Date: Sun Aug 15 12:00:02 2021 +0000 vrf: Reset skb conntrack connection on VRF rcv [ Upstream commit 09e856d54bda5f288ef8437a90ab2b9b3eab83d1 ] To fix the "reverse-NAT" for replies. When a packet is sent over a VRF, the POST_ROUTING hooks are called twice: Once from the VRF interface, and once from the "actual" interface the packet will be sent from: 1) First SNAT: l3mdev_l3_out() -> vrf_l3_out() -> .. -> vrf_output_direct() This causes the POST_ROUTING hooks to run. 2) Second SNAT: 'ip_output()' calls POST_ROUTING hooks again. Similarly for replies, first ip_rcv() calls PRE_ROUTING hooks, and second vrf_l3_rcv() calls them again. As an example, consider the following SNAT rule: > iptables -t nat -A POSTROUTING -p udp -m udp --dport 53 -j SNAT --to-source 2.2.2.2 -o vrf_1 In this case sending over a VRF will create 2 conntrack entries. The first is from the VRF interface, which performs the IP SNAT. The second will run the SNAT, but since the "expected reply" will remain the same, conntrack randomizes the source port of the packet: e..g With a socket bound to 1.1.1.1:10000, sending to 3.3.3.3:53, the conntrack rules are: udp 17 29 src=2.2.2.2 dst=3.3.3.3 sport=10000 dport=53 packets=1 bytes=68 [UNREPLIED] src=3.3.3.3 dst=2.2.2.2 sport=53 dport=61033 packets=0 bytes=0 mark=0 use=1 udp 17 29 src=1.1.1.1 dst=3.3.3.3 sport=10000 dport=53 packets=1 bytes=68 [UNREPLIED] src=3.3.3.3 dst=2.2.2.2 sport=53 dport=10000 packets=0 bytes=0 mark=0 use=1 i.e. First SNAT IP from 1.1.1.1 --> 2.2.2.2, and second the src port is SNAT-ed from 10000 --> 61033. But when a reply is sent (3.3.3.3:53 -> 2.2.2.2:61033) only the later conntrack entry is matched: udp 17 29 src=2.2.2.2 dst=3.3.3.3 sport=10000 dport=53 packets=1 bytes=68 src=3.3.3.3 dst=2.2.2.2 sport=53 dport=61033 packets=1 bytes=49 mark=0 use=1 udp 17 28 src=1.1.1.1 dst=3.3.3.3 sport=10000 dport=53 packets=1 bytes=68 [UNREPLIED] src=3.3.3.3 dst=2.2.2.2 sport=53 dport=10000 packets=0 bytes=0 mark=0 use=1 And a "port 61033 unreachable" ICMP packet is sent back. The issue is that when PRE_ROUTING hooks are called from vrf_l3_rcv(), the skb already has a conntrack flow attached to it, which means nf_conntrack_in() will not resolve the flow again. This means only the dest port is "reverse-NATed" (61033 -> 10000) but the dest IP remains 2.2.2.2, and since the socket is bound to 1.1.1.1 it's not received. This can be verified by logging the 4-tuple of the packet in '__udp4_lib_rcv()'. The fix is then to reset the flow when skb is received on a VRF, to let conntrack resolve the flow again (which now will hit the earlier flow). To reproduce: (Without the fix "Got pkt_to_nat_port" will not be printed by running 'bash ./repro'): $ cat run_in_A1.py import logging logging.getLogger("scapy.runtime").setLevel(logging.ERROR) from scapy.all import * import argparse def get_packet_to_send(udp_dst_port, msg_name): return Ether(src='11:22:33:44:55:66', dst=iface_mac)/ \ IP(src='3.3.3.3', dst='2.2.2.2')/ \ UDP(sport=53, dport=udp_dst_port)/ \ Raw(f'{msg_name}\x0012345678901234567890') parser = argparse.ArgumentParser() parser.add_argument('-iface_mac', dest="iface_mac", type=str, required=True, help="From run_in_A3.py") parser.add_argument('-socket_port', dest="socket_port", type=str, required=True, help="From run_in_A3.py") parser.add_argument('-v1_mac', dest="v1_mac", type=str, required=True, help="From script") args, _ = parser.parse_known_args() iface_mac = args.iface_mac socket_port = int(args.socket_port) v1_mac = args.v1_mac print(f'Source port before NAT: {socket_port}') while True: pkts = sniff(iface='_v0', store=True, count=1, timeout=10) if 0 == len(pkts): print('Something failed, rerun the script :(', flush=True) break pkt = pkts[0] if not pkt.haslayer('UDP'): continue pkt_sport = pkt.getlayer('UDP').sport print(f'Source port after NAT: {pkt_sport}', flush=True) pkt_to_send = get_packet_to_send(pkt_sport, 'pkt_to_nat_port') sendp(pkt_to_send, '_v0', verbose=False) # Will not be received pkt_to_send = get_packet_to_send(socket_port, 'pkt_to_socket_port') sendp(pkt_to_send, '_v0', verbose=False) break $ cat run_in_A2.py import socket import netifaces print(f"{netifaces.ifaddresses('e00000')[netifaces.AF_LINK][0]['addr']}", flush=True) s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) s.setsockopt(socket.SOL_SOCKET, socket.SO_BINDTODEVICE, str('vrf_1' + '\0').encode('utf-8')) s.connect(('3.3.3.3', 53)) print(f'{s. getsockname()[1]}', flush=True) s.settimeout(5) while True: try: # Periodically send in order to keep the conntrack entry alive. s.send(b'a'*40) resp = s.recvfrom(1024) msg_name = resp[0].decode('utf-8').split('\0')[0] print(f"Got {msg_name}", flush=True) except Exception as e: pass $ cat repro.sh ip netns del A1 2> /dev/null ip netns del A2 2> /dev/null ip netns add A1 ip netns add A2 ip -n A1 link add _v0 type veth peer name _v1 netns A2 ip -n A1 link set _v0 up ip -n A2 link add e00000 type bond ip -n A2 link add lo0 type dummy ip -n A2 link add vrf_1 type vrf table 10001 ip -n A2 link set vrf_1 up ip -n A2 link set e00000 master vrf_1 ip -n A2 addr add 1.1.1.1/24 dev e00000 ip -n A2 link set e00000 up ip -n A2 link set _v1 master e00000 ip -n A2 link set _v1 up ip -n A2 link set lo0 up ip -n A2 addr add 2.2.2.2/32 dev lo0 ip -n A2 neigh add 1.1.1.10 lladdr 77:77:77:77:77:77 dev e00000 ip -n A2 route add 3.3.3.3/32 via 1.1.1.10 dev e00000 table 10001 ip netns exec A2 iptables -t nat -A POSTROUTING -p udp -m udp --dport 53 -j \ SNAT --to-source 2.2.2.2 -o vrf_1 sleep 5 ip netns exec A2 python3 run_in_A2.py > x & XPID=$! sleep 5 IFACE_MAC=`sed -n 1p x` SOCKET_PORT=`sed -n 2p x` V1_MAC=`ip -n A2 link show _v1 | sed -n 2p | awk '{print $2'}` ip netns exec A1 python3 run_in_A1.py -iface_mac ${IFACE_MAC} -socket_port \ ${SOCKET_PORT} -v1_mac ${SOCKET_PORT} sleep 5 kill -9 $XPID wait $XPID 2> /dev/null ip netns del A1 ip netns del A2 tail x -n 2 rm x set +x Fixes: 73e20b761acf ("net: vrf: Add support for PREROUTING rules on vrf device") Signed-off-by: Lahav Schlesinger Reviewed-by: David Ahern Link: https://lore.kernel.org/r/20210815120002.2787653-1-lschlesinger@drivenets.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a5607b1d8e34961e10de9cd1f83b7f9d0890aec3 Author: Michael Chan Date: Sun Aug 15 16:15:37 2021 -0400 bnxt_en: Add missing DMA memory barriers [ Upstream commit 828affc27ed43441bd1efdaf4e07e96dd43a0362 ] Each completion ring entry has a valid bit to indicate that the entry contains a valid completion event. The driver's main poll loop __bnxt_poll_work() has the proper dma_rmb() to make sure the valid bit of the next entry has been checked before proceeding further. But when we call bnxt_rx_pkt() to process the RX event, the RX completion event consists of two completion entries and only the first entry has been checked to be valid. We need the same barrier after checking the next completion entry. Add missing dma_rmb() barriers in bnxt_rx_pkt() and other similar locations. Fixes: 67a95e2022c7 ("bnxt_en: Need memory barrier when processing the completion ring.") Reported-by: Lance Richardson Reviewed-by: Andy Gospodarek Reviewed-by: Lance Richardson Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 020761f49efb63edd0530630d2cbde8c61454bdd Author: Michael Chan Date: Sun Aug 15 16:15:36 2021 -0400 bnxt_en: Disable aRFS if running on 212 firmware [ Upstream commit 976e52b718c3de9077fff8f3f674afb159c57fb1 ] 212 firmware broke aRFS, so disable it. Traffic may stop after ntuple filters are inserted and deleted by the 212 firmware. Fixes: ae10ae740ad2 ("bnxt_en: Add new hardware RFS mode.") Reviewed-by: Pavan Chebbi Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1a2798f36805928b4b436ccca0757ce3d7e59304 Author: Andy Shevchenko Date: Fri Aug 13 20:33:27 2021 +0300 ptp_pch: Restore dependency on PCI [ Upstream commit 55c8fca1dae1fb0d11deaa21b65a647dedb1bc50 ] During the swap dependency on PCH_GBE to selection PTP_1588_CLOCK_PCH incidentally dropped the implicit dependency on the PCI. Restore it. Fixes: 18d359ceb044 ("pch_gbe, ptp_pch: Fix the dependency direction between these drivers") Reported-by: kernel test robot Signed-off-by: Andy Shevchenko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 010d7ad77e2d87686eb64688fdf40532cb55c429 Author: Pavel Skripkin Date: Fri Aug 13 18:14:33 2021 +0300 net: 6pack: fix slab-out-of-bounds in decode_data [ Upstream commit 19d1532a187669ce86d5a2696eb7275310070793 ] Syzbot reported slab-out-of bounds write in decode_data(). The problem was in missing validation checks. Syzbot's reproducer generated malicious input, which caused decode_data() to be called a lot in sixpack_decode(). Since rx_count_cooked is only 400 bytes and noone reported before, that 400 bytes is not enough, let's just check if input is malicious and complain about buffer overrun. Fail log: ================================================================== BUG: KASAN: slab-out-of-bounds in drivers/net/hamradio/6pack.c:843 Write of size 1 at addr ffff888087c5544e by task kworker/u4:0/7 CPU: 0 PID: 7 Comm: kworker/u4:0 Not tainted 5.6.0-rc3-syzkaller #0 ... Workqueue: events_unbound flush_to_ldisc Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x197/0x210 lib/dump_stack.c:118 print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374 __kasan_report.cold+0x1b/0x32 mm/kasan/report.c:506 kasan_report+0x12/0x20 mm/kasan/common.c:641 __asan_report_store1_noabort+0x17/0x20 mm/kasan/generic_report.c:137 decode_data.part.0+0x23b/0x270 drivers/net/hamradio/6pack.c:843 decode_data drivers/net/hamradio/6pack.c:965 [inline] sixpack_decode drivers/net/hamradio/6pack.c:968 [inline] Reported-and-tested-by: syzbot+fc8cd9a673d4577fb2e4@syzkaller.appspotmail.com Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Pavel Skripkin Reviewed-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 47d43f06fd879d66cfba77ea20111be48ceece0b Author: Maxim Kochetkov Date: Wed Aug 11 10:10:36 2021 +0300 soc: fsl: qe: fix static checker warning [ Upstream commit c1e64c0aec8cb0499e61af7ea086b59abba97945 ] The patch be7ecbd240b2: "soc: fsl: qe: convert QE interrupt controller to platform_device" from Aug 3, 2021, leads to the following static checker warning: drivers/soc/fsl/qe/qe_ic.c:438 qe_ic_init() warn: unsigned 'qe_ic->virq_low' is never less than zero. In old variant irq_of_parse_and_map() returns zero if failed so unsigned int for virq_high/virq_low was ok. In new variant platform_get_irq() returns negative error codes if failed so we need to use int for virq_high/virq_low. Also simplify high_handler checking and remove the curly braces to make checkpatch happy. Fixes: be7ecbd240b2 ("soc: fsl: qe: convert QE interrupt controller to platform_device") Signed-off-by: Maxim Kochetkov Reported-by: Dan Carpenter Signed-off-by: Li Yang Signed-off-by: Sasha Levin commit 5eb70221eb037965cc11d747c9eb9030902920c6 Author: Jakub Kicinski Date: Thu Aug 12 14:42:42 2021 -0700 bnxt: count Tx drops [ Upstream commit fb9f7190092d2bbd1f8f0b1cc252732cbe99a87e ] Drivers should count packets they are dropping. Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.") Reviewed-by: Michael Chan Reviewed-by: Edwin Peer Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 40c767494e15d462c486dff57b43c89f07920e70 Author: Jakub Kicinski Date: Thu Aug 12 14:42:41 2021 -0700 bnxt: make sure xmit_more + errors does not miss doorbells [ Upstream commit e8d8c5d80f5e9d4586c68061b62c642752289095 ] skbs are freed on error and not put on the ring. We may, however, be in a situation where we're freeing the last skb of a batch, and there is a doorbell ring pending because of xmit_more() being true earlier. Make sure we ring the door bell in such situations. Since errors are rare don't pay attention to xmit_more() and just always flush the pending frames. The busy case should be safe to be left alone because it can only happen if start_xmit races with completions and they both enable the queue. In that case the kick can't be pending. Noticed while reading the code. Fixes: 4d172f21cefe ("bnxt_en: Implement xmit_more.") Reviewed-by: Michael Chan Reviewed-by: Edwin Peer Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7812792579683092e1e091e711cac82736f69499 Author: Jakub Kicinski Date: Thu Aug 12 14:42:40 2021 -0700 bnxt: disable napi before canceling DIM [ Upstream commit 01cca6b9330ac7460de44eeeb3a0607f8aae69ff ] napi schedules DIM, napi has to be disabled first, then DIM canceled. Noticed while reading the code. Fixes: 0bc0b97fca73 ("bnxt_en: cleanup DIM work on device shutdown") Fixes: 6a8788f25625 ("bnxt_en: add support for software dynamic interrupt moderation") Reviewed-by: Michael Chan Reviewed-by: Edwin Peer Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7edc1a0deca89176078a57db7d4e5c881f2dd296 Author: Jakub Kicinski Date: Thu Aug 12 14:42:39 2021 -0700 bnxt: don't lock the tx queue from napi poll [ Upstream commit 3c603136c9f82833813af77185618de5af67676c ] We can't take the tx lock from the napi poll routine, because netpoll can poll napi at any moment, including with the tx lock already held. The tx lock is protecting against two paths - the disable path, and (as Michael points out) the NETDEV_TX_BUSY case which may occur if NAPI completions race with start_xmit and both decide to re-enable the queue. For the disable/ifdown path use synchronize_net() to make sure closing the device does not race we restarting the queues. Annotate accesses to dev_state against data races. For the NAPI cleanup vs start_xmit path - appropriate barriers are already in place in the main spot where Tx queue is stopped but we need to do the same careful dance in the TX_BUSY case. Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.") Reviewed-by: Michael Chan Reviewed-by: Edwin Peer Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a89ba11b263b6567798f802bdf893fa6f5f0d7d1 Author: Ilya Leoshkevich Date: Thu Aug 12 17:18:10 2021 +0200 bpf: Clear zext_dst of dead insns [ Upstream commit 45c709f8c71b525b51988e782febe84ce933e7e0 ] "access skb fields ok" verifier test fails on s390 with the "verifier bug. zext_dst is set, but no reg is defined" message. The first insns of the test prog are ... 0: 61 01 00 00 00 00 00 00 ldxw %r0,[%r1+0] 8: 35 00 00 01 00 00 00 00 jge %r0,0,1 10: 61 01 00 08 00 00 00 00 ldxw %r0,[%r1+8] ... and the 3rd one is dead (this does not look intentional to me, but this is a separate topic). sanitize_dead_code() converts dead insns into "ja -1", but keeps zext_dst. When opt_subreg_zext_lo32_rnd_hi32() tries to parse such an insn, it sees this discrepancy and bails. This problem can be seen only with JITs whose bpf_jit_needs_zext() returns true. Fix by clearning dead insns' zext_dst. The commits that contributed to this problem are: 1. 5aa5bd14c5f8 ("bpf: add initial suite for selftests"), which introduced the test with the dead code. 2. 5327ed3d44b7 ("bpf: verifier: mark verified-insn with sub-register zext flag"), which introduced the zext_dst flag. 3. 83a2881903f3 ("bpf: Account for BPF_FETCH in insn_has_def32()"), which introduced the sanity check. 4. 9183671af6db ("bpf: Fix leakage under speculation on mispredicted branches"), which bisect points to. It's best to fix this on stable branches that contain the second one, since that's the point where the inconsistency was introduced. Fixes: 5327ed3d44b7 ("bpf: verifier: mark verified-insn with sub-register zext flag") Signed-off-by: Ilya Leoshkevich Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20210812151811.184086-2-iii@linux.ibm.com Signed-off-by: Sasha Levin commit 3d7f5031f870a5b0f86b080d72106944c92ab3b3 Author: jason-jh.lin Date: Tue Aug 10 12:01:48 2021 +0800 drm/mediatek: Add component_del in OVL and COLOR remove function [ Upstream commit da4d4517ba70216799e3eb3b9bd71aa9dca065da ] Add component_del in OVL and COLOR remove function. Fixes: ff1395609e20 ("drm/mediatek: Move mtk_ddp_comp_init() from sub driver to DRM driver") Signed-off-by: jason-jh.lin Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit e5f25a6ea31a6915c764858335798b94ce7eba98 Author: jason-jh.lin Date: Tue Aug 10 10:55:03 2021 +0800 drm/mediatek: Add AAL output size configuration [ Upstream commit 71ac6f390f6a3017f58d05d677b961bb1f851338 ] To avoid the output width and height is incorrect, AAL_OUTPUT_SIZE configuration should be set. Fixes: 0664d1392c26 ("drm/mediatek: Add AAL engine basic function") Signed-off-by: jason-jh.lin Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 88e35118e7c9661a84abab96373680c03f55feee Author: Eli Cohen Date: Wed Aug 11 08:37:59 2021 +0300 vdpa/mlx5: Fix queue type selection logic [ Upstream commit 879753c816dbbdb2a9a395aa4448d29feee92d1a ] get_queue_type() comments that splict virtqueue is preferred, however, the actual logic preferred packed virtqueues. Since firmware has not supported packed virtqueues we ended up using split virtqueues as was desired. Since we do not advertise support for packed virtqueues, we add a check to verify split virtqueues are indeed supported. Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices") Signed-off-by: Eli Cohen Link: https://lore.kernel.org/r/20210811053759.66752-1-elic@nvidia.com Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit c903a1fd0968a09b9a4df8e0bd24d6030ede6604 Author: Eli Cohen Date: Wed Aug 11 08:37:13 2021 +0300 vdpa/mlx5: Avoid destroying MR on empty iotlb [ Upstream commit 08dbd5660232bede7916d8568003012c1182cc9a ] The current code treats an empty iotlb provdied in set_map() as a special case and destroy the memory region object. This must not be done since the virtqueue objects reference this MR. Doing so will cause the driver unload to emit errors and log timeouts caused by the firmware complaining on busy resources. This patch treats an empty iotlb as any other change of mapping. In this case, mlx5_vdpa_create_mr() will fail and the entire set_map() call to fail. This issue has not been encountered before but was seen to occur in a non-official version of qemu. Since qemu is a userspace program, the driver must protect against such case. Fixes: 94abbccdf291 ("vdpa/mlx5: Add shared memory registration code") Signed-off-by: Eli Cohen Link: https://lore.kernel.org/r/20210811053713.66658-1-elic@nvidia.com Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 29236481a883fcc3435b4a49d763a7bd544cedc2 Author: Xie Yongji Date: Thu Jul 15 16:00:25 2021 +0800 vDPA/ifcvf: Fix return value check for vdpa_alloc_device() [ Upstream commit 1057afa0121db8bd3ca4718c8e0ca12388ab7759 ] The vdpa_alloc_device() returns an error pointer upon failure, not NULL. To handle the failure correctly, this replaces NULL check with IS_ERR() check and propagate the error upwards. Fixes: 5a2414bc454e ("virtio: Intel IFC VF driver for VDPA") Reported-by: Dan Carpenter Signed-off-by: Xie Yongji Link: https://lore.kernel.org/r/20210715080026.242-3-xieyongji@bytedance.com Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Reviewed-by: Stefano Garzarella Signed-off-by: Sasha Levin commit 080d65ba644faeaa672906c71fef783ce47ef044 Author: Xie Yongji Date: Thu Jul 15 16:00:24 2021 +0800 vp_vdpa: Fix return value check for vdpa_alloc_device() [ Upstream commit 9632e78e82648aa98340df78eab9106f63da151e ] The vdpa_alloc_device() returns an error pointer upon failure, not NULL. To handle the failure correctly, this replaces NULL check with IS_ERR() check and propagate the error upwards. Fixes: 64b9f64f80a6 ("vdpa: introduce virtio pci driver") Reported-by: Dan Carpenter Signed-off-by: Xie Yongji Link: https://lore.kernel.org/r/20210715080026.242-2-xieyongji@bytedance.com Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Reviewed-by: Stefano Garzarella Signed-off-by: Sasha Levin commit 434887c6ac4184a8b20e0ca46614e2985a9ae705 Author: Xie Yongji Date: Thu Jul 15 16:00:23 2021 +0800 vdpa_sim: Fix return value check for vdpa_alloc_device() [ Upstream commit 2b847f21145d84e2e1dde99d3e2c00a5468f02e4 ] The vdpa_alloc_device() returns an error pointer upon failure, not NULL. To handle the failure correctly, this replaces NULL check with IS_ERR() check and propagate the error upwards. Fixes: 2c53d0f64c06 ("vdpasim: vDPA device simulator") Reported-by: Dan Carpenter Signed-off-by: Xie Yongji Link: https://lore.kernel.org/r/20210715080026.242-1-xieyongji@bytedance.com Signed-off-by: Michael S. Tsirkin Reviewed-by: Stefano Garzarella Signed-off-by: Sasha Levin commit 83f6738578b3ceb5e08edab0c2baffb08d5187bd Author: Xie Yongji Date: Wed Jul 28 21:07:56 2021 +0800 vhost: Fix the calculation in vhost_overflow() [ Upstream commit f7ad318ea0ad58ebe0e595e59aed270bb643b29b ] This fixes the incorrect calculation for integer overflow when the last address of iova range is 0xffffffff. Fixes: ec33d031a14b ("vhost: detect 32 bit integer wrap around") Reported-by: Jason Wang Signed-off-by: Xie Yongji Acked-by: Jason Wang Link: https://lore.kernel.org/r/20210728130756.97-2-xieyongji@bytedance.com Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit dcd6c72344f3bb7584bdd31d5739e010c6c79b53 Author: Tony Lindgren Date: Wed Aug 11 08:34:46 2021 +0300 bus: ti-sysc: Fix error handling for sysc_check_active_timer() [ Upstream commit 06a089ef644934372a3062528244fca3417d3430 ] We have changed the return type for sysc_check_active_timer() from -EBUSY to -ENXIO, but the gpt12 system timer fix still checks for -EBUSY. We are also not returning on other errors like we did earlier as noted by Pavel Machek . Commit 3ff340e24c9d ("bus: ti-sysc: Fix gpt12 system timer issue with reserved status") should have been updated for commit 65fb73676112 ("bus: ti-sysc: suppress err msg for timers used as clockevent/source"). Let's fix the issue by checking for -ENXIO and returning on any other errors as suggested by Pavel Machek . Fixes: 3ff340e24c9d ("bus: ti-sysc: Fix gpt12 system timer issue with reserved status") Depends-on: 65fb73676112 ("bus: ti-sysc: suppress err msg for timers used as clockevent/source") Reported-by: Pavel Machek Reviewed-by: Pavel Machek (CIP) Cc: Grygorii Strashko Cc: Jarkko Nikula Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 8a821b88b1a66c48f5ee8be1b39b6b4ff0cad1c6 Author: Xie Yongji Date: Wed Jul 28 21:07:55 2021 +0800 vhost-vdpa: Fix integer overflow in vhost_vdpa_process_iotlb_update() [ Upstream commit 0e398290cff997610b66e73573faaee70c9a700e ] The "msg->iova + msg->size" addition can have an integer overflow if the iotlb message is from a malicious user space application. So let's fix it. Fixes: 1b48dc03e575 ("vhost: vdpa: report iova range") Reported-by: Dan Carpenter Signed-off-by: Xie Yongji Acked-by: Jason Wang Link: https://lore.kernel.org/r/20210728130756.97-1-xieyongji@bytedance.com Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 6caaf9fcb7b4f808d73ca5aeb391bdf766a4dd04 Author: Parav Pandit Date: Wed Jul 21 17:26:47 2021 +0300 virtio: Protect vqs list access [ Upstream commit 0e566c8f0f2e8325e35f6f97e13cde5356b41814 ] VQs may be accessed to mark the device broken while they are created/destroyed. Hence protect the access to the vqs list. Fixes: e2dcdfe95c0b ("virtio: virtio_break_device() to mark all virtqueues broken.") Signed-off-by: Parav Pandit Link: https://lore.kernel.org/r/20210721142648.1525924-4-parav@nvidia.com Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit b380dfb298daad55d41a9abc70d793abcb3ebb2e Author: Randy Dunlap Date: Sun Aug 8 16:04:40 2021 -0700 dccp: add do-while-0 stubs for dccp_pr_debug macros [ Upstream commit 86aab09a4870bb8346c9579864588c3d7f555299 ] GCC complains about empty macros in an 'if' statement, so convert them to 'do {} while (0)' macros. Fixes these build warnings: net/dccp/output.c: In function 'dccp_xmit_packet': ../net/dccp/output.c:283:71: warning: suggest braces around empty body in an 'if' statement [-Wempty-body] 283 | dccp_pr_debug("transmit_skb() returned err=%d\n", err); net/dccp/ackvec.c: In function 'dccp_ackvec_update_old': ../net/dccp/ackvec.c:163:80: warning: suggest braces around empty body in an 'else' statement [-Wempty-body] 163 | (unsigned long long)seqno, state); Fixes: dc841e30eaea ("dccp: Extend CCID packet dequeueing interface") Fixes: 380240864451 ("dccp ccid-2: Update code for the Ack Vector input/registration routine") Signed-off-by: Randy Dunlap Cc: dccp@vger.kernel.org Cc: "David S. Miller" Cc: Jakub Kicinski Cc: Gerrit Renker Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5238de0459c0ff9c963ec6f09241b3e313aa6977 Author: Marek Behún Date: Thu Jul 1 00:56:01 2021 +0200 cpufreq: armada-37xx: forbid cpufreq for 1.2 GHz variant [ Upstream commit 484f2b7c61b9ae58cc00c5127bcbcd9177af8dfe ] The 1.2 GHz variant of the Armada 3720 SOC is unstable with DVFS: when the SOC boots, the WTMI firmware sets clocks and AVS values that work correctly with 1.2 GHz CPU frequency, but random crashes occur once cpufreq driver starts scaling. We do not know currently what is the reason: - it may be that the voltage value for L0 for 1.2 GHz variant provided by the vendor in the OTP is simply incorrect when scaling is used, - it may be that some delay is needed somewhere, - it may be something else. The most sane solution now seems to be to simply forbid the cpufreq driver on 1.2 GHz variant. Signed-off-by: Marek Behún Fixes: 92ce45fb875d ("cpufreq: Add DVFS support for Armada 37xx") Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit ed6b6c758b67d6af650679d45d30c240cf1c0b0f Author: Maxim Kochetkov Date: Tue Aug 3 14:35:38 2021 +0300 soc: fsl: qe: convert QE interrupt controller to platform_device [ Upstream commit be7ecbd240b2f9ec544d3ce6fccf4cec3cd15dca ] Since 5.13 QE's ucc nodes can't get interrupts from devicetree: ucc@2000 { cell-index = <1>; reg = <0x2000 0x200>; interrupts = <32>; interrupt-parent = <&qeic>; }; Now fw_devlink expects driver to create and probe a struct device for interrupt controller. So lets convert this driver to simple platform_device with probe(). Also use platform_get_ and devm_ family function to get/allocate resources and drop unused .compatible = "qeic". [1] - https://lore.kernel.org/lkml/CAGETcx9PiX==mLxB9PO8Myyk6u2vhPVwTMsA5NkD-ywH5xhusw@mail.gmail.com Fixes: e590474768f1 ("driver core: Set fw_devlink=on by default") Fixes: ea718c699055 ("Revert "Revert "driver core: Set fw_devlink=on by default""") Signed-off-by: Maxim Kochetkov Reported-by: kernel test robot Reported-by: Dan Carpenter Acked-by: Saravana Kannan Signed-off-by: Li Yang Signed-off-by: Sasha Levin commit b39db8c4397d394f91f8714aac952cacf9a148ca Author: Manivannan Sadhasivam Date: Tue Jul 27 11:58:13 2021 +0530 mtd: rawnand: Fix probe failure due to of_get_nand_secure_regions() [ Upstream commit b48027083a78b13356695555a05b0e085e378687 ] Due to 14f97f0b8e2b, the rawnand platforms without "secure-regions" property defined in DT fails to probe. The issue is, of_get_nand_secure_regions() errors out if of_property_count_elems_of_size() returns a negative error code. If the "secure-regions" property is not present in DT, then also we'll get -EINVAL from of_property_count_elems_of_size() but it should not be treated as an error for platforms not declaring "secure-regions" in DT. So fix this behaviour by checking for the existence of that property in DT and return 0 if it is not present. Fixes: 14f97f0b8e2b ("mtd: rawnand: Add a check in of_get_nand_secure_regions()") Reported-by: Martin Kaiser Signed-off-by: Manivannan Sadhasivam Reviewed-by: Martin Kaiser Tested-by: Martin Kaiser Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210727062813.32619-1-manivannan.sadhasivam@linaro.org Signed-off-by: Sasha Levin commit dd53a5f93b2edda3ee0fb54f453566b88510219d Author: Arnd Bergmann Date: Wed Jul 21 17:06:56 2021 +0200 mt76: fix enum type mismatch [ Upstream commit abf3d98dee7c4038152ce88833ddc2189f68cbd4 ] There is no 'NONE' version of 'enum mcu_cipher_type', and returning 'MT_CIPHER_NONE' causes a warning: drivers/net/wireless/mediatek/mt76/mt7921/mcu.c: In function 'mt7921_mcu_get_cipher': drivers/net/wireless/mediatek/mt76/mt7921/mcu.c:114:24: error: implicit conversion from 'enum mt76_cipher_type' to 'enum mcu_cipher_type' [-Werror=enum-conversion] 114 | return MT_CIPHER_NONE; | ^~~~~~~~~~~~~~ Add the missing MCU_CIPHER_NONE defintion that fits in here with the same value. Fixes: c368362c36d3 ("mt76: fix iv and CCMP header insertion") Signed-off-by: Arnd Bergmann Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210721150745.1914829-1-arnd@kernel.org Signed-off-by: Sasha Levin commit c442bd5a0e20716309fc4431932e2618b56bcae4 Author: Caleb Connolly Date: Tue Jul 20 15:33:38 2021 +0000 arm64: dts: qcom: sdm845-oneplus: fix reserved-mem [ Upstream commit d77c95bf9a64d8620662151b2b10efd8221f4bcc ] Fix the upper guard and the "removed_region", this fixes the random crashes which used to occur in memory intensive loads. I'm not sure WHY the upper guard being 0x2000 instead of 0x1000 doesn't fix this, but it HAS to be 0x1000. Fixes: e60fd5ac1f68 ("arm64: dts: qcom: sdm845-oneplus-common: guard rmtfs-mem") Signed-off-by: Caleb Connolly Link: https://lore.kernel.org/r/20210720153125.43389-2-caleb@connolly.tech Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit ae19ca1cb3f0ca88d87c3765b94535de35ad0370 Author: Petr Vorel Date: Tue Jun 22 21:10:19 2021 +0200 arm64: dts: qcom: msm8994-angler: Disable cont_splash_mem [ Upstream commit 0e5ded926f2a0f8b57dfa7f0d69a30767e1ea2ce ] As the default definition breaks booting angler: [ 1.862561] printk: console [ttyMSM0] enabled [ 1.872260] msm_serial: driver initialized D - 15524 - pm_driver_init, Delta cont_splash_mem was introduced in 74d6d0a145835, but the problem manifested after commit '86588296acbf ("fdt: Properly handle "no-map" field in the memory region")'. Disabling it because Angler's firmware does not report where the memory is allocated (dmesg from downstream kernel): [ 0.000000] cma: Found cont_splash_mem@0, memory base 0x0000000000000000, size 16 MiB, limit 0x0000000000000000 [ 0.000000] cma: CMA: reserved 16 MiB at 0x0000000000000000 for cont_splash_mem Similar issue might be on Google Nexus 5X (lg-bullhead). Other MSM8992/4 are known to report correct address. Fixes: 74d6d0a145835 ("arm64: dts: qcom: msm8994/8994-kitakami: Fix up the memory map") Suggested-by: Konrad Dybcio Signed-off-by: Petr Vorel Link: https://lore.kernel.org/r/20210622191019.23771-1-petr.vorel@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 1c4678cb01eec8cfe9adb54be4971779821f23b1 Author: Lukasz Luba Date: Tue Aug 3 10:07:44 2021 +0100 cpufreq: arm_scmi: Fix error path when allocation failed [ Upstream commit f7d635883fb73414c7c4e2648b42adc296c5d40d ] Stop the initialization when cpumask allocation failed and return an error. Fixes: 80a064dbd556 ("scmi-cpufreq: Get opp_shared_cpus from opp-v2 for EM") Signed-off-by: Lukasz Luba Reviewed-by: Sudeep Holla Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 731825e59e1de9597268091c850ae482d4733a17 Author: Frank Wunderlich Date: Sat Jul 31 09:47:37 2021 +0200 iommu: Check if group is NULL before remove device [ Upstream commit 5aa95d8834e07907e64937d792c12ffef7fb271f ] If probe_device is failing, iommu_group is not initialized because iommu_group_add_device is not reached, so freeing it will result in NULL pointer access. iommu_bus_init ->bus_iommu_probe ->probe_iommu_group in for each:/* return -22 in fail case */ ->iommu_probe_device ->__iommu_probe_device /* return -22 here.*/ -> ops->probe_device /* return -22 here.*/ -> iommu_group_get_for_dev -> ops->device_group -> iommu_group_add_device //good case ->remove_iommu_group //in fail case, it will remove group ->iommu_release_device ->iommu_group_remove_device // here we don't have group In my case ops->probe_device (mtk_iommu_probe_device from mtk_iommu_v1.c) is due to failing fwspec->ops mismatch. Fixes: d72e31c93746 ("iommu: IOMMU Groups") Signed-off-by: Frank Wunderlich Link: https://lore.kernel.org/r/20210731074737.4573-1-linux@fw-web.de Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 02491c3d81ef0f3608ab556c2a35514c61c6caf2 Author: Petr Vorel Date: Tue Jul 13 20:57:34 2021 +0200 arm64: dts: qcom: msm8992-bullhead: Fix cont_splash_mem mapping [ Upstream commit 3cb6a271f4b04f11270111638c24fa5c0b846dec ] cont_splash_mem has different memory mapping than generic from msm8994.dtsi: [ 0.000000] cma: Found cont_splash_mem@0, memory base 0x0000000003400000, size 12 MiB, limit 0xffffffffffffffff [ 0.000000] cma: CMA: reserved 12 MiB at 0x0000000003400000 for cont_splash_mem This fixes boot. Fixes: 976d321f32dc ("arm64: dts: qcom: msm8992: Make the DT an overlay on top of 8994") Signed-off-by: Petr Vorel Link: https://lore.kernel.org/r/20210713185734.380-3-petr.vorel@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit aa9cac63e49c09b429d48d9dc6aa80d51aa31ffd Author: Petr Vorel Date: Tue Jul 13 20:57:33 2021 +0200 arm64: dts: qcom: msm8992-bullhead: Remove PSCI [ Upstream commit 9d1fc2e4f5a94a492c7dd1ca577c66fdb7571c84 ] Bullhead firmware obviously doesn't support PSCI as it fails to boot with this definition. Fixes: 329e16d5f8fc ("arm64: dts: qcom: msm8992: Add PSCI support.") Signed-off-by: Petr Vorel Link: https://lore.kernel.org/r/20210713185734.380-2-petr.vorel@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 6fed550393b8b5912130980dd7a4658a8aeced8e Author: Srinivas Kandagatla Date: Tue Jul 6 09:35:23 2021 +0100 arm64: dts: qcom: c630: fix correct powerdown pin for WSA881x [ Upstream commit 9a253bb42f190efd1a1c156939ad7298b3529dca ] WSA881x powerdown pin is connected to GPIO1, GPIO2 not GPIO2 and GPIO3, so correct this. This was working so far due to a shift bug in gpio driver, however once that is fixed this will stop working, so fix this! For some reason we forgot to add this dts change in last merge cycle so currently audio is broken in 5.13 as the gpio driver fix already landed in 5.13. Reported-by: Shawn Guo Fixes: 45021d35fcb2 ("arm64: dts: qcom: c630: Enable audio support") Signed-off-by: Srinivas Kandagatla Tested-by: Shawn Guo Link: https://lore.kernel.org/r/20210706083523.10601-1-srinivas.kandagatla@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 73bb2572339d5da659c1be0172dfeaea2473c8ee Author: Dan Carpenter Date: Thu Jun 17 16:37:25 2021 +0300 mtd: rawnand: Add a check in of_get_nand_secure_regions() [ Upstream commit 14f97f0b8e2b9950c028d0cb7311ffe26a3cc1c0 ] Check for whether of_property_count_elems_of_size() returns a negative error code. Fixes: 13b89768275d ("mtd: rawnand: Add support for secure regions in NAND memory") Signed-off-by: Dan Carpenter Reviewed-by: Manivannan Sadhasivam Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/YMtQFXE0F1w7mUh+@mwanda Signed-off-by: Sasha Levin commit 85f5d3d0bc2e92cf36e7127282392525f82eff81 Author: Vincent Fu Date: Wed Aug 4 19:49:23 2021 +0000 kyber: make trace_block_rq call consistent with documentation [ Upstream commit fb7b9b0231ba8f77587c23f5257a4fdb6df1219e ] The kyber ioscheduler calls trace_block_rq_insert() *after* the request is added to the queue but the documentation for trace_block_rq_insert() says that the call should be made *before* the request is added to the queue. Move the tracepoint for the kyber ioscheduler so that it is consistent with the documentation. Signed-off-by: Vincent Fu Link: https://lore.kernel.org/r/20210804194913.10497-1-vincent.fu@samsung.com Reviewed by: Adam Manzanares Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit a6488cc30f01e4b741be3ba01c5b8f4409062db3 Author: Qingqing Zhuo Date: Thu Jul 22 14:48:54 2021 -0400 drm/amd/display: workaround for hard hang on HPD on native DP [ Upstream commit c4152b297d56d3696ad0a9003169bc5b98ad7b72 ] [Why] HPD disable and enable sequences are not mutually exclusive on Linux. For HPDs that spans over 1s (i.e. HPD low = 1s), part of the disable sequence (specifically, a request to SMU to lower refclk) could come right before the call to PHY enable, causing DMUB to access an unresponsive PHY and thus a hard hang on the system. [How] Disable 48mhz refclk off on native DP. Reviewed-by: Hersen Wu Acked-by: Aurabindo Pillai Signed-off-by: Qingqing Zhuo Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a4ebe05cd99e741a2ec7d166f64dcd54a611531f Author: Bing Guo Date: Mon Jul 19 18:24:06 2021 -0400 drm/amd/display: Fix Dynamic bpp issue with 8K30 with Navi 1X [ Upstream commit 06050a0f01dbac2ca33145ef19a72041206ea983 ] Why: In DCN2x, HW doesn't automatically divide MASTER_UPDATE_LOCK_DB_X by the number of pipes ODM Combined. How: Set MASTER_UPDATE_LOCK_DB_X to the value that is adjusted by the number of pipes ODM Combined. Reviewed-by: Martin Leung Acked-by: Aurabindo Pillai Signed-off-by: Bing Guo Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 5fd92907a473d528e32330ed5f1b1063701660a3 Author: Apurva Nandan Date: Fri Jul 16 23:25:03 2021 +0000 spi: cadence-quadspi: Fix check condition for DTR ops [ Upstream commit 0395be967b067d99494113d78470574e86a02ed4 ] buswidth and dtr fields in spi_mem_op are only valid when the corresponding spi_mem_op phase has a non-zero length. For example, SPI NAND core doesn't set buswidth when using SPI_MEM_OP_NO_ADDR phase. Fix the dtr checks in set_protocol() and suppports_mem_op() to ignore empty spi_mem_op phases, as checking for dtr field in empty phase will result in false negatives. Signed-off-by: Apurva Nandan Link: https://lore.kernel.org/r/20210716232504.182-3-a-nandan@ti.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d6080ac32e3e9760aa5c6635f158886db8fc30cb Author: Peter Zijlstra Date: Thu Jul 29 11:14:57 2021 +0200 perf/x86: Fix out of bound MSR access [ Upstream commit f4b4b45652578357031fbbef7f7a1b04f6fa2dc3 ] On Wed, Jul 28, 2021 at 12:49:43PM -0400, Vince Weaver wrote: > [32694.087403] unchecked MSR access error: WRMSR to 0x318 (tried to write 0x0000000000000000) at rIP: 0xffffffff8106f854 (native_write_msr+0x4/0x20) > [32694.101374] Call Trace: > [32694.103974] perf_clear_dirty_counters+0x86/0x100 The problem being that it doesn't filter out all fake counters, in specific the above (erroneously) tries to use FIXED_BTS. Limit the fixed counters indexes to the hardware supplied number. Reported-by: Vince Weaver Signed-off-by: Peter Zijlstra (Intel) Tested-by: Vince Weaver Tested-by: Like Xu Link: https://lkml.kernel.org/r/YQJxka3dxgdIdebG@hirez.programming.kicks-ass.net Signed-off-by: Sasha Levin commit cae49c93c71ce1c55e99e00ff6ae258e80fcb3ce Author: Ivan T. Ivanov Date: Wed Aug 4 11:13:39 2021 +0300 net: usb: lan78xx: don't modify phy_device state concurrently [ Upstream commit 6b67d4d63edece1033972214704c04f36c5be89a ] Currently phy_device state could be left in inconsistent state shown by following alert message[1]. This is because phy_read_status could be called concurrently from lan78xx_delayedwork, phy_state_machine and __ethtool_get_link. Fix this by making sure that phy_device state is updated atomically. [1] lan78xx 1-1.1.1:1.0 eth0: No phy led trigger registered for speed(-1) Signed-off-by: Ivan T. Ivanov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d45f37c6120ea435d77717ba6be2de2d271b4f0e Author: Petko Manolov Date: Tue Aug 3 20:25:23 2021 +0300 net: usb: pegasus: Check the return value of get_geristers() and friends; [ Upstream commit 8a160e2e9aeb8318159b48701ad8a6e22274372d ] Certain call sites of get_geristers() did not do proper error handling. This could be a problem as get_geristers() typically return the data via pointer to a buffer. If an error occurred the code is carelessly manipulating the wrong data. Signed-off-by: Petko Manolov Reviewed-by: Pavel Skripkin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e5f45fdefd8d3648e56e7bf98a02d4ebe3b8e829 Author: Sudeep Holla Date: Sat Jun 26 02:01:03 2021 +0200 ARM: dts: nomadik: Fix up interrupt controller node names [ Upstream commit 47091f473b364c98207c4def197a0ae386fc9af1 ] Once the new schema interrupt-controller/arm,vic.yaml is added, we get the below warnings: arch/arm/boot/dts/ste-nomadik-nhk15.dt.yaml: intc@10140000: $nodename:0: 'intc@10140000' does not match '^interrupt-controller(@[0-9a-f,]+)*$' Fix the node names for the interrupt controller to conform to the standard node name interrupt-controller@.. Signed-off-by: Sudeep Holla Signed-off-by: Linus Walleij Cc: Linus Walleij Link: https://lore.kernel.org/r/20210617210825.3064367-2-sudeep.holla@arm.com Link: https://lore.kernel.org/r/20210626000103.830184-1-linus.walleij@linaro.org' Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 56dcfd2e01452efdf2e22e7e7ce60cda046380fc Author: Prabhakar Kushwaha Date: Thu Jul 29 14:43:06 2021 +0300 qede: fix crash in rmmod qede while automatic debug collection [ Upstream commit 1159e25c137422bdc48ee96e3fb014bd942092c6 ] A crash has been observed if rmmod is done while automatic debug collection in progress. It is due to a race condition between both of them. To fix stop the sp_task during unload to avoid running qede_sp_task even if they are schedule during removal process. Signed-off-by: Alok Prasad Signed-off-by: Shai Malin Signed-off-by: Ariel Elior Signed-off-by: Prabhakar Kushwaha Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0620a81e8040052e59efcf9dfa5420781beed06a Author: Yifan Zhang Date: Thu Jun 10 09:55:01 2021 +0800 drm/amdgpu: fix the doorbell missing when in CGPG issue for renoir. [ Upstream commit 1c0539a6fc8a4a4b77278e35d763073890de96b9 ] If GC has entered CGPG, ringing doorbell > first page doesn't wakeup GC. Enlarge CP_MEC_DOORBELL_RANGE_UPPER to workaround this issue. Signed-off-by: Yifan Zhang Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c6751ce1a2a415a78e4f5b621628da03196b804c Author: lijinlin Date: Tue Jul 27 11:44:55 2021 +0800 scsi: core: Fix capacity set to zero after offlinining device [ Upstream commit f0f82e2476f6adb9c7a0135cfab8091456990c99 ] After adding physical volumes to a volume group through vgextend, the kernel will rescan the partitions. This in turn will cause the device capacity to be queried. If the device status is set to offline through sysfs at this time, READ CAPACITY command will return a result which the host byte is DID_NO_CONNECT, and the capacity of the device will be set to zero in read_capacity_error(). After setting device status back to running, the capacity of the device will remain stuck at zero. Fix this issue by rescanning device when the device state changes to SDEV_RUNNING. Link: https://lore.kernel.org/r/20210727034455.1494960-1-lijinlin3@huawei.com Reviewed-by: Bart Van Assche Signed-off-by: lijinlin Signed-off-by: Wu Bo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 87820c748fda2716c5d8e9490dba202f40c26347 Author: Sreekanth Reddy Date: Mon Jul 26 17:24:02 2021 +0530 scsi: core: Avoid printing an error if target_alloc() returns -ENXIO [ Upstream commit 70edd2e6f652f67d854981fd67f9ad0f1deaea92 ] Avoid printing a 'target allocation failed' error if the driver target_alloc() callback function returns -ENXIO. This return value indicates that the corresponding H:C:T:L entry is empty. Removing this error reduces the scan time if the user issues SCAN_WILD_CARD scan operation through sysfs parameter on a host with a lot of empty H:C:T:L entries. Avoiding the printk on -ENXIO matches the behavior of the other callback functions during scanning. Link: https://lore.kernel.org/r/20210726115402.1936-1-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 7bbfccc78e0ebe609e37e8b95e525568fc3fd7b6 Author: Ye Bin Date: Wed Jan 13 14:31:03 2021 +0800 scsi: scsi_dh_rdac: Avoid crash during rdac_bus_attach() [ Upstream commit bc546c0c9abb3bb2fb46866b3d1e6ade9695a5f6 ] The following BUG_ON() was observed during RDAC scan: [595952.944297] kernel BUG at drivers/scsi/device_handler/scsi_dh_rdac.c:427! [595952.951143] Internal error: Oops - BUG: 0 [#1] SMP ...... [595953.251065] Call trace: [595953.259054] check_ownership+0xb0/0x118 [595953.269794] rdac_bus_attach+0x1f0/0x4b0 [595953.273787] scsi_dh_handler_attach+0x3c/0xe8 [595953.278211] scsi_dh_add_device+0xc4/0xe8 [595953.282291] scsi_sysfs_add_sdev+0x8c/0x2a8 [595953.286544] scsi_probe_and_add_lun+0x9fc/0xd00 [595953.291142] __scsi_scan_target+0x598/0x630 [595953.295395] scsi_scan_target+0x120/0x130 [595953.299481] fc_user_scan+0x1a0/0x1c0 [scsi_transport_fc] [595953.304944] store_scan+0xb0/0x108 [595953.308420] dev_attr_store+0x44/0x60 [595953.312160] sysfs_kf_write+0x58/0x80 [595953.315893] kernfs_fop_write+0xe8/0x1f0 [595953.319888] __vfs_write+0x60/0x190 [595953.323448] vfs_write+0xac/0x1c0 [595953.326836] ksys_write+0x74/0xf0 [595953.330221] __arm64_sys_write+0x24/0x30 Code is in check_ownership: list_for_each_entry_rcu(tmp, &h->ctlr->dh_list, node) { /* h->sdev should always be valid */ BUG_ON(!tmp->sdev); tmp->sdev->access_state = access_state; } rdac_bus_attach initialize_controller list_add_rcu(&h->node, &h->ctlr->dh_list); h->sdev = sdev; rdac_bus_detach list_del_rcu(&h->node); h->sdev = NULL; Fix the race between rdac_bus_attach() and rdac_bus_detach() where h->sdev is NULL when processing the RDAC attach. Link: https://lore.kernel.org/r/20210113063103.2698953-1-yebin10@huawei.com Reviewed-by: Bart Van Assche Signed-off-by: Ye Bin Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f57f3722788ee9f284ae764d91d422677b146486 Author: Harshvardhan Jha Date: Thu Jul 8 13:16:42 2021 +0530 scsi: megaraid_mm: Fix end of loop tests for list_for_each_entry() [ Upstream commit 77541f78eadfe9fdb018a7b8b69f0f2af2cf4b82 ] The list_for_each_entry() iterator, "adapter" in this code, can never be NULL. If we exit the loop without finding the correct adapter then "adapter" points invalid memory that is an offset from the list head. This will eventually lead to memory corruption and presumably a kernel crash. Link: https://lore.kernel.org/r/20210708074642.23599-1-harshvardhan.jha@oracle.com Acked-by: Sumit Saxena Signed-off-by: Harshvardhan Jha Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit fa3c19ceaa8b4b7c29d710c2c407df57d256a6c5 Author: Igor Pylypiv Date: Wed Jul 7 11:59:45 2021 -0700 scsi: pm80xx: Fix TMF task completion race condition [ Upstream commit d712d3fb484b7fa8d1d57e9ca6f134bb9d8c18b1 ] The TMF timeout timer may trigger at the same time when the response from a controller is being handled. When this happens the SAS task may get freed before the response processing is finished. Fix this by calling complete() only when SAS_TASK_STATE_DONE is not set. A similar race condition was fixed in commit b90cd6f2b905 ("scsi: libsas: fix a race condition when smp task timeout") Link: https://lore.kernel.org/r/20210707185945.35559-1-ipylypiv@google.com Reviewed-by: Vishakha Channapattan Acked-by: Jack Wang Signed-off-by: Igor Pylypiv Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit c589360bd3a901399535e539cea0d1ce910fb167 Author: Peter Ujfalusi Date: Sat Jul 17 22:00:21 2021 +0300 dmaengine: of-dma: router_xlate to return -EPROBE_DEFER if controller is not yet available [ Upstream commit eda97cb095f2958bbad55684a6ca3e7d7af0176a ] If the router_xlate can not find the controller in the available DMA devices then it should return with -EPORBE_DEFER in a same way as the of_dma_request_slave_channel() does. The issue can be reproduced if the event router is registered before the DMA controller itself and a driver would request for a channel before the controller is registered. In of_dma_request_slave_channel(): 1. of_dma_find_controller() would find the dma_router 2. ofdma->of_dma_xlate() would fail and returned NULL 3. -ENODEV is returned as error code with this patch we would return in this case the correct -EPROBE_DEFER and the client can try to request the channel later. Signed-off-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20210717190021.21897-1-peter.ujfalusi@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit d09867c795c3f77dc32f7d3e9a1766482e22193d Author: Dave Gerlach Date: Fri Jul 16 09:07:30 2021 -0700 ARM: dts: am43x-epos-evm: Reduce i2c0 bus speed for tps65218 [ Upstream commit 20a6b3fd8e2e2c063b25fbf2ee74d86b898e5087 ] Based on the latest timing specifications for the TPS65218 from the data sheet, http://www.ti.com/lit/ds/symlink/tps65218.pdf, document SLDS206 from November 2014, we must change the i2c bus speed to better fit within the minimum high SCL time required for proper i2c transfer. When running at 400khz, measurements show that SCL spends 0.8125 uS/1.666 uS high/low which violates the requirement for minimum high period of SCL provided in datasheet Table 7.6 which is 1 uS. Switching to 100khz gives us 5 uS/5 uS high/low which both fall above the minimum given values for 100 khz, 4.0 uS/4.7 uS high/low. Without this patch occasionally a voltage set operation from the kernel will appear to have worked but the actual voltage reflected on the PMIC will not have updated, causing problems especially with cpufreq that may update to a higher OPP without actually raising the voltage on DCDC2, leading to a hang. Signed-off-by: Dave Gerlach Signed-off-by: Kevin Hilman Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 38df50afe852bc50425c8fa5960b6ad42cf4da96 Author: Harshvardhan Jha Date: Sun Jul 25 23:23:55 2021 +0530 net: xfrm: Fix end of loop tests for list_for_each_entry [ Upstream commit 480e93e12aa04d857f7cc2e6fcec181c0d690404 ] The list_for_each_entry() iterator, "pos" in this code, can never be NULL so the warning will never be printed. Signed-off-by: Harshvardhan Jha Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 1718285e14194bcbda55fb4c7cbaca8f8f2a1bbc Author: Uwe Kleine-König Date: Wed Jul 21 11:53:21 2021 +0200 spi: spi-mux: Add module info needed for autoloading [ Upstream commit 1d5ccab95f06675a269f4cb223a1e3f6d1ebef42 ] With the spi device table udev can autoload the spi-mux module in the presence of an spi-mux device. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20210721095321.2165453-1-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7c6e26d59bfbcbd1f52b3fc976d197f60e951a2e Author: Yu Kuai Date: Tue Jul 6 20:45:21 2021 +0800 dmaengine: usb-dmac: Fix PM reference leak in usb_dmac_probe() [ Upstream commit 1da569fa7ec8cb0591c74aa3050d4ea1397778b4 ] pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by moving the error_pm label above the pm_runtime_put() in the error path. Reported-by: Hulk Robot Signed-off-by: Yu Kuai Link: https://lore.kernel.org/r/20210706124521.1371901-1-yukuai3@huawei.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit fcd998a0536e7767e1fa42856f61829dfef7c112 Author: Adrian Larumbe Date: Wed Jul 7 00:43:38 2021 +0100 dmaengine: xilinx_dma: Fix read-after-free bug when terminating transfers [ Upstream commit 7dd2dd4ff9f3abda601f22b9d01441a0869d20d7 ] When user calls dmaengine_terminate_sync, the driver will clean up any remaining descriptors for all the pending or active transfers that had previously been submitted. However, this might happen whilst the tasklet is invoking the DMA callback for the last finished transfer, so by the time it returns and takes over the channel's spinlock, the list of completed descriptors it was traversing is no longer valid. This leads to a read-after-free situation. Fix it by signalling whether a user-triggered termination has happened by means of a boolean variable. Signed-off-by: Adrian Larumbe Link: https://lore.kernel.org/r/20210706234338.7696-3-adrian.martinezlarumbe@imgtec.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit d9aee1535e7bc20da35ab1743e122f4b80f9fbf4 Author: Alan Stern Date: Mon Jul 12 14:54:36 2021 -0400 USB: core: Fix incorrect pipe calculation in do_proc_control() [ Upstream commit b0863f1927323110e3d0d69f6adb6a91018a9a3c ] When the user submits a control URB via usbfs, the user supplies the bRequestType value and the kernel uses it to compute the pipe value. However, do_proc_control() performs this computation incorrectly in the case where the bRequestType direction bit is set to USB_DIR_IN and the URB's transfer length is 0: The pipe's direction is also set to IN but it should be OUT, which is the direction the actual transfer will use regardless of bRequestType. Commit 5cc59c418fde ("USB: core: WARN if pipe direction != setup packet direction") added a check to compare the direction bit in the pipe value to a control URB's actual direction and to WARN if they are different. This can be triggered by the incorrect computation mentioned above, as found by syzbot. This patch fixes the computation, thus avoiding the WARNing. Reported-and-tested-by: syzbot+72af3105289dcb4c055b@syzkaller.appspotmail.com Signed-off-by: Alan Stern Link: https://lore.kernel.org/r/20210712185436.GB326369@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 08fb58a2c3dce16065f5aa38b2c9d338ca18b20c Author: Alan Stern Date: Mon Jun 7 11:23:07 2021 -0400 USB: core: Avoid WARNings for 0-length descriptor requests [ Upstream commit 60dfe484cef45293e631b3a6e8995f1689818172 ] The USB core has utility routines to retrieve various types of descriptors. These routines will now provoke a WARN if they are asked to retrieve 0 bytes (USB "receive" requests must not have zero length), so avert this by checking the size argument at the start. CC: Johan Hovold Reported-and-tested-by: syzbot+7dbcd9ff34dc4ed45240@syzkaller.appspotmail.com Reviewed-by: Johan Hovold Signed-off-by: Alan Stern Link: https://lore.kernel.org/r/20210607152307.GD1768031@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 261d195d5fe6caf4e40a2dfaa6eb61c814f1c146 Author: Nadav Amit Date: Sat Aug 7 17:13:42 2021 -0700 io_uring: Use WRITE_ONCE() when writing to sq_flags [ Upstream commit 20c0b380f971e7d48f5d978bc27d827f7eabb21a ] The compiler should be forbidden from any strange optimization for async writes to user visible data-structures. Without proper protection, the compiler can cause write-tearing or invent writes that would confuse the userspace. However, there are writes to sq_flags which are not protected by WRITE_ONCE(). Use WRITE_ONCE() for these writes. This is purely a theoretical issue. Presumably, any compiler is very unlikely to do such optimizations. Fixes: 75b28affdd6a ("io_uring: allocate the two rings together") Cc: Jens Axboe Cc: Pavel Begunkov Signed-off-by: Nadav Amit Link: https://lore.kernel.org/r/20210808001342.964634-3-namit@vmware.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit e8daa0dd99c90d3ee4e27c4f053c5f6e70c6e767 Author: Andreas Persson Date: Mon Jul 12 09:54:52 2021 +0200 mtd: cfi_cmdset_0002: fix crash when erasing/writing AMD cards commit 2394e628738933aa014093d93093030f6232946d upstream. Erasing an AMD linear flash card (AM29F016D) crashes after the first sector has been erased. Likewise, writing to it crashes after two bytes have been written. The reason is a missing check for a null pointer - the cmdset_priv field is not set for this type of card. Fixes: 4844ef80305d ("mtd: cfi_cmdset_0002: Add support for polling status register") Signed-off-by: Andreas Persson Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/DB6P189MB05830B3530B8087476C5CFE4C1159@DB6P189MB0583.EURP189.PROD.OUTLOOK.COM Signed-off-by: Greg Kroah-Hartman commit bc18751f31c6c99ce3ff13be72a86d77f56540d0 Author: hamadmarri Date: Thu Aug 19 20:24:26 2021 +0300 Disable RDB by default