commit 129c15b606278f9254a16013f7e5a94a128d9bcd Author: Greg Kroah-Hartman Date: Tue Feb 14 19:11:56 2023 +0100 Linux 6.1.12 Link: https://lore.kernel.org/r/20230213144742.219399167@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Florian Fainelli Tested-by: Conor Dooley Tested-by: Allen Pais Tested-by: Justin M. Forbes Tested-by: Shuah Khan Tested-by: Bagas Sanjaya Tested-by: Ron Economos Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee Tested-by: Salvatore Bonaccorso Tested-by: Jon Hunter Signed-off-by: Greg Kroah-Hartman commit da1ae884562cc22e2705113cc39712477e37ab4e Author: Tom Lendacky Date: Thu Feb 9 09:22:26 2023 -0600 Documentation/hw-vuln: Add documentation for Cross-Thread Return Predictions commit 493a2c2d23ca91afba96ac32b6cbafb54382c2a3 upstream. Add the admin guide for the Cross-Thread Return Predictions vulnerability. Signed-off-by: Tom Lendacky Message-Id: <60f9c0b4396956ce70499ae180cb548720b25c7e.1675956146.git.thomas.lendacky@amd.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 40c4fdfc942e0c93054884546bf785fe24c6831e Author: Tom Lendacky Date: Thu Feb 9 09:22:25 2023 -0600 KVM: x86: Mitigate the cross-thread return address predictions bug commit 6f0f2d5ef895d66a3f2b32dd05189ec34afa5a55 upstream. By default, KVM/SVM will intercept attempts by the guest to transition out of C0. However, the KVM_CAP_X86_DISABLE_EXITS capability can be used by a VMM to change this behavior. To mitigate the cross-thread return address predictions bug (X86_BUG_SMT_RSB), a VMM must not be allowed to override the default behavior to intercept C0 transitions. Use a module parameter to control the mitigation on processors that are vulnerable to X86_BUG_SMT_RSB. If the processor is vulnerable to the X86_BUG_SMT_RSB bug and the module parameter is set to mitigate the bug, KVM will not allow the disabling of the HLT, MWAIT and CSTATE exits. Signed-off-by: Tom Lendacky Message-Id: <4019348b5e07148eb4d593380a5f6713b93c9a16.1675956146.git.thomas.lendacky@amd.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cc95b5d240b631e42e2863e1dcb6ad83920cc449 Author: Tom Lendacky Date: Thu Feb 9 09:22:24 2023 -0600 x86/speculation: Identify processors vulnerable to SMT RSB predictions commit be8de49bea505e7777a69ef63d60e02ac1712683 upstream. Certain AMD processors are vulnerable to a cross-thread return address predictions bug. When running in SMT mode and one of the sibling threads transitions out of C0 state, the other sibling thread could use return target predictions from the sibling thread that transitioned out of C0. The Spectre v2 mitigations cover the Linux kernel, as it fills the RSB when context switching to the idle thread. However, KVM allows a VMM to prevent exiting guest mode when transitioning out of C0. A guest could act maliciously in this situation, so create a new x86 BUG that can be used to detect if the processor is vulnerable. Reviewed-by: Borislav Petkov (AMD) Signed-off-by: Tom Lendacky Message-Id: <91cec885656ca1fcd4f0185ce403a53dd9edecb7.1675956146.git.thomas.lendacky@amd.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7fa83855852e4b13dd05702569f3f0bb3e1c624d Author: Ville Syrjälä Date: Tue Feb 7 08:43:35 2023 +0200 drm/i915: Fix VBT DSI DVO port handling commit 6a7ff131f17f44c593173c5ee30e2c03ef211685 upstream. Turns out modern (icl+) VBTs still declare their DSI ports as MIPI-A and MIPI-C despite the PHYs now being A and B. Remap appropriately to allow the panels declared as MIPI-C to work. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8016 Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20230207064337.18697-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula (cherry picked from commit 118b5c136c04da705b274b0d39982bb8b7430fc5) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit baaed8c92927e2530a799daf2e909e6688dc2943 Author: Aravind Iddamsetty Date: Fri Feb 3 19:22:05 2023 +0530 drm/i915: Initialize the obj flags for shmem objects commit 44e4c5684fcc82d8f099656c4ea39d9571e2a8ac upstream. Obj flags for shmem objects is not being set correctly. Fixes in setting BO_ALLOC_USER flag which applies to shmem objs as well. v2: Add fixes tag (Tvrtko, Matt A) Fixes: 13d29c823738 ("drm/i915/ehl: unconditionally flush the pages on acquire") Cc: # v5.15+ Cc: Matthew Auld Cc: Tvrtko Ursulin Reviewed-by: Matthew Auld Signed-off-by: Aravind Iddamsetty Reviewed-by: Andrzej Hajda Signed-off-by: Tvrtko Ursulin [tursulin: Grouped all tags together.] Link: https://patchwork.freedesktop.org/patch/msgid/20230203135205.4051149-1-aravind.iddamsetty@intel.com (cherry picked from commit bca0d1d3ceeb07be45a51c0fa4d57a0ce31b6aed) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit bfa700d12274bd3509b64fd545d1046eef89d564 Author: Rob Clark Date: Fri Feb 3 08:49:20 2023 -0800 drm/i915: Move fd_install after last use of fence commit 251e8c5b1b1fadcc387a8e618c7437d330bdac3e upstream. Because eb_composite_fence_create() drops the fence_array reference after creation of the sync_file, only the sync_file holds a ref to the fence. But fd_install() makes that reference visable to userspace, so it must be the last thing we do with the fence. Signed-off-by: Rob Clark Fixes: 00dae4d3d35d ("drm/i915: Implement SINGLE_TIMELINE with a syncobj (v4)") Cc: # v5.15+ [tursulin: Added stable tag.] Reviewed-by: Tvrtko Ursulin Signed-off-by: Tvrtko Ursulin Link: https://patchwork.freedesktop.org/patch/msgid/20230203164937.4035503-1-robdclark@gmail.com (cherry picked from commit 960dafa30455450d318756a9896a02727f2639e0) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 5af27a53a881ed49e071875c10760b0fc13996a1 Author: Melissa Wen Date: Tue Jan 31 15:05:46 2023 -0100 drm/amd/display: fix cursor offset on rotation 180 commit 49d0555976f0972af68397ed996375c135b38ba7 upstream. Cursor gets clipped off in the middle of the screen with hw rotation 180. Fix a miscalculation of cursor offset when it's placed near the edges in the pipe split case. Cursor bugs with hw rotation were reported on AMD issue tracker: https://gitlab.freedesktop.org/drm/amd/-/issues/2247 The issues on rotation 270 was fixed by: https://lore.kernel.org/amd-gfx/20221118125935.4013669-22-Brian.Chang@amd.com/ that partially addressed the rotation 180 too. So, this patch is the final bits for rotation 180. Reported-by: Xaver Hugl Reviewed-by: Harry Wentland Fixes: 9d84c7ef8a87 ("drm/amd/display: Correct cursor position on horizontal mirror") Signed-off-by: Melissa Wen Signed-off-by: Hamza Mahfooz Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 8d81e1c6865e7114d9829b0f3c73a66cd3a0963d Author: Alex Deucher Date: Tue Jan 31 09:56:46 2023 -0500 drm/amd/display: properly handling AGP aperture in vm setup commit 5c4e8c71d1202cd84d870e7e5cb8d6b52f9c3507 upstream. Take into account whether or not the AGP aperture is enabled or not when calculating the system aperture. Fixes white screens with DCN 3.1.4. Based on a patch from Yifan Zhang Cc: Yifan Zhang Acked-by: Harry Wentland Reviewed-by: Yifan Zhang Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org # 6.1.x Signed-off-by: Greg Kroah-Hartman commit 4609e1773222670af42e71c3a7bbf0453438d74a Author: Jane Jian Date: Fri Jan 13 18:53:45 2023 +0800 drm/amdgpu/smu: skip pptable init under sriov commit c6ac406cd8ff610a2d5da298b1d3071acfcde7f0 upstream. sriov does not need to init pptable from amdgpu driver we finish it from PF Signed-off-by: Jane Jian Acked-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org # 6.1.x Signed-off-by: Greg Kroah-Hartman commit 2bcbbef9cace772f5b7128b11401c515982de34b Author: Guilherme G. Piccoli Date: Thu Feb 2 10:48:56 2023 -0300 drm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini commit 5ad7bbf3dba5c4a684338df1f285080f2588b535 upstream. Currently amdgpu calls drm_sched_fini() from the fence driver sw fini routine - such function is expected to be called only after the respective init function - drm_sched_init() - was executed successfully. Happens that we faced a driver probe failure in the Steam Deck recently, and the function drm_sched_fini() was called even without its counter-part had been previously called, causing the following oops: amdgpu: probe of 0000:04:00.0 failed with error -110 BUG: kernel NULL pointer dereference, address: 0000000000000090 PGD 0 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 609 Comm: systemd-udevd Not tainted 6.2.0-rc3-gpiccoli #338 Hardware name: Valve Jupiter/Jupiter, BIOS F7A0113 11/04/2022 RIP: 0010:drm_sched_fini+0x84/0xa0 [gpu_sched] [...] Call Trace: amdgpu_fence_driver_sw_fini+0xc8/0xd0 [amdgpu] amdgpu_device_fini_sw+0x2b/0x3b0 [amdgpu] amdgpu_driver_release_kms+0x16/0x30 [amdgpu] devm_drm_dev_init_release+0x49/0x70 [...] To prevent that, check if the drm_sched was properly initialized for a given ring before calling its fini counter-part. Notice ideally we'd use sched.ready for that; such field is set as the latest thing on drm_sched_init(). But amdgpu seems to "override" the meaning of such field - in the above oops for example, it was a GFX ring causing the crash, and the sched.ready field was set to true in the ring init routine, regardless of the state of the DRM scheduler. Hence, we ended-up using sched.ops as per Christian's suggestion [0], and also removed the no_scheduler check [1]. [0] https://lore.kernel.org/amd-gfx/984ee981-2906-0eaf-ccec-9f80975cb136@amd.com/ [1] https://lore.kernel.org/amd-gfx/cd0e2994-f85f-d837-609f-7056d5fb7231@amd.com/ Fixes: 067f44c8b459 ("drm/amdgpu: avoid over-handle of fence driver fini in s3 test (v2)") Suggested-by: Christian König Cc: Guchun Chen Cc: Luben Tuikov Cc: Mario Limonciello Reviewed-by: Luben Tuikov Signed-off-by: Guilherme G. Piccoli Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit d82e6903b395aafc5c94b7282eccdd13903942a3 Author: Evan Quan Date: Tue Feb 7 10:42:31 2023 +0800 drm/amd/pm: bump SMU 13.0.7 driver_if header version commit dc38b996db968f51f0fe45845a519c5cd7f6bd04 upstream. This can suppress the warning caused by version mismatch. Signed-off-by: Evan Quan Acked-by: Alex Deucher Acked-by: Guchun Chen Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org # 6.1.x Signed-off-by: Greg Kroah-Hartman commit e379d5662c26b65384d95674559f9343be132851 Author: Kent Russell Date: Mon Feb 6 12:21:42 2023 -0500 drm/amdgpu: Add unique_id support for GC 11.0.1/2 commit c108a18462949fe709ebd6b0be68398d643bc285 upstream. These can support unique_id, so create the sysfs file for them Signed-off-by: Kent Russell Reviewed-by: Harish Kasiviswanathan Reviewed-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org # 6.1.x Signed-off-by: Greg Kroah-Hartman commit daaa0760cd0b6cf5985384d24e991f6c23a236e7 Author: Evan Quan Date: Tue Jan 31 10:40:09 2023 +0800 drm/amd/pm: bump SMU 13.0.0 driver_if header version commit 9874cc2df4e892c8744aa0472866cbf7c3cf1862 upstream. This can suppress the warning caused by version mismatch. Signed-off-by: Evan Quan Acked-by: Alex Deucher Acked-by: Guchun Chen Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org # 6.1.x Signed-off-by: Greg Kroah-Hartman commit 346631d52a42ca29c6673637c7d0cb493df72748 Author: Darren Hart Date: Wed Feb 8 16:28:21 2023 -0800 arm64: efi: Force the use of SetVirtualAddressMap() on eMAG and Altra Max machines commit 190233164cd77115f8dea718cbac561f557092c6 upstream. Commit 550b33cfd445 ("arm64: efi: Force the use of SetVirtualAddressMap() on Altra machines") identifies the Altra family via the family field in the type#1 SMBIOS record. eMAG and Altra Max machines are similarly affected but not detected with the strict strcmp test. The type1_family smbios string is not an entirely reliable means of identifying systems with this issue as OEMs can, and do, use their own strings for these fields. However, until we have a better solution, capture the bulk of these systems by adding strcmp matching for "eMAG" and "Altra Max". Fixes: 550b33cfd445 ("arm64: efi: Force the use of SetVirtualAddressMap() on Altra machines") Cc: # 6.1.x Cc: Alexandru Elisei Signed-off-by: Darren Hart Tested-by: Justin He Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman commit 3b4c045a98f53a8890a94bb5846a390c8e39e673 Author: David Chen Date: Thu Feb 9 17:48:28 2023 +0000 Fix page corruption caused by racy check in __free_pages commit 462a8e08e0e6287e5ce13187257edbf24213ed03 upstream. When we upgraded our kernel, we started seeing some page corruption like the following consistently: BUG: Bad page state in process ganesha.nfsd pfn:1304ca page:0000000022261c55 refcount:0 mapcount:-128 mapping:0000000000000000 index:0x0 pfn:0x1304ca flags: 0x17ffffc0000000() raw: 0017ffffc0000000 ffff8a513ffd4c98 ffffeee24b35ec08 0000000000000000 raw: 0000000000000000 0000000000000001 00000000ffffff7f 0000000000000000 page dumped because: nonzero mapcount CPU: 0 PID: 15567 Comm: ganesha.nfsd Kdump: loaded Tainted: P B O 5.10.158-1.nutanix.20221209.el7.x86_64 #1 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/05/2016 Call Trace: dump_stack+0x74/0x96 bad_page.cold+0x63/0x94 check_new_page_bad+0x6d/0x80 rmqueue+0x46e/0x970 get_page_from_freelist+0xcb/0x3f0 ? _cond_resched+0x19/0x40 __alloc_pages_nodemask+0x164/0x300 alloc_pages_current+0x87/0xf0 skb_page_frag_refill+0x84/0x110 ... Sometimes, it would also show up as corruption in the free list pointer and cause crashes. After bisecting the issue, we found the issue started from commit e320d3012d25 ("mm/page_alloc.c: fix freeing non-compound pages"): if (put_page_testzero(page)) free_the_page(page, order); else if (!PageHead(page)) while (order-- > 0) free_the_page(page + (1 << order), order); So the problem is the check PageHead is racy because at this point we already dropped our reference to the page. So even if we came in with compound page, the page can already be freed and PageHead can return false and we will end up freeing all the tail pages causing double free. Fixes: e320d3012d25 ("mm/page_alloc.c: fix freeing non-compound pages") Link: https://lore.kernel.org/lkml/BYAPR02MB448855960A9656EEA81141FC94D99@BYAPR02MB4488.namprd02.prod.outlook.com/ Cc: Andrew Morton Cc: stable@vger.kernel.org Signed-off-by: Chunwei Chen Reviewed-by: Vlastimil Babka Reviewed-by: Matthew Wilcox (Oracle) Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 274d9a28527d64a95107a1e62c71632065f0924f Author: Heiner Kallweit Date: Thu Feb 9 21:10:31 2023 +0100 arm64: dts: meson-axg: Make mmc host controller interrupts level-sensitive commit d182bcf300772d8b2e5f43e47fa0ebda2b767cc4 upstream. The usage of edge-triggered interrupts lead to lost interrupts under load, see [0]. This was confirmed to be fixed by using level-triggered interrupts. The report was about SDIO. However, as the host controller is the same for SD and MMC, apply the change to all mmc controller instances. [0] https://www.spinics.net/lists/linux-mmc/msg73991.html Fixes: 221cf34bac54 ("ARM64: dts: meson-axg: enable the eMMC controller") Reported-by: Peter Suti Tested-by: Vyacheslav Bocharov Tested-by: Peter Suti Cc: stable@vger.kernel.org Signed-off-by: Heiner Kallweit Acked-by: Neil Armstrong Link: https://lore.kernel.org/r/c00655d3-02f8-6f5f-4239-ca2412420cad@gmail.com Signed-off-by: Neil Armstrong Signed-off-by: Greg Kroah-Hartman commit 222b1070b0fa12be25f9503a503724a899c6326b Author: Heiner Kallweit Date: Thu Feb 9 21:11:10 2023 +0100 arm64: dts: meson-g12-common: Make mmc host controller interrupts level-sensitive commit ac8db4cceed218cca21c84f9d75ce88182d8b04f upstream. The usage of edge-triggered interrupts lead to lost interrupts under load, see [0]. This was confirmed to be fixed by using level-triggered interrupts. The report was about SDIO. However, as the host controller is the same for SD and MMC, apply the change to all mmc controller instances. [0] https://www.spinics.net/lists/linux-mmc/msg73991.html Fixes: 4759fd87b928 ("arm64: dts: meson: g12a: add mmc nodes") Tested-by: FUKAUMI Naoki Tested-by: Martin Blumenstingl Tested-by: Jerome Brunet Cc: stable@vger.kernel.org Signed-off-by: Heiner Kallweit Acked-by: Neil Armstrong Link: https://lore.kernel.org/r/27d89baa-b8fa-baca-541b-ef17a97cde3c@gmail.com Signed-off-by: Neil Armstrong Signed-off-by: Greg Kroah-Hartman commit a01ad536becb5d4c001a7d50dc1ca9fa14ef75a8 Author: Heiner Kallweit Date: Thu Feb 9 21:11:47 2023 +0100 arm64: dts: meson-gx: Make mmc host controller interrupts level-sensitive commit 66e45351f7d6798751f98001d1fcd572024d87f0 upstream. The usage of edge-triggered interrupts lead to lost interrupts under load, see [0]. This was confirmed to be fixed by using level-triggered interrupts. The report was about SDIO. However, as the host controller is the same for SD and MMC, apply the change to all mmc controller instances. [0] https://www.spinics.net/lists/linux-mmc/msg73991.html Fixes: ef8d2ffedf18 ("ARM64: dts: meson-gxbb: add MMC support") Cc: stable@vger.kernel.org Signed-off-by: Heiner Kallweit Acked-by: Neil Armstrong Link: https://lore.kernel.org/r/76e042e0-a610-5ed5-209f-c4d7f879df44@gmail.com Signed-off-by: Neil Armstrong Signed-off-by: Greg Kroah-Hartman commit 446ac8dd8997cd71befd726ce30520e6c35d80a5 Author: Wander Lairson Costa Date: Thu Feb 2 09:30:20 2023 -0300 rtmutex: Ensure that the top waiter is always woken up commit db370a8b9f67ae5f17e3d5482493294467784504 upstream. Let L1 and L2 be two spinlocks. Let T1 be a task holding L1 and blocked on L2. T1, currently, is the top waiter of L2. Let T2 be the task holding L2. Let T3 be a task trying to acquire L1. The following events will lead to a state in which the wait queue of L2 isn't empty, but no task actually holds the lock. T1 T2 T3 == == == spin_lock(L1) | raw_spin_lock(L1->wait_lock) | rtlock_slowlock_locked(L1) | | task_blocks_on_rt_mutex(L1, T3) | | | orig_waiter->lock = L1 | | | orig_waiter->task = T3 | | | raw_spin_unlock(L1->wait_lock) | | | rt_mutex_adjust_prio_chain(T1, L1, L2, orig_waiter, T3) spin_unlock(L2) | | | | | rt_mutex_slowunlock(L2) | | | | | | raw_spin_lock(L2->wait_lock) | | | | | | wakeup(T1) | | | | | | raw_spin_unlock(L2->wait_lock) | | | | | | | | waiter = T1->pi_blocked_on | | | | waiter == rt_mutex_top_waiter(L2) | | | | waiter->task == T1 | | | | raw_spin_lock(L2->wait_lock) | | | | dequeue(L2, waiter) | | | | update_prio(waiter, T1) | | | | enqueue(L2, waiter) | | | | waiter != rt_mutex_top_waiter(L2) | | | | L2->owner == NULL | | | | wakeup(T1) | | | | raw_spin_unlock(L2->wait_lock) T1 wakes up T1 != top_waiter(L2) schedule_rtlock() If the deadline of T1 is updated before the call to update_prio(), and the new deadline is greater than the deadline of the second top waiter, then after the requeue, T1 is no longer the top waiter, and the wrong task is woken up which will then go back to sleep because it is not the top waiter. This can be reproduced in PREEMPT_RT with stress-ng: while true; do stress-ng --sched deadline --sched-period 1000000000 \ --sched-runtime 800000000 --sched-deadline \ 1000000000 --mmapfork 23 -t 20 done A similar issue was pointed out by Thomas versus the cases where the top waiter drops out early due to a signal or timeout, which is a general issue for all regular rtmutex use cases, e.g. futex. The problematic code is in rt_mutex_adjust_prio_chain(): // Save the top waiter before dequeue/enqueue prerequeue_top_waiter = rt_mutex_top_waiter(lock); rt_mutex_dequeue(lock, waiter); waiter_update_prio(waiter, task); rt_mutex_enqueue(lock, waiter); // Lock has no owner? if (!rt_mutex_owner(lock)) { // Top waiter changed ----> if (prerequeue_top_waiter != rt_mutex_top_waiter(lock)) ----> wake_up_state(waiter->task, waiter->wake_state); This only takes the case into account where @waiter is the new top waiter due to the requeue operation. But it fails to handle the case where @waiter is not longer the top waiter due to the requeue operation. Ensure that the new top waiter is woken up so in all cases so it can take over the ownerless lock. [ tglx: Amend changelog, add Fixes tag ] Fixes: c014ef69b3ac ("locking/rtmutex: Add wake_state to rt_mutex_waiter") Signed-off-by: Wander Lairson Costa Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230117172649.52465-1-wander@redhat.com Link: https://lore.kernel.org/r/20230202123020.14844-1-wander@redhat.com Signed-off-by: Greg Kroah-Hartman commit 386a8d694f95f5d9b844946f17e6376b92a8abff Author: Yafang Shao Date: Sun Feb 12 15:13:03 2023 +0000 tracing: Fix TASK_COMM_LEN in trace event format file commit b6c7abd1c28a63ad633433d037ee15a1bc3023ba upstream. After commit 3087c61ed2c4 ("tools/testing/selftests/bpf: replace open-coded 16 with TASK_COMM_LEN"), the content of the format file under /sys/kernel/tracing/events/task/task_newtask was changed from field:char comm[16]; offset:12; size:16; signed:0; to field:char comm[TASK_COMM_LEN]; offset:12; size:16; signed:0; John reported that this change breaks older versions of perfetto. Then Mathieu pointed out that this behavioral change was caused by the use of __stringify(_len), which happens to work on macros, but not on enum labels. And he also gave the suggestion on how to fix it: :One possible solution to make this more robust would be to extend :struct trace_event_fields with one more field that indicates the length :of an array as an actual integer, without storing it in its stringified :form in the type, and do the formatting in f_show where it belongs. The result as follows after this change, $ cat /sys/kernel/tracing/events/task/task_newtask/format field:char comm[16]; offset:12; size:16; signed:0; Link: https://lore.kernel.org/lkml/Y+QaZtz55LIirsUO@google.com/ Link: https://lore.kernel.org/linux-trace-kernel/20230210155921.4610-1-laoar.shao@gmail.com/ Link: https://lore.kernel.org/linux-trace-kernel/20230212151303.12353-1-laoar.shao@gmail.com Cc: stable@vger.kernel.org Cc: Alexei Starovoitov Cc: Kajetan Puchalski CC: Qais Yousef Fixes: 3087c61ed2c4 ("tools/testing/selftests/bpf: replace open-coded 16 with TASK_COMM_LEN") Reported-by: John Stultz Debugged-by: Mathieu Desnoyers Suggested-by: Mathieu Desnoyers Suggested-by: Steven Rostedt Signed-off-by: Yafang Shao Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit a2e60fee4b7681bb9664f6a638d9630102ac978b Author: Friedrich Vock Date: Thu Feb 2 17:21:03 2023 +0100 drm/amdgpu: Use the TGID for trace_amdgpu_vm_update_ptes commit e53448e0a1efa5133c7db78f1df1f4caf177676b upstream. The pid field corresponds to the result of gettid() in userspace. However, userspace cannot reliably attribute PTE events to processes with just the thread id. This patch allows userspace to easily attribute PTE update events to specific processes by comparing this field with the result of getpid(). For attributing events to specific threads, the thread id is also contained in the common fields of each trace event. Reviewed-by: Christian König Signed-off-by: Friedrich Vock Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 6f097c24815e67909a1fcc2c605586d02babd673 Author: Nicholas Piggin Date: Mon Feb 6 14:22:40 2023 +1000 powerpc/64s/interrupt: Fix interrupt exit race with security mitigation switch commit 2ea31e2e62bbc4d11c411eeb36f1b02841dbcab1 upstream. The RFI and STF security mitigation options can flip the interrupt_exit_not_reentrant static branch condition concurrently with the interrupt exit code which tests that branch. Interrupt exit tests this condition to set MSR[EE|RI] for exit, then again in the case a soft-masked interrupt is found pending, to recover the MSR so the interrupt can be replayed before attempting to exit again. If the condition changes between these two tests, the MSR and irq soft-mask state will become corrupted, leading to warnings and possible crashes. For example, if the branch is initially true then false, MSR[EE] will be 0 but PACA_IRQ_HARD_DIS clear and EE may not get enabled, leading to warnings in irq_64.c. Fixes: 13799748b957 ("powerpc/64: use interrupt restart table to speed up return from interrupt") Cc: stable@vger.kernel.org # v5.14+ Reported-by: Sachin Sant Tested-by: Sachin Sant Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20230206042240.92103-1-npiggin@gmail.com Signed-off-by: Greg Kroah-Hartman commit 026cae99d06409752145e2472c1b264cc5fb6bf1 Author: Guo Ren Date: Sat Feb 4 01:35:31 2023 -0500 riscv: kprobe: Fixup misaligned load text commit eb7423273cc9922ee2d05bf660c034d7d515bb91 upstream. The current kprobe would cause a misaligned load for the probe point. This patch fixup it with two half-word loads instead. Fixes: c22b0bcb1dd0 ("riscv: Add kprobes supported") Signed-off-by: Guo Ren Signed-off-by: Guo Ren Link: https://lore.kernel.org/linux-riscv/878rhig9zj.fsf@all.your.base.are.belong.to.us/ Reported-by: Bjorn Topel Reviewed-by: Björn Töpel Link: https://lore.kernel.org/r/20230204063531.740220-1-guoren@kernel.org Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit 7d151eccd07a0a9767f3e0af976e05a9210ea678 Author: Guo Ren Date: Thu Jan 26 22:53:06 2023 -0500 riscv: Fixup race condition on PG_dcache_clean in flush_icache_pte commit 950b879b7f0251317d26bae0687e72592d607532 upstream. In commit 588a513d3425 ("arm64: Fix race condition on PG_dcache_clean in __sync_icache_dcache()"), we found RISC-V has the same issue as the previous arm64. The previous implementation didn't guarantee the correct sequence of operations, which means flush_icache_all() hasn't been called when the PG_dcache_clean was set. That would cause a risk of page synchronization. Fixes: 08f051eda33b ("RISC-V: Flush I$ when making a dirty page executable") Signed-off-by: Guo Ren Signed-off-by: Guo Ren Reviewed-by: Andrew Jones Reviewed-by: Conor Dooley Link: https://lore.kernel.org/r/20230127035306.1819561-1-guoren@kernel.org Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit 9f55a0a2d94fd731e396b8586be6babca49dfd92 Author: Dan Williams Date: Wed Jan 25 12:23:46 2023 -0800 nvdimm: Support sizeof(struct page) > MAX_STRUCT_PAGE_SIZE commit c91d713630848460de8669e6570307b7e559863b upstream. Commit 6e9f05dc66f9 ("libnvdimm/pfn_dev: increase MAX_STRUCT_PAGE_SIZE") ...updated MAX_STRUCT_PAGE_SIZE to account for sizeof(struct page) potentially doubling in the case of CONFIG_KMSAN=y. Unfortunately this doubles the amount of capacity stolen from user addressable capacity for everyone, regardless of whether they are using the debug option. Revert that change, mandate that MAX_STRUCT_PAGE_SIZE never exceed 64, but allow for debug scenarios to proceed with creating debug sized page maps with a compile option to support debug scenarios. Note that this only applies to cases where the page map is permanent, i.e. stored in a reservation of the pmem itself ("--map=dev" in "ndctl create-namespace" terms). For the "--map=mem" case, since the allocation is ephemeral for the lifespan of the namespace, there are no explicit restriction. However, the implicit restriction, of having enough available "System RAM" to store the page map for the typically large pmem, still applies. Fixes: 6e9f05dc66f9 ("libnvdimm/pfn_dev: increase MAX_STRUCT_PAGE_SIZE") Cc: Cc: Alexander Potapenko Cc: Marco Elver Reported-by: Jeff Moyer Acked-by: Yu Zhao Link: https://lore.kernel.org/r/167467815773.463042.7022545814443036382.stgit@dwillia2-xfh.jf.intel.com Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit a89868254cd2079b800361e68f39ac4e57293080 Author: Xiubo Li Date: Tue Feb 7 13:04:52 2023 +0800 ceph: flush cap releases when the session is flushed commit e7d84c6a1296d059389f7342d9b4b7defb518d3a upstream. MDS expects the completed cap release prior to responding to the session flush for cache drop. Cc: stable@vger.kernel.org Link: http://tracker.ceph.com/issues/38009 Signed-off-by: Xiubo Li Reviewed-by: Venky Shankar Reviewed-by: Jeff Layton Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 62890f3eabf80676c0fefbbdd88e0f3f12528032 Author: Evan Quan Date: Fri Feb 3 15:33:59 2023 +0800 drm/amd/pm: add SMU 13.0.7 missing GetPptLimit message mapping commit 0e763afcb50814e256ecb780fcc0f3bade2e1a0c upstream. Add missing GetPptLimit message mapping. Signed-off-by: Evan Quan Reviewed-by: Feifei Xu Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org # 6.1.x Signed-off-by: Greg Kroah-Hartman commit 7d2cd4736d1aba688d25801623ffead12caed768 Author: Krzysztof Kozlowski Date: Fri Feb 3 17:50:54 2023 +0100 pinctrl: qcom: sm8450-lpass-lpi: correct swr_rx_data group commit 5921b250f43870e7d8044ca14e402292ceb3e3a8 upstream. According to hardware programming guide, the swr_rx_data pin group has only two pins (GPIO5 and GPIO6). This is also visible in "struct sm8450_groups" in the driver - GPIO15 does not have swr_rx_data function. Fixes: ec1652fc4d56 ("pinctrl: qcom: Add sm8450 lpass lpi pinctrl driver") Cc: Signed-off-by: Krzysztof Kozlowski Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20230203165054.390762-1-krzysztof.kozlowski@linaro.org Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit ab6fd64dda2ba0b2fae1a34fe68edf1769c16c4a Author: Paul Cercueil Date: Wed Dec 14 13:37:04 2022 +0100 clk: ingenic: jz4760: Update M/N/OD calculation algorithm commit ecfb9f404771dde909ce7743df954370933c3be2 upstream. The previous algorithm was pretty broken. - The inner loop had a '(m > m_max)' condition, and the value of 'm' would increase in each iteration; - Each iteration would actually multiply 'm' by two, so it is not needed to re-compute the whole equation at each iteration; - It would loop until (m & 1) == 0, which means it would loop at most once. - The outer loop would divide the 'n' value by two at the end of each iteration. This meant that for a 12 MHz parent clock and a 1.2 GHz requested clock, it would first try n=12, then n=6, then n=3, then n=1, none of which would work; the only valid value is n=2 in this case. Simplify this algorithm with a single for loop, which decrements 'n' after each iteration, addressing all of the above problems. Fixes: bdbfc029374f ("clk: ingenic: Add support for the JZ4760") Cc: Signed-off-by: Paul Cercueil Link: https://lore.kernel.org/r/20221214123704.7305-1-paul@crapouillou.net Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 15f9f8eb3b8b1d1831899b4ffb816a0ecc57f044 Author: Dan Williams Date: Tue Feb 7 11:04:30 2023 -0800 cxl/region: Fix passthrough-decoder detection commit 711442e29f16f0d39dd0e2460c9baacfccb9d5a7 upstream. A passthrough decoder is a decoder that maps only 1 target. It is a special case because it does not impose any constraints on the interleave-math as compared to a decoder with multiple targets. Extend the passthrough case to multi-target-capable decoders that only have one target selected. I.e. the current code was only considering passthrough *ports* which are only a subset of the potential passthrough decoder scenarios. Fixes: e4f6dfa9ef75 ("cxl/region: Fix 'distance' calculation with passthrough ports") Cc: Reviewed-by: Dave Jiang Link: https://lore.kernel.org/r/167564540422.847146.13816934143225777888.stgit@dwillia2-xfh.jf.intel.com Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit a04c7d062b537ff787d00da95bdfe343260d4beb Author: Fan Ni Date: Thu Dec 15 17:09:14 2022 +0000 cxl/region: Fix null pointer dereference for resetting decoder commit 4fa4302d6dc7de7e8e74dc7405611a2efb4bf54b upstream. Not all decoders have a reset callback. The CXL specification allows a host bridge with a single root port to have no explicit HDM decoders. Currently the region driver assumes there are none. As such the CXL core creates a special pass through decoder instance without a commit/reset callback. Prior to this patch, the ->reset() callback was called unconditionally when calling cxl_region_decode_reset. Thus a configuration with 1 Host Bridge, 1 Root Port, and one directly attached CXL type 3 device or multiple CXL type 3 devices attached to downstream ports of a switch can cause a null pointer dereference. Before the fix, a kernel crash was observed when we destroy the region, and a pass through decoder is reset. The issue can be reproduced as below, 1) create a region with a CXL setup which includes a HB with a single root port under which a memdev is attached directly. 2) destroy the region with cxl destroy-region regionX -f. Fixes: 176baefb2eb5 ("cxl/hdm: Commit decoder state to hardware") Cc: Signed-off-by: Fan Ni Reviewed-by: Davidlohr Bueso Reviewed-by: Dave Jiang Reviewed-by: Jonathan Cameron Tested-by: Gregory Price Reviewed-by: Gregory Price Link: https://lore.kernel.org/r/20221215170909.2650271-1-fan.ni@samsung.com Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 01815a1caf2fec67910a7fb108241b22699e6590 Author: Prashant Malani Date: Wed Feb 8 20:53:19 2023 +0000 usb: typec: altmodes/displayport: Fix probe pin assign check commit 54e5c00a4eb0a4c663445b245f641bbfab142430 upstream. While checking Pin Assignments of the port and partner during probe, we don't take into account whether the peripheral is a plug or receptacle. This manifests itself in a mode entry failure on certain docks and dongles with captive cables. For instance, the Startech.com Type-C to DP dongle (Model #CDP2DP) advertises its DP VDO as 0x405. This would fail the Pin Assignment compatibility check, despite it supporting Pin Assignment C as a UFP. Update the check to use the correct DP Pin Assign macros that take the peripheral's receptacle bit into account. Fixes: c1e5c2f0cb8a ("usb: typec: altmodes/displayport: correct pin assignment for UFP receptacles") Cc: stable@vger.kernel.org Reported-by: Diana Zigterman Signed-off-by: Prashant Malani Link: https://lore.kernel.org/r/20230208205318.131385-1-pmalani@chromium.org Signed-off-by: Greg Kroah-Hartman commit db9c4a94b6291dc166e77e56951b9e7256ecc0e9 Author: Mark Pearson Date: Wed Feb 8 13:12:23 2023 -0500 usb: core: add quirk for Alcor Link AK9563 smartcard reader commit 303e724d7b1e1a0a93daf0b1ab5f7c4f53543b34 upstream. The Alcor Link AK9563 smartcard reader used on some Lenovo platforms doesn't work. If LPM is enabled the reader will provide an invalid usb config descriptor. Added quirk to disable LPM. Verified fix on Lenovo P16 G1 and T14 G3 Tested-by: Miroslav Zatko Tested-by: Dennis Wassenberg Cc: stable@vger.kernel.org Signed-off-by: Dennis Wassenberg Signed-off-by: Mark Pearson Link: https://lore.kernel.org/r/20230208181223.1092654-1-mpearson-lenovo@squebb.ca Signed-off-by: Greg Kroah-Hartman commit 51aa10112b12ff353b18d8bfc6e1eaff68142c81 Author: Anand Jain Date: Fri Jan 20 21:47:16 2023 +0800 btrfs: free device in btrfs_close_devices for a single device filesystem commit 5f58d783fd7823b2c2d5954d1126e702f94bfc4c upstream. We have this check to make sure we don't accidentally add older devices that may have disappeared and re-appeared with an older generation from being added to an fs_devices (such as a replace source device). This makes sense, we don't want stale disks in our file system. However for single disks this doesn't really make sense. I've seen this in testing, but I was provided a reproducer from a project that builds btrfs images on loopback devices. The loopback device gets cached with the new generation, and then if it is re-used to generate a new file system we'll fail to mount it because the new fs is "older" than what we have in cache. Fix this by freeing the cache when closing the device for a single device filesystem. This will ensure that the mount command passed device path is scanned successfully during the next mount. CC: stable@vger.kernel.org # 5.10+ Reported-by: Daan De Meyer Signed-off-by: Josef Bacik Signed-off-by: Anand Jain Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 1ab4bed3fc8bf279eeb0865936c56bef49759a57 Author: Filipe Manana Date: Tue Jan 10 14:56:39 2023 +0000 btrfs: simplify update of last_dir_index_offset when logging a directory commit 6afaed53cc9adde69d8a76ff5b4d740d5efbc54c upstream. When logging a directory, we always set the inode's last_dir_index_offset to the offset of the last dir index item we found. This is using an extra field in the log context structure, and it makes more sense to update it only after we insert dir index items, and we could directly update the inode's last_dir_index_offset field instead. So make this simpler by updating the inode's last_dir_index_offset only when we actually insert dir index keys in the log tree, and getting rid of the last_dir_item_offset field in the log context structure. Reported-by: David Arendt Link: https://lore.kernel.org/linux-btrfs/ae169fc6-f504-28f0-a098-6fa6a4dfb612@leemhuis.info/ Reported-by: Maxim Mikityanskiy Link: https://lore.kernel.org/linux-btrfs/Y8voyTXdnPDz8xwY@mail.gmail.com/ Reported-by: Hunter Wardlaw Link: https://bugzilla.suse.com/show_bug.cgi?id=1207231 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216851 CC: stable@vger.kernel.org # 6.1+ Reviewed-by: Josef Bacik Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit f676c8a695880f71624ada09183b5009829626ef Author: Matthieu Baerts Date: Tue Feb 7 14:04:18 2023 +0100 selftests: mptcp: stop tests earlier commit 070d6dafacbaa9d1f2e4e3edc263853d194af15e upstream. These 'endpoint' tests from 'mptcp_join.sh' selftest start a transfer in the background and check the status during this transfer. Once the expected events have been recorded, there is no reason to wait for the data transfer to finish. It can be stopped earlier to reduce the execution time by more than half. For these tests, the exchanged data were not verified. Errors, if any, were ignored but that's fine, plenty of other tests are looking at that. It is then OK to mute stderr now that we are sure errors will be printed (and still ignored) because the transfer is stopped before the end. Fixes: e274f7154008 ("selftests: mptcp: add subflow limits test-cases") Cc: stable@vger.kernel.org Signed-off-by: Matthieu Baerts Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b7692fb9a2b02270612f29041dde63dba73841ad Author: Paolo Abeni Date: Tue Feb 7 14:04:17 2023 +0100 selftests: mptcp: allow more slack for slow test-case commit a635a8c3df66ab68dc088c08a4e9e955e22c0e64 upstream. A test-case is frequently failing on some extremely slow VMs. The mptcp transfer completes before the script is able to do all the required PM manipulation. Address the issue in the simplest possible way, making the transfer even more slow. Additionally dump more info in case of failures, to help debugging similar problems in the future and init dump_stats var. Fixes: e274f7154008 ("selftests: mptcp: add subflow limits test-cases") Cc: stable@vger.kernel.org Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/323 Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts Signed-off-by: Matthieu Baerts Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ba36772a1cc94a70e55942c049b2e33fc482ff99 Author: Paolo Abeni Date: Tue Feb 7 14:04:16 2023 +0100 mptcp: be careful on subflow status propagation on errors commit 1249db44a102d9d3541ed7798d4b01ffdcf03524 upstream. Currently the subflow error report callback unconditionally propagates the fallback subflow status to the owning msk. If the msk is already orphaned, the above prevents the code from correctly tracking the msk moving to the TCP_CLOSE state and doing the appropriate cleanup. All the above causes increasing memory usage over time and sporadic self-tests failures. There is a great deal of infrastructure trying to propagate correctly the fallback subflow status to the owning mptcp socket, e.g. via mptcp_subflow_eof() and subflow_sched_work_if_closed(): in the error propagation path we need only to cope with unorphaned sockets. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/339 Fixes: 15cc10453398 ("mptcp: deliver ssk errors to msk") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts Signed-off-by: Matthieu Baerts Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e266ad04ec3993244b663303e3d2281524bb1732 Author: Paolo Abeni Date: Tue Feb 7 14:04:13 2023 +0100 mptcp: do not wait for bare sockets' timeout commit d4e85922e3e7ef2071f91f65e61629b60f3a9cf4 upstream. If the peer closes all the existing subflows for a given mptcp socket and later the application closes it, the current implementation let it survive until the timewait timeout expires. While the above is allowed by the protocol specification it consumes resources for almost no reason and additionally causes sporadic self-tests failures. Let's move the mptcp socket to the TCP_CLOSE state when there are no alive subflows at close time, so that the allocated resources will be freed immediately. Fixes: e16163b6e2b7 ("mptcp: refactor shutdown and close") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts Signed-off-by: Matthieu Baerts Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0d2cf3fae701646061e295815bb7588d2f3671cc Author: Alan Stern Date: Fri Feb 3 14:32:09 2023 -0500 net: USB: Fix wrong-direction WARNING in plusb.c commit 811d581194f7412eda97acc03d17fc77824b561f upstream. The syzbot fuzzer detected a bug in the plusb network driver: A zero-length control-OUT transfer was treated as a read instead of a write. In modern kernels this error provokes a WARNING: usb 1-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType c0 WARNING: CPU: 0 PID: 4645 at drivers/usb/core/urb.c:411 usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411 Modules linked in: CPU: 1 PID: 4645 Comm: dhcpcd Not tainted 6.2.0-rc6-syzkaller-00050-g9f266ccaa2f5 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023 RIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411 ... Call Trace: usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [inline] usb_control_msg+0x320/0x4a0 drivers/usb/core/message.c:153 __usbnet_read_cmd+0xb9/0x390 drivers/net/usb/usbnet.c:2010 usbnet_read_cmd+0x96/0xf0 drivers/net/usb/usbnet.c:2068 pl_vendor_req drivers/net/usb/plusb.c:60 [inline] pl_set_QuickLink_features drivers/net/usb/plusb.c:75 [inline] pl_reset+0x2f/0xf0 drivers/net/usb/plusb.c:85 usbnet_open+0xcc/0x5d0 drivers/net/usb/usbnet.c:889 __dev_open+0x297/0x4d0 net/core/dev.c:1417 __dev_change_flags+0x587/0x750 net/core/dev.c:8530 dev_change_flags+0x97/0x170 net/core/dev.c:8602 devinet_ioctl+0x15a2/0x1d70 net/ipv4/devinet.c:1147 inet_ioctl+0x33f/0x380 net/ipv4/af_inet.c:979 sock_do_ioctl+0xcc/0x230 net/socket.c:1169 sock_ioctl+0x1f8/0x680 net/socket.c:1286 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd The fix is to call usbnet_write_cmd() instead of usbnet_read_cmd() and remove the USB_DIR_IN flag. Reported-and-tested-by: syzbot+2a0e7abd24f1eb90ce25@syzkaller.appspotmail.com Signed-off-by: Alan Stern Fixes: 090ffa9d0e90 ("[PATCH] USB: usbnet (9/9) module for pl2301/2302 cables") CC: stable@vger.kernel.org Link: https://lore.kernel.org/r/00000000000052099f05f3b3e298@google.com/ Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3684a2f6affa1ca52a5d4a12f04d0652efdee65e Author: ZhaoLong Wang Date: Mon Feb 6 09:10:09 2023 +0800 cifs: Fix use-after-free in rdata->read_into_pages() commit aa5465aeca3c66fecdf7efcf554aed79b4c4b211 upstream. When the network status is unstable, use-after-free may occur when read data from the server. BUG: KASAN: use-after-free in readpages_fill_pages+0x14c/0x7e0 Call Trace: dump_stack_lvl+0x38/0x4c print_report+0x16f/0x4a6 kasan_report+0xb7/0x130 readpages_fill_pages+0x14c/0x7e0 cifs_readv_receive+0x46d/0xa40 cifs_demultiplex_thread+0x121c/0x1490 kthread+0x16b/0x1a0 ret_from_fork+0x2c/0x50 Allocated by task 2535: kasan_save_stack+0x22/0x50 kasan_set_track+0x25/0x30 __kasan_kmalloc+0x82/0x90 cifs_readdata_direct_alloc+0x2c/0x110 cifs_readdata_alloc+0x2d/0x60 cifs_readahead+0x393/0xfe0 read_pages+0x12f/0x470 page_cache_ra_unbounded+0x1b1/0x240 filemap_get_pages+0x1c8/0x9a0 filemap_read+0x1c0/0x540 cifs_strict_readv+0x21b/0x240 vfs_read+0x395/0x4b0 ksys_read+0xb8/0x150 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc Freed by task 79: kasan_save_stack+0x22/0x50 kasan_set_track+0x25/0x30 kasan_save_free_info+0x2e/0x50 __kasan_slab_free+0x10e/0x1a0 __kmem_cache_free+0x7a/0x1a0 cifs_readdata_release+0x49/0x60 process_one_work+0x46c/0x760 worker_thread+0x2a4/0x6f0 kthread+0x16b/0x1a0 ret_from_fork+0x2c/0x50 Last potentially related work creation: kasan_save_stack+0x22/0x50 __kasan_record_aux_stack+0x95/0xb0 insert_work+0x2b/0x130 __queue_work+0x1fe/0x660 queue_work_on+0x4b/0x60 smb2_readv_callback+0x396/0x800 cifs_abort_connection+0x474/0x6a0 cifs_reconnect+0x5cb/0xa50 cifs_readv_from_socket.cold+0x22/0x6c cifs_read_page_from_socket+0xc1/0x100 readpages_fill_pages.cold+0x2f/0x46 cifs_readv_receive+0x46d/0xa40 cifs_demultiplex_thread+0x121c/0x1490 kthread+0x16b/0x1a0 ret_from_fork+0x2c/0x50 The following function calls will cause UAF of the rdata pointer. readpages_fill_pages cifs_read_page_from_socket cifs_readv_from_socket cifs_reconnect __cifs_reconnect cifs_abort_connection mid->callback() --> smb2_readv_callback queue_work(&rdata->work) # if the worker completes first, # the rdata is freed cifs_readv_complete kref_put cifs_readdata_release kfree(rdata) return rdata->... # UAF in readpages_fill_pages() Similarly, this problem also occurs in the uncache_fill_pages(). Fix this by adjusts the order of condition judgment in the return statement. Signed-off-by: ZhaoLong Wang Cc: stable@vger.kernel.org Acked-by: Paulo Alcantara (SUSE) Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 33dd18fbbb2d3cf97a409daffba57968a1c8fa24 Author: Andy Shevchenko Date: Mon Feb 6 16:15:59 2023 +0200 pinctrl: intel: Restore the pins that used to be in Direct IRQ mode [ Upstream commit a8520be3ffef3d25b53bf171a7ebe17ee0154175 ] If the firmware mangled the register contents too much, check the saved value for the Direct IRQ mode. If it matches, we will restore the pin state. Reported-by: Jim Minter Fixes: 6989ea4881c8 ("pinctrl: intel: Save and restore pins in "direct IRQ" mode") Tested-by: Jim Minter Signed-off-by: Andy Shevchenko Acked-by: Mika Westerberg Link: https://lore.kernel.org/r/20230206141558.20916-1-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 3319d7292568ada688613629c7ee13df580408b2 Author: Joel Stanley Date: Tue Jan 31 08:38:45 2023 +1030 pinctrl: aspeed: Revert "Force to disable the function's signal" [ Upstream commit 606d4ef4922662ded34aa7218288c3043ce0a41a ] This reverts commit cf517fef601b9dde151f0afc27164d13bf1fd907. The commit cf517fef601b ("pinctrl: aspeed: Force to disable the function's signal") exposed a problem with fetching the regmap for reading the GFX register. The Romulus machine the device tree contains a gpio hog for GPIO S7. With the patch applied: Muxing pin 151 for GPIO Disabling signal VPOB9 for VPO aspeed-g5-pinctrl 1e6e2080.pinctrl: Failed to acquire regmap for IP block 1 aspeed-g5-pinctrl 1e6e2080.pinctrl: request() failed for pin 151 The code path is aspeed-gpio -> pinmux-g5 -> regmap -> clk, and the of_clock code returns an error as it doesn't have a valid struct clk_hw pointer. The regmap call happens because pinmux wants to check the GFX node (IP block 1) to query bits there. For reference, before the offending patch: Muxing pin 151 for GPIO Disabling signal VPOB9 for VPO Want SCU8C[0x00000080]=0x1, got 0x0 from 0x00000000 Disabling signal VPOB9 for VPOOFF1 Want SCU8C[0x00000080]=0x1, got 0x0 from 0x00000000 Disabling signal VPOB9 for VPOOFF2 Want SCU8C[0x00000080]=0x1, got 0x0 from 0x00000000 Enabling signal GPIOS7 for GPIOS7 Muxed pin 151 as GPIOS7 gpio-943 (seq_cont): hogged as output/low We can't skip the clock check to allow pinmux to proceed, because the write to disable VPOB9 will try to set a bit in the GFX register space which will not stick when the IP is in reset. However, we do not want to enable the IP just so pinmux can do a disable-enable dance for the pin. For now, revert the offending patch while a correct solution is found. Fixes: cf517fef601b ("pinctrl: aspeed: Force to disable the function's signal") Link: https://github.com/openbmc/linux/issues/218 Signed-off-by: Joel Stanley Link: https://lore.kernel.org/r/20230130220845.917985-1-joel@jms.id.au Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit ebe63349cd48ae314040acbf54236c9d66be8c81 Author: Serge Semin Date: Fri Jan 13 21:59:42 2023 +0300 spi: dw: Fix wrong FIFO level setting for long xfers [ Upstream commit c63b8fd14a7db719f8252038a790638728c4eb66 ] Due to using the u16 type in the min_t() macros the SPI transfer length will be cast to word before participating in the conditional statement implied by the macro. Thus if the transfer length is greater than 64KB the Tx/Rx FIFO threshold level value will be determined by the leftover of the truncated after the type-case length. In the worst case it will cause the dramatical performance drop due to the "Tx FIFO Empty" or "Rx FIFO Full" interrupts triggered on each xfer word sent/received to/from the bus. The problem can be easily fixed by specifying the unsigned int type in the min_t() macros thus preventing the possible data loss. Fixes: ea11370fffdf ("spi: dw: get TX level without an additional variable") Reported-by: Sergey Nazarov Signed-off-by: Serge Semin Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20230113185942.2516-1-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit bcc487001a15f71f103d102cba4ac8145d7a68f2 Author: Maxim Korotkov Date: Fri Nov 18 13:43:32 2022 +0300 pinctrl: single: fix potential NULL dereference [ Upstream commit d2d73e6d4822140445ad4a7b1c6091e0f5fe703b ] Added checking of pointer "function" in pcs_set_mux(). pinmux_generic_get_function() can return NULL and the pointer "function" was dereferenced without checking against NULL. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 571aec4df5b7 ("pinctrl: single: Use generic pinmux helpers for managing functions") Signed-off-by: Maxim Korotkov Reviewed-by: Tony Lindgren Link: https://lore.kernel.org/r/20221118104332.943-1-korotkov.maxim.s@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 9eab7b053947add8f9d6dcd78800b4db9adf66a9 Author: Joel Stanley Date: Fri Jan 20 09:48:56 2023 +1030 pinctrl: aspeed: Fix confusing types in return value [ Upstream commit 287a344a11f1ebd31055cf9b22c88d7005f108d7 ] The function signature is int, but we return a bool. Instead return a negative errno as the kerneldoc suggests. Fixes: 4d3d0e4272d8 ("pinctrl: Add core support for Aspeed SoCs") Signed-off-by: Joel Stanley Reviewed-by: Andrew Jeffery Link: https://lore.kernel.org/r/20230119231856.52014-1-joel@jms.id.au Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit b048b969b362405ac20334da87d282b60e34af02 Author: Guodong Liu Date: Wed Jan 18 14:21:16 2023 +0800 pinctrl: mediatek: Fix the drive register definition of some Pins [ Upstream commit 5754a1c98b18009cb3030dc391aa37b77428a0bd ] The drive adjustment register definition of gpio13 and gpio81 is wrong: "the start address for the range" of gpio18 is corrected to 0x000, "the start bit for the first register within the range" of gpio81 is corrected to 24. Fixes: 6cf5e9ef362a ("pinctrl: add pinctrl driver on mt8195") Signed-off-by: Guodong Liu Link: https://lore.kernel.org/r/20230118062116.26315-1-Guodong.Liu@mediatek.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 6353ebac4612a9f78f2e67adb6a568ae170599f7 Author: Geert Uytterhoeven Date: Tue Jan 3 17:45:30 2023 +0100 clk: microchip: mpfs-ccc: Use devm_kasprintf() for allocating formatted strings [ Upstream commit 86d884f5287f4369c198811aaa4931a3a11f36d2 ] In various places, string buffers of a fixed size are allocated, and filled using snprintf() with the same fixed size, which is error-prone. Replace this by calling devm_kasprintf() instead, which always uses the appropriate size. While at it, remove an unneeded intermediate variable, which allows us to drop a cast as a bonus. With the initial behavior it would have been possible to have a device tree with a node address that would make "ccc_pll" exceed 18 characters. If that happened, the would be cut off & both pll 0 & 1 would be named identically. If that happens, pll1 would fail to register. Thus, the fixes tag has been added to this commit. Fixes: d39fb172760e ("clk: microchip: add PolarFire SoC fabric clock support") Signed-off-by: Geert Uytterhoeven Reviewed-by: Conor Dooley Tested-by: Conor Dooley [claudiu.beznea: added the rationale behind fixes tag] Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/f904fd28b2087d1463ea65f059924e3b1acc193c.1672764239.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit dcfe5431fb0fcc130958f33472a6b8327e5cba8c Author: Amadeusz Sławiński Date: Tue Feb 7 22:04:28 2023 +0100 ASoC: topology: Return -ENOMEM on memory allocation failure [ Upstream commit c173ee5b2fa6195066674d66d1d7e191010fb1ff ] When handling error path, ret needs to be set to correct value. Reported-by: kernel test robot Reported-by: Dan Carpenter Fixes: d29d41e28eea ("ASoC: topology: Add support for multiple kcontrol types to a widget") Reviewed-by: Cezary Rojewski Signed-off-by: Amadeusz Sławiński Link: https://lore.kernel.org/r/20230207210428.2076354-1-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3b858f23cefb2398701459cf821b150523a791de Author: Shengjiu Wang Date: Tue Feb 7 17:04:24 2023 +0800 ASoC: fsl_sai: fix getting version from VERID [ Upstream commit 29aab38823b61e482995c24644bd2d8acfe56185 ] The version information is at the bit31 ~ bit16 in the VERID register, so need to right shift 16bit to get it, otherwise the result of comparison "sai->verid.version >= 0x0301" is wrong. Fixes: 99c1e74f25d4 ("ASoC: fsl_sai: store full version instead of major/minor") Signed-off-by: Shengjiu Wang Reviewed-by: Iuliana Prodan Reviewed-by: Fabio Estevam Link: https://lore.kernel.org/r/1675760664-25193-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 84560e33cea5d7f95e51a5a2ffff7525bbef5e94 Author: Daniel Beer Date: Thu Oct 27 21:38:38 2022 +1300 ASoC: tas5805m: add missing page switch. [ Upstream commit e0576cd642ced1ac65370b4516b7be9f536a0498 ] In tas5805m_refresh, we switch pages to update the DSP volume control, but we need to switch back to page 0 before trying to alter the soft-mute control. This latter page-switch was missing. Fixes: ec45268467f4 ("ASoC: add support for TAS5805M digital amplifier") Signed-off-by: Daniel Beer Link: https://lore.kernel.org/r/1fea38a71ea6ab0225d19ab28d1fa12828d762d0.1675497326.git.daniel.beer@igorinstitute.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3e984873e4ac2bcec2749a3d92506ba2a3f0ac95 Author: Daniel Beer Date: Thu Oct 27 21:28:31 2022 +1300 ASoC: tas5805m: rework to avoid scheduling while atomic. [ Upstream commit 147323792693bf013f60dca160be1d32bd4d180a ] There's some setup we need to do in order to get the DSP initialized, and this can't be done until a bit-clock is ready. In an earlier version of this driver, this work was done in a DAPM callback. The DAPM callback doesn't guarantee that the bit-clock is running, so the work was moved instead to the trigger callback. Unfortunately this callback runs in atomic context, and the setup code needs to do I2C transactions. Here we use a work_struct to kick off the setup in a thread instead. Fixes: ec45268467f4 ("ASoC: add support for TAS5805M digital amplifier") Signed-off-by: Daniel Beer Link: https://lore.kernel.org/r/85d8ba405cb009a7a3249b556dc8f3bdb1754fdf.1675497326.git.daniel.beer@igorinstitute.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0f3d5c12b612b0220f8d90982207bf1996e0f493 Author: Chen-Yu Tsai Date: Thu Feb 2 18:40:14 2023 +0800 arm64: dts: mediatek: mt8195: Fix vdosys* compatible strings [ Upstream commit 97801cfcf9565247bcc53b67ea47fa87b1704375 ] When vdosys1 was initially added, it was incorrectly assumed to be compatible with vdosys0, and thus both had the same mt8195-mmsys compatible attached. This has since been corrected in commit b237efd47df7 ("dt-bindings: arm: mediatek: mmsys: change compatible for MT8195") and commit 82219cfbef18 ("dt-bindings: arm: mediatek: mmsys: add vdosys1 compatible for MT8195"). The device tree needs to be fixed as well, otherwise the vdosys1 block fails to work, and causes its dependent power domain controller to not work either. Change the compatible string of vdosys1 to "mediatek,mt8195-vdosys1". While at it, also add the new "mediatek,mt8195-vdosys0" compatible to vdosys0. Fixes: 6aa5b46d1755 ("arm64: dts: mt8195: Add vdosys and vppsys clock nodes") Signed-off-by: Chen-Yu Tsai Tested-by: AngeloGioacchino Del Regno Reviewed-by: AngeloGioacchino Del Regno Acked-by: Matthias Brugger Link: https://lore.kernel.org/r/20230202104014.2931517-1-wenst@chromium.org Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 12773070b09b8be2a396881a09f377bc2660cfa2 Author: Liu Shixin Date: Wed Dec 7 10:50:38 2022 +0800 riscv: stacktrace: Fix missing the first frame [ Upstream commit cb80242cc679d6397e77d8a964deeb3ff218d2b5 ] When running kfence_test, I found some testcases failed like this: # test_out_of_bounds_read: EXPECTATION FAILED at mm/kfence/kfence_test.c:346 Expected report_matches(&expect) to be true, but is false not ok 1 - test_out_of_bounds_read The corresponding call-trace is: BUG: KFENCE: out-of-bounds read in kunit_try_run_case+0x38/0x84 Out-of-bounds read at 0x(____ptrval____) (32B right of kfence-#10): kunit_try_run_case+0x38/0x84 kunit_generic_run_threadfn_adapter+0x12/0x1e kthread+0xc8/0xde ret_from_exception+0x0/0xc The kfence_test using the first frame of call trace to check whether the testcase is succeed or not. Commit 6a00ef449370 ("riscv: eliminate unreliable __builtin_frame_address(1)") skip first frame for all case, which results the kfence_test failed. Indeed, we only need to skip the first frame for case (task==NULL || task==current). With this patch, the call-trace will be: BUG: KFENCE: out-of-bounds read in test_out_of_bounds_read+0x88/0x19e Out-of-bounds read at 0x(____ptrval____) (1B left of kfence-#7): test_out_of_bounds_read+0x88/0x19e kunit_try_run_case+0x38/0x84 kunit_generic_run_threadfn_adapter+0x12/0x1e kthread+0xc8/0xde ret_from_exception+0x0/0xc Fixes: 6a00ef449370 ("riscv: eliminate unreliable __builtin_frame_address(1)") Signed-off-by: Liu Shixin Tested-by: Samuel Holland Link: https://lore.kernel.org/r/20221207025038.1022045-1-liushixin2@huawei.com Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 885f729b249f371cd9a3eef3c27d6a33482f5a6c Author: Dan Carpenter Date: Tue Jan 31 13:02:13 2023 +0300 ALSA: pci: lx6464es: fix a debug loop [ Upstream commit 5dac9f8dc25fefd9d928b98f6477ff3daefd73e3 ] This loop accidentally reuses the "i" iterator for both the inside and the outside loop. The value of MAX_STREAM_BUFFER is 5. I believe that chip->rmh.stat_len is in the 2-12 range. If the value of .stat_len is 4 or more then it will loop exactly one time, but if it's less then it is a forever loop. It looks like it was supposed to combined into one loop where conditions are checked. Fixes: 8e6320064c33 ("ALSA: lx_core: Remove useless #if 0 .. #endif") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/Y9jnJTis/mRFJAQp@kili Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 65473ade50628fd4c798482eaca07d499aae3841 Author: Dan Johansen Date: Sat Jan 28 12:24:32 2023 +0100 arm64: dts: rockchip: set sdmmc0 speed to sd-uhs-sdr50 on rock-3a [ Upstream commit bc121b707e816616567683e51fd9194c2309977a ] As other rk336x based devices, the Rock 3 Model A has issues with high speed SD cards, so lower the speed to 50 instead of 104 in the same manor has the Quartz64 Model B has. Fixes: 22a442e6586c ("arm64: dts: rockchip: add basic dts for the radxa rock3 model a") Signed-off-by: Dan Johansen Link: https://lore.kernel.org/r/20230128112432.132302-1-strit@manjaro.org Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 10150d35091778beb5840b6a6ecf371e127f4e69 Author: Arnaud Ferraris Date: Thu Dec 15 11:19:47 2022 +0100 arm64: dts: rockchip: fix input enable pinconf on rk3399 [ Upstream commit 6f515b663d49a14fb63f8c5d0a2a4ae53d44790a ] When the input enable pinconf was introduced, a default drive-strength value of 2 was set for the pull up/down configs. However, this parameter is unneeded when configuring the pin as input, and having a single hardcoded value here is actually harmful: GPIOs on the RK3399 have various same drive-strength capabilities depending on the bank and port they belong to. As an example, trying to configure the GPIO4_PD3 pin as an input with pull-up enabled fails with the following output: [ 10.706542] rockchip-pinctrl pinctrl: unsupported driver strength 2 [ 10.713661] rockchip-pinctrl pinctrl: pin_config_set op failed for pin 155 (acceptable drive-strength values for this pin being 3, 6, 9 and 12) Let's drop the drive-strength property from all input pinconfs in order to solve this issue. Fixes: ec48c3e82ca3 ("arm64: dts: rockchip: add an input enable pinconf to rk3399") Signed-off-by: Arnaud Ferraris Reviewed-by: Caleb Connolly Link: https://lore.kernel.org/r/20221215101947.254896-1-arnaud.ferraris@collabora.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 81685c59dc4b8a790955b560fe47eec4f4f2d694 Author: Hangbin Liu Date: Wed Feb 8 11:21:10 2023 +0800 selftests: forwarding: lib: quote the sysctl values [ Upstream commit 3a082086aa200852545cf15159213582c0c80eba ] When set/restore sysctl value, we should quote the value as some keys may have multi values, e.g. net.ipv4.ping_group_range Fixes: f5ae57784ba8 ("selftests: forwarding: lib: Add sysctl_set(), sysctl_restore()") Signed-off-by: Hangbin Liu Reviewed-by: Petr Machata Link: https://lore.kernel.org/r/20230208032110.879205-1-liuhangbin@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 399f1cccc447546e77967cc957414bb1dd0f7b4e Author: Vladimir Oltean Date: Tue Feb 7 20:31:17 2023 +0200 net: mscc: ocelot: fix all IPv6 getting trapped to CPU when PTP timestamping is used [ Upstream commit 2fcde9fe258ec8b88d41def38e43ca4da32c0a9a ] While running this selftest which usually passes: ~/selftests/drivers/net/dsa# ./local_termination.sh eno0 swp0 TEST: swp0: Unicast IPv4 to primary MAC address [ OK ] TEST: swp0: Unicast IPv4 to macvlan MAC address [ OK ] TEST: swp0: Unicast IPv4 to unknown MAC address [ OK ] TEST: swp0: Unicast IPv4 to unknown MAC address, promisc [ OK ] TEST: swp0: Unicast IPv4 to unknown MAC address, allmulti [ OK ] TEST: swp0: Multicast IPv4 to joined group [ OK ] TEST: swp0: Multicast IPv4 to unknown group [ OK ] TEST: swp0: Multicast IPv4 to unknown group, promisc [ OK ] TEST: swp0: Multicast IPv4 to unknown group, allmulti [ OK ] TEST: swp0: Multicast IPv6 to joined group [ OK ] TEST: swp0: Multicast IPv6 to unknown group [ OK ] TEST: swp0: Multicast IPv6 to unknown group, promisc [ OK ] TEST: swp0: Multicast IPv6 to unknown group, allmulti [ OK ] if I start PTP timestamping then run it again (debug prints added by me), the unknown IPv6 MC traffic is seen by the CPU port even when it should have been dropped: ~/selftests/drivers/net/dsa# ptp4l -i swp0 -2 -P -m ptp4l[225.410]: selected /dev/ptp1 as PTP clock [ 225.445746] mscc_felix 0000:00:00.5: ocelot_l2_ptp_trap_add: port 0 adding L2 PTP trap [ 225.453815] mscc_felix 0000:00:00.5: ocelot_ipv4_ptp_trap_add: port 0 adding IPv4 PTP event trap [ 225.462703] mscc_felix 0000:00:00.5: ocelot_ipv4_ptp_trap_add: port 0 adding IPv4 PTP general trap [ 225.471768] mscc_felix 0000:00:00.5: ocelot_ipv6_ptp_trap_add: port 0 adding IPv6 PTP event trap [ 225.480651] mscc_felix 0000:00:00.5: ocelot_ipv6_ptp_trap_add: port 0 adding IPv6 PTP general trap ptp4l[225.488]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[225.488]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE ^C ~/selftests/drivers/net/dsa# ./local_termination.sh eno0 swp0 TEST: swp0: Unicast IPv4 to primary MAC address [ OK ] TEST: swp0: Unicast IPv4 to macvlan MAC address [ OK ] TEST: swp0: Unicast IPv4 to unknown MAC address [ OK ] TEST: swp0: Unicast IPv4 to unknown MAC address, promisc [ OK ] TEST: swp0: Unicast IPv4 to unknown MAC address, allmulti [ OK ] TEST: swp0: Multicast IPv4 to joined group [ OK ] TEST: swp0: Multicast IPv4 to unknown group [ OK ] TEST: swp0: Multicast IPv4 to unknown group, promisc [ OK ] TEST: swp0: Multicast IPv4 to unknown group, allmulti [ OK ] TEST: swp0: Multicast IPv6 to joined group [ OK ] TEST: swp0: Multicast IPv6 to unknown group [FAIL] reception succeeded, but should have failed TEST: swp0: Multicast IPv6 to unknown group, promisc [ OK ] TEST: swp0: Multicast IPv6 to unknown group, allmulti [ OK ] The PGID_MCIPV6 is configured correctly to not flood to the CPU, I checked that. Furthermore, when I disable back PTP RX timestamping (ptp4l doesn't do that when it exists), packets are RX filtered again as they should be: ~/selftests/drivers/net/dsa# hwstamp_ctl -i swp0 -r 0 [ 218.202854] mscc_felix 0000:00:00.5: ocelot_l2_ptp_trap_del: port 0 removing L2 PTP trap [ 218.212656] mscc_felix 0000:00:00.5: ocelot_ipv4_ptp_trap_del: port 0 removing IPv4 PTP event trap [ 218.222975] mscc_felix 0000:00:00.5: ocelot_ipv4_ptp_trap_del: port 0 removing IPv4 PTP general trap [ 218.233133] mscc_felix 0000:00:00.5: ocelot_ipv6_ptp_trap_del: port 0 removing IPv6 PTP event trap [ 218.242251] mscc_felix 0000:00:00.5: ocelot_ipv6_ptp_trap_del: port 0 removing IPv6 PTP general trap current settings: tx_type 1 rx_filter 12 new settings: tx_type 1 rx_filter 0 ~/selftests/drivers/net/dsa# ./local_termination.sh eno0 swp0 TEST: swp0: Unicast IPv4 to primary MAC address [ OK ] TEST: swp0: Unicast IPv4 to macvlan MAC address [ OK ] TEST: swp0: Unicast IPv4 to unknown MAC address [ OK ] TEST: swp0: Unicast IPv4 to unknown MAC address, promisc [ OK ] TEST: swp0: Unicast IPv4 to unknown MAC address, allmulti [ OK ] TEST: swp0: Multicast IPv4 to joined group [ OK ] TEST: swp0: Multicast IPv4 to unknown group [ OK ] TEST: swp0: Multicast IPv4 to unknown group, promisc [ OK ] TEST: swp0: Multicast IPv4 to unknown group, allmulti [ OK ] TEST: swp0: Multicast IPv6 to joined group [ OK ] TEST: swp0: Multicast IPv6 to unknown group [ OK ] TEST: swp0: Multicast IPv6 to unknown group, promisc [ OK ] TEST: swp0: Multicast IPv6 to unknown group, allmulti [ OK ] So it's clear that something in the PTP RX trapping logic went wrong. Looking a bit at the code, I can see that there are 4 typos, which populate "ipv4" VCAP IS2 key filter fields for IPv6 keys. VCAP IS2 keys of type OCELOT_VCAP_KEY_IPV4 and OCELOT_VCAP_KEY_IPV6 are handled by is2_entry_set(). OCELOT_VCAP_KEY_IPV4 looks at &filter->key.ipv4, and OCELOT_VCAP_KEY_IPV6 at &filter->key.ipv6. Simply put, when we populate the wrong key field, &filter->key.ipv6 fields "proto.mask" and "proto.value" remain all zeroes (or "don't care"). So is2_entry_set() will enter the "else" of this "if" condition: if (msk == 0xff && (val == IPPROTO_TCP || val == IPPROTO_UDP)) and proceed to ignore the "proto" field. The resulting rule will match on all IPv6 traffic, trapping it to the CPU. This is the reason why the local_termination.sh selftest sees it, because control traps are stronger than the PGID_MCIPV6 used for flooding (from the forwarding data path). But the problem is in fact much deeper. We trap all IPv6 traffic to the CPU, but if we're bridged, we set skb->offload_fwd_mark = 1, so software forwarding will not take place and IPv6 traffic will never reach its destination. The fix is simple - correct the typos. I was intentionally inaccurate in the commit message about the breakage occurring when any PTP timestamping is enabled. In fact it only happens when L4 timestamping is requested (HWTSTAMP_FILTER_PTP_V2_EVENT or HWTSTAMP_FILTER_PTP_V2_L4_EVENT). But ptp4l requests a larger RX timestamping filter than it needs for "-2": HWTSTAMP_FILTER_PTP_V2_EVENT. I wanted people skimming through git logs to not think that the bug doesn't affect them because they only use ptp4l in L2 mode. Fixes: 96ca08c05838 ("net: mscc: ocelot: set up traps for PTP packets") Signed-off-by: Vladimir Oltean Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/20230207183117.1745754-1-vladimir.oltean@nxp.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 1d52bbfd469af69fbcae88c67f160ce1b968e7f3 Author: Pietro Borrello Date: Tue Feb 7 18:26:34 2023 +0000 rds: rds_rm_zerocopy_callback() use list_first_entry() [ Upstream commit f753a68980cf4b59a80fe677619da2b1804f526d ] rds_rm_zerocopy_callback() uses list_entry() on the head of a list causing a type confusion. Use list_first_entry() to actually access the first element of the rs_zcookie_queue list. Fixes: 9426bbc6de99 ("rds: use list structure to track information for zerocopy completion notification") Reviewed-by: Willem de Bruijn Signed-off-by: Pietro Borrello Link: https://lore.kernel.org/r/20230202-rds-zerocopy-v3-1-83b0df974f9a@diag.uniroma1.it Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit da32c2d9f64b959145e86f9f2afdf974ea351be3 Author: Ido Schimmel Date: Tue Feb 7 16:18:19 2023 +0200 selftests: Fix failing VXLAN VNI filtering test [ Upstream commit b963d9d5b9437a6b99504987310f98537c9e77d4 ] iproute2 does not recognize the "group6" and "remote6" keywords. Fix by using "group" and "remote" instead. Before: # ./test_vxlan_vnifiltering.sh [...] Tests passed: 25 Tests failed: 2 After: # ./test_vxlan_vnifiltering.sh [...] Tests passed: 27 Tests failed: 0 Fixes: 3edf5f66c12a ("selftests: add new tests for vxlan vnifiltering") Signed-off-by: Ido Schimmel Reviewed-by: Alexander Duyck Link: https://lore.kernel.org/r/20230207141819.256689-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0ae9d81109e9bf3d0151df1f60632efb98ac497f Author: Kevin Yang Date: Tue Feb 7 02:08:20 2023 +0000 txhash: fix sk->sk_txrehash default [ Upstream commit c11204c78d6966c5bda6dd05c3ac5cbb193f93e3 ] This code fix a bug that sk->sk_txrehash gets its default enable value from sysctl_txrehash only when the socket is a TCP listener. We should have sysctl_txrehash to set the default sk->sk_txrehash, no matter TCP, nor listerner/connector. Tested by following packetdrill: 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 socket(..., SOCK_DGRAM, IPPROTO_UDP) = 4 // SO_TXREHASH == 74, default to sysctl_txrehash == 1 +0 getsockopt(3, SOL_SOCKET, 74, [1], [4]) = 0 +0 getsockopt(4, SOL_SOCKET, 74, [1], [4]) = 0 Fixes: 26859240e4ee ("txhash: Add socket option to control TX hash rethink behavior") Signed-off-by: Kevin Yang Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 44a265af4aa926bc60e45f7f6dd60c201aef6d62 Author: Tariq Toukan Date: Mon Feb 6 22:47:03 2023 +0200 net: ethernet: mtk_eth_soc: fix wrong parameters order in __xdp_rxq_info_reg() [ Upstream commit c966153d120222cd4e85e1e1601584d7d4d91dcb ] Parameters 'queue_index' and 'napi_id' are passed in a swapped order. Fix it here. Fixes: 23233e577ef9 ("net: ethernet: mtk_eth_soc: rely on page_pool for single page buffers") Signed-off-by: Tariq Toukan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5f9c656ab2c4c36f3b85819c7a9a8bec5711cfb5 Author: Sasha Neftin Date: Mon Feb 6 15:58:18 2023 -0800 igc: Add ndo_tx_timeout support [ Upstream commit 9b275176270efd18f2f4e328b32be1bad34c4c0d ] On some platforms, 100/1000/2500 speeds seem to have sometimes problems reporting false positive tx unit hang during stressful UDP traffic. Likely other Intel drivers introduce responses to a tx hang. Update the 'tx hang' comparator with the comparison of the head and tail of ring pointers and restore the tx_timeout_factor to the previous value (one). This can be test by using netperf or iperf3 applications. Example: iperf3 -s -p 5001 iperf3 -c 192.168.0.2 --udp -p 5001 --time 600 -b 0 netserver -p 16604 netperf -H 192.168.0.2 -l 600 -p 16604 -t UDP_STREAM -- -m 64000 Fixes: b27b8dc77b5e ("igc: Increase timeout value for Speed 100/1000/2500") Signed-off-by: Sasha Neftin Tested-by: Naama Meir Signed-off-by: Tony Nguyen Link: https://lore.kernel.org/r/20230206235818.662384-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 190296d51b4690e6175f25230ea53c8b2f7cdf64 Author: Shay Drory Date: Wed Dec 14 22:16:23 2022 +0200 net/mlx5: Serialize module cleanup with reload and remove [ Upstream commit 8f0d1451ecf7b3bd5a06ffc866c753d0f3ab4683 ] Currently, remove and reload flows can run in parallel to module cleanup. This design is error prone. For example: aux_drivers callbacks are called from both cleanup and remove flows with different lockings, which can cause a deadlock[1]. Hence, serialize module cleanup with reload and remove. [1] cleanup remove ------- ------ auxiliary_driver_unregister(); devl_lock() auxiliary_device_delete(mlx5e_aux) device_lock(mlx5e_aux) devl_lock() device_lock(mlx5e_aux) Fixes: 912cebf420c2 ("net/mlx5e: Connect ethernet part to auxiliary bus") Signed-off-by: Shay Drory Reviewed-by: Moshe Shemesh Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit b266f3158171b128b43b6ad32b32175edb05fc90 Author: Shay Drory Date: Wed Jan 25 17:39:36 2023 +0200 net/mlx5: fw_tracer, Zero consumer index when reloading the tracer [ Upstream commit 184e1e4474dbcfebc4dbd1fa823a329978f25506 ] When tracer is reloaded, the device will log the traces at the beginning of the log buffer. Also, driver is reading the log buffer in chunks in accordance to the consumer index. Hence, zero consumer index when reloading the tracer. Fixes: 4383cfcc65e7 ("net/mlx5: Add devlink reload") Signed-off-by: Shay Drory Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 525e29974e3ce3e5f61c66ee8f3eb97a0eccf892 Author: Shay Drory Date: Mon Jan 9 15:27:40 2023 +0200 net/mlx5: fw_tracer, Clear load bit when freeing string DBs buffers [ Upstream commit db561fed6b8fa3878e74d5df6512a4a38152b63e ] Whenever the driver is reading the string DBs into buffers, the driver is setting the load bit, but the driver never clears this bit. As a result, in case load bit is on and the driver query the device for new string DBs, the driver won't read again the string DBs. Fix it by clearing the load bit when query the device for new string DBs. Fixes: 2d69356752ff ("net/mlx5: Add support for fw live patch event") Signed-off-by: Shay Drory Reviewed-by: Moshe Shemesh Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit ee128b700fd0c6689785196577d00ec968857e8e Author: Maher Sanalla Date: Sun Jan 22 23:24:56 2023 +0200 net/mlx5: Expose SF firmware pages counter [ Upstream commit 9965bbebae59b3563a4d95e4aed121e8965dfdc2 ] Currently, each core device has VF pages counter which stores number of fw pages used by its VFs and SFs. The current design led to a hang when performing firmware reset on DPU, where the DPU PFs stalled in sriov unload flow due to waiting on release of SFs pages instead of waiting on only VFs pages. Thus, Add a separate counter for SF firmware pages, which will prevent the stall scenario described above. Fixes: 1958fc2f0712 ("net/mlx5: SF, Add auxiliary device driver") Signed-off-by: Maher Sanalla Reviewed-by: Shay Drory Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit bbdfebb08ff5eb67ae65539c8cbb728c8f246552 Author: Maher Sanalla Date: Sun Jan 22 21:09:40 2023 +0200 net/mlx5: Store page counters in a single array [ Upstream commit c3bdbaea654d8df39112de33037106134a520dc7 ] Currently, an independent page counter is used for tracking memory usage for each function type such as VF, PF and host PF (DPU). For better code-readibilty, use a single array that stores the number of allocated memory pages for each function type. Signed-off-by: Maher Sanalla Reviewed-by: Shay Drory Signed-off-by: Saeed Mahameed Stable-dep-of: 9965bbebae59 ("net/mlx5: Expose SF firmware pages counter") Signed-off-by: Sasha Levin commit 5ccc3707e97527d815e0fe1129b7f659828754b9 Author: Dragos Tatulea Date: Mon Jan 23 16:06:32 2023 +0200 net/mlx5e: IPoIB, Show unknown speed instead of error [ Upstream commit 8aa5f171d51c1cb69e5e3106df4dd1a446102823 ] ethtool is returning an error for unknown speeds for the IPoIB interface: $ ethtool ib0 netlink error: failed to retrieve link settings netlink error: Invalid argument netlink error: failed to retrieve link settings netlink error: Invalid argument Settings for ib0: Link detected: no After this change, ethtool will return success and show "unknown speed": $ ethtool ib0 Settings for ib0: Supported ports: [ ] Supported link modes: Not reported Supported pause frame use: No Supports auto-negotiation: No Supported FEC modes: Not reported Advertised link modes: Not reported Advertised pause frame use: No Advertised auto-negotiation: No Advertised FEC modes: Not reported Speed: Unknown! Duplex: Full Auto-negotiation: off Port: Other PHYAD: 0 Transceiver: internal Link detected: no Fixes: eb234ee9d541 ("net/mlx5e: IPoIB, Add support for get_link_ksettings in ethtool") Signed-off-by: Dragos Tatulea Reviewed-by: Gal Pressman Reviewed-by: Tariq Toukan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 026eb3e01a3dc67ff8313a0613f1f4f1f5ade428 Author: Amir Tzin Date: Sun Jan 8 15:54:46 2023 +0200 net/mlx5e: Fix crash unsetting rx-vlan-filter in switchdev mode [ Upstream commit 8974aa9638df557f4642acef707af15648a03555 ] Moving to switchdev mode with rx-vlan-filter on and then setting it off causes the kernel to crash since fs->vlan is freed during nic profile cleanup flow. RX VLAN filtering is not supported in switchdev mode so unset it when changing to switchdev and restore its value when switching back to legacy. trace: [] RIP: 0010:mlx5e_disable_cvlan_filter+0x43/0x70 [] set_feature_cvlan_filter+0x37/0x40 [mlx5_core] [] mlx5e_handle_feature+0x3a/0x60 [mlx5_core] [] mlx5e_set_features+0x6d/0x160 [mlx5_core] [] __netdev_update_features+0x288/0xa70 [] ethnl_set_features+0x309/0x380 [] ? __nla_parse+0x21/0x30 [] genl_family_rcv_msg_doit.isra.17+0x110/0x150 [] genl_rcv_msg+0x112/0x260 [] ? features_reply_size+0xe0/0xe0 [] ? genl_family_rcv_msg_doit.isra.17+0x150/0x150 [] netlink_rcv_skb+0x4e/0x100 [] genl_rcv+0x24/0x40 [] netlink_unicast+0x1ab/0x290 [] netlink_sendmsg+0x257/0x4f0 [] sock_sendmsg+0x5c/0x70 Fixes: cb67b832921c ("net/mlx5e: Introduce SRIOV VF representors") Signed-off-by: Amir Tzin Reviewed-by: Maor Dickman Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 1e9b6d279db1025dfd8dc425850e7ccc5d3a8547 Author: Vlad Buslov Date: Thu Jan 26 14:47:12 2023 +0100 net/mlx5: Bridge, fix ageing of peer FDB entries [ Upstream commit da0c52426cd23f8728eff72c2b2d2a3eb6b451f5 ] SWITCHDEV_FDB_ADD_TO_BRIDGE event handler that updates FDB entry 'lastuse' field is only executed for eswitch that owns the entry. However, if peer entry processed packets at least once it will have hardware counter 'used' value greater than entry 'lastuse' from that point on, which will cause FDB entry not being aged out. Process the event on all eswitch instances. Fixes: ff9b7521468b ("net/mlx5: Bridge, support LAG") Signed-off-by: Vlad Buslov Reviewed-by: Maor Dickman Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit aee099bb0cd4ee96bc9912df2c17e679ad306e5c Author: Adham Faris Date: Sun Jan 8 18:09:32 2023 +0200 net/mlx5e: Update rx ring hw mtu upon each rx-fcs flag change [ Upstream commit 1e66220948df815d7b37e0ff8b4627ce10433738 ] rq->hw_mtu is used in function en_rx.c/mlx5e_skb_from_cqe_mpwrq_linear() to catch oversized packets. If FCS is concatenated to the end of the packet then the check should be updated accordingly. Rx rings initialization (mlx5e_init_rxq_rq()) invoked for every new set of channels, as part of mlx5e_safe_switch_params(), unknowingly if it runs with default configuration or not. Current rq->hw_mtu initialization assumes default configuration and ignores params->scatter_fcs_en flag state. Fix this, by accounting for params->scatter_fcs_en flag state during rq->hw_mtu initialization. In addition, updating rq->hw_mtu value during ingress traffic might lead to packets drop and oversize_pkts_sw_drop counter increase with no good reason. Hence we remove this optimization and switch the set of channels with a new one, to make sure we don't get false positives on the oversize_pkts_sw_drop counter. Fixes: 102722fc6832 ("net/mlx5e: Add support for RXFCS feature flag") Signed-off-by: Adham Faris Reviewed-by: Tariq Toukan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 4d15289c22fa045ecda0b26a10f2d21bb5912c4f Author: Vladimir Oltean Date: Sun Feb 5 21:24:08 2023 +0200 net: mscc: ocelot: fix VCAP filters not matching on MAC with "protocol 802.1Q" [ Upstream commit f964f8399df29d3e3ced77177cf35131cd2491bf ] Alternative short title: don't instruct the hardware to match on EtherType with "protocol 802.1Q" flower filters. It doesn't work for the reasons detailed below. With a command such as the following: tc filter add dev $swp1 ingress chain $(IS1 2) pref 3 \ protocol 802.1Q flower skip_sw vlan_id 200 src_mac $h1_mac \ action vlan modify id 300 \ action goto chain $(IS2 0 0) the created filter is set by ocelot_flower_parse_key() to be of type OCELOT_VCAP_KEY_ETYPE, and etype is set to {value=0x8100, mask=0xffff}. This gets propagated all the way to is1_entry_set() which commits it to hardware (the VCAP_IS1_HK_ETYPE field of the key). Compare this to the case where src_mac isn't specified - the key type is OCELOT_VCAP_KEY_ANY, and is1_entry_set() doesn't populate VCAP_IS1_HK_ETYPE. The problem is that for VLAN-tagged frames, the hardware interprets the ETYPE field as holding the encapsulated VLAN protocol. So the above filter will only match those packets which have an encapsulated protocol of 0x8100, rather than all packets with VLAN ID 200 and the given src_mac. The reason why this is allowed to occur is because, although we have a block of code in ocelot_flower_parse_key() which sets "match_protocol" to false when VLAN keys are present, that code executes too late. There is another block of code, which executes for Ethernet addresses, and has a "goto finished_key_parsing" and skips the VLAN header parsing. By skipping it, "match_protocol" remains with the value it was initialized with, i.e. "true", and "proto" is set to f->common.protocol, or 0x8100. The concept of ignoring some keys rather than erroring out when they are present but can't be offloaded is dubious in itself, but is present since the initial commit fe3490e6107e ("net: mscc: ocelot: Hardware ofload for tc flower filter"), and it's outside of the scope of this patch to change that. The problem was introduced when the driver started to interpret the flower filter's protocol, and populate the VCAP filter's ETYPE field based on it. To fix this, it is sufficient to move the code that parses the VLAN keys earlier than the "goto finished_key_parsing" instruction. This will ensure that if we have a flower filter with both VLAN and Ethernet address keys, it won't match on ETYPE 0x8100, because the VLAN key parsing sets "match_protocol = false". Fixes: 86b956de119c ("net: mscc: ocelot: support matching on EtherType") Signed-off-by: Vladimir Oltean Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/20230205192409.1796428-1-vladimir.oltean@nxp.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 139c759823b066d8e85c9bce469ec0559fc9018e Author: Vladimir Oltean Date: Sun Feb 5 16:07:13 2023 +0200 net: dsa: mt7530: don't change PVC_EG_TAG when CPU port becomes VLAN-aware [ Upstream commit 0b6d6425103a676e2b6a81f3fd35d7ea4f9b90ec ] Frank reports that in a mt7530 setup where some ports are standalone and some are in a VLAN-aware bridge, 8021q uppers of the standalone ports lose their VLAN tag on xmit, as seen by the link partner. This seems to occur because once the other ports join the VLAN-aware bridge, mt7530_port_vlan_filtering() also calls mt7530_port_set_vlan_aware(ds, cpu_dp->index), and this affects the way that the switch processes the traffic of the standalone port. Relevant is the PVC_EG_TAG bit. The MT7530 documentation says about it: EG_TAG: Incoming Port Egress Tag VLAN Attribution 0: disabled (system default) 1: consistent (keep the original ingress tag attribute) My interpretation is that this setting applies on the ingress port, and "disabled" is basically the normal behavior, where the egress tag format of the packet (tagged or untagged) is decided by the VLAN table (MT7530_VLAN_EGRESS_UNTAG or MT7530_VLAN_EGRESS_TAG). But there is also an option of overriding the system default behavior, and for the egress tagging format of packets to be decided not by the VLAN table, but simply by copying the ingress tag format (if ingress was tagged, egress is tagged; if ingress was untagged, egress is untagged; aka "consistent). This is useful in 2 scenarios: - VLAN-unaware bridge ports will always encounter a miss in the VLAN table. They should forward a packet as-is, though. So we use "consistent" there. See commit e045124e9399 ("net: dsa: mt7530: fix tagged frames pass-through in VLAN-unaware mode"). - Traffic injected from the CPU port. The operating system is in god mode; if it wants a packet to exit as VLAN-tagged, it sends it as VLAN-tagged. Otherwise it sends it as VLAN-untagged*. *This is true only if we don't consider the bridge TX forwarding offload feature, which mt7530 doesn't support. So for now, make the CPU port always stay in "consistent" mode to allow software VLANs to be forwarded to their egress ports with the VLAN tag intact, and not stripped. Link: https://lore.kernel.org/netdev/trinity-e6294d28-636c-4c40-bb8b-b523521b00be-1674233135062@3c-app-gmx-bs36/ Fixes: e045124e9399 ("net: dsa: mt7530: fix tagged frames pass-through in VLAN-unaware mode") Reported-by: Frank Wunderlich Tested-by: Frank Wunderlich Signed-off-by: Vladimir Oltean Tested-by: Arınç ÜNAL Reviewed-by: Florian Fainelli Link: https://lore.kernel.org/r/20230205140713.1609281-1-vladimir.oltean@nxp.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 47f4ff6f23f00f5501ff2d7054c1a37c170a7aa0 Author: Zhang Changzhong Date: Mon Dec 12 15:11:26 2022 -0800 ice: switch: fix potential memleak in ice_add_adv_recipe() [ Upstream commit 4a606ce68426c88ff2563382b33cc34f3485fe57 ] When ice_add_special_words() fails, the 'rm' is not released, which will lead to a memory leak. Fix this up by going to 'err_unroll' label. Compile tested only. Fixes: 8b032a55c1bd ("ice: low level support for tunnels") Signed-off-by: Zhang Changzhong Tested-by: Sujai Buvaneswaran Signed-off-by: Tony Nguyen Reviewed-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 8eeca43d8e7e34c06ff0a2d97f1d7f9a82a70423 Author: Brett Creeley Date: Mon Jan 16 13:34:58 2023 +0100 ice: Fix disabling Rx VLAN filtering with port VLAN enabled [ Upstream commit c793f8ea15e312789b5b6b4a5e7b0b92315be5cb ] If the user turns on the vf-true-promiscuous-support flag, then Rx VLAN filtering will be disabled if the VF requests to enable promiscuous mode. When the VF is in a port VLAN, this is the incorrect behavior because it will allow the VF to receive traffic outside of its port VLAN domain. Fortunately this only resulted in the VF(s) receiving broadcast traffic outside of the VLAN domain because all of the VLAN promiscuous rules are based on the port VLAN ID. Fix this by setting the .disable_rx_filtering VLAN op to a no-op when a port VLAN is enabled on the VF. Also, make sure to make this fix for both Single VLAN Mode and Double VLAN Mode enabled devices. Fixes: c31af68a1b94 ("ice: Add outer_vlan_ops and VSI specific VLAN ops implementations") Signed-off-by: Brett Creeley Signed-off-by: Karen Ostrowska Tested-by: Marek Szlosek Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit df59e05401450973c8c7e96fd74b49e24442dc1f Author: Anirudh Venkataramanan Date: Mon Jan 30 14:06:40 2023 -0800 ice: Do not use WQ_MEM_RECLAIM flag for workqueue [ Upstream commit 4d159f7884f78b1aacb99b4fc37d1e3cb1194e39 ] When both ice and the irdma driver are loaded, a warning in check_flush_dependency is being triggered. This is due to ice driver workqueue being allocated with the WQ_MEM_RECLAIM flag and the irdma one is not. According to kernel documentation, this flag should be set if the workqueue will be involved in the kernel's memory reclamation flow. Since it is not, there is no need for the ice driver's WQ to have this flag set so remove it. Example trace: [ +0.000004] workqueue: WQ_MEM_RECLAIM ice:ice_service_task [ice] is flushing !WQ_MEM_RECLAIM infiniband:0x0 [ +0.000139] WARNING: CPU: 0 PID: 728 at kernel/workqueue.c:2632 check_flush_dependency+0x178/0x1a0 [ +0.000011] Modules linked in: bonding tls xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_cha in_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink bridge stp llc rfkill vfat fat intel_rapl_msr intel _rapl_common isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct1 0dif_pclmul crc32_pclmul ghash_clmulni_intel rapl intel_cstate rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_ core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_cm iw_cm iTCO_wdt iTCO_vendor_support ipmi_ssif irdma mei_me ib_uverbs ib_core intel_uncore joydev pcspkr i2c_i801 acpi_ipmi mei lpc_ich i2c_smbus intel_pch_thermal ioatdma ipmi_si acpi_power_meter acpi_pad xfs libcrc32c sd_mod t10_pi crc64_rocksoft crc64 sg ahci ixgbe libahci ice i40e igb crc32c_intel mdio i2c_algo_bit liba ta dca wmi dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse [ +0.000161] [last unloaded: bonding] [ +0.000006] CPU: 0 PID: 728 Comm: kworker/0:2 Tainted: G S 6.2.0-rc2_next-queue-13jan-00458-gc20aabd57164 #1 [ +0.000006] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0010.010620200716 01/06/2020 [ +0.000003] Workqueue: ice ice_service_task [ice] [ +0.000127] RIP: 0010:check_flush_dependency+0x178/0x1a0 [ +0.000005] Code: 89 8e 02 01 e8 49 3d 40 00 49 8b 55 18 48 8d 8d d0 00 00 00 48 8d b3 d0 00 00 00 4d 89 e0 48 c7 c7 e0 3b 08 9f e8 bb d3 07 01 <0f> 0b e9 be fe ff ff 80 3d 24 89 8e 02 00 0f 85 6b ff ff ff e9 06 [ +0.000004] RSP: 0018:ffff88810a39f990 EFLAGS: 00010282 [ +0.000005] RAX: 0000000000000000 RBX: ffff888141bc2400 RCX: 0000000000000000 [ +0.000004] RDX: 0000000000000001 RSI: dffffc0000000000 RDI: ffffffffa1213a80 [ +0.000003] RBP: ffff888194bf3400 R08: ffffed117b306112 R09: ffffed117b306112 [ +0.000003] R10: ffff888bd983088b R11: ffffed117b306111 R12: 0000000000000000 [ +0.000003] R13: ffff888111f84d00 R14: ffff88810a3943ac R15: ffff888194bf3400 [ +0.000004] FS: 0000000000000000(0000) GS:ffff888bd9800000(0000) knlGS:0000000000000000 [ +0.000003] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.000003] CR2: 000056035b208b60 CR3: 000000017795e005 CR4: 00000000007706f0 [ +0.000003] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ +0.000003] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ +0.000002] PKRU: 55555554 [ +0.000003] Call Trace: [ +0.000002] [ +0.000003] __flush_workqueue+0x203/0x840 [ +0.000006] ? mutex_unlock+0x84/0xd0 [ +0.000008] ? __pfx_mutex_unlock+0x10/0x10 [ +0.000004] ? __pfx___flush_workqueue+0x10/0x10 [ +0.000006] ? mutex_lock+0xa3/0xf0 [ +0.000005] ib_cache_cleanup_one+0x39/0x190 [ib_core] [ +0.000174] __ib_unregister_device+0x84/0xf0 [ib_core] [ +0.000094] ib_unregister_device+0x25/0x30 [ib_core] [ +0.000093] irdma_ib_unregister_device+0x97/0xc0 [irdma] [ +0.000064] ? __pfx_irdma_ib_unregister_device+0x10/0x10 [irdma] [ +0.000059] ? up_write+0x5c/0x90 [ +0.000005] irdma_remove+0x36/0x90 [irdma] [ +0.000062] auxiliary_bus_remove+0x32/0x50 [ +0.000007] device_release_driver_internal+0xfa/0x1c0 [ +0.000005] bus_remove_device+0x18a/0x260 [ +0.000007] device_del+0x2e5/0x650 [ +0.000005] ? __pfx_device_del+0x10/0x10 [ +0.000003] ? mutex_unlock+0x84/0xd0 [ +0.000004] ? __pfx_mutex_unlock+0x10/0x10 [ +0.000004] ? _raw_spin_unlock+0x18/0x40 [ +0.000005] ice_unplug_aux_dev+0x52/0x70 [ice] [ +0.000160] ice_service_task+0x1309/0x14f0 [ice] [ +0.000134] ? __pfx___schedule+0x10/0x10 [ +0.000006] process_one_work+0x3b1/0x6c0 [ +0.000008] worker_thread+0x69/0x670 [ +0.000005] ? __kthread_parkme+0xec/0x110 [ +0.000007] ? __pfx_worker_thread+0x10/0x10 [ +0.000005] kthread+0x17f/0x1b0 [ +0.000005] ? __pfx_kthread+0x10/0x10 [ +0.000004] ret_from_fork+0x29/0x50 [ +0.000009] Fixes: 940b61af02f4 ("ice: Initialize PF and setup miscellaneous interrupt") Signed-off-by: Anirudh Venkataramanan Signed-off-by: Marcin Szycik Tested-by: Jakub Andrysiak Signed-off-by: Tony Nguyen Reviewed-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 437f8892ece746821f824e29f826e610a596054f Author: Dave Airlie Date: Mon Feb 6 07:05:28 2023 +1000 nvidiafb: detect the hardware support before removing console. [ Upstream commit 04119ab1a49fc41cb70f0472be5455af268fa260 ] This driver removed the console, but hasn't yet decided if it could take over the console yet. Instead of doing that, probe the hw for support and then remove the console afterwards. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216859 Fixes: 145eed48de27 ("fbdev: Remove conflicting devices on PCI bus") Reported-by: Zeno Davatz Tested-by: Zeno Davatz Tested-by: Thomas Zimmermann Reviewed-by: Thomas Zimmermann Signed-off-by: Dave Airlie Link: https://patchwork.freedesktop.org/patch/msgid/20230205210751.3842103-1-airlied@gmail.com Signed-off-by: Sasha Levin commit c47c2b173d0cd027897fbeb3b80b840d2c775f6e Author: Will Deacon Date: Tue Jan 31 22:17:19 2023 +0000 cpuset: Call set_cpus_allowed_ptr() with appropriate mask for task [ Upstream commit 7a2127e66a00e073db8d90f9aac308f4a8a64226 ] set_cpus_allowed_ptr() will fail with -EINVAL if the requested affinity mask is not a subset of the task_cpu_possible_mask() for the task being updated. Consequently, on a heterogeneous system with cpusets spanning the different CPU types, updates to the cgroup hierarchy can silently fail to update task affinities when the effective affinity mask for the cpuset is expanded. For example, consider an arm64 system with 4 CPUs, where CPUs 2-3 are the only cores capable of executing 32-bit tasks. Attaching a 32-bit task to a cpuset containing CPUs 0-2 will correctly affine the task to CPU 2. Extending the cpuset to CPUs 0-3, however, will fail to extend the affinity mask of the 32-bit task because update_tasks_cpumask() will pass the full 0-3 mask to set_cpus_allowed_ptr(). Extend update_tasks_cpumask() to take a temporary 'cpumask' paramater and use it to mask the 'effective_cpus' mask with the possible mask for each task being updated. Fixes: 431c69fac05b ("cpuset: Honour task_cpu_possible_mask() in guarantee_online_cpus()") Signed-off-by: Will Deacon Acked-by: Waiman Long Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 5489930113dc9dbdd12c947591e981bb0afa1d59 Author: Ryan Neph Date: Fri Feb 3 15:33:44 2023 -0800 drm/virtio: exbuf->fence_fd unmodified on interrupted wait [ Upstream commit 8f20660f053cefd4693e69cfff9cf58f4f7c4929 ] An interrupted dma_fence_wait() becomes an -ERESTARTSYS returned to userspace ioctl(DRM_IOCTL_VIRTGPU_EXECBUFFER) calls, prompting to retry the ioctl(), but the passed exbuf->fence_fd has been reset to -1, making the retry attempt fail at sync_file_get_fence(). The uapi for DRM_IOCTL_VIRTGPU_EXECBUFFER is changed to retain the passed value for exbuf->fence_fd when returning anything besides a successful result from the ioctl. Fixes: 2cd7b6f08bc4 ("drm/virtio: add in/out fence support for explicit synchronization") Signed-off-by: Ryan Neph Reviewed-by: Rob Clark Reviewed-by: Dmitry Osipenko Signed-off-by: Dmitry Osipenko Link: https://patchwork.freedesktop.org/patch/msgid/20230203233345.2477767-1-ryanneph@chromium.org Signed-off-by: Sasha Levin commit d05b72328810897a28fe313735481789edfef7e4 Author: Ville Syrjälä Date: Tue Jan 31 02:21:24 2023 +0200 drm/i915: Don't do the WM0->WM1 copy w/a if WM1 is already enabled [ Upstream commit 90d5e8301ac24550be80d193aa5582cab56c29fc ] Due to a workaround we have to make sure the WM1 watermarks block/lines values are sensible even when WM1 is disabled. To that end we copy those values from WM0. However since we now keep each wm level enabled on a per-plane basis it doesn't seem necessary to do that copy when we already have an enabled WM1 on the current plane. That is, we might be in a situation where another plane can only do WM0 (and thus needs the copy) but the current plane's WM1 is still perfectly valid (ie. fits into the current DDB allocation). Skipping the copy could avoid reprogramming the plane's registers needlessly in some cases. Fixes: a301cb0fca2d ("drm/i915: Keep plane watermarks enabled more aggressively") Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20230131002127.29305-1-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy (cherry picked from commit c580c2d27ac8754cc6f01da1d715b7272f5f9cbb) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 16da5f6d38ac35a2b598df5acf45b03c2eb1211a Author: Mario Limonciello Date: Fri Feb 3 16:08:49 2023 -0600 HID: amd_sfh: if no sensors are enabled, clean up [ Upstream commit 7bcfdab3f0c6672ca52be3cb65a0550d8b99554b ] It was reported that commit b300667b33b2 ("HID: amd_sfh: Disable the interrupt for all command") had caused increased resume time on HP Envy x360. Before this commit 3 sensors were reported, but they were not actually functional. After this commit the sensors are no longer reported, but also the resume time increased. To avoid this problem explicitly look for the number of disabled sensors. If all the sensors are disabled, clean everything up. Fixes: b300667b33b2 ("HID: amd_sfh: Disable the interrupt for all command") Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2115 Reported-by: Xaver Hugl Signed-off-by: Mario Limonciello Acked-by: Basavaraj Natikar Link: https://lore.kernel.org/r/20230203220850.13924-1-mario.limonciello@amd.com Signed-off-by: Benjamin Tissoires Signed-off-by: Sasha Levin commit c0eb3c0cdd1bb6501ad72521b13d3b3316e038e9 Author: Casper Andersson Date: Fri Feb 3 09:55:57 2023 +0100 net: microchip: sparx5: fix PTP init/deinit not checking all ports [ Upstream commit d7d94b2612f5dc25d61dc7bf58aafe7b31f40191 ] Check all ports instead of just port_count ports. PTP init was only checking ports 0 to port_count. If the hardware ports are not mapped starting from 0 then they would be missed, e.g. if only ports 20-30 were mapped it would attempt to init ports 0-10, resulting in NULL pointers when attempting to timestamp. Now it will init all mapped ports. Fixes: 70dfe25cd866 ("net: sparx5: Update extraction/injection for timestamping") Signed-off-by: Casper Andersson Reviewed-by: Horatiu Vultur Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 89c0c69fc7398f3ea3bc900a7ae3cab0c8c97f4e Author: Herton R. Krzesinski Date: Fri Feb 3 13:04:48 2023 -0300 uapi: add missing ip/ipv6 header dependencies for linux/stddef.h [ Upstream commit 03702d4d29be4e2510ec80b248dbbde4e57030d9 ] Since commit 58e0be1ef6118 ("net: use struct_group to copy ip/ipv6 header addresses"), ip and ipv6 headers started to use the __struct_group definition, which is defined at include/uapi/linux/stddef.h. However, linux/stddef.h isn't explicitly included in include/uapi/linux/{ip,ipv6}.h, which breaks build of xskxceiver bpf selftest if you install the uapi headers in the system: $ make V=1 xskxceiver -C tools/testing/selftests/bpf ... make: Entering directory '(...)/tools/testing/selftests/bpf' gcc -g -O0 -rdynamic -Wall -Werror (...) In file included from xskxceiver.c:79: /usr/include/linux/ip.h:103:9: error: expected specifier-qualifier-list before ‘__struct_group’ 103 | __struct_group(/* no tag */, addrs, /* no attrs */, | ^~~~~~~~~~~~~~ ... Include the missing dependency in ip.h and do the same for the ipv6.h header. Fixes: 58e0be1ef611 ("net: use struct_group to copy ip/ipv6 header addresses") Signed-off-by: Herton R. Krzesinski Reviewed-by: Carlos O'Donell Tested-by: Carlos O'Donell Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c97c7c3103a3ebe30ae215a2f5fee1a45430b973 Author: Douglas Anderson Date: Thu Feb 2 14:00:23 2023 -0800 cpufreq: qcom-hw: Fix cpufreq_driver->get() for non-LMH systems [ Upstream commit 51be2fffd65d9f9cb427030ab0ee85d791b4437d ] On a sc7180-based Chromebook, when I go to /sys/devices/system/cpu/cpu0/cpufreq I can see: cpuinfo_cur_freq:2995200 cpuinfo_max_freq:1804800 scaling_available_frequencies:300000 576000 ... 1708800 1804800 scaling_cur_freq:1804800 scaling_max_freq:1804800 As you can see the `cpuinfo_cur_freq` is bogus. It turns out that this bogus info started showing up as of commit c72cf0cb1d77 ("cpufreq: qcom-hw: Fix the frequency returned by cpufreq_driver->get()"). That commit seems to assume that everyone is on the LMH bandwagon, but sc7180 isn't. Let's go back to the old code in the case where LMH isn't used. Fixes: c72cf0cb1d77 ("cpufreq: qcom-hw: Fix the frequency returned by cpufreq_driver->get()") Signed-off-by: Douglas Anderson Reviewed-by: Konrad Dybcio Reviewed-by: Manivannan Sadhasivam [ Viresh: Fixed the 'fixes' tag ] Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 07154f94c213d59f73ef7ca2e7f60379714816a9 Author: Allen Hubbe Date: Thu Feb 2 13:55:37 2023 -0800 ionic: missed doorbell workaround [ Upstream commit b69585bfceceeffda940906cabfdaee4b47bde92 ] In one version of the HW there is a remote possibility that it will miss the doorbell ring. This adds a bit of protection to be sure we don't stall a queue from a missed doorbell. Fixes: 0f3154e6bcb3 ("ionic: Add Tx and Rx handling") Signed-off-by: Allen Hubbe Signed-off-by: Shannon Nelson Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a16f6ea194fe0ea24c05fa51c46cd1dc38c7380d Author: Neel Patel Date: Wed Oct 26 07:37:44 2022 -0700 ionic: refactor use of ionic_rx_fill() [ Upstream commit e55f0f5befc26e2ba6bb8c1f945ea8e37ee0e334 ] The same pre-work code is used before each call to ionic_rx_fill(), so bring it in and make it a part of the routine. Signed-off-by: Neel Patel Signed-off-by: Shannon Nelson Signed-off-by: Jakub Kicinski Stable-dep-of: b69585bfcece ("ionic: missed doorbell workaround") Signed-off-by: Sasha Levin commit db34b5352e92155cdb8f4566469343526b2eeb1b Author: Neel Patel Date: Thu Feb 2 13:55:35 2023 -0800 ionic: clean interrupt before enabling queue to avoid credit race [ Upstream commit e8797a058466b60fc5a3291b92430c93ba90eaff ] Clear the interrupt credits before enabling the queue rather than after to be sure that the enabled queue starts at 0 and that we don't wipe away possible credits after enabling the queue. Fixes: 0f3154e6bcb3 ("ionic: Add Tx and Rx handling") Signed-off-by: Neel Patel Signed-off-by: Shannon Nelson Reviewed-by: Leon Romanovsky Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 95e29c11abe566e814aec9802581916def981a41 Author: Heiner Kallweit Date: Thu Feb 2 21:45:36 2023 +0100 net: phy: meson-gxl: use MMD access dummy stubs for GXL, internal PHY [ Upstream commit 69ff53e4a4c9498eeed7d1441f68a1481dc69251 ] Jerome provided the information that also the GXL internal PHY doesn't support MMD register access and EEE. MMD reads return 0xffff, what results in e.g. completely wrong ethtool --show-eee output. Therefore use the MMD dummy stubs. Fixes: d853d145ea3e ("net: phy: add an option to disable EEE advertisement") Suggested-by: Jerome Brunet Signed-off-by: Heiner Kallweit Link: https://lore.kernel.org/r/84432fe4-0be4-bc82-4e5c-557206b40f56@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9c6a896b8d40da37ac22ee2ef821b241698977f6 Author: Radhey Shyam Pandey Date: Thu Feb 2 17:56:19 2023 +0530 net: macb: Perform zynqmp dynamic configuration only for SGMII interface [ Upstream commit c9011b028e956c3b6baa6f131d9eec43e4e52020 ] In zynqmp platforms where firmware supports dynamic SGMII configuration but has other non-SGMII ethernet devices, it fails them with no packets received at the RX interface. To fix this behaviour perform SGMII dynamic configuration only for the SGMII phy interface. Fixes: 32cee7818111 ("net: macb: Add zynqmp SGMII dynamic configuration support") Signed-off-by: Radhey Shyam Pandey Reviewed-by: Jiri Pirko Reported-by: Michal Simek Tested-by: Michal Simek Reviewed-by: Claudiu Beznea Link: https://lore.kernel.org/r/1675340779-27499-1-git-send-email-radhey.shyam.pandey@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d974330c1d9915ae0940828df779fa8b0cfbb80c Author: Qi Zheng Date: Thu Feb 2 17:32:55 2023 +0800 bonding: fix error checking in bond_debug_reregister() [ Upstream commit cbe83191d40d8925b7a99969d037d2a0caf69294 ] Since commit ff9fb72bc077 ("debugfs: return error values, not NULL") changed return value of debugfs_rename() in error cases from %NULL to %ERR_PTR(-ERROR), we should also check error values instead of NULL. Fixes: ff9fb72bc077 ("debugfs: return error values, not NULL") Signed-off-by: Qi Zheng Acked-by: Jay Vosburgh Link: https://lore.kernel.org/r/20230202093256.32458-1-zhengqi.arch@bytedance.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a65723e299dc0fea45d8160590f8c0e109405579 Author: Clément Léger Date: Tue Jan 31 11:02:42 2023 +0100 net: phylink: move phy_device_free() to correctly release phy device [ Upstream commit ce93fdb5f2ca5c9e2a9668411cc39091507f8dc9 ] After calling fwnode_phy_find_device(), the phy device refcount is incremented. Then, when the phy device is attached to a netdev with phy_attach_direct(), the refcount is also incremented but only decremented in the caller if phy_attach_direct() fails. Move phy_device_free() before the "if" to always release it correctly. Indeed, either phy_attach_direct() failed and we don't want to keep a reference to the phydev or it succeeded and a reference has been taken internally. Fixes: 25396f680dd6 ("net: phylink: introduce phylink_fwnode_phy_connect()") Signed-off-by: Clément Léger Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a7f0ec26cd67e7ad6e56753694fddb67a9730f27 Author: Michal Suchanek Date: Wed Feb 1 10:22:47 2023 -0600 of: Make OF framebuffer device names unique [ Upstream commit 241d2fb56a18473af5f2ff0d512992a996eb64dd ] Since Linux 5.19 this error is observed: sysfs: cannot create duplicate filename '/devices/platform/of-display' This is because multiple devices with the same name 'of-display' are created on the same bus. Update the code to create numbered device names for the displays. Also, fix a node refcounting issue when exiting the boot display loop. cc: linuxppc-dev@lists.ozlabs.org References: https://bugzilla.kernel.org/show_bug.cgi?id=216095 Fixes: 52b1b46c39ae ("of: Create platform devices for OF framebuffers") Reported-by: Erhard F. Suggested-by: Thomas Zimmermann Signed-off-by: Michal Suchanek Link: https://lore.kernel.org/r/20230201162247.3575506-1-robh@kernel.org [robh: Rework to avoid node refcount leaks] Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit 5954eaab6bb70aff29fbdc9ae991ed68c7b7331f Author: Christian Hopps Date: Thu Jan 26 11:33:50 2023 -0500 xfrm: fix bug with DSCP copy to v6 from v4 tunnel [ Upstream commit 6028da3f125fec34425dbd5fec18e85d372b2af6 ] When copying the DSCP bits for decap-dscp into IPv6 don't assume the outer encap is always IPv6. Instead, as with the inner IPv4 case, copy the DSCP bits from the correctly saved "tos" value in the control block. Fixes: 227620e29509 ("[IPSEC]: Separate inner/outer mode processing on input") Signed-off-by: Christian Hopps Acked-by: Herbert Xu Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit d53903cc2396e0c18ab5e60f47f7cf7c10f5e492 Author: Yang Yingliang Date: Sun Jan 29 17:37:57 2023 +0800 RDMA/usnic: use iommu_map_atomic() under spin_lock() [ Upstream commit b7e08a5a63a11627601915473c3b569c1f6c6c06 ] usnic_uiom_map_sorted_intervals() is called under spin_lock(), iommu_map() might sleep, use iommu_map_atomic() to avoid potential sleep in atomic context. Fixes: e3cf00d0a87f ("IB/usnic: Add Cisco VIC low-level hardware driver") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20230129093757.637354-1-yangyingliang@huawei.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 360682fe7df262d94fae54f737c487bec0f9190d Author: Nikita Zhandarovich Date: Thu Jan 26 10:52:30 2023 -0800 RDMA/irdma: Fix potential NULL-ptr-dereference [ Upstream commit 5d9745cead1f121974322b94ceadfb4d1e67960e ] in_dev_get() can return NULL which will cause a failure once idev is dereferenced in in_dev_for_each_ifa_rtnl(). This patch adds a check for NULL value in idev beforehand. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 146b9756f14c ("RDMA/irdma: Add connection manager") Signed-off-by: Nikita Zhandarovich Link: https://lore.kernel.org/r/20230126185230.62464-1-n.zhandarovich@fintech.ru Reviewed-by: Sindhu Devale Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit f6d8b6762bee15551e538eef021b93477634d38f Author: Eric Dumazet Date: Thu Jan 26 11:21:30 2023 +0000 xfrm: annotate data-race around use_time [ Upstream commit 0a9e5794b21e2d1303759ff8fe5f9215db7757ba ] KCSAN reported multiple cpus can update use_time at the same time. Adds READ_ONCE()/WRITE_ONCE() annotations. Note that 32bit arches are not fully protected, but they will probably no longer be supported/used in 2106. BUG: KCSAN: data-race in __xfrm_policy_check / __xfrm_policy_check write to 0xffff88813e7ec108 of 8 bytes by interrupt on cpu 0: __xfrm_policy_check+0x6ae/0x17f0 net/xfrm/xfrm_policy.c:3664 __xfrm_policy_check2 include/net/xfrm.h:1174 [inline] xfrm_policy_check include/net/xfrm.h:1179 [inline] xfrm6_policy_check+0x2e9/0x320 include/net/xfrm.h:1189 udpv6_queue_rcv_one_skb+0x48/0xa30 net/ipv6/udp.c:703 udpv6_queue_rcv_skb+0x2d6/0x310 net/ipv6/udp.c:792 udp6_unicast_rcv_skb+0x16b/0x190 net/ipv6/udp.c:935 __udp6_lib_rcv+0x84b/0x9b0 net/ipv6/udp.c:1020 udpv6_rcv+0x4b/0x50 net/ipv6/udp.c:1133 ip6_protocol_deliver_rcu+0x99e/0x1020 net/ipv6/ip6_input.c:439 ip6_input_finish net/ipv6/ip6_input.c:484 [inline] NF_HOOK include/linux/netfilter.h:302 [inline] ip6_input+0xca/0x180 net/ipv6/ip6_input.c:493 dst_input include/net/dst.h:454 [inline] ip6_rcv_finish+0x1e9/0x2d0 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:302 [inline] ipv6_rcv+0x85/0x140 net/ipv6/ip6_input.c:309 __netif_receive_skb_one_core net/core/dev.c:5482 [inline] __netif_receive_skb+0x8b/0x1b0 net/core/dev.c:5596 process_backlog+0x23f/0x3b0 net/core/dev.c:5924 __napi_poll+0x65/0x390 net/core/dev.c:6485 napi_poll net/core/dev.c:6552 [inline] net_rx_action+0x37e/0x730 net/core/dev.c:6663 __do_softirq+0xf2/0x2c7 kernel/softirq.c:571 do_softirq+0xb1/0xf0 kernel/softirq.c:472 __local_bh_enable_ip+0x6f/0x80 kernel/softirq.c:396 __raw_read_unlock_bh include/linux/rwlock_api_smp.h:257 [inline] _raw_read_unlock_bh+0x17/0x20 kernel/locking/spinlock.c:284 wg_socket_send_skb_to_peer+0x107/0x120 drivers/net/wireguard/socket.c:184 wg_packet_create_data_done drivers/net/wireguard/send.c:251 [inline] wg_packet_tx_worker+0x142/0x360 drivers/net/wireguard/send.c:276 process_one_work+0x3d3/0x720 kernel/workqueue.c:2289 worker_thread+0x618/0xa70 kernel/workqueue.c:2436 kthread+0x1a9/0x1e0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 write to 0xffff88813e7ec108 of 8 bytes by interrupt on cpu 1: __xfrm_policy_check+0x6ae/0x17f0 net/xfrm/xfrm_policy.c:3664 __xfrm_policy_check2 include/net/xfrm.h:1174 [inline] xfrm_policy_check include/net/xfrm.h:1179 [inline] xfrm6_policy_check+0x2e9/0x320 include/net/xfrm.h:1189 udpv6_queue_rcv_one_skb+0x48/0xa30 net/ipv6/udp.c:703 udpv6_queue_rcv_skb+0x2d6/0x310 net/ipv6/udp.c:792 udp6_unicast_rcv_skb+0x16b/0x190 net/ipv6/udp.c:935 __udp6_lib_rcv+0x84b/0x9b0 net/ipv6/udp.c:1020 udpv6_rcv+0x4b/0x50 net/ipv6/udp.c:1133 ip6_protocol_deliver_rcu+0x99e/0x1020 net/ipv6/ip6_input.c:439 ip6_input_finish net/ipv6/ip6_input.c:484 [inline] NF_HOOK include/linux/netfilter.h:302 [inline] ip6_input+0xca/0x180 net/ipv6/ip6_input.c:493 dst_input include/net/dst.h:454 [inline] ip6_rcv_finish+0x1e9/0x2d0 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:302 [inline] ipv6_rcv+0x85/0x140 net/ipv6/ip6_input.c:309 __netif_receive_skb_one_core net/core/dev.c:5482 [inline] __netif_receive_skb+0x8b/0x1b0 net/core/dev.c:5596 process_backlog+0x23f/0x3b0 net/core/dev.c:5924 __napi_poll+0x65/0x390 net/core/dev.c:6485 napi_poll net/core/dev.c:6552 [inline] net_rx_action+0x37e/0x730 net/core/dev.c:6663 __do_softirq+0xf2/0x2c7 kernel/softirq.c:571 do_softirq+0xb1/0xf0 kernel/softirq.c:472 __local_bh_enable_ip+0x6f/0x80 kernel/softirq.c:396 __raw_read_unlock_bh include/linux/rwlock_api_smp.h:257 [inline] _raw_read_unlock_bh+0x17/0x20 kernel/locking/spinlock.c:284 wg_socket_send_skb_to_peer+0x107/0x120 drivers/net/wireguard/socket.c:184 wg_packet_create_data_done drivers/net/wireguard/send.c:251 [inline] wg_packet_tx_worker+0x142/0x360 drivers/net/wireguard/send.c:276 process_one_work+0x3d3/0x720 kernel/workqueue.c:2289 worker_thread+0x618/0xa70 kernel/workqueue.c:2436 kthread+0x1a9/0x1e0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 value changed: 0x0000000063c62d6f -> 0x0000000063c62d70 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 4185 Comm: kworker/1:2 Tainted: G W 6.2.0-rc4-syzkaller-00009-gd532dd102151-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Workqueue: wg-crypt-wg0 wg_packet_tx_worker Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot Signed-off-by: Eric Dumazet Cc: Steffen Klassert Cc: Arnd Bergmann Acked-by: Arnd Bergmann Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 7197460dcd43ff0e4a502ba855dd82d37c2848cc Author: Dragos Tatulea Date: Tue Jan 24 20:24:18 2023 +0200 IB/IPoIB: Fix legacy IPoIB due to wrong number of queues [ Upstream commit e632291a2dbce45a24cddeb5fe28fe71d724ba43 ] The cited commit creates child PKEY interfaces over netlink will multiple tx and rx queues, but some devices doesn't support more than 1 tx and 1 rx queues. This causes to a crash when traffic is sent over the PKEY interface due to the parent having a single queue but the child having multiple queues. This patch fixes the number of queues to 1 for legacy IPoIB at the earliest possible point in time. BUG: kernel NULL pointer dereference, address: 000000000000036b PGD 0 P4D 0 Oops: 0000 [#1] SMP CPU: 4 PID: 209665 Comm: python3 Not tainted 6.1.0_for_upstream_min_debug_2022_12_12_17_02 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:kmem_cache_alloc+0xcb/0x450 Code: ce 7e 49 8b 50 08 49 83 78 10 00 4d 8b 28 0f 84 cb 02 00 00 4d 85 ed 0f 84 c2 02 00 00 41 8b 44 24 28 48 8d 4a 01 49 8b 3c 24 <49> 8b 5c 05 00 4c 89 e8 65 48 0f c7 0f 0f 94 c0 84 c0 74 b8 41 8b RSP: 0018:ffff88822acbbab8 EFLAGS: 00010202 RAX: 0000000000000070 RBX: ffff8881c28e3e00 RCX: 00000000064f8dae RDX: 00000000064f8dad RSI: 0000000000000a20 RDI: 0000000000030d00 RBP: 0000000000000a20 R08: ffff8882f5d30d00 R09: ffff888104032f40 R10: ffff88810fade828 R11: 736f6d6570736575 R12: ffff88810081c000 R13: 00000000000002fb R14: ffffffff817fc865 R15: 0000000000000000 FS: 00007f9324ff9700(0000) GS:ffff8882f5d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000036b CR3: 00000001125af004 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: skb_clone+0x55/0xd0 ip6_finish_output2+0x3fe/0x690 ip6_finish_output+0xfa/0x310 ip6_send_skb+0x1e/0x60 udp_v6_send_skb+0x1e5/0x420 udpv6_sendmsg+0xb3c/0xe60 ? ip_mc_finish_output+0x180/0x180 ? __switch_to_asm+0x3a/0x60 ? __switch_to_asm+0x34/0x60 sock_sendmsg+0x33/0x40 __sys_sendto+0x103/0x160 ? _copy_to_user+0x21/0x30 ? kvm_clock_get_cycles+0xd/0x10 ? ktime_get_ts64+0x49/0xe0 __x64_sys_sendto+0x25/0x30 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f9374f1ed14 Code: 42 41 f8 ff 44 8b 4c 24 2c 4c 8b 44 24 20 89 c5 44 8b 54 24 28 48 8b 54 24 18 b8 2c 00 00 00 48 8b 74 24 10 8b 7c 24 08 0f 05 <48> 3d 00 f0 ff ff 77 34 89 ef 48 89 44 24 08 e8 68 41 f8 ff 48 8b RSP: 002b:00007f9324ff7bd0 EFLAGS: 00000293 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f9324ff7cc8 RCX: 00007f9374f1ed14 RDX: 00000000000002fb RSI: 00007f93000052f0 RDI: 0000000000000030 RBP: 0000000000000000 R08: 00007f9324ff7d40 R09: 000000000000001c R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 000000012a05f200 R14: 0000000000000001 R15: 00007f9374d57bdc Fixes: dbc94a0fb817 ("IB/IPoIB: Fix queue count inconsistency for PKEY child interfaces") Signed-off-by: Dragos Tatulea Link: https://lore.kernel.org/r/95eb6b74c7cf49fa46281f9d056d685c9fa11d38.1674584576.git.leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 419674224390fca298020fc0751a20812f84b12d Author: Eric Dumazet Date: Fri Jan 20 13:02:49 2023 +0000 xfrm/compat: prevent potential spectre v1 gadget in xfrm_xlate32_attr() [ Upstream commit b6ee896385380aa621102e8ea402ba12db1cabff ] int type = nla_type(nla); if (type > XFRMA_MAX) { return -EOPNOTSUPP; } @type is then used as an array index and can be used as a Spectre v1 gadget. if (nla_len(nla) < compat_policy[type].len) { array_index_nospec() can be used to prevent leaking content of kernel memory to malicious users. Fixes: 5106f4a8acff ("xfrm/compat: Add 32=>64-bit messages translator") Signed-off-by: Eric Dumazet Cc: Dmitry Safonov Cc: Steffen Klassert Reviewed-by: Dmitry Safonov Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 0a4f811f2e5d07bbd0c9226f4afb0a1270a831ae Author: Dean Luick Date: Thu Jan 12 13:16:02 2023 -0500 IB/hfi1: Restore allocated resources on failed copyout [ Upstream commit 6601fc0d15ffc20654e39486f9bef35567106d68 ] Fix a resource leak if an error occurs. Fixes: f404ca4c7ea8 ("IB/hfi1: Refactor hfi_user_exp_rcv_setup() IOCTL") Signed-off-by: Dean Luick Signed-off-by: Dennis Dalessandro Link: https://lore.kernel.org/r/167354736291.2132367.10894218740150168180.stgit@awfm-02.cornelisnetworks.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit cf118814ae89f4ae702fd376089cdac296915877 Author: Anastasia Belova Date: Tue Jan 10 12:14:50 2023 +0300 xfrm: compat: change expression for switch in xfrm_xlate64 [ Upstream commit eb6c59b735aa6cca77cdbb59cc69d69a0d63d986 ] Compare XFRM_MSG_NEWSPDINFO (value from netlink configuration messages enum) with nlh_src->nlmsg_type instead of nlh_src->nlmsg_type - XFRM_MSG_BASE. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 4e9505064f58 ("net/xfrm/compat: Copy xfrm_spdattr_type_t atributes") Signed-off-by: Anastasia Belova Acked-by: Dmitry Safonov <0x7f454c46@gmail.com> Tested-by: Dmitry Safonov <0x7f454c46@gmail.com> Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 3fc0b7b7e9a571426613ea678b5a8c5efe8c8f52 Author: Bastien Nocera Date: Fri Feb 3 11:18:00 2023 +0100 HID: logitech: Disable hi-res scrolling on USB commit 690eb7dec72ae52d1d710d14a451844b4d0f4f19 upstream. On some Logitech mice, such as the G903, and possibly the G403, the HID events are generated on a different interface to the HID++ one. If we enable hi-res through the HID++ interface, the HID interface wouldn't know anything about it, and handle the events as if they were regular scroll events, making the mouse unusable. Disable hi-res scrolling on those devices until we implement scroll events through HID++. Signed-off-by: Bastien Nocera Tested-by: Tobias Klausmann Link: https://bugzilla.kernel.org/show_bug.cgi?id=216885 Fixes: 908d325e1665 ("HID: logitech-hidpp: Detect hi-res scrolling support") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230203101800.139380-1-hadess@hadess.net Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit c86e6d30c52227e6a02ff88d116b8dd9da172879 Author: Devid Antonio Filoni Date: Fri Nov 25 18:04:18 2022 +0100 can: j1939: do not wait 250 ms if the same addr was already claimed commit 4ae5e1e97c44f4654516c1d41591a462ed62fa7b upstream. The ISO 11783-5 standard, in "4.5.2 - Address claim requirements", states: d) No CF shall begin, or resume, transmission on the network until 250 ms after it has successfully claimed an address except when responding to a request for address-claimed. But "Figure 6" and "Figure 7" in "4.5.4.2 - Address-claim prioritization" show that the CF begins the transmission after 250 ms from the first AC (address-claimed) message even if it sends another AC message during that time window to resolve the address contention with another CF. As stated in "4.4.2.3 - Address-claimed message": In order to successfully claim an address, the CF sending an address claimed message shall not receive a contending claim from another CF for at least 250 ms. As stated in "4.4.3.2 - NAME management (NM) message": 1) A commanding CF can d) request that a CF with a specified NAME transmit the address- claimed message with its current NAME. 2) A target CF shall d) send an address-claimed message in response to a request for a matching NAME Taking the above arguments into account, the 250 ms wait is requested only during network initialization. Do not restart the timer on AC message if both the NAME and the address match and so if the address has already been claimed (timer has expired) or the AC message has been sent to resolve the contention with another CF (timer is still running). Signed-off-by: Devid Antonio Filoni Acked-by: Oleksij Rempel Link: https://lore.kernel.org/all/20221125170418.34575-1-devid.filoni@egluetechnologies.com Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Cc: stable@vger.kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit ad7e46427f9299a8e5976b124bf1d6cdd988c66c Author: Mark Brown Date: Sat Jan 28 17:47:50 2023 +0000 of/address: Return an error when no valid dma-ranges are found commit f6933c01e42d2fc83b9133ed755609e4aac6eadd upstream. Commit 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range") converted the parsing of dma-range properties to use code shared with the PCI range parser. The intent was to introduce no functional changes however in the case where we fail to translate the first resource instead of returning -EINVAL the new code we return 0. Restore the previous behaviour by returning an error if we find no valid ranges, the original code only handled the first range but subsequently support for parsing all supplied ranges was added. This avoids confusing code using the parsed ranges which doesn't expect to successfully parse ranges but have only a list terminator returned, this fixes breakage with so far as I can tell all DMA for on SoC devices on the Socionext Synquacer platform which has a firmware supplied DT. A bisect identified the original conversion as triggering the issues there. Fixes: 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range") Signed-off-by: Mark Brown Cc: Luca Di Stefano Cc: 993612@bugs.debian.org Cc: stable@kernel.org Link: https://lore.kernel.org/r/20230126-synquacer-boot-v2-1-cb80fd23c4e2@kernel.org Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman commit 0a3e60b3fe492c2420b46629539542e6ccea1bcb Author: Shiju Jose Date: Thu Feb 2 18:23:09 2023 +0000 tracing: Fix poll() and select() do not work on per_cpu trace_pipe and trace_pipe_raw commit 3e46d910d8acf94e5360126593b68bf4fee4c4a1 upstream. poll() and select() on per_cpu trace_pipe and trace_pipe_raw do not work since kernel 6.1-rc6. This issue is seen after the commit 42fb0a1e84ff525ebe560e2baf9451ab69127e2b ("tracing/ring-buffer: Have polling block on watermark"). This issue is firstly detected and reported, when testing the CXL error events in the rasdaemon and also erified using the test application for poll() and select(). This issue occurs for the per_cpu case, when calling the ring_buffer_poll_wait(), in kernel/trace/ring_buffer.c, with the buffer_percent > 0 and then wait until the percentage of pages are available. The default value set for the buffer_percent is 50 in the kernel/trace/trace.c. As a fix, allow userspace application could set buffer_percent as 0 through the buffer_percent_fops, so that the task will wake up as soon as data is added to any of the specific cpu buffer. Link: https://lore.kernel.org/linux-trace-kernel/20230202182309.742-2-shiju.jose@huawei.com Cc: Cc: Cc: Cc: stable@vger.kernel.org Fixes: 42fb0a1e84ff5 ("tracing/ring-buffer: Have polling block on watermark") Signed-off-by: Shiju Jose Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 5c4bd3f2f6ebb1e41e2df71d3f0a3450aa0bf102 Author: Bjorn Helgaas Date: Fri Feb 3 13:57:39 2023 -0600 Revert "PCI/ASPM: Refactor L1 PM Substates Control Register programming" commit ff209ecc376a2ea8dd106a1f594427a5d94b7dd3 upstream. This reverts commit 5e85eba6f50dc288c22083a7e213152bcc4b8208. Thomas Witt reported that 5e85eba6f50d ("PCI/ASPM: Refactor L1 PM Substates Control Register programming") broke suspend/resume on a Tuxedo Infinitybook S 14 v5, which seems to use a Clevo L140CU Mainboard. The main symptom is: iwlwifi 0000:02:00.0: Unable to change power state from D3hot to D0, device inaccessible nvme 0000:03:00.0: Unable to change power state from D3hot to D0, device inaccessible and the machine is only partially usable after resume. It can't run dmesg and can't do a clean reboot. This happens on every suspend/resume cycle. Revert 5e85eba6f50d until we can figure out the root cause. Fixes: 5e85eba6f50d ("PCI/ASPM: Refactor L1 PM Substates Control Register programming") Link: https://bugzilla.kernel.org/show_bug.cgi?id=216877 Reported-by: Thomas Witt Tested-by: Thomas Witt Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org # v6.1+ Cc: Vidya Sagar Signed-off-by: Greg Kroah-Hartman commit 3361eb2256f9e427c03a32f887519f06d192289a Author: Bjorn Helgaas Date: Fri Feb 3 13:57:29 2023 -0600 Revert "PCI/ASPM: Save L1 PM Substates Capability for suspend/resume" commit a7152be79b627428c628da2a887ca4b2512a78fd upstream. This reverts commit 4ff116d0d5fd8a025604b0802d93a2d5f4e465d1. Tasev Nikola and Mark Enriquez reported that resume from suspend was broken in v6.1-rc1. Tasev bisected to a47126ec29f5 ("PCI/PTM: Cache PTM Capability offset"), but we can't figure out how that could be related. Mark saw the same symptoms and bisected to 4ff116d0d5fd ("PCI/ASPM: Save L1 PM Substates Capability for suspend/resume"), which does have a connection: it restores L1 Substates configuration while ASPM L1 may be enabled: pci_restore_state pci_restore_aspm_l1ss_state aspm_program_l1ss pci_write_config_dword(PCI_L1SS_CTL1, ctl1) # L1SS restore pci_restore_pcie_state pcie_capability_write_word(PCI_EXP_LNKCTL, cap[i++]) # L1 restore which is a problem because PCIe r6.0, sec 5.5.4, requires that: If setting either or both of the enable bits for ASPM L1 PM Substates, both ports must be configured as described in this section while ASPM L1 is disabled. Separately, Thomas Witt reported that 5e85eba6f50d ("PCI/ASPM: Refactor L1 PM Substates Control Register programming") broke suspend/resume, and it depends on 4ff116d0d5fd. Revert 4ff116d0d5fd ("PCI/ASPM: Save L1 PM Substates Capability for suspend/resume") to fix the resume issue and enable revert of 5e85eba6f50d to fix the issue Thomas reported. Note that reverting 4ff116d0d5fd means L1 Substates config may be lost on suspend/resume. As far as we know the system will use more power but will still *work* correctly. Fixes: 4ff116d0d5fd ("PCI/ASPM: Save L1 PM Substates Capability for suspend/resume") Link: https://bugzilla.kernel.org/show_bug.cgi?id=216782 Link: https://bugzilla.kernel.org/show_bug.cgi?id=216877 Reported-by: Tasev Nikola Reported-by: Mark Enriquez Reported-by: Thomas Witt Tested-by: Mark Enriquez Tested-by: Thomas Witt Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org # v6.1+ Cc: Vidya Sagar Signed-off-by: Greg Kroah-Hartman commit 63380b631f3dc04cf3139265732d860d870019f7 Author: Andy Chi Date: Tue Feb 7 16:30:09 2023 +0800 ALSA: hda/realtek: fix mute/micmute LEDs don't work for a HP platform. commit 6c4715aa5b0ab1c0d35780b7c552e952dbb5515d upstream. There is a HP platform needs ALC236_FIXUP_HP_GPIO_LED quirk to make mic-mute/audio-mute working. Signed-off-by: Andy Chi Cc: Link: https://lore.kernel.org/r/20230207083011.100189-1-andy.chi@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit fdc304eef6e84153ca9a1e842c0c535085868fe0 Author: Stefan Binding Date: Mon Feb 6 15:00:19 2023 +0000 ALSA: hda/realtek: Add quirk for ASUS UM3402 using CS35L41 commit 7a17e8423a133a6ac238462126d7f88faaccc681 upstream. This Asus Zenbook laptop use Realtek HDA codec combined with 2xCS35L41 Amplifiers using I2C with External Boost. Signed-off-by: Stefan Binding Cc: Link: https://lore.kernel.org/r/20230206150019.3825120-1-sbinding@opensource.cirrus.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 566cad13beb62c9a2e9937becc9a4f4d5c12d257 Author: Elvis Angelaccio Date: Sun Feb 5 19:56:18 2023 +0100 ALSA: hda/realtek: Enable mute/micmute LEDs on HP Elitebook, 645 G9 commit 9a6804aa1c92cd28e89e746ace44d5ba101db76c upstream. The HP Elitebook 645 G9 laptop (with motherboard model 89D2) uses the ALC236 codec and requires the alc236_fixup_hp_mute_led_micmute_vref fixup in order to enable mute/micmute LEDs. Note: the alc236_fixup_hp_gpio_led fixup, which is used by the Elitebook 640 G9, does not work with the 645 G9. [ rearranged the entry in SSID order -- tiwai ] Signed-off-by: Elvis Angelaccio Cc: Link: https://lore.kernel.org/r/4055cb48-e228-8a13-524d-afbb7aaafebe@kde.org Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 49f4284ab3b52fd320b8ef1186b2287f791a71e3 Author: Guillaume Pinot Date: Sun Jan 29 18:13:38 2023 +0100 ALSA: hda/realtek: Fix the speaker output on Samsung Galaxy Book2 Pro 360 commit bd401fd730cbcb0717bbc5438f15084db10f9259 upstream. Samsung Galaxy Book2 Pro 360 (13" 2022 NP930QED-KA1FR) with codec SSID 144d:ca03 requires the same workaround for enabling the speaker amp like other Samsung models with ALC298 codec. Cc: Signed-off-by: Guillaume Pinot Link: https://lore.kernel.org/r/20230129171338.17249-1-texitoi@texitoi.eu Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9d26f571df4de4b8991aeb30c4ccc7b0a30f0ec7 Author: Artemii Karasev Date: Tue Feb 7 18:20:26 2023 +0500 ALSA: emux: Avoid potential array out-of-bound in snd_emux_xg_control() commit 6a32425f953b955b4ff82f339d01df0b713caa5d upstream. snd_emux_xg_control() can be called with an argument 'param' greater than size of 'control' array. It may lead to accessing 'control' array at a wrong index. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Artemii Karasev Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: Link: https://lore.kernel.org/r/20230207132026.2870-1-karasev@ispras.ru Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ab9b01a7acd56a21a64cd881e61c7a5369bd4602 Author: Edson Juliano Drosdeck Date: Tue Feb 7 15:37:20 2023 -0300 ALSA: hda/realtek: Add Positivo N14KP6-TG commit 88d18b8896bd98e636b632f805b7e84e61458255 upstream. Positivo N14KP6-TG (1c6c:1251) require quirk for enabling headset-mic Signed-off-by: Edson Juliano Drosdeck Cc: Link: https://lore.kernel.org/r/20230207183720.2519-1-edson.drosdeck@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8ab575add354e48126591606262446fa1ee7ebd4 Author: Alexander Potapenko Date: Tue Jan 24 12:32:34 2023 +0100 btrfs: zlib: zero-initialize zlib workspace commit eadd7deca0ad8a83edb2b894d8326c78e78635d6 upstream. KMSAN reports uses of uninitialized memory in zlib's longest_match() called on memory originating from zlib_alloc_workspace(). This issue is known by zlib maintainers and is claimed to be harmless, but to be on the safe side we'd better initialize the memory. Link: https://zlib.net/zlib_faq.html#faq36 Reported-by: syzbot+14d9e7602ebdf7ec0a60@syzkaller.appspotmail.com CC: stable@vger.kernel.org # 5.4+ Signed-off-by: Alexander Potapenko Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 66cf3a8273abcac9c52b088f87f926e1a699d959 Author: Josef Bacik Date: Wed Jan 18 16:35:13 2023 -0500 btrfs: limit device extents to the device size commit 3c538de0f2a74d50aff7278c092f88ae59cee688 upstream. There was a recent regression in btrfs/177 that started happening with the size class patches ("btrfs: introduce size class to block group allocator"). This however isn't a regression introduced by those patches, but rather the bug was uncovered by a change in behavior in these patches. The patches triggered more chunk allocations in the ^free-space-tree case, which uncovered a race with device shrink. The problem is we will set the device total size to the new size, and use this to find a hole for a device extent. However during shrink we may have device extents allocated past this range, so we could potentially find a hole in a range past our new shrink size. We don't actually limit our found extent to the device size anywhere, we assume that we will not find a hole past our device size. This isn't true with shrink as we're relocating block groups and thus creating holes past the device size. Fix this by making sure we do not search past the new device size, and if we wander into any device extents that start after our device size simply break from the loop and use whatever hole we've already found. CC: stable@vger.kernel.org # 4.14+ Signed-off-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 6b2aaf302ce8baf8e5a41777e97a8d1ac7b9b8f5 Author: Michael Kelley Date: Mon Feb 6 12:11:57 2023 -0800 hv_netvsc: Allocate memory in netvsc_dma_map() with GFP_ATOMIC commit c6aa9d3b43cd11ac13a8220368a3b0483c6751d4 upstream. Memory allocations in the network transmit path must use GFP_ATOMIC so they won't sleep. Reported-by: Paolo Abeni Link: https://lore.kernel.org/lkml/8a4d08f94d3e6fe8b6da68440eaa89a088ad84f9.camel@redhat.com/ Fixes: 846da38de0e8 ("net: netvsc: Add Isolation VM support for netvsc driver") Cc: stable@vger.kernel.org Signed-off-by: Michael Kelley Link: https://lore.kernel.org/r/1675714317-48577-1-git-send-email-mikelley@microsoft.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman