commit 22852eaf43ec64b7dc0aa72687b22237b65a88f9 Author: Greg Kroah-Hartman Date: Wed Jan 10 17:17:02 2024 +0100 Linux 6.6.11 Link: https://lore.kernel.org/r/20240108150602.976232871@linuxfoundation.org Tested-by: SeongJae Park Tested-by: Florian Fainelli Tested-by: Allen Pais Tested-by: Shuah Khan Tested-by: Salvatore Bonaccorso Tested-by: Bagas Sanjaya Tested-by: Ron Economos Tested-by: Linux Kernel Functional Testing Tested-by: Takeshi Ogasawara Tested-by: Luna Jernberg Tested-by: Conor Dooley Tested-by: Jon Hunter Tested-by: Kelsey Steele Tested-by: Harshit Mogalapalli Tested-by: kernelci.org bot Tested-by: Ricardo B. Marliere Signed-off-by: Greg Kroah-Hartman commit e53b78e3cfb1c39381f6c4e3d74e96633bfeace6 Author: Bryan O'Donoghue Date: Thu Sep 28 01:58:25 2023 +0100 media: qcom: camss: Comment CSID dt_id field commit f910d3ba78a2677c23508f225eb047d89eb4b2b6 upstream. Digging into the documentation we find that the DT_ID bitfield is used to map the six bit DT to a two bit ID code. This value is concatenated to the VC bitfield to create a CID value. DT_ID is the two least significant bits of CID and VC the most significant bits. Originally we set dt_id = vc * 4 in and then subsequently set dt_id = vc. commit 3c4ed72a16bc ("media: camss: sm8250: Virtual channels for CSID") silently fixed the multiplication by four which would give a better value for the generated CID without mentioning what was being done or why. Next up I haplessly changed the value back to "dt_id = vc * 4" since there didn't appear to be any logic behind it. Hans asked what the change was for and I honestly couldn't remember the provenance of it, so I dug in. Link: https://lore.kernel.org/linux-arm-msm/edd4bf9b-0e1b-883c-1a4d-50f4102c3924@xs4all.nl/ Add a comment so the next hapless programmer doesn't make this same mistake. Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit c897fb3da8a7ff8138d472fb3e8a0f050c447999 Author: Alison Schofield Date: Sun Nov 26 16:09:30 2023 -0800 cxl/memdev: Hold region_rwsem during inject and clear poison ops commit 0e33ac9c3ffe5e4f55c68345f44cea7fec2fe750 upstream. Poison inject and clear are supported via debugfs where a privileged user can inject and clear poison to a device physical address. Commit 458ba8189cb4 ("cxl: Add cxl_decoders_committed() helper") added a lockdep assert that highlighted a gap in poison inject and clear functions where holding the dpa_rwsem does not assure that a a DPA is not added to a region. The impact for inject and clear is that if the DPA address being injected or cleared has been attached to a region, but not yet committed, the dev_dbg() message intended to alert the debug user that they are acting on a mapped address is not emitted. Also, the cxl_poison trace event that serves as a log of the inject and clear activity will not include region info. Close this gap by snapshotting an unchangeable region state during poison inject and clear operations. That means holding both the region_rwsem and the dpa_rwsem during the inject and clear ops. Fixes: d2fbc4865802 ("cxl/memdev: Add support for the Inject Poison mailbox command") Fixes: 9690b07748d1 ("cxl/memdev: Add support for the Clear Poison mailbox command") Signed-off-by: Alison Schofield Reviewed-by: Davidlohr Bueso Reviewed-by: Dave Jiang Link: https://lore.kernel.org/r/08721dc1df0a51e4e38fecd02425c3475912dfd5.1701041440.git.alison.schofield@intel.com Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 0a460481df435f955d569b44e7674ff81dfc7f74 Author: Dave Jiang Date: Fri Nov 17 13:18:48 2023 -0700 cxl/hdm: Fix a benign lockdep splat commit 36a1c2ee50f573972aea3c3019555f47ee0094c0 upstream. The new helper "cxl_num_decoders_committed()" added a lockdep assertion to validate that port->commit_end is protected against modification. That assertion fires in init_hdm_decoder() where it is initializing port->commit_end. Given that it is both accessing and writing that property it obstensibly needs the lock. In practice, CXL decoder commit rules (must commit in order) and the in-order discovery of device decoders makes the manipulation of ->commit_end in init_hdm_decoder() safe. However, rather than rely on the subtle rules of CXL hardware, just make the implementation obviously correct from a software perspective. The Fixes: tag is only for cleaning up a lockdep splat, there is no functional issue addressed by this fix. Fixes: 458ba8189cb4 ("cxl: Add cxl_decoders_committed() helper") Signed-off-by: Dave Jiang Link: https://lore.kernel.org/r/170025232811.2147250.16376901801315194121.stgit@djiang5-mobl3 Acked-by: Davidlohr Bueso Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit c56f610fe9470f79c82de3ec765b3c1e66ef2c71 Author: Dave Jiang Date: Mon Nov 6 10:26:45 2023 -0700 cxl: Add cxl_num_decoders_committed() usage to cxl_test commit e05501e8a84eee4f819f31b9ce663bddd01b3b69 upstream. Commit 458ba8189cb4 ("cxl: Add cxl_decoders_committed() helper") missed the conversion for cxl_test. Add usage of cxl_num_decoders_committed() to replace the open coding. Suggested-by: Alison Schofield Signed-off-by: Dave Jiang Reviewed-by: Fan Ni Link: https://lore.kernel.org/r/169929160525.824083.11813222229025394254.stgit@djiang5-mobl3 Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 2e22a9095fe315b561d4ba834d929c0f2c420f30 Author: Wenchao Chen Date: Mon Dec 4 14:49:34 2023 +0800 mmc: sdhci-sprd: Fix eMMC init failure after hw reset commit 8abf77c88929b6d20fa4f9928b18d6448d64e293 upstream. Some eMMC devices that do not close the auto clk gate after hw reset will cause eMMC initialization to fail. Let's fix this. Signed-off-by: Wenchao Chen Fixes: ff874dbc4f86 ("mmc: sdhci-sprd: Disable CLK_AUTO when the clock is less than 400K") Reviewed-by: Baolin Wang Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20231204064934.21236-1-wenchao.chen@unisoc.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 73432eb655a88dfd407e409065a3930adeea406e Author: Geert Uytterhoeven Date: Mon Dec 4 12:29:53 2023 +0100 mmc: core: Cancel delayed work before releasing host commit 1036f69e251380573e256568cf814506e3fb9988 upstream. On RZ/Five SMARC EVK, where probing of SDHI is deferred due to probe deferral of the vqmmc-supply regulator: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at kernel/time/timer.c:1738 __run_timers.part.0+0x1d0/0x1e8 Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 6.7.0-rc4 #101 Hardware name: Renesas SMARC EVK based on r9a07g043f01 (DT) epc : __run_timers.part.0+0x1d0/0x1e8 ra : __run_timers.part.0+0x134/0x1e8 epc : ffffffff800771a4 ra : ffffffff80077108 sp : ffffffc800003e60 gp : ffffffff814f5028 tp : ffffffff8140c5c0 t0 : ffffffc800000000 t1 : 0000000000000001 t2 : ffffffff81201300 s0 : ffffffc800003f20 s1 : ffffffd8023bc4a0 a0 : 00000000fffee6b0 a1 : 0004010000400000 a2 : ffffffffc0000016 a3 : ffffffff81488640 a4 : ffffffc800003e60 a5 : 0000000000000000 a6 : 0000000004000000 a7 : ffffffc800003e68 s2 : 0000000000000122 s3 : 0000000000200000 s4 : 0000000000000000 s5 : ffffffffffffffff s6 : ffffffff81488678 s7 : ffffffff814886c0 s8 : ffffffff814f49c0 s9 : ffffffff81488640 s10: 0000000000000000 s11: ffffffc800003e60 t3 : 0000000000000240 t4 : 0000000000000a52 t5 : ffffffd8024ae018 t6 : ffffffd8024ae038 status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 [] __run_timers.part.0+0x1d0/0x1e8 [] run_timer_softirq+0x24/0x4a [] __do_softirq+0xc6/0x1fa [] irq_exit_rcu+0x66/0x84 [] handle_riscv_irq+0x40/0x4e [] call_on_irq_stack+0x1c/0x28 ---[ end trace 0000000000000000 ]--- What happens? renesas_sdhi_probe() { tmio_mmc_host_alloc() mmc_alloc_host() INIT_DELAYED_WORK(&host->detect, mmc_rescan); devm_request_irq(tmio_mmc_irq); /* * After this, the interrupt handler may be invoked at any time * * tmio_mmc_irq() * { * __tmio_mmc_card_detect_irq() * mmc_detect_change() * _mmc_detect_change() * mmc_schedule_delayed_work(&host->detect, delay); * } */ tmio_mmc_host_probe() tmio_mmc_init_ocr() -EPROBE_DEFER tmio_mmc_host_free() mmc_free_host() } When expire_timers() runs later, it warns because the MMC host structure containing the delayed work was freed, and now contains an invalid work function pointer. Fix this by cancelling any pending delayed work before releasing the MMC host structure. Signed-off-by: Geert Uytterhoeven Tested-by: Lad Prabhakar Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/205dc4c91b47e31b64392fe2498c7a449e717b4b.1701689330.git.geert+renesas@glider.be Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 882ab492767a147636812a9ed9e6005df8f14884 Author: Jorge Ramirez-Ortiz Date: Fri Dec 1 16:31:43 2023 +0100 mmc: rpmb: fixes pause retune on all RPMB partitions. commit e7794c14fd73e5eb4a3e0ecaa5334d5a17377c50 upstream. When RPMB was converted to a character device, it added support for multiple RPMB partitions (Commit 97548575bef3 ("mmc: block: Convert RPMB to a character device"). One of the changes in this commit was transforming the variable target_part defined in __mmc_blk_ioctl_cmd into a bitmask. This inadvertently regressed the validation check done in mmc_blk_part_switch_pre() and mmc_blk_part_switch_post(), so let's fix it. Fixes: 97548575bef3 ("mmc: block: Convert RPMB to a character device") Signed-off-by: Jorge Ramirez-Ortiz Reviewed-by: Linus Walleij Cc: Link: https://lore.kernel.org/r/20231201153143.1449753-1-jorge@foundries.io Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 1f1e1d8006baa56c7894dc897d852b8be842ac9a Author: Ziyang Huang Date: Wed Oct 11 00:44:00 2023 +0800 mmc: meson-mx-sdhc: Fix initialization frozen issue commit 8c124d998ea0c9022e247b11ac51f86ec8afa0e1 upstream. Commit 4bc31edebde5 ("mmc: core: Set HS clock speed before sending HS CMD13") set HS clock (52MHz) before switching to HS mode. For this freq, FCLK_DIV5 will be selected and div value is 10 (reg value is 9). Then we set rx_clk_phase to 11 or 15 which is out of range and make hardware frozen. After we send command request, no irq will be interrupted and the mmc driver will keep to wait for request finished, even durning rebooting. So let's set it to Phase 90 which should work in most cases. Then let meson_mx_sdhc_execute_tuning() to find the accurate value for data transfer. If this doesn't work, maybe need to define a factor in dts. Fixes: e4bf1b0970ef ("mmc: host: meson-mx-sdhc: new driver for the Amlogic Meson SDHC host") Signed-off-by: Ziyang Huang Tested-by: Anand Moon Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/TYZPR01MB5556A3E71554A2EC08597EA4C9CDA@TYZPR01MB5556.apcprd01.prod.exchangelabs.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit ceb3af6860155803d9326e9c7b0e7a47bf68201f Author: Joshua Ashton Date: Mon Jan 1 18:28:22 2024 +0000 drm/amd/display: Fix sending VSC (+ colorimetry) packets for DP/eDP displays without PSR commit 202260f64519e591b5cd99626e441b6559f571a3 upstream. The check for sending the vsc infopacket to the display was gated behind PSR (Panel Self Refresh) being enabled. The vsc infopacket also contains the colorimetry (specifically the container color gamut) information for the stream on modern DP. PSR is typically only supported on mobile phone eDP displays, thus this was not getting sent for typical desktop monitors or TV screens. This functionality is needed for proper HDR10 functionality on DP as it wants BT2020 RGB/YCbCr for the container color space. Cc: stable@vger.kernel.org Cc: Harry Wentland Cc: Xaver Hugl Cc: Melissa Wen Fixes: 15f9dfd545a1 ("drm/amd/display: Register Colorspace property for DP and HDMI") Tested-by: Simon Berz Tested-by: Xaver Hugl Signed-off-by: Joshua Ashton Signed-off-by: Hamza Mahfooz Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit fd32475126985119b6a8b86f0c4becc7a3900b4f Author: Alex Deucher Date: Wed Dec 20 12:33:45 2023 -0500 drm/amd/display: add nv12 bounding box commit 7e725c20fea8914ef1829da777f517ce1a93d388 upstream. This was included in gpu_info firmware, move it into the driver for consistency with other nv1x parts. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2318 Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 039c4551438ec4f3c5789402470f07276f37c5d8 Author: Alex Deucher Date: Wed Dec 20 12:36:08 2023 -0500 drm/amdgpu: skip gpu_info fw loading on navi12 commit 21f6137c64c65d6808c4a81006956197ca203383 upstream. It's no longer required. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2318 Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 2247df454c7bb4b13939794fe6fae8510868d241 Author: Jiajun Xie Date: Wed Dec 20 13:28:39 2023 +0800 mm: fix unmap_mapping_range high bits shift bug commit 9eab0421fa94a3dde0d1f7e36ab3294fc306c99d upstream. The bug happens when highest bit of holebegin is 1, suppose holebegin is 0x8000000111111000, after shift, hba would be 0xfff8000000111111, then vma_interval_tree_foreach would look it up fail or leads to the wrong result. error call seq e.g.: - mmap(..., offset=0x8000000111111000) |- syscall(mmap, ... unsigned long, off): |- ksys_mmap_pgoff( ... , off >> PAGE_SHIFT); here pgoff is correctly shifted to 0x8000000111111, but pass 0x8000000111111000 as holebegin to unmap would then cause terrible result, as shown below: - unmap_mapping_range(..., loff_t const holebegin) |- pgoff_t hba = holebegin >> PAGE_SHIFT; /* hba = 0xfff8000000111111 unexpectedly */ The issue happens in Heterogeneous computing, where the device(e.g. gpu) and host share the same virtual address space. A simple workflow pattern which hit the issue is: /* host */ 1. userspace first mmap a file backed VA range with specified offset. e.g. (offset=0x800..., mmap return: va_a) 2. write some data to the corresponding sys page e.g. (va_a = 0xAABB) /* device */ 3. gpu workload touches VA, triggers gpu fault and notify the host. /* host */ 4. reviced gpu fault notification, then it will: 4.1 unmap host pages and also takes care of cpu tlb (use unmap_mapping_range with offset=0x800...) 4.2 migrate sys page to device 4.3 setup device page table and resolve device fault. /* device */ 5. gpu workload continued, it accessed va_a and got 0xAABB. 6. gpu workload continued, it wrote 0xBBCC to va_a. /* host */ 7. userspace access va_a, as expected, it will: 7.1 trigger cpu vm fault. 7.2 driver handling fault to migrate gpu local page to host. 8. userspace then could correctly get 0xBBCC from va_a 9. done But in step 4.1, if we hit the bug this patch mentioned, then userspace would never trigger cpu fault, and still get the old value: 0xAABB. Making holebegin unsigned first fixes the bug. Link: https://lkml.kernel.org/r/20231220052839.26970-1-jiajun.xie.sh@gmail.com Signed-off-by: Jiajun Xie Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit b240a3ef3d9188caa9a5507e4b9a8acfb7190703 Author: Benjamin Bara Date: Thu Jan 4 09:17:08 2024 +0100 i2c: core: Fix atomic xfer check for non-preempt config commit a3368e1186e3ce8e38f78cbca019622095b1f331 upstream. Since commit aa49c90894d0 ("i2c: core: Run atomic i2c xfer when !preemptible"), the whole reboot/power off sequence on non-preempt kernels is using atomic i2c xfer, as !preemptible() always results to 1. During device_shutdown(), the i2c might be used a lot and not all busses have implemented an atomic xfer handler. This results in a lot of avoidable noise, like: [ 12.687169] No atomic I2C transfer handler for 'i2c-0' [ 12.692313] WARNING: CPU: 6 PID: 275 at drivers/i2c/i2c-core.h:40 i2c_smbus_xfer+0x100/0x118 ... Fix this by allowing non-atomic xfer when the interrupts are enabled, as it was before. Link: https://lore.kernel.org/r/20231222230106.73f030a5@yea Link: https://lore.kernel.org/r/20240102150350.3180741-1-mwalle@kernel.org Link: https://lore.kernel.org/linux-i2c/13271b9b-4132-46ef-abf8-2c311967bb46@mailbox.org/ Fixes: aa49c90894d0 ("i2c: core: Run atomic i2c xfer when !preemptible") Cc: stable@vger.kernel.org # v5.2+ Signed-off-by: Benjamin Bara Tested-by: Michael Walle Tested-by: Tor Vic [wsa: removed a comment which needs more work, code is ok] Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit dfb8a426e030c14737dfde038cf9c173c8032f08 Author: Jinghao Jia Date: Tue Jan 2 17:33:45 2024 -0600 x86/kprobes: fix incorrect return address calculation in kprobe_emulate_call_indirect commit f5d03da48d062966c94f0199d20be0b3a37a7982 upstream. kprobe_emulate_call_indirect currently uses int3_emulate_call to emulate indirect calls. However, int3_emulate_call always assumes the size of the call to be 5 bytes when calculating the return address. This is incorrect for register-based indirect calls in x86, which can be either 2 or 3 bytes depending on whether REX prefix is used. At kprobe runtime, the incorrect return address causes control flow to land onto the wrong place after return -- possibly not a valid instruction boundary. This can lead to a panic like the following: [ 7.308204][ C1] BUG: unable to handle page fault for address: 000000000002b4d8 [ 7.308883][ C1] #PF: supervisor read access in kernel mode [ 7.309168][ C1] #PF: error_code(0x0000) - not-present page [ 7.309461][ C1] PGD 0 P4D 0 [ 7.309652][ C1] Oops: 0000 [#1] SMP [ 7.309929][ C1] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.7.0-rc5-trace-for-next #6 [ 7.310397][ C1] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-20220807_005459-localhost 04/01/2014 [ 7.311068][ C1] RIP: 0010:__common_interrupt+0x52/0xc0 [ 7.311349][ C1] Code: 01 00 4d 85 f6 74 39 49 81 fe 00 f0 ff ff 77 30 4c 89 f7 4d 8b 5e 68 41 ba 91 76 d8 42 45 03 53 fc 74 02 0f 0b cc ff d3 65 48 <8b> 05 30 c7 ff 7e 65 4c 89 3d 28 c7 ff 7e 5b 41 5c 41 5e 41 5f c3 [ 7.312512][ C1] RSP: 0018:ffffc900000e0fd0 EFLAGS: 00010046 [ 7.312899][ C1] RAX: 0000000000000001 RBX: 0000000000000023 RCX: 0000000000000001 [ 7.313334][ C1] RDX: 00000000000003cd RSI: 0000000000000001 RDI: ffff888100d302a4 [ 7.313702][ C1] RBP: 0000000000000001 R08: 0ef439818636191f R09: b1621ff338a3b482 [ 7.314146][ C1] R10: ffffffff81e5127b R11: ffffffff81059810 R12: 0000000000000023 [ 7.314509][ C1] R13: 0000000000000000 R14: ffff888100d30200 R15: 0000000000000000 [ 7.314951][ C1] FS: 0000000000000000(0000) GS:ffff88813bc80000(0000) knlGS:0000000000000000 [ 7.315396][ C1] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 7.315691][ C1] CR2: 000000000002b4d8 CR3: 0000000003028003 CR4: 0000000000370ef0 [ 7.316153][ C1] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 7.316508][ C1] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 7.316948][ C1] Call Trace: [ 7.317123][ C1] [ 7.317279][ C1] ? __die_body+0x64/0xb0 [ 7.317482][ C1] ? page_fault_oops+0x248/0x370 [ 7.317712][ C1] ? __wake_up+0x96/0xb0 [ 7.317964][ C1] ? exc_page_fault+0x62/0x130 [ 7.318211][ C1] ? asm_exc_page_fault+0x22/0x30 [ 7.318444][ C1] ? __cfi_native_send_call_func_single_ipi+0x10/0x10 [ 7.318860][ C1] ? default_idle+0xb/0x10 [ 7.319063][ C1] ? __common_interrupt+0x52/0xc0 [ 7.319330][ C1] common_interrupt+0x78/0x90 [ 7.319546][ C1] [ 7.319679][ C1] [ 7.319854][ C1] asm_common_interrupt+0x22/0x40 [ 7.320082][ C1] RIP: 0010:default_idle+0xb/0x10 [ 7.320309][ C1] Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 b8 0c 67 40 a5 66 90 0f 00 2d 09 b9 3b 00 fb f4 c3 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 b8 0c 67 40 a5 e9 [ 7.321449][ C1] RSP: 0018:ffffc9000009bee8 EFLAGS: 00000256 [ 7.321808][ C1] RAX: ffff88813bca8b68 RBX: 0000000000000001 RCX: 000000000001ef0c [ 7.322227][ C1] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 000000000001ef0c [ 7.322656][ C1] RBP: ffffc9000009bef8 R08: 8000000000000000 R09: 00000000000008c2 [ 7.323083][ C1] R10: 0000000000000000 R11: ffffffff81058e70 R12: 0000000000000000 [ 7.323530][ C1] R13: ffff8881002b30c0 R14: 0000000000000000 R15: 0000000000000000 [ 7.323948][ C1] ? __cfi_lapic_next_deadline+0x10/0x10 [ 7.324239][ C1] default_idle_call+0x31/0x50 [ 7.324464][ C1] do_idle+0xd3/0x240 [ 7.324690][ C1] cpu_startup_entry+0x25/0x30 [ 7.324983][ C1] start_secondary+0xb4/0xc0 [ 7.325217][ C1] secondary_startup_64_no_verify+0x179/0x17b [ 7.325498][ C1] [ 7.325641][ C1] Modules linked in: [ 7.325906][ C1] CR2: 000000000002b4d8 [ 7.326104][ C1] ---[ end trace 0000000000000000 ]--- [ 7.326354][ C1] RIP: 0010:__common_interrupt+0x52/0xc0 [ 7.326614][ C1] Code: 01 00 4d 85 f6 74 39 49 81 fe 00 f0 ff ff 77 30 4c 89 f7 4d 8b 5e 68 41 ba 91 76 d8 42 45 03 53 fc 74 02 0f 0b cc ff d3 65 48 <8b> 05 30 c7 ff 7e 65 4c 89 3d 28 c7 ff 7e 5b 41 5c 41 5e 41 5f c3 [ 7.327570][ C1] RSP: 0018:ffffc900000e0fd0 EFLAGS: 00010046 [ 7.327910][ C1] RAX: 0000000000000001 RBX: 0000000000000023 RCX: 0000000000000001 [ 7.328273][ C1] RDX: 00000000000003cd RSI: 0000000000000001 RDI: ffff888100d302a4 [ 7.328632][ C1] RBP: 0000000000000001 R08: 0ef439818636191f R09: b1621ff338a3b482 [ 7.329223][ C1] R10: ffffffff81e5127b R11: ffffffff81059810 R12: 0000000000000023 [ 7.329780][ C1] R13: 0000000000000000 R14: ffff888100d30200 R15: 0000000000000000 [ 7.330193][ C1] FS: 0000000000000000(0000) GS:ffff88813bc80000(0000) knlGS:0000000000000000 [ 7.330632][ C1] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 7.331050][ C1] CR2: 000000000002b4d8 CR3: 0000000003028003 CR4: 0000000000370ef0 [ 7.331454][ C1] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 7.331854][ C1] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 7.332236][ C1] Kernel panic - not syncing: Fatal exception in interrupt [ 7.332730][ C1] Kernel Offset: disabled [ 7.333044][ C1] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- The relevant assembly code is (from objdump, faulting address highlighted): ffffffff8102ed9d: 41 ff d3 call *%r11 ffffffff8102eda0: 65 48 <8b> 05 30 c7 ff mov %gs:0x7effc730(%rip),%rax The emulation incorrectly sets the return address to be ffffffff8102ed9d + 0x5 = ffffffff8102eda2, which is the 8b byte in the middle of the next mov. This in turn causes incorrect subsequent instruction decoding and eventually triggers the page fault above. Instead of invoking int3_emulate_call, perform push and jmp emulation directly in kprobe_emulate_call_indirect. At this point we can obtain the instruction size from p->ainsn.size so that we can calculate the correct return address. Link: https://lore.kernel.org/all/20240102233345.385475-1-jinghao7@illinois.edu/ Fixes: 6256e668b7af ("x86/kprobes: Use int3 instead of debug trap for single-step") Cc: stable@vger.kernel.org Signed-off-by: Jinghao Jia Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman commit d44bd49abe3defbc205f058f0f60aa65bc31f78a Author: Takashi Sakamoto Date: Tue Jan 2 20:01:50 2024 +0900 firewire: ohci: suppress unexpected system reboot in AMD Ryzen machines and ASM108x/VT630x PCIe cards commit ac9184fbb8478dab4a0724b279f94956b69be827 upstream. VIA VT6306/6307/6308 provides PCI interface compliant to 1394 OHCI. When the hardware is combined with Asmedia ASM1083/1085 PCIe-to-PCI bus bridge, it appears that accesses to its 'Isochronous Cycle Timer' register (offset 0xf0 on PCI memory space) often causes unexpected system reboot in any type of AMD Ryzen machine (both 0x17 and 0x19 families). It does not appears in the other type of machine (AMD pre-Ryzen machine, Intel machine, at least), or in the other OHCI 1394 hardware (e.g. Texas Instruments). The issue explicitly appears at a commit dcadfd7f7c74 ("firewire: core: use union for callback of transaction completion") added to v6.5 kernel. It changed 1394 OHCI driver to access to the register every time to dispatch local asynchronous transaction. However, the issue exists in older version of kernel as long as it runs in AMD Ryzen machine, since the access to the register is required to maintain bus time. It is not hard to imagine that users experience the unexpected system reboot when generating bus reset by plugging any devices in, or reading the register by time-aware application programs; e.g. audio sample processing. This commit suppresses the unexpected system reboot in the combination of hardware. It avoids the access itself. As a result, the software stack can not provide the hardware time anymore to unit drivers, userspace applications, and nodes in the same IEEE 1394 bus. It brings apparent disadvantage since time-aware application programs require it, while time-unaware applications are available again; e.g. sbp2. Cc: stable@vger.kernel.org Reported-by: Jiri Slaby Closes: https://bugzilla.suse.com/show_bug.cgi?id=1215436 Reported-by: Mario Limonciello Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217994 Reported-by: Tobias Gruetzmacher Closes: https://sourceforge.net/p/linux1394/mailman/message/58711901/ Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2240973 Closes: https://bugs.launchpad.net/linux/+bug/2043905 Link: https://lore.kernel.org/r/20240102110150.244475-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto Signed-off-by: Greg Kroah-Hartman commit e73022d600175f2d88010438b91897c624e33c64 Author: Yu Zhao Date: Fri Dec 22 21:56:47 2023 -0700 mm/mglru: skip special VMAs in lru_gen_look_around() commit c28ac3c7eb945fee6e20f47d576af68fdff1392a upstream. Special VMAs like VM_PFNMAP can contain anon pages from COW. There isn't much profit in doing lookaround on them. Besides, they can trigger the pte_special() warning in get_pte_pfn(). Skip them in lru_gen_look_around(). Link: https://lkml.kernel.org/r/20231223045647.1566043-1-yuzhao@google.com Fixes: 018ee47f1489 ("mm: multi-gen LRU: exploit locality in rmap") Signed-off-by: Yu Zhao Reported-by: syzbot+03fd9b3f71641f0ebf2d@syzkaller.appspotmail.com Closes: https://lore.kernel.org/000000000000f9ff00060d14c256@google.com/ Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 22c8e0b87bcb03c9310c4a9e0781a77d1d2dfc8a Author: Eric Dumazet Date: Wed Sep 20 17:29:41 2023 +0000 net: constify sk_dst_get() and __sk_dst_get() argument [ Upstream commit 5033f58d5feed1040eebeadb0c5efc95b8bf5720 ] Both helpers only read fields from their socket argument. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f797a2f74a8e4e24a4f9f19cb2d37e245d224c9b Author: duanqiangwen Date: Thu Dec 14 10:33:37 2023 +0800 net: libwx: fix memory leak on free page [ Upstream commit 738b54b9b6236f573eed2453c4cbfa77326793e2 ] ifconfig ethx up, will set page->refcount larger than 1, and then ifconfig ethx down, calling __page_frag_cache_drain() to free pages, it is not compatible with page pool. So deleting codes which changing page->refcount. Fixes: 3c47e8ae113a ("net: libwx: Support to receive packets in NAPI") Signed-off-by: duanqiangwen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 51079378514d4cc3f8cc24c5ee09d02662a7ff0a Author: Ira Weiny Date: Mon Oct 16 16:25:05 2023 -0700 cxl/pmu: Ensure put_device on pmu devices [ Upstream commit ef3d5cf9c59cccb012aa6b93d99f4c6eb5d6648e ] The following kmemleaks were detected when removing the cxl module stack: unreferenced object 0xffff88822616b800 (size 1024): ... backtrace: [<00000000bedc6f83>] kmalloc_trace+0x26/0x90 [<00000000448d1afc>] devm_cxl_pmu_add+0x3a/0x110 [cxl_core] [<00000000ca3bfe16>] 0xffffffffa105213b [<00000000ba7f78dc>] local_pci_probe+0x41/0x90 [<000000005bb027ac>] pci_device_probe+0xb0/0x1c0 ... unreferenced object 0xffff8882260abcc0 (size 16): ... hex dump (first 16 bytes): 70 6d 75 5f 6d 65 6d 30 2e 30 00 26 82 88 ff ff pmu_mem0.0.&.... backtrace: ... [<00000000152b5e98>] dev_set_name+0x43/0x50 [<00000000c228798b>] devm_cxl_pmu_add+0x102/0x110 [cxl_core] [<00000000ca3bfe16>] 0xffffffffa105213b [<00000000ba7f78dc>] local_pci_probe+0x41/0x90 [<000000005bb027ac>] pci_device_probe+0xb0/0x1c0 ... unreferenced object 0xffff8882272af200 (size 256): ... backtrace: [<00000000bedc6f83>] kmalloc_trace+0x26/0x90 [<00000000a14d1813>] device_add+0x4ea/0x890 [<00000000a3f07b47>] devm_cxl_pmu_add+0xbe/0x110 [cxl_core] [<00000000ca3bfe16>] 0xffffffffa105213b [<00000000ba7f78dc>] local_pci_probe+0x41/0x90 [<000000005bb027ac>] pci_device_probe+0xb0/0x1c0 ... devm_cxl_pmu_add() correctly registers a device remove function but it only calls device_del() which is only part of device unregistration. Properly call device_unregister() to free up the memory associated with the device. Fixes: 1ad3f701c399 ("cxl/pci: Find and register CXL PMU devices") Cc: Jonathan Cameron Signed-off-by: Ira Weiny Reviewed-by: Jonathan Cameron Reviewed-by: Dave Jiang Link: https://lore.kernel.org/r/20231016-pmu-unregister-fix-v1-1-1e2eb2fa3c69@intel.com Signed-off-by: Dan Williams Signed-off-by: Sasha Levin commit 95b3904a261a9f810205da560e802cc326f50d77 Author: Eric Dumazet Date: Tue Dec 12 16:46:21 2023 +0000 net: prevent mss overflow in skb_segment() [ Upstream commit 23d05d563b7e7b0314e65c8e882bc27eac2da8e7 ] Once again syzbot is able to crash the kernel in skb_segment() [1] GSO_BY_FRAGS is a forbidden value, but unfortunately the following computation in skb_segment() can reach it quite easily : mss = mss * partial_segs; 65535 = 3 * 5 * 17 * 257, so many initial values of mss can lead to a bad final result. Make sure to limit segmentation so that the new mss value is smaller than GSO_BY_FRAGS. [1] general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 1 PID: 5079 Comm: syz-executor993 Not tainted 6.7.0-rc4-syzkaller-00141-g1ae4cd3cbdd0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023 RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551 Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00 RSP: 0018:ffffc900043473d0 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597 RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070 RBP: ffffc90004347578 R08: 0000000000000005 R09: 000000000000ffff R10: 000000000000ffff R11: 0000000000000002 R12: ffff888063202ac0 R13: 0000000000010000 R14: 000000000000ffff R15: 0000000000000046 FS: 0000555556e7e380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020010000 CR3: 0000000027ee2000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: udp6_ufo_fragment+0xa0e/0xd00 net/ipv6/udp_offload.c:109 ipv6_gso_segment+0x534/0x17e0 net/ipv6/ip6_offload.c:120 skb_mac_gso_segment+0x290/0x610 net/core/gso.c:53 __skb_gso_segment+0x339/0x710 net/core/gso.c:124 skb_gso_segment include/net/gso.h:83 [inline] validate_xmit_skb+0x36c/0xeb0 net/core/dev.c:3626 __dev_queue_xmit+0x6f3/0x3d60 net/core/dev.c:4338 dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x257/0x380 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x24c6/0x5220 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 __sys_sendto+0x255/0x340 net/socket.c:2190 __do_sys_sendto net/socket.c:2202 [inline] __se_sys_sendto net/socket.c:2198 [inline] __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b RIP: 0033:0x7f8692032aa9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 d1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff8d685418 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f8692032aa9 RDX: 0000000000010048 RSI: 00000000200000c0 RDI: 0000000000000003 RBP: 00000000000f4240 R08: 0000000020000540 R09: 0000000000000014 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff8d685480 R13: 0000000000000001 R14: 00007fff8d685480 R15: 0000000000000003 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551 Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00 RSP: 0018:ffffc900043473d0 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597 RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070 RBP: ffffc90004347578 R08: 0000000000000005 R09: 000000000000ffff R10: 000000000000ffff R11: 0000000000000002 R12: ffff888063202ac0 R13: 0000000000010000 R14: 000000000000ffff R15: 0000000000000046 FS: 0000555556e7e380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020010000 CR3: 0000000027ee2000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Fixes: 3953c46c3ac7 ("sk_buff: allow segmenting based on frag sizes") Signed-off-by: Eric Dumazet Cc: Marcelo Ricardo Leitner Reviewed-by: Willem de Bruijn Link: https://lore.kernel.org/r/20231212164621.4131800-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e1b45baa2e382f7058f993e01ac48df224ff70c6 Author: Haren Myneni Date: Sat Nov 25 15:51:04 2023 -0800 powerpc/pseries/vas: Migration suspend waits for no in-progress open windows [ Upstream commit 0cf72f7f14d12cb065c3d01954cf42fc5638aa69 ] The hypervisor returns migration failure if all VAS windows are not closed. During pre-migration stage, vas_migration_handler() sets migration_in_progress flag and closes all windows from the list. The allocate VAS window routine checks the migration flag, setup the window and then add it to the list. So there is possibility of the migration handler missing the window that is still in the process of setup. t1: Allocate and open VAS t2: Migration event window lock vas_pseries_mutex If migration_in_progress set unlock vas_pseries_mutex return open window HCALL unlock vas_pseries_mutex Modify window HCALL lock vas_pseries_mutex setup window migration_in_progress=true Closes all windows from the list // May miss windows that are // not in the list unlock vas_pseries_mutex lock vas_pseries_mutex return if nr_closed_windows == 0 // No DLPAR CPU or migration add window to the list // Window will be added to the // list after the setup is completed unlock vas_pseries_mutex return unlock vas_pseries_mutex Close VAS window // due to DLPAR CPU or migration return -EBUSY This patch resolves the issue with the following steps: - Set the migration_in_progress flag without holding mutex. - Introduce nr_open_wins_progress counter in VAS capabilities struct - This counter tracks the number of open windows are still in progress - The allocate setup window thread closes windows if the migration is set and decrements nr_open_window_progress counter - The migration handler waits for no in-progress open windows. The code flow with the fix is as follows: t1: Allocate and open VAS t2: Migration event window lock vas_pseries_mutex If migration_in_progress set unlock vas_pseries_mutex return open window HCALL nr_open_wins_progress++ // Window opened, but not // added to the list yet unlock vas_pseries_mutex Modify window HCALL migration_in_progress=true setup window lock vas_pseries_mutex Closes all windows from the list While nr_open_wins_progress { unlock vas_pseries_mutex lock vas_pseries_mutex sleep if nr_closed_windows == 0 // Wait if any open window in or migration is not started // progress. The open window // No DLPAR CPU or migration // thread closes the window without add window to the list // adding to the list and return if nr_open_wins_progress-- // the migration is in progress. unlock vas_pseries_mutex return Close VAS window nr_open_wins_progress-- unlock vas_pseries_mutex return -EBUSY lock vas_pseries_mutex } unlock vas_pseries_mutex return Fixes: 37e6764895ef ("powerpc/pseries/vas: Add VAS migration handler") Signed-off-by: Haren Myneni Signed-off-by: Michael Ellerman Link: https://msgid.link/20231125235104.3405008-1-haren@linux.ibm.com Signed-off-by: Sasha Levin commit 24f855a88c9580d3aea5150d971e0ffb0f6e6b6d Author: Yong-Xuan Wang Date: Wed Dec 13 06:16:09 2023 +0000 RISCV: KVM: update external interrupt atomically for IMSIC swfile [ Upstream commit 4ad9843e1ea088bd2529290234c6c4c6374836a7 ] The emulated IMSIC update the external interrupt pending depending on the value of eidelivery and topei. It might lose an interrupt when it is interrupted before setting the new value to the pending status. For example, when VCPU0 sends an IPI to VCPU1 via IMSIC: VCPU0 VCPU1 CSRSWAP topei = 0 The VCPU1 has claimed all the external interrupt in its interrupt handler. topei of VCPU1's IMSIC = 0 set pending in VCPU1's IMSIC topei of VCPU1' IMSIC = 1 set the external interrupt pending of VCPU1 clear the external interrupt pending of VCPU1 When the VCPU1 switches back to VS mode, it exits the interrupt handler because the result of CSRSWAP topei is 0. If there are no other external interrupts injected into the VCPU1's IMSIC, VCPU1 will never know this pending interrupt unless it initiative read the topei. If the interruption occurs between updating interrupt pending in IMSIC and updating external interrupt pending of VCPU, it will not cause a problem. Suppose that the VCPU1 clears the IPI pending in IMSIC right after VCPU0 sets the pending, the external interrupt pending of VCPU1 will not be set because the topei is 0. But when the VCPU1 goes back to VS mode, the pending IPI will be reported by the CSRSWAP topei, it will not lose this interrupt. So we only need to make the external interrupt updating procedure as a critical section to avoid the problem. Fixes: db8b7e97d613 ("RISC-V: KVM: Add in-kernel virtualization of AIA IMSIC") Tested-by: Roy Lin Tested-by: Wayling Chen Co-developed-by: Vincent Chen Signed-off-by: Vincent Chen Signed-off-by: Yong-Xuan Wang Signed-off-by: Anup Patel Signed-off-by: Sasha Levin commit 44386067682818822fee1b166c4eb875e56cb65d Author: Yang Yingliang Date: Wed Nov 29 17:00:00 2023 +0800 dmaengine: fsl-edma: fix wrong pointer check in fsl_edma3_attach_pd() [ Upstream commit bffa7218dcddb80e7f18dfa545dd4b359b11dd93 ] device_link_add() returns NULL pointer not PTR_ERR() when it fails, so replace the IS_ERR() check with NULL pointer check. Fixes: 72f5801a4e2b ("dmaengine: fsl-edma: integrate v3 support") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20231129090000.841440-1-yangyingliang@huaweicloud.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 7734bb38104ac0b199b3a4de7a9b619dcc0f0d75 Author: Guanjun Date: Mon Dec 11 13:37:03 2023 +0800 dmaengine: idxd: Protect int_handle field in hw descriptor [ Upstream commit 778dfacc903d4b1ef5b7a9726e3a36bc15913d29 ] The int_handle field in hw descriptor should also be protected by wmb() before possibly triggering a DMA read. Fixes: eb0cf33a91b4 (dmaengine: idxd: move interrupt handle assignment) Signed-off-by: Guanjun Reviewed-by: Dave Jiang Reviewed-by: Fenghua Yu Reviewed-by: Lijun Pan Link: https://lore.kernel.org/r/20231211053704.2725417-2-guanjun@linux.alibaba.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 1695423c96307edea8eafd9658f8f97a2371346a Author: Alex Deucher Date: Thu Nov 30 17:34:07 2023 -0500 drm/amd/display: Increase frame warning limit with KASAN or KCSAN in dml [ Upstream commit 5b750b22530fe53bf7fd6a30baacd53ada26911b ] Does the same thing as: commit 6740ec97bcdb ("drm/amd/display: Increase frame warning limit with KASAN or KCSAN in dml2") Reviewed-by: Harry Wentland Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202311302107.hUDXVyWT-lkp@intel.com/ Fixes: 67e38874b85b ("drm/amd/display: Increase num voltage states to 40") Signed-off-by: Alex Deucher Cc: Alvin Lee Cc: Hamza Mahfooz Cc: Samson Tam Cc: Harry Wentland Signed-off-by: Sasha Levin commit e4a5b2f60e0697ad6f4844a76b142764cad3d745 Author: Alison Schofield Date: Mon Nov 13 14:13:24 2023 -0800 kernel/resource: Increment by align value in get_free_mem_region() [ Upstream commit 659aa050a53817157b7459529538598a6449c1d3 ] Currently get_free_mem_region() searches for available capacity in increments equal to the region size being requested. This can cause the search to take giant steps through the resource leaving needless gaps and missing available space. Specifically 'cxl create-region' fails with ERANGE even though capacity of the given size and CXL's expected 256M x InterleaveWays alignment can be satisfied. Replace the total-request-size increment with a next alignment increment so that the next possible address is always examined for availability. Fixes: 14b80582c43e ("resource: Introduce alloc_free_mem_region()") Reported-by: Dmytro Adamenko Reported-by: Dan Williams Signed-off-by: Alison Schofield Reviewed-by: Dave Jiang Link: https://lore.kernel.org/r/20231113221324.1118092-1-alison.schofield@intel.com Cc: Jason Gunthorpe Reviewed-by: Christoph Hellwig Signed-off-by: Dan Williams Signed-off-by: Sasha Levin commit 4c269350e3c66596fbcc86229f6b54cec966f2c5 Author: Alison Schofield Date: Sun Nov 26 16:09:29 2023 -0800 cxl/core: Always hold region_rwsem while reading poison lists [ Upstream commit 5558b92e8d39e18aa19619be2ee37274e9592528 ] A read of a device poison list is triggered via a sysfs attribute and the results are logged as kernel trace events of type cxl_poison. The work is managed by either: a) the region driver when one of more regions map the device, or by b) the memdev driver when no regions map the device. In the case of a) the region driver holds the region_rwsem while reading the poison by committed endpoint decoder mappings and for any unmapped resources. This makes sure that the cxl_poison trace event trace reports valid region info. (Region name, HPA, and UUID). In the case of b) the memdev driver holds the dpa_rwsem preventing new DPA resources from being attached to a region. However, it leaves a gap between region attach and decoder commit actions. If a DPA in the gap is in the poison list, the cxl_poison trace event will omit the region info. Close the gap by holding the region_rwsem and the dpa_rwsem when reading poison per memdev. Since both methods now hold both locks, down_read both from the caller. Doing so also addresses the lockdep assert that found this issue: Commit 458ba8189cb4 ("cxl: Add cxl_decoders_committed() helper") Fixes: f0832a586396 ("cxl/region: Provide region info to the cxl_poison trace event") Signed-off-by: Alison Schofield Reviewed-by: Davidlohr Bueso Reviewed-by: Dave Jiang Link: https://lore.kernel.org/r/08e8e7ec9a3413b91d51de39e385653494b1eed0.1701041440.git.alison.schofield@intel.com Signed-off-by: Dan Williams Signed-off-by: Sasha Levin commit 07f9a20b899a15bb8d280e3168e6a0efc77061bd Author: Dave Jiang Date: Mon Oct 16 10:57:48 2023 -0700 cxl: Add cxl_decoders_committed() helper [ Upstream commit 458ba8189cb4380aa6a6cc4d52ab067f80a64829 ] Add a helper to retrieve the number of decoders committed for the port. Replace all the open coding of the calculation with the helper. Link: https://lore.kernel.org/linux-cxl/651c98472dfed_ae7e729495@dwillia2-xfh.jf.intel.com.notmuch/ Suggested-by: Dan Williams Signed-off-by: Dave Jiang Reviewed-by: Jonathan Cameron Reviewed-by: Jim Harris Reviewed-by: Alison Schofield Link: https://lore.kernel.org/r/169747906849.272156.1729290904857372335.stgit@djiang5-mobl3 Signed-off-by: Dan Williams Stable-dep-of: 5558b92e8d39 ("cxl/core: Always hold region_rwsem while reading poison lists") Signed-off-by: Sasha Levin commit 9826255cdec671a4f0f083d457cfc79b95bbc738 Author: Alvin Lee Date: Wed Nov 8 17:16:28 2023 -0500 drm/amd/display: Increase num voltage states to 40 [ Upstream commit 67e38874b85b8df7b23d29f78ac3d7ecccd9519d ] [Description] If during driver init stage there are greater than 20 intermediary voltage states while constructing the SOC BB we could hit issues because we will index outside of the clock_limits array and start overwriting data. Increase the total number of states to 40 to avoid this issue. Cc: stable@vger.kernel.org # 6.1+ Reviewed-by: Samson Tam Acked-by: Hamza Mahfooz Signed-off-by: Alvin Lee Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 93d67b62c7689644b9555405cc64cefa9ee58436 Author: Ville Syrjälä Date: Tue Nov 21 07:43:15 2023 +0200 drm/i915: Call intel_pre_plane_updates() also for pipes getting enabled [ Upstream commit d21a3962d3042e6f56ad324cf18bdd64a1e6ecfa ] We used to call intel_pre_plane_updates() for any pipe going through a modeset whether the pipe was previously enabled or not. This in fact needed to apply all the necessary clock gating workarounds/etc. Restore the correct behaviour. Fixes: 39919997322f ("drm/i915: Disable all planes before modesetting any pipes") Reviewed-by: Jani Nikula Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20231121054324.9988-3-ville.syrjala@linux.intel.com (cherry picked from commit e0d5ce11ed0a21bb2bf328ad82fd261783c7ad88) Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit c33fc69553b21080f38ed58fa0673a7155338281 Author: Alex Bee Date: Mon Nov 27 19:14:18 2023 +0100 clk: rockchip: rk3128: Fix SCLK_SDMMC's clock name [ Upstream commit 99fe9ee56bd2f7358f1bc72551c2f3a6bbddf80a ] SCLK_SDMMC is the parent for SCLK_SDMMC_DRV and SCLK_SDMMC_SAMPLE, but used with the (more) correct name sclk_sdmmc. SD card tuning does currently fail as the parent can't be found under that name. There is no need to suffix the name with '0' since RK312x SoCs do have a single sdmmc controller - so rename it to the name which is already used by it's children. Fixes: f6022e88faca ("clk: rockchip: add clock controller for rk3128") Signed-off-by: Alex Bee Link: https://lore.kernel.org/r/20231127181415.11735-6-knaerzche@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit b58d2fc1f94de6476dbf9ab5591c4233366ec6a3 Author: Finley Xiao Date: Mon Nov 27 19:14:16 2023 +0100 clk: rockchip: rk3128: Fix aclk_peri_src's parent [ Upstream commit 98dcc6be3859fb15257750b8e1d4e0eefd2c5e1e ] According to the TRM there are no specific gpll_peri, cpll_peri, gpll_div2_peri or gpll_div3_peri gates, but a single clk_peri_src gate. Instead mux_clk_peri_src directly connects to the plls respectively the pll divider clocks. Fix this by creating a single gated composite. Also rename all occurrences of aclk_peri_src to clk_peri_src, since it is the parent for peri aclks, pclks and hclks. That name also matches the one used in the TRM. Fixes: f6022e88faca ("clk: rockchip: add clock controller for rk3128") Signed-off-by: Finley Xiao [renamed aclk_peri_src -> clk_peri_src and added commit message] Signed-off-by: Alex Bee Link: https://lore.kernel.org/r/20231127181415.11735-4-knaerzche@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 09aa95c0e7147f810c05301e1999949c5b99d3f6 Author: Su Hui Date: Mon Nov 20 17:10:47 2023 +0800 phy: sunplus: return negative error code in sp_usb_phy_probe [ Upstream commit 2a9c713825b3127ece11984abf973672c9779518 ] devm_phy_create() return negative error code, 'ret' should be 'PTR_ERR(phy)' rather than '-PTR_ERR(phy)'. Fixes: 99d9ccd97385 ("phy: usb: Add USB2.0 phy driver for Sunplus SP7021") Signed-off-by: Su Hui Link: https://lore.kernel.org/r/20231120091046.163781-1-suhui@nfschina.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit c7573ba35562475e0d8a01e3ffe3b70c7bb9d6f6 Author: Michael Walle Date: Thu Nov 23 12:02:02 2023 +0100 phy: mediatek: mipi: mt8183: fix minimal supported frequency [ Upstream commit 06f76e464ac81c6915430b7155769ea4ef16efe4 ] The lowest supported clock frequency of the PHY is 125MHz (see also mtk_mipi_tx_pll_enable()), but the clamping in .round_rate() has the wrong minimal value, which will make the .enable() op return -EINVAL on low frequencies. Fix the minimal clamping value. Fixes: efda51a58b4a ("drm/mediatek: add mipi_tx driver for mt8183") Signed-off-by: Michael Walle Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20231123110202.2025585-1-mwalle@kernel.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 9cdfbfc652ac5db4d7791a53c76574f5896ae3ee Author: Lu Baolu Date: Wed Nov 22 11:26:02 2023 +0800 iommu/vt-d: Support enforce_cache_coherency only for empty domains [ Upstream commit e645c20e8e9cde549bc233435d3c1338e1cd27fe ] The enforce_cache_coherency callback ensures DMA cache coherency for devices attached to the domain. Intel IOMMU supports enforced DMA cache coherency when the Snoop Control bit in the IOMMU's extended capability register is set. Supporting it differs between legacy and scalable modes. In legacy mode, it's supported page-level by setting the SNP field in second-stage page-table entries. In scalable mode, it's supported in PASID-table granularity by setting the PGSNP field in PASID-table entries. In legacy mode, mappings before attaching to a device have SNP fields cleared, while mappings after the callback have them set. This means partial DMAs are cache coherent while others are not. One possible fix is replaying mappings and flipping SNP bits when attaching a domain to a device. But this seems to be over-engineered, given that all real use cases just attach an empty domain to a device. To meet practical needs while reducing mode differences, only support enforce_cache_coherency on a domain without mappings if SNP field is used. Fixes: fc0051cb9590 ("iommu/vt-d: Check domain force_snooping against attached devices") Signed-off-by: Lu Baolu Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20231114011036.70142-1-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 41294f9d178257fda7535983cf13693d38cc4914 Author: Nuno Sa Date: Mon Nov 6 16:07:30 2023 +0100 iio: imu: adis16475: use bit numbers in assign_bit() [ Upstream commit 1cd2fe4fd63e54b799a68c0856bda18f2e40caa8 ] assign_bit() expects a bit number and not a mask like BIT(x). Hence, just remove the BIT() macro from the #defines. Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202311060647.i9XyO4ej-lkp@intel.com/ Fixes: fff7352bf7a3ce ("iio: imu: Add support for adis16475") Signed-off-by: Nuno Sa Link: https://lore.kernel.org/r/20231106150730.945-1-nuno.sa@analog.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 634d43a2dafa29c7c4ef9913bb951d25235ae42a Author: Xiaolei Wang Date: Tue Nov 14 06:57:13 2023 +0800 dmaengine: fsl-edma: Add judgment on enabling round robin arbitration [ Upstream commit 3448397a47c08c291c3fccb7ac5f0f429fd547e0 ] Add judgment on enabling round robin arbitration to avoid exceptions if this function is not supported. Call trace: fsl_edma_resume_early+0x1d4/0x208 dpm_run_callback+0xd4/0x304 device_resume_early+0xb0/0x208 dpm_resume_early+0x224/0x528 suspend_devices_and_enter+0x3e4/0xd00 pm_suspend+0x3c4/0x910 state_store+0x90/0x124 kobj_attr_store+0x48/0x64 sysfs_kf_write+0x84/0xb4 kernfs_fop_write_iter+0x19c/0x264 vfs_write+0x664/0x858 ksys_write+0xc8/0x180 __arm64_sys_write+0x44/0x58 invoke_syscall+0x5c/0x178 el0_svc_common.constprop.0+0x11c/0x14c do_el0_svc+0x30/0x40 el0_svc+0x58/0xa8 el0t_64_sync_handler+0xc0/0xc4 el0t_64_sync+0x190/0x194 Fixes: 72f5801a4e2b ("dmaengine: fsl-edma: integrate v3 support") Signed-off-by: Xiaolei Wang Reviewed-by: Frank Li Link: https://lore.kernel.org/r/20231113225713.1892643-3-xiaolei.wang@windriver.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit df9e5371221fa7360dfc002079fdc8966109542a Author: Xiaolei Wang Date: Tue Nov 14 06:57:12 2023 +0800 dmaengine: fsl-edma: Do not suspend and resume the masked dma channel when the system is sleeping [ Upstream commit 2838a897654c4810153cc51646414ffa54fd23b0 ] Some channels may be masked. When the system is suspended, if these masked channels are not filtered out, this will lead to null pointer operations and system crash: Unable to handle kernel NULL pointer dereference at virtual address Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000894300000 [00000000000002a0] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP Modules linked in: CPU: 1 PID: 989 Comm: sh Tainted: G B 6.6.0-16203-g557fb7a3ec4c-dirty #70 Hardware name: Freescale i.MX8QM MEK (DT) pstate: 400000c5 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: fsl_edma_disable_request+0x3c/0x78 lr: fsl_edma_disable_request+0x3c/0x78 sp:ffff800089ae7690 x29: ffff800089ae7690 x28: ffff000807ab5440 x27: ffff000807ab5830 x26: 0000000000000008 x25: 0000000000000278 x24: 0000000000000001 23: ffff000807ab4328 x22: 0000000000000000 x21: 0000000000000009 x20: ffff800082616940 x19: 0000000000000000 x18: 0000000000000000 x17: 3d3d3d3d3d3d3d3d x16: 3d3d3d3d3d3d3d3d x15: 3d3d3d3d3d3d3d3d x14: 3d3d3d3d3d3d3d3d x13: 3d3d3d3d3d3d3d3d x12: 1ffff00010d45724 x11: ffff700010d45724 x10: dfff800000000000 x9: dfff800000000000 x8: 00008fffef2ba8dc x7: 0000000000000001 x6: ffff800086a2b927 x5: ffff800086a2b920 x4: ffff700010d45725 x3: ffff8000800d5bbc x2 : 0000000000000000 x1 : ffff000800c1d880 x0 : 0000000000000001 Call trace: fsl_edma_disable_request+0x3c/0x78 fsl_edma_suspend_late+0x128/0x12c dpm_run_callback+0xd4/0x304 __device_suspend_late+0xd0/0x240 dpm_suspend_late+0x174/0x59c suspend_devices_and_enter+0x194/0xd00 pm_suspend+0x3c4/0x910 Fixes: 72f5801a4e2b ("dmaengine: fsl-edma: integrate v3 support") Signed-off-by: Xiaolei Wang Link: https://lore.kernel.org/r/20231113225713.1892643-2-xiaolei.wang@windriver.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 2bd6f2164821669a64c7dbae4b7bf46f36ab5126 Author: Jai Luthra Date: Thu Nov 23 14:57:31 2023 +0530 dmaengine: ti: k3-psil-am62a: Fix SPI PDMA data [ Upstream commit be37542afbfcd27b3bb99a135abf9b4736b96f75 ] AM62Ax has 3 SPI channels where each channel has 4x TX and 4x RX threads. Also fix the thread numbers to match what the firmware expects according to the PSI-L device description. Link: http://downloads.ti.com/tisci/esd/latest/5_soc_doc/am62ax/psil_cfg.html [1] Fixes: aac6db7e243a ("dmaengine: ti: k3-psil-am62a: Add AM62Ax PSIL and PDMA data") Signed-off-by: Jai Luthra Link: https://lore.kernel.org/r/20231123-psil_fix-v1-1-6604d80819be@ti.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 6c9e7caeb29a3df95e262d33355ab066d433d266 Author: Ronald Wahl Date: Mon Oct 30 20:01:13 2023 +0100 dmaengine: ti: k3-psil-am62: Fix SPI PDMA data [ Upstream commit 744f5e7b69710701dc225020769138f8ca2894df ] AM62x has 3 SPI channels where each channel has 4 TX and 4 RX threads. This also fixes the thread numbers. Signed-off-by: Ronald Wahl Fixes: 5ac6bfb58777 ("dmaengine: ti: k3-psil: Add AM62x PSIL and PDMA data") Reviewed-by: Jai Luthra Acked-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20231030190113.16782-1-rwahl@gmx.de Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit a7ccc9d9001b59a7ce56b3655386cc76885ad8fe Author: Andrew Davis Date: Wed Oct 25 09:33:02 2023 -0500 phy: ti: gmii-sel: Fix register offset when parent is not a syscon node [ Upstream commit 0f40d5099cd6d828fd7de6227d3eabe86016724c ] When the node for this phy selector is a child node of a syscon node then the property 'reg' is used as an offset into the parent regmap. When the node is standalone and gets its own regmap this offset is pre-applied. So we need to track which method was used to get the regmap and not apply the offset in the standalone case. Fixes: 1fdfa7cccd35 ("phy: ti: gmii-sel: Allow parent to not be syscon node") Signed-off-by: Andrew Davis Reviewed-by: Roger Quadros Link: https://lore.kernel.org/r/20231025143302.1265633-1-afd@ti.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 42db0099eca3bee8459b8c0121975dc8d7cc1c75 Author: Claudio Imbrenda Date: Thu Nov 2 16:35:49 2023 +0100 KVM: s390: vsie: fix wrong VIR 37 when MSO is used [ Upstream commit 80aea01c48971a1fffc0252d036995572d84950d ] When the host invalidates a guest page, it will also check if the page was used to map the prefix of any guest CPUs, in which case they are stopped and marked as needing a prefix refresh. Upon starting the affected CPUs again, their prefix pages are explicitly faulted in and revalidated if they had been invalidated. A bit in the PGSTEs indicates whether or not a page might contain a prefix. The bit is allowed to overindicate. Pages above 2G are skipped, because they cannot be prefixes, since KVM runs all guests with MSO = 0. The same applies for nested guests (VSIE). When the host invalidates a guest page that maps the prefix of the nested guest, it has to stop the affected nested guest CPUs and mark them as needing a prefix refresh. The same PGSTE bit used for the guest prefix is also used for the nested guest. Pages above 2G are skipped like for normal guests, which is the source of the bug. The nested guest runs is the guest primary address space. The guest could be running the nested guest using MSO != 0. If the MSO + prefix for the nested guest is above 2G, the check for nested prefix will skip it. This will cause the invalidation notifier to not stop the CPUs of the nested guest and not mark them as needing refresh. When the nested guest is run again, its prefix will not be refreshed, since it has not been marked for refresh. This will cause a fatal validity intercept with VIR code 37. Fix this by removing the check for 2G for nested guests. Now all invalidations of pages with the notify bit set will always scan the existing VSIE shadow state descriptors. This allows to catch invalidations of nested guest prefix mappings even when the prefix is above 2G in the guest virtual address space. Fixes: a3508fbe9dc6 ("KVM: s390: vsie: initial support for nested virtualization") Tested-by: Nico Boehr Reviewed-by: Nico Boehr Reviewed-by: David Hildenbrand Message-ID: <20231102153549.53984-1-imbrenda@linux.ibm.com> Signed-off-by: Claudio Imbrenda Signed-off-by: Sasha Levin commit b649a7fe9a8b41a01b608e129a90af09d4b5f52f Author: Jisheng Zhang Date: Tue Sep 12 23:40:40 2023 +0800 riscv: don't probe unaligned access speed if already done [ Upstream commit c20d36cc2a2073d4cdcda92bd7a1bb9b3b3b7c79 ] If misaligned_access_speed percpu var isn't so called "HWPROBE MISALIGNED UNKNOWN", it means the probe has happened(this is possible for example, hotplug off then hotplug on one cpu), and the percpu var has been set, don't probe again in this case. Signed-off-by: Jisheng Zhang Fixes: 584ea6564bca ("RISC-V: Probe for unaligned access speed") Reviewed-by: Conor Dooley Link: https://lore.kernel.org/r/20230912154040.3306-1-jszhang@kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 5d1e4e5fd1e91af95d25a032e5ad893bb9699929 Author: Frederic Weisbecker Date: Fri Oct 27 16:40:49 2023 +0200 rcu/tasks-trace: Handle new PF_IDLE semantics [ Upstream commit a80712b9cc7e57830260ec5e1feb9cdb59e1da2f ] The commit: cff9b2332ab7 ("kernel/sched: Modify initial boot task idle setup") has changed the semantics of what is to be considered an idle task in such a way that the idle task of an offline CPU may not carry the PF_IDLE flag anymore. However RCU-tasks-trace tests the opposite assertion, still assuming that idle tasks carry the PF_IDLE flag during their whole lifecycle. Remove this assumption to avoid spurious warnings but keep the initial test verifying that the idle task is the current task on any offline CPU. Reported-by: Naresh Kamboju Fixes: cff9b2332ab7 ("kernel/sched: Modify initial boot task idle setup") Suggested-by: Joel Fernandes Suggested-by: "Paul E. McKenney" Acked-by: Peter Zijlstra (Intel) Signed-off-by: Frederic Weisbecker Signed-off-by: Sasha Levin commit b3ffc11675847b97144c2b1a430521b22c3cfdd4 Author: Frederic Weisbecker Date: Fri Oct 27 16:40:48 2023 +0200 rcu/tasks: Handle new PF_IDLE semantics [ Upstream commit 9715ed501b585d47444865071674c961c0cc0020 ] The commit: cff9b2332ab7 ("kernel/sched: Modify initial boot task idle setup") has changed the semantics of what is to be considered an idle task in such a way that CPU boot code preceding the actual idle loop is excluded from it. This has however introduced new potential RCU-tasks stalls when either: 1) Grace period is started before init/0 had a chance to set PF_IDLE, keeping it stuck in the holdout list until idle ever schedules. 2) Grace period is started when some possible CPUs have never been online, keeping their idle tasks stuck in the holdout list until the CPU ever boots up. 3) Similar to 1) but with secondary CPUs: Grace period is started concurrently with secondary CPU booting, putting its idle task in the holdout list because PF_IDLE isn't yet observed on it. It stays then stuck in the holdout list until that CPU ever schedules. The effect is mitigated here by the hotplug AP thread that must run to bring the CPU up. Fix this with handling the new semantics of PF_IDLE, keeping in mind that it may or may not be set on an idle task. Take advantage of that to strengthen the coverage of an RCU-tasks quiescent state within an idle task, excluding the CPU boot code from it. Only the code running within the idle loop is now a quiescent state, along with offline CPUs. Fixes: cff9b2332ab7 ("kernel/sched: Modify initial boot task idle setup") Suggested-by: Joel Fernandes Suggested-by: "Paul E. McKenney" Acked-by: Peter Zijlstra (Intel) Signed-off-by: Frederic Weisbecker Signed-off-by: Sasha Levin commit 547c59c83abfc2abfae20262cf30d14c9e73f350 Author: Frederic Weisbecker Date: Fri Oct 27 16:40:47 2023 +0200 rcu: Introduce rcu_cpu_online() [ Upstream commit 2be4686d866ad5896f2bb94d82fe892197aea9c7 ] Export the RCU point of view as to when a CPU is considered offline (ie: when does RCU consider that a CPU is sufficiently down in the hotplug process to not feature any possible read side). This will be used by RCU-tasks whose vision of an offline CPU should reasonably match the one of RCU core. Fixes: cff9b2332ab7 ("kernel/sched: Modify initial boot task idle setup") Acked-by: Peter Zijlstra (Intel) Signed-off-by: Frederic Weisbecker Signed-off-by: Sasha Levin commit 39d04e558882ca317c5e64cc99c2a03494047257 Author: Peter Zijlstra Date: Tue Oct 31 09:53:08 2023 +0100 rcu: Break rcu_node_0 --> &rq->__lock order [ Upstream commit 85d68222ddc5f4522e456d97d201166acb50f716 ] Commit 851a723e45d1 ("sched: Always clear user_cpus_ptr in do_set_cpus_allowed()") added a kfree() call to free any user provided affinity mask, if present. It was changed later to use kfree_rcu() in commit 9a5418bc48ba ("sched/core: Use kfree_rcu() in do_set_cpus_allowed()") to avoid a circular locking dependency problem. It turns out that even kfree_rcu() isn't safe for avoiding circular locking problem. As reported by kernel test robot, the following circular locking dependency now exists: &rdp->nocb_lock --> rcu_node_0 --> &rq->__lock Solve this by breaking the rcu_node_0 --> &rq->__lock chain by moving the resched_cpu() out from under rcu_node lock. [peterz: heavily borrowed from Waiman's Changelog] [paulmck: applied Z qiang feedback] Fixes: 851a723e45d1 ("sched: Always clear user_cpus_ptr in do_set_cpus_allowed()") Reported-by: kernel test robot Acked-by: Waiman Long Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/oe-lkp/202310302207.a25f1a30-oliver.sang@intel.com Signed-off-by: Paul E. McKenney Signed-off-by: Frederic Weisbecker Signed-off-by: Sasha Levin commit 17f449600a98a18709e7f1c85546523d07480b79 Author: Dan Carpenter Date: Tue Oct 31 12:53:06 2023 +0300 ACPI: thermal: Fix acpi_thermal_unregister_thermal_zone() cleanup [ Upstream commit 4b27d5c420335dad7aea1aa6e799fe1d05c63b7e ] The acpi_thermal_unregister_thermal_zone() is paired with acpi_thermal_register_thermal_zone() so it should mirror it. It should clean up all the resources that the register function allocated and leave the stuff that was allocated elsewhere. Unfortunately, it doesn't call thermal_zone_device_disable(). Also it calls kfree(tz->trip_table) when it shouldn't. That was allocated in acpi_thermal_add(). Putting the kfree() here leads to a double free in the acpi_thermal_add() clean up function. Likewise, the acpi_thermal_remove() should mirror acpi_thermal_add() so it should have an explicit kfree(tz->trip_table) as well. Fixes: ec23c1c462de ("ACPI: thermal: Use trip point table to register thermal zones") Signed-off-by: Dan Carpenter Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 04ebb29dc9aabd4c71f5f796e9fa7fee7c477456 Author: Moshe Shemesh Date: Wed Oct 25 20:49:59 2023 +0300 RDMA/mlx5: Fix mkey cache WQ flush [ Upstream commit a53e215f90079f617360439b1b6284820731e34c ] The cited patch tries to ensure no pending works on the mkey cache workqueue by disabling adding new works and call flush_workqueue(). But this workqueue also has delayed works which might still be pending the delay time to be queued. Add cancel_delayed_work() for the delayed works which waits to be queued and then the flush_workqueue() will flush all works which are already queued and running. Fixes: 374012b00457 ("RDMA/mlx5: Fix mkey cache possible deadlock on cleanup") Link: https://lore.kernel.org/r/b8722f14e7ed81452f791764a26d2ed4cfa11478.1698256179.git.leon@kernel.org Signed-off-by: Moshe Shemesh Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit eaab31dceb114bc69a38e0ad00fab88138b76b6e Author: Marek Vasut Date: Fri Oct 27 10:58:24 2023 +0200 clk: si521xx: Increase stack based print buffer size in probe [ Upstream commit 7e52b1164a474dc7b90f68fbb40e35ccd7f7e2e2 ] Increase the size of temporary print buffer on stack to fix the following warnings reported by LKP. Since all the input parameters of snprintf() are under control of this driver, it is not possible to trigger and overflow here, but since the print buffer is on stack and discarded once driver probe() finishes, it is not an issue to increase it by 10 bytes and fix the warning in the process. Make it so. " drivers/clk/clk-si521xx.c: In function 'si521xx_probe': >> drivers/clk/clk-si521xx.c:318:26: warning: '%d' directive output may be truncated writing between 1 and 10 bytes into a region of size 2 [-Wformat-truncation=] snprintf(name, 6, "DIFF%d", i); ^~ drivers/clk/clk-si521xx.c:318:21: note: directive argument in the range [0, 2147483647] snprintf(name, 6, "DIFF%d", i); ^~~~~~~~ drivers/clk/clk-si521xx.c:318:3: note: 'snprintf' output between 6 and 15 bytes into a destination of size 6 snprintf(name, 6, "DIFF%d", i); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ " Fixes: edc12763a3a2 ("clk: si521xx: Clock driver for Skyworks Si521xx I2C PCIe clock generators") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202310260412.AGASjFN4-lkp@intel.com/ Signed-off-by: Marek Vasut Link: https://lore.kernel.org/r/20231027085840.30098-1-marex@denx.de Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 94eacb45d816a5f1827662486c64e69f7972dffc Author: Alex Williamson Date: Mon Oct 16 16:47:35 2023 -0600 vfio/mtty: Overhaul mtty interrupt handling [ Upstream commit 293fbc28818135743f54d46c418ede3e4a20a742 ] The mtty driver does not currently conform to the vfio SET_IRQS uAPI. For example, it claims to support mask and unmask of INTx, but actually does nothing. It claims to support AUTOMASK for INTx, but doesn't. It fails to teardown eventfds under the full semantics specified by the SET_IRQS ioctl. It also fails to teardown eventfds when the device is closed, leading to memory leaks. It claims to support the request IRQ, but doesn't. Fix all these. A side effect of this is that QEMU will now report a warning: vfio : Failed to set up UNMASK eventfd signaling for interrupt \ INTX-0: VFIO_DEVICE_SET_IRQS failure: Inappropriate ioctl for device The fact is that the unmask eventfd was never supported but quietly failed. mtty never honored the AUTOMASK behavior, therefore there was nothing to unmask. QEMU is verbose about the failure, but properly falls back to userspace unmasking. Fixes: 9d1a546c53b4 ("docs: Sample driver to demonstrate how to use Mediated device framework.") Reviewed-by: Cédric Le Goater Link: https://lore.kernel.org/r/20231016224736.2575718-2-alex.williamson@redhat.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 6feb483ab744abf2df2514a850d7e86df710e480 Author: Longfang Liu Date: Fri Oct 13 11:49:57 2023 +0800 crypto: hisilicon/qm - fix EQ/AEQ interrupt issue [ Upstream commit 5acab6eb592387191c1bb745ba9b815e1e076db5 ] During hisilicon accelerator live migration operation. In order to prevent the problem of EQ/AEQ interrupt loss. Migration driver will trigger an EQ/AEQ doorbell at the end of the migration. This operation may cause double interruption of EQ/AEQ events. To ensure that the EQ/AEQ interrupt processing function is normal. The interrupt handling functionality of EQ/AEQ needs to be updated. Used to handle repeated interrupts event. Fixes: b0eed085903e ("hisi_acc_vfio_pci: Add support for VFIO live migration") Signed-off-by: Longfang Liu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit bcf6fe34a314b5db771533157479647e486ce84f Author: Svyatoslav Pankratov Date: Mon Oct 9 13:27:19 2023 +0100 crypto: qat - fix double free during reset [ Upstream commit 01aed663e6c421aeafc9c330bda630976b50a764 ] There is no need to free the reset_data structure if the recovery is unsuccessful and the reset is synchronous. The function adf_dev_aer_schedule_reset() handles the cleanup properly. Only asynchronous resets require such structure to be freed inside the reset worker. Fixes: d8cba25d2c68 ("crypto: qat - Intel(R) QAT driver framework") Signed-off-by: Svyatoslav Pankratov Signed-off-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 64170e83ae89655f884ccf83c43490cd684e2c40 Author: Eric Biggers Date: Sun Oct 8 19:31:16 2023 -0700 crypto: xts - use 'spawn' for underlying single-block cipher [ Upstream commit bb40d32689d73c46de39a0529d551f523f21dc9b ] Since commit adad556efcdd ("crypto: api - Fix built-in testing dependency failures"), the following warning appears when booting an x86_64 kernel that is configured with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y and CONFIG_CRYPTO_AES_NI_INTEL=y, even when CONFIG_CRYPTO_XTS=y and CONFIG_CRYPTO_AES=y: alg: skcipher: skipping comparison tests for xts-aes-aesni because xts(ecb(aes-generic)) is unavailable This is caused by an issue in the xts template where it allocates an "aes" single-block cipher without declaring a dependency on it via the crypto_spawn mechanism. This issue was exposed by the above commit because it reversed the order that the algorithms are tested in. Specifically, when "xts(ecb(aes-generic))" is instantiated and tested during the comparison tests for "xts-aes-aesni", the "xts" template allocates an "aes" crypto_cipher for encrypting tweaks. This resolves to "aes-aesni". (Getting "aes-aesni" instead of "aes-generic" here is a bit weird, but it's apparently intended.) Due to the above-mentioned commit, the testing of "aes-aesni", and the finalization of its registration, now happens at this point instead of before. At the end of that, crypto_remove_spawns() unregisters all algorithm instances that depend on a lower-priority "aes" implementation such as "aes-generic" but that do not depend on "aes-aesni". However, because "xts" does not use the crypto_spawn mechanism for its "aes", its dependency on "aes-aesni" is not recognized by crypto_remove_spawns(). Thus, crypto_remove_spawns() unexpectedly unregisters "xts(ecb(aes-generic))". Fix this issue by making the "xts" template use the crypto_spawn mechanism for its "aes" dependency, like what other templates do. Note, this fix could be applied as far back as commit f1c131b45410 ("crypto: xts - Convert to skcipher"). However, the issue only got exposed by the much more recent changes to how the crypto API runs the self-tests, so there should be no need to backport this to very old kernels. Also, an alternative fix would be to flip the list iteration order in crypto_start_tests() to restore the original testing order. I'm thinking we should do that too, since the original order seems more natural, but it shouldn't be relied on for correctness. Fixes: adad556efcdd ("crypto: api - Fix built-in testing dependency failures") Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 3f1800cade99da5451c908c9257e74e850d0b925 Author: Ian Rogers Date: Fri Oct 6 21:44:38 2023 -0700 bpftool: Align output skeleton ELF code [ Upstream commit 23671f4dfd10b48b4a2fee4768886f0d8ec55b7e ] libbpf accesses the ELF data requiring at least 8 byte alignment, however, the data is generated into a C string that doesn't guarantee alignment. Fix this by assigning to an aligned char array. Use sizeof on the array, less one for the \0 terminator, rather than generating a constant. Fixes: a6cc6b34b93e ("bpftool: Provide a helper method for accessing skeleton's embedded ELF data") Signed-off-by: Ian Rogers Signed-off-by: Andrii Nakryiko Reviewed-by: Alan Maguire Acked-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20231007044439.25171-1-irogers@google.com Signed-off-by: Sasha Levin commit 0b39339f8afa7549125323072a1a29a237ca5c29 Author: Denys Zagorui Date: Thu Sep 7 02:02:10 2023 -0700 bpftool: Fix -Wcast-qual warning [ Upstream commit ebc8484d0e6da9e6c9e8cfa1f40bf94e9c6fc512 ] This cast was made by purpose for older libbpf where the bpf_object_skeleton field is void * instead of const void * to eliminate a warning (as i understand -Wincompatible-pointer-types-discards-qualifiers) but this cast introduces another warning (-Wcast-qual) for libbpf where data field is const void * It makes sense for bpftool to be in sync with libbpf from kernel sources Signed-off-by: Denys Zagorui Signed-off-by: Andrii Nakryiko Acked-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20230907090210.968612-1-dzagorui@cisco.com Stable-dep-of: 23671f4dfd10 ("bpftool: Align output skeleton ELF code") Signed-off-by: Sasha Levin commit 030346df8cc417edbf8f8d77d152a95368480fb8 Author: Eric Dumazet Date: Wed Sep 20 17:29:43 2023 +0000 tcp: derive delack_max from rto_min [ Upstream commit bbf80d713fe75cfbecda26e7c03a9a8d22af2f4f ] While BPF allows to set icsk->->icsk_delack_max and/or icsk->icsk_rto_min, we have an ip route attribute (RTAX_RTO_MIN) to be able to tune rto_min, but nothing to consequently adjust max delayed ack, which vary from 40ms to 200 ms (TCP_DELACK_{MIN|MAX}). This makes RTAX_RTO_MIN of almost no practical use, unless customers are in big trouble. Modern days datacenter communications want to set rto_min to ~5 ms, and the max delayed ack one jiffie smaller to avoid spurious retransmits. After this patch, an "rto_min 5" route attribute will effectively lower max delayed ack timers to 4 ms. Note in the following ss output, "rto:6 ... ato:4" $ ss -temoi dst XXXXXX State Recv-Q Send-Q Local Address:Port Peer Address:Port Process ESTAB 0 0 [2002:a05:6608:295::]:52950 [2002:a05:6608:297::]:41597 ino:255134 sk:1001 <-> skmem:(r0,rb1707063,t872,tb262144,f0,w0,o0,bl0,d0) ts sack cubic wscale:8,8 rto:6 rtt:0.02/0.002 ato:4 mss:4096 pmtu:4500 rcvmss:536 advmss:4096 cwnd:10 bytes_sent:54823160 bytes_acked:54823121 bytes_received:54823120 segs_out:1370582 segs_in:1370580 data_segs_out:1370579 data_segs_in:1370578 send 16.4Gbps pacing_rate 32.6Gbps delivery_rate 1.72Gbps delivered:1370579 busy:26920ms unacked:1 rcv_rtt:34.615 rcv_space:65920 rcv_ssthresh:65535 minrtt:0.015 snd_wnd:65536 While we could argue this patch fixes a bug with RTAX_RTO_MIN, I do not add a Fixes: tag, so that we can soak it a bit before asking backports to stable branches. Signed-off-by: Eric Dumazet Acked-by: Soheil Hassas Yeganeh Acked-by: Neal Cardwell Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 88a884dec1044be5ff33fc7478586c2d870c8559 Author: Bryan O'Donoghue Date: Wed Aug 30 16:16:08 2023 +0100 media: qcom: camss: Fix genpd cleanup [ Upstream commit f69791c39745e64621216fe8919cb73c0065002b ] Right now we never release the power-domains properly on the error path. Add a routine to be reused for this purpose and appropriate jumps in probe() to run that routine where necessary. Fixes: 2f6f8af67203 ("media: camss: Refactor VFE power domain toggling") Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 3c97918a8a65f8a7cd3e1648719d1d6766ed6eba Author: Bryan O'Donoghue Date: Wed Aug 30 16:16:07 2023 +0100 media: qcom: camss: Fix V4L2 async notifier error path [ Upstream commit b278080a89f452063915beda0ade6b3ed5ee4271 ] Previously the jump label err_cleanup was used higher in the probe() function to release the async notifier however the async notifier registration was moved later in the code rendering the previous four jumps redundant. Rename the label from err_cleanup to err_v4l2_device_unregister to capture what the jump does. Fixes: 51397a4ec75d ("media: qcom: Initialise V4L2 async notifier later") Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil [hverkuil: fix old name in commit log: err_v4l2_device_register -> err_v4l2_device_unregister] Signed-off-by: Sasha Levin commit f302f37f1630fa57d309ee8571031d169784141c Author: Tirthendu Sarkar Date: Thu Sep 7 09:20:32 2023 +0530 xsk: add multi-buffer support for sockets sharing umem [ Upstream commit d609f3d228a8efe991f44f11f24146e2a5209755 ] Userspace applications indicate their multi-buffer capability to xsk using XSK_USE_SG socket bind flag. For sockets using shared umem the bind flag may contain XSK_USE_SG only for the first socket. For any subsequent socket the only option supported is XDP_SHARED_UMEM. Add option XDP_UMEM_SG_FLAG in umem config flags to store the multi-buffer handling capability when indicated by XSK_USE_SG option in bing flag by the first socket. Use this to derive multi-buffer capability for subsequent sockets in xsk core. Signed-off-by: Tirthendu Sarkar Fixes: 81470b5c3c66 ("xsk: introduce XSK_USE_SG bind flag for xsk socket") Acked-by: Maciej Fijalkowski Link: https://lore.kernel.org/r/20230907035032.2627879-1-tirthendu.sarkar@intel.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit bf07fda050c80ee4ad87b3f27607dba8314d26f3 Author: Matthew Wilcox (Oracle) Date: Mon Dec 18 13:58:35 2023 +0000 mm/memory-failure: pass the folio and the page to collect_procs() [ Upstream commit 376907f3a0b34a17e80417825f8cc1c40fcba81b ] Patch series "Three memory-failure fixes". I've been looking at the memory-failure code and I believe I have found three bugs that need fixing -- one going all the way back to 2010! I'll have more patches later to use folios more extensively but didn't want these bugfixes to get caught up in that. This patch (of 3): Both collect_procs_anon() and collect_procs_file() iterate over the VMA interval trees looking for a single pgoff, so it is wrong to look for the pgoff of the head page as is currently done. However, it is also wrong to look at page->mapping of the precise page as this is invalid for tail pages. Clear up the confusion by passing both the folio and the precise page to collect_procs(). Link: https://lkml.kernel.org/r/20231218135837.3310403-1-willy@infradead.org Link: https://lkml.kernel.org/r/20231218135837.3310403-2-willy@infradead.org Fixes: 415c64c1453a ("mm/memory-failure: split thp earlier in memory error handling") Signed-off-by: Matthew Wilcox (Oracle) Cc: Dan Williams Cc: Naoya Horiguchi Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 393155f9b2655beaf86a79fe2a72246db3ee2b4a Author: Matthew Wilcox (Oracle) Date: Wed Aug 23 00:13:14 2023 +0100 mm: convert DAX lock/unlock page to lock/unlock folio [ Upstream commit 91e79d22be75fec88ae58d274a7c9e49d6215099 ] The one caller of DAX lock/unlock page already calls compound_head(), so use page_folio() instead, then use a folio throughout the DAX code to remove uses of page->mapping and page->index. [jane.chu@oracle.com: add comment to mf_generic_kill_procss(), simplify mf_generic_kill_procs:folio initialization] Link: https://lkml.kernel.org/r/20230908222336.186313-1-jane.chu@oracle.com Link: https://lkml.kernel.org/r/20230822231314.349200-1-willy@infradead.org Signed-off-by: Matthew Wilcox (Oracle) Signed-off-by: Jane Chu Acked-by: Naoya Horiguchi Cc: Dan Williams Cc: Jane Chu Signed-off-by: Andrew Morton Stable-dep-of: 376907f3a0b3 ("mm/memory-failure: pass the folio and the page to collect_procs()") Signed-off-by: Sasha Levin commit 200bc36613253fe1feb61edd43dcd0e496fdb2e0 Author: Thomas Lange Date: Thu Jan 4 09:57:44 2024 +0100 net: Implement missing SO_TIMESTAMPING_NEW cmsg support [ Upstream commit 382a32018b74f407008615e0e831d05ed28e81cd ] Commit 9718475e6908 ("socket: Add SO_TIMESTAMPING_NEW") added the new socket option SO_TIMESTAMPING_NEW. However, it was never implemented in __sock_cmsg_send thus breaking SO_TIMESTAMPING cmsg for platforms using SO_TIMESTAMPING_NEW. Fixes: 9718475e6908 ("socket: Add SO_TIMESTAMPING_NEW") Link: https://lore.kernel.org/netdev/6a7281bf-bc4a-4f75-bb88-7011908ae471@app.fastmail.com/ Signed-off-by: Thomas Lange Reviewed-by: Willem de Bruijn Link: https://lore.kernel.org/r/20240104085744.49164-1-thomas@corelatus.se Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ea37c4b61107494fd7257f4985568417a894a3e2 Author: Michael Chan Date: Wed Jan 3 16:59:24 2024 -0800 bnxt_en: Remove mis-applied code from bnxt_cfg_ntp_filters() [ Upstream commit e009b2efb7a8850498796b360043ac25c8d3d28f ] The 2 lines to check for the BNXT_HWRM_PF_UNLOAD_SP_EVENT bit was mis-applied to bnxt_cfg_ntp_filters() and should have been applied to bnxt_sp_task(). Fixes: 19241368443f ("bnxt_en: Send PF driver unload notification to all VFs.") Reviewed-by: Andy Gospodarek Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 428ae1b99fce52eb6de16bc9bad406b3129985e1 Author: Claudiu Beznea Date: Wed Jan 3 10:13:53 2024 +0200 net: ravb: Wait for operating mode to be applied [ Upstream commit 9039cd4c61635b2d541009a7cd5e2cc052402f28 ] CSR.OPS bits specify the current operating mode and (according to documentation) they are updated by HW when the operating mode change request is processed. To comply with this check CSR.OPS before proceeding. Commit introduces ravb_set_opmode() that does all the necessities for setting the operating mode (set CCC.OPC (and CCC.GAC, CCC.CSEL, if any) and wait for CSR.OPS) and call it where needed. This should comply with all the HW manuals requirements as different manual variants specify that different modes need to be checked in CSR.OPS when setting CCC.OPC. If gPTP active in config mode is supported and it needs to be enabled, the CCC.GAC and CCC.CSEL needs to be configured along with CCC.OPC in the same write access. For this, ravb_set_opmode() allows passing GAC and CSEL as part of opmode and the function updates accordingly CCC register. Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper") Signed-off-by: Claudiu Beznea Reviewed-by: Sergey Shtylyov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ba75a06fa273f1ee34543228970fe90235f5121e Author: Chen Ni Date: Wed Jan 3 03:35:34 2024 +0000 asix: Add check for usbnet_get_endpoints [ Upstream commit eaac6a2d26b65511e164772bec6918fcbc61938e ] Add check for usbnet_get_endpoints() and return the error if it fails in order to transfer the error. Fixes: 16626b0cc3d5 ("asix: Add a new driver for the AX88172A") Signed-off-by: Chen Ni Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 67a4a2589db0d43f68c9eda4eab6d03969ae6d5f Author: Naveen Mamindlapalli Date: Tue Jan 2 19:44:00 2024 +0530 octeontx2-af: Re-enable MAC TX in otx2_stop processing [ Upstream commit 818ed8933bd17bc91a9fa8b94a898189c546fc1a ] During QoS scheduling testing with multiple strict priority flows, the netdev tx watchdog timeout routine is invoked when a low priority QoS queue doesn't get a chance to transmit the packets because other high priority flows are completely subscribing the transmit link. The netdev tx watchdog timeout routine will stop MAC RX and TX functionality in otx2_stop() routine before cleanup of HW TX queues which results in SMQ flush errors because the packets belonging to low priority queues will never gets flushed since MAC TX is disabled. This patch fixes the issue by re-enabling MAC TX to ensure the packets in HW pipeline gets flushed properly. Fixes: a7faa68b4e7f ("octeontx2-af: Start/Stop traffic in CGX along with NPC") Signed-off-by: Naveen Mamindlapalli Signed-off-by: Sunil Kovvuri Goutham Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f725e894b12380ecbe72c38efd10f7ce26cd2c87 Author: Naveen Mamindlapalli Date: Tue Jan 2 15:26:43 2024 +0530 octeontx2-af: Always configure NIX TX link credits based on max frame size [ Upstream commit a0d9528f6daf7fe8de217fa80a94d2989d2a57a7 ] Currently the NIX TX link credits are initialized based on the max frame size that can be transmitted on a link but when the MTU is changed, the NIX TX link credits are reprogrammed by the SW based on the new MTU value. Since SMQ max packet length is programmed to max frame size by default, there is a chance that NIX TX may stall while sending a max frame sized packet on the link with insufficient credits to send the packet all at once. This patch avoids stall issue by not changing the link credits dynamically when the MTU is changed. Fixes: 1c74b89171c3 ("octeontx2-af: Wait for TX link idle for credits change") Signed-off-by: Naveen Mamindlapalli Signed-off-by: Sunil Kovvuri Goutham Signed-off-by: Nithin Kumar Dabilpuram Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 511e4a5796243b7c5ccc108966532b050f8f1e2c Author: Wen Gu Date: Wed Dec 27 15:40:35 2023 +0800 net/smc: fix invalid link access in dumping SMC-R connections [ Upstream commit 9dbe086c69b8902c85cece394760ac212e9e4ccc ] A crash was found when dumping SMC-R connections. It can be reproduced by following steps: - environment: two RNICs on both sides. - run SMC-R between two sides, now a SMC_LGR_SYMMETRIC type link group will be created. - set the first RNIC down on either side and link group will turn to SMC_LGR_ASYMMETRIC_LOCAL then. - run 'smcss -R' and the crash will be triggered. BUG: kernel NULL pointer dereference, address: 0000000000000010 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 8000000101fdd067 P4D 8000000101fdd067 PUD 10ce46067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 3 PID: 1810 Comm: smcss Kdump: loaded Tainted: G W E 6.7.0-rc6+ #51 RIP: 0010:__smc_diag_dump.constprop.0+0x36e/0x620 [smc_diag] Call Trace: ? __die+0x24/0x70 ? page_fault_oops+0x66/0x150 ? exc_page_fault+0x69/0x140 ? asm_exc_page_fault+0x26/0x30 ? __smc_diag_dump.constprop.0+0x36e/0x620 [smc_diag] smc_diag_dump_proto+0xd0/0xf0 [smc_diag] smc_diag_dump+0x26/0x60 [smc_diag] netlink_dump+0x19f/0x320 __netlink_dump_start+0x1dc/0x300 smc_diag_handler_dump+0x6a/0x80 [smc_diag] ? __pfx_smc_diag_dump+0x10/0x10 [smc_diag] sock_diag_rcv_msg+0x121/0x140 ? __pfx_sock_diag_rcv_msg+0x10/0x10 netlink_rcv_skb+0x5a/0x110 sock_diag_rcv+0x28/0x40 netlink_unicast+0x22a/0x330 netlink_sendmsg+0x240/0x4a0 __sock_sendmsg+0xb0/0xc0 ____sys_sendmsg+0x24e/0x300 ? copy_msghdr_from_user+0x62/0x80 ___sys_sendmsg+0x7c/0xd0 ? __do_fault+0x34/0x1a0 ? do_read_fault+0x5f/0x100 ? do_fault+0xb0/0x110 __sys_sendmsg+0x4d/0x80 do_syscall_64+0x45/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 When the first RNIC is set down, the lgr->lnk[0] will be cleared and an asymmetric link will be allocated in lgr->link[SMC_LINKS_PER_LGR_MAX - 1] by smc_llc_alloc_alt_link(). Then when we try to dump SMC-R connections in __smc_diag_dump(), the invalid lgr->lnk[0] will be accessed, resulting in this issue. So fix it by accessing the right link. Fixes: f16a7dd5cf27 ("smc: netlink interface for SMC sockets") Reported-by: henaumars Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=7616 Signed-off-by: Wen Gu Reviewed-by: Tony Lu Link: https://lore.kernel.org/r/1703662835-53416-1-git-send-email-guwen@linux.alibaba.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ed192246db7554325e99e1e4f8b01e2a2eaeb9fc Author: Dinghao Liu Date: Wed Dec 27 15:02:27 2023 +0800 net/qla3xxx: fix potential memleak in ql_alloc_buffer_queues [ Upstream commit 89f45c30172c80e55c887f32f1af8e184124577b ] When dma_alloc_coherent() fails, we should free qdev->lrg_buf to prevent potential memleak. Fixes: 1357bfcf7106 ("qla3xxx: Dynamically size the rx buffer queue based on the MTU.") Signed-off-by: Dinghao Liu Link: https://lore.kernel.org/r/20231227070227.10527-1-dinghao.liu@zju.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3ffd05c2cccd28b9bd50956a4ec0c9a6cb9cfa2e Author: Xuan Zhuo Date: Tue Dec 26 17:43:33 2023 +0800 virtio_net: fix missing dma unmap for resize [ Upstream commit 2311e06b9bf3d44e15f9175af177a782806f688f ] For rq, we have three cases getting buffers from virtio core: 1. virtqueue_get_buf{,_ctx} 2. virtqueue_detach_unused_buf 3. callback for virtqueue_resize But in commit 295525e29a5b("virtio_net: merge dma operations when filling mergeable buffers"), I missed the dma unmap for the #3 case. That will leak some memory, because I did not release the pages referred by the unused buffers. If we do such script, we will make the system OOM. while true do ethtool -G ens4 rx 128 ethtool -G ens4 rx 256 free -m done Fixes: 295525e29a5b ("virtio_net: merge dma operations when filling mergeable buffers") Signed-off-by: Xuan Zhuo Acked-by: Michael S. Tsirkin Link: https://lore.kernel.org/r/20231226094333.47740-1-xuanzhuo@linux.alibaba.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e2e5c2a3f90f57f097129b13efe823b8dd32a40c Author: Eric Dumazet Date: Thu Sep 21 08:52:17 2023 +0000 virtio_net: avoid data-races on dev->stats fields [ Upstream commit d12a26b74fb77434b73fe39022266c4b00907219 ] Use DEV_STATS_INC() and DEV_STATS_READ() which provide atomicity on paths that can be used concurrently. Reported-by: syzbot Signed-off-by: Eric Dumazet Reviewed-by: Xuan Zhuo Cc: "Michael S. Tsirkin" Cc: Jason Wang Signed-off-by: David S. Miller Stable-dep-of: 2311e06b9bf3 ("virtio_net: fix missing dma unmap for resize") Signed-off-by: Sasha Levin commit 6d2e4e56576f37e8edbb4032778403a6423d99b6 Author: John Johansen Date: Mon Dec 18 01:10:03 2023 -0800 apparmor: Fix move_mount mediation by detecting if source is detached [ Upstream commit 8026e40608b4d552216d2a818ca7080a4264bb44 ] Prevent move_mount from applying the attach_disconnected flag to move_mount(). This prevents detached mounts from appearing as / when applying mount mediation, which is not only incorrect but could result in bad policy being generated. Basic mount rules like allow mount, allow mount options=(move) -> /target/, will allow detached mounts, allowing older policy to continue to function. New policy gains the ability to specify `detached` as a source option allow mount detached -> /target/, In addition make sure support of move_mount is advertised as a feature to userspace so that applications that generate policy can respond to the addition. Note: this fixes mediation of move_mount when a detached mount is used, it does not fix the broader regression of apparmor mediation of mounts under the new mount api. Link: https://lore.kernel.org/all/68c166b8-5b4d-4612-8042-1dee3334385b@leemhuis.info/T/#mb35fdde37f999f08f0b02d58dc1bf4e6b65b8da2 Fixes: 157a3537d6bc ("apparmor: Fix regression in mount mediation") Reviewed-by: Georgia Garcia Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 1d95d871f907e9f355949451252ec45f8515bb6f Author: Rodrigo Cataldo Date: Fri Dec 8 15:58:16 2023 +0100 igc: Fix hicredit calculation [ Upstream commit 947dfc8138dfaeb6e966e2d661de89eb203e3064 ] According to the Intel Software Manual for I225, Section 7.5.2.7, hicredit should be multiplied by the constant link-rate value, 0x7736. Currently, the old constant link-rate value, 0x7735, from the boards supported on igb are being used, most likely due to a copy'n'paste, as the rest of the logic is the same for both drivers. Update hicredit accordingly. Fixes: 1ab011b0bf07 ("igc: Add support for CBS offloading") Reviewed-by: Kurt Kanzenbach Signed-off-by: Rodrigo Cataldo Acked-by: Vinicius Costa Gomes Tested-by: Naama Meir Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 17f5cfeb15d683d2481498b26b0ed1c4e86380c1 Author: Andrii Staikov Date: Thu Dec 21 14:27:35 2023 +0100 i40e: Restore VF MSI-X state during PCI reset [ Upstream commit 371e576ff3e8580d91d49026e5d5faebf5565558 ] During a PCI FLR the MSI-X Enable flag in the VF PCI MSI-X capability register will be cleared. This can lead to issues when a VF is assigned to a VM because in these cases the VF driver receives no indication of the PF PCI error/reset and additionally it is incapable of restoring the cleared flag in the hypervisor configuration space without fully reinitializing the driver interrupt functionality. Since the VF driver is unable to easily resolve this condition on its own, restore the VF MSI-X flag during the PF PCI reset handling. Fixes: 19b7960b2da1 ("i40e: implement split PCI error reset handler") Co-developed-by: Karen Ostrowska Signed-off-by: Karen Ostrowska Co-developed-by: Mateusz Palczewski Signed-off-by: Mateusz Palczewski Reviewed-by: Wojciech Drewek Reviewed-by: Przemek Kitszel Signed-off-by: Andrii Staikov Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 1ee4eb8024eec36d134337e769e14c800bcacaad Author: Mark Brown Date: Wed Jan 3 18:34:04 2024 +0000 ASoC: meson: g12a-tohdmitx: Fix event generation for S/PDIF mux [ Upstream commit b036d8ef3120b996751495ce25994eea58032a98 ] When a control changes value the return value from _put() should be 1 so we get events generated to userspace notifying applications of the change. While the I2S mux gets this right the S/PDIF mux does not, fix the return value. Fixes: c8609f3870f7 ("ASoC: meson: add g12a tohdmitx control") Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20240103-meson-enum-val-v1-4-424af7a8fb91@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3d5a6ed6aa43c4f7220e8ecf06b4fbfcd2c254f3 Author: Mark Brown Date: Wed Jan 3 18:34:03 2024 +0000 ASoC: meson: g12a-toacodec: Fix event generation [ Upstream commit 172c88244b5f2d3375403ebb504d407be0fded59 ] When a control changes value the return value from _put() should be 1 so we get events generated to userspace notifying applications of the change. We are checking if there has been a change and exiting early if not but we are not providing the correct return value in the latter case, fix this. Fixes: af2618a2eee8 ("ASoC: meson: g12a: add internal DAC glue driver") Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20240103-meson-enum-val-v1-3-424af7a8fb91@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 28fdf45be31f9feb20da9fc7bbd7b4e0a9f44fdf Author: Mark Brown Date: Wed Jan 3 18:34:02 2024 +0000 ASoC: meson: g12a-tohdmitx: Validate written enum values [ Upstream commit 1e001206804be3f3d21f4a1cf16e5d059d75643f ] When writing to an enum we need to verify that the value written is valid for the enumeration, the helper function snd_soc_item_enum_to_val() doesn't do it since it needs to return an unsigned (and in any case we'd need to check the return value). Fixes: c8609f3870f7 ("ASoC: meson: add g12a tohdmitx control") Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20240103-meson-enum-val-v1-2-424af7a8fb91@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 97ee19ff491479822eade8a869d49f9ddcd71e75 Author: Mark Brown Date: Wed Jan 3 18:34:01 2024 +0000 ASoC: meson: g12a-toacodec: Validate written enum values [ Upstream commit 3150b70e944ead909260285dfb5707d0bedcf87b ] When writing to an enum we need to verify that the value written is valid for the enumeration, the helper function snd_soc_item_enum_to_val() doesn't do it since it needs to return an unsigned (and in any case we'd need to check the return value). Fixes: af2618a2eee8 ("ASoC: meson: g12a: add internal DAC glue driver") Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20240103-meson-enum-val-v1-1-424af7a8fb91@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d715f2949a9cfe9fb2e9f5854978991a3de523be Author: Ke Xiao Date: Mon Dec 18 15:08:50 2023 +0800 i40e: fix use-after-free in i40e_aqc_add_filters() [ Upstream commit 6a15584e99db8918b60e507539c7446375dcf366 ] Commit 3116f59c12bd ("i40e: fix use-after-free in i40e_sync_filters_subtask()") avoided use-after-free issues, by increasing refcount during update the VSI filter list to the HW. However, it missed the unicast situation. When deleting an unicast FDB entry, the i40e driver will release the mac_filter, and i40e_service_task will concurrently request firmware to add the mac_filter, which will lead to the following use-after-free issue. Fix again for both netdev->uc and netdev->mc. BUG: KASAN: use-after-free in i40e_aqc_add_filters+0x55c/0x5b0 [i40e] Read of size 2 at addr ffff888eb3452d60 by task kworker/8:7/6379 CPU: 8 PID: 6379 Comm: kworker/8:7 Kdump: loaded Tainted: G Workqueue: i40e i40e_service_task [i40e] Call Trace: dump_stack+0x71/0xab print_address_description+0x6b/0x290 kasan_report+0x14a/0x2b0 i40e_aqc_add_filters+0x55c/0x5b0 [i40e] i40e_sync_vsi_filters+0x1676/0x39c0 [i40e] i40e_service_task+0x1397/0x2bb0 [i40e] process_one_work+0x56a/0x11f0 worker_thread+0x8f/0xf40 kthread+0x2a0/0x390 ret_from_fork+0x1f/0x40 Allocated by task 21948: kasan_kmalloc+0xa6/0xd0 kmem_cache_alloc_trace+0xdb/0x1c0 i40e_add_filter+0x11e/0x520 [i40e] i40e_addr_sync+0x37/0x60 [i40e] __hw_addr_sync_dev+0x1f5/0x2f0 i40e_set_rx_mode+0x61/0x1e0 [i40e] dev_uc_add_excl+0x137/0x190 i40e_ndo_fdb_add+0x161/0x260 [i40e] rtnl_fdb_add+0x567/0x950 rtnetlink_rcv_msg+0x5db/0x880 netlink_rcv_skb+0x254/0x380 netlink_unicast+0x454/0x610 netlink_sendmsg+0x747/0xb00 sock_sendmsg+0xe2/0x120 __sys_sendto+0x1ae/0x290 __x64_sys_sendto+0xdd/0x1b0 do_syscall_64+0xa0/0x370 entry_SYSCALL_64_after_hwframe+0x65/0xca Freed by task 21948: __kasan_slab_free+0x137/0x190 kfree+0x8b/0x1b0 __i40e_del_filter+0x116/0x1e0 [i40e] i40e_del_mac_filter+0x16c/0x300 [i40e] i40e_addr_unsync+0x134/0x1b0 [i40e] __hw_addr_sync_dev+0xff/0x2f0 i40e_set_rx_mode+0x61/0x1e0 [i40e] dev_uc_del+0x77/0x90 rtnl_fdb_del+0x6a5/0x860 rtnetlink_rcv_msg+0x5db/0x880 netlink_rcv_skb+0x254/0x380 netlink_unicast+0x454/0x610 netlink_sendmsg+0x747/0xb00 sock_sendmsg+0xe2/0x120 __sys_sendto+0x1ae/0x290 __x64_sys_sendto+0xdd/0x1b0 do_syscall_64+0xa0/0x370 entry_SYSCALL_64_after_hwframe+0x65/0xca Fixes: 3116f59c12bd ("i40e: fix use-after-free in i40e_sync_filters_subtask()") Fixes: 41c445ff0f48 ("i40e: main driver core") Signed-off-by: Ke Xiao Signed-off-by: Ding Hui Cc: Di Zhu Reviewed-by: Jan Sokolowski Reviewed-by: Simon Horman Reviewed-by: Jacob Keller Tested-by: Pucha Himasekhar Reddy (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit d5e0bb03d99c350ee48e421bb5eaf61b65955b85 Author: Marc Dionne Date: Thu Dec 21 09:12:30 2023 -0400 net: Save and restore msg_namelen in sock_sendmsg [ Upstream commit 01b2885d9415152bcb12ff1f7788f500a74ea0ed ] Commit 86a7e0b69bd5 ("net: prevent rewrite of msg_name in sock_sendmsg()") made sock_sendmsg save the incoming msg_name pointer and restore it before returning, to insulate the caller against msg_name being changed by the called code. If the address length was also changed however, we may return with an inconsistent structure where the length doesn't match the address, and attempts to reuse it may lead to lost packets. For example, a kernel that doesn't have commit 1c5950fc6fe9 ("udp6: fix potential access to stale information") will replace a v4 mapped address with its ipv4 equivalent, and shorten namelen accordingly from 28 to 16. If the caller attempts to reuse the resulting msg structure, it will have the original ipv6 (v4 mapped) address but an incorrect v4 length. Fixes: 86a7e0b69bd5 ("net: prevent rewrite of msg_name in sock_sendmsg()") Signed-off-by: Marc Dionne Reviewed-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9824064683a74aa307575d18da14fd0f061f1055 Author: Pablo Neira Ayuso Date: Mon Jan 1 20:15:33 2024 +0100 netfilter: nft_immediate: drop chain reference counter on error [ Upstream commit b29be0ca8e816119ccdf95cc7d7c7be9bde005f1 ] In the init path, nft_data_init() bumps the chain reference counter, decrement it on error by following the error path which calls nft_data_release() to restore it. Fixes: 4bedf9eee016 ("netfilter: nf_tables: fix chain binding transaction logic") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 97cbb828482a1870d804629ae3087554565d2539 Author: Brad Cowie Date: Fri Dec 22 11:43:11 2023 +1300 netfilter: nf_nat: fix action not being set for all ct states [ Upstream commit e6345d2824a3f58aab82428d11645e0da861ac13 ] This fixes openvswitch's handling of nat packets in the related state. In nf_ct_nat_execute(), which is called from nf_ct_nat(), ICMP/ICMPv6 packets in the IP_CT_RELATED or IP_CT_RELATED_REPLY state, which have not been dropped, will follow the goto, however the placement of the goto label means that updating the action bit field will be bypassed. This causes ovs_nat_update_key() to not be called from ovs_ct_nat() which means the openvswitch match key for the ICMP/ICMPv6 packet is not updated and the pre-nat value will be retained for the key, which will result in the wrong openflow rule being matched for that packet. Move the goto label above where the action bit field is being set so that it is updated in all cases where the packet is accepted. Fixes: ebddb1404900 ("net: move the nat function to nf_nat_ovs for ovs and tc") Signed-off-by: Brad Cowie Reviewed-by: Simon Horman Acked-by: Xin Long Acked-by: Aaron Conole Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit d4969c264d9107820f84574b5298f9eda7fdac2c Author: Adrian Cinal Date: Thu Dec 28 14:56:38 2023 +0100 net: bcmgenet: Fix FCS generation for fragmented skbuffs [ Upstream commit e584f2ff1e6cc9b1d99e8a6b0f3415940d1b3eb3 ] The flag DMA_TX_APPEND_CRC was only written to the first DMA descriptor in the TX path, where each descriptor corresponds to a single skbuff fragment (or the skbuff head). This led to packets with no FCS appearing on the wire if the kernel allocated the packet in fragments, which would always happen when using PACKET_MMAP/TPACKET (cf. tpacket_fill_skb() in net/af_packet.c). Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file") Signed-off-by: Adrian Cinal Acked-by: Doug Berger Acked-by: Florian Fainelli Link: https://lore.kernel.org/r/20231228135638.1339245-1-adriancinal1@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9f2e244bfc9e14808cde1d3774063f613f964c7a Author: Zhipeng Lu Date: Mon Dec 25 19:29:14 2023 +0800 sfc: fix a double-free bug in efx_probe_filters [ Upstream commit d5a306aedba34e640b11d7026dbbafb78ee3a5f6 ] In efx_probe_filters, the channel->rps_flow_id is freed in a efx_for_each_channel marco when success equals to 0. However, after the following call chain: ef100_net_open |-> efx_probe_filters |-> ef100_net_stop |-> efx_remove_filters The channel->rps_flow_id is freed again in the efx_for_each_channel of efx_remove_filters, triggering a double-free bug. Fixes: a9dc3d5612ce ("sfc_ef100: RX filter table management and related gubbins") Reviewed-by: Simon Horman Reviewed-by: Edward Cree Signed-off-by: Zhipeng Lu Link: https://lore.kernel.org/r/20231225112915.3544581-1-alexious@zju.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 015414fdc068ab54ebcac181824ca0800e5855db Author: Stefan Wahren Date: Thu Dec 28 20:39:02 2023 +0100 ARM: sun9i: smp: Fix array-index-out-of-bounds read in sunxi_mc_smp_init [ Upstream commit 72ad3b772b6d393701df58ba1359b0bb346a19ed ] Running a multi-arch kernel (multi_v7_defconfig) on a Raspberry Pi 3B+ with enabled CONFIG_UBSAN triggers the following warning: UBSAN: array-index-out-of-bounds in arch/arm/mach-sunxi/mc_smp.c:810:29 index 2 is out of range for type 'sunxi_mc_smp_data [2]' CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc6-00248-g5254c0cbc92d Hardware name: BCM2835 unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x40/0x4c dump_stack_lvl from ubsan_epilogue+0x8/0x34 ubsan_epilogue from __ubsan_handle_out_of_bounds+0x78/0x80 __ubsan_handle_out_of_bounds from sunxi_mc_smp_init+0xe4/0x4cc sunxi_mc_smp_init from do_one_initcall+0xa0/0x2fc do_one_initcall from kernel_init_freeable+0xf4/0x2f4 kernel_init_freeable from kernel_init+0x18/0x158 kernel_init from ret_from_fork+0x14/0x28 Since the enabled method couldn't match with any entry from sunxi_mc_smp_data, the value of the index shouldn't be used right after the loop. So move it after the check of ret in order to have a valid index. Fixes: 1631090e34f5 ("ARM: sun9i: smp: Add is_a83t field") Signed-off-by: Stefan Wahren Link: https://lore.kernel.org/r/20231228193903.9078-1-wahrenst@gmx.net Reviewed-by: Chen-Yu Tsai Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 4d9b792986dd446e2907ad591e31811f3e724eaa Author: Hangbin Liu Date: Sat Dec 23 20:59:22 2023 +0800 selftests: bonding: do not set port down when adding to bond [ Upstream commit 61fa2493ca76fd7bb74e13f0205274f4ab0aa696 ] Similar to commit be809424659c ("selftests: bonding: do not set port down before adding to bond"). The bond-arp-interval-causes-panic test failed after commit a4abfa627c38 ("net: rtnetlink: Enslave device before bringing it up") as the kernel will set the port down _after_ adding to bond if setting port down specifically. Fix it by removing the link down operation when adding to bond. Fixes: 2ffd57327ff1 ("selftests: bonding: cause oops in bond_rr_gen_slave_id") Signed-off-by: Hangbin Liu Tested-by: Benjamin Poirier Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 742e4af3d7d751d7bef3a6a898652518e772efb1 Author: Jörn-Thorben Hinz Date: Fri Dec 22 00:19:01 2023 +0100 net: Implement missing getsockopt(SO_TIMESTAMPING_NEW) [ Upstream commit 7f6ca95d16b96567ce4cf458a2790ff17fa620c3 ] Commit 9718475e6908 ("socket: Add SO_TIMESTAMPING_NEW") added the new socket option SO_TIMESTAMPING_NEW. Setting the option is handled in sk_setsockopt(), querying it was not handled in sk_getsockopt(), though. Following remarks on an earlier submission of this patch, keep the old behavior of getsockopt(SO_TIMESTAMPING_OLD) which returns the active flags even if they actually have been set through SO_TIMESTAMPING_NEW. The new getsockopt(SO_TIMESTAMPING_NEW) is stricter, returning flags only if they have been set through the same option. Fixes: 9718475e6908 ("socket: Add SO_TIMESTAMPING_NEW") Link: https://lore.kernel.org/lkml/20230703175048.151683-1-jthinz@mailbox.tu-berlin.de/ Link: https://lore.kernel.org/netdev/0d7cddc9-03fa-43db-a579-14f3e822615b@app.fastmail.com/ Signed-off-by: Jörn-Thorben Hinz Reviewed-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d090faafd9548f372ef3a943cd9a5dea4c292bae Author: Kai-Heng Feng Date: Fri Dec 22 12:34:09 2023 +0800 r8169: Fix PCI error on system resume [ Upstream commit 9c476269bff2908a20930c58085bf0b05ebd569a ] Some r8168 NICs stop working upon system resume: [ 688.051096] r8169 0000:02:00.1 enp2s0f1: rtl_ep_ocp_read_cond == 0 (loop: 10, delay: 10000). [ 688.175131] r8169 0000:02:00.1 enp2s0f1: Link is Down ... [ 691.534611] r8169 0000:02:00.1 enp2s0f1: PCI error (cmd = 0x0407, status_errs = 0x0000) Not sure if it's related, but those NICs have a BMC device at function 0: 02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. Realtek RealManage BMC [10ec:816e] (rev 1a) Trial and error shows that increase the loop wait on rtl_ep_ocp_read_cond to 30 can eliminate the issue, so let rtl8168ep_driver_start() to wait a bit longer. Fixes: e6d6ca6e1204 ("r8169: Add support for another RTL8168FP") Signed-off-by: Kai-Heng Feng Reviewed-by: Heiner Kallweit Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4083c9bc3809f99850e83a06183e6f20d35d18d2 Author: Hangyu Hua Date: Thu Dec 21 10:25:31 2023 +0800 net: sched: em_text: fix possible memory leak in em_text_destroy() [ Upstream commit 8fcb0382af6f1ef50936f1be05b8149eb2f88496 ] m->data needs to be freed when em_text_destroy is called. Fixes: d675c989ed2d ("[PKT_SCHED]: Packet classification based on textsearch (ematch)") Acked-by: Jamal Hadi Salim Signed-off-by: Hangyu Hua Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 463fe6953f3b02fe33e7414f4ddb3319ed6f44f9 Author: David Thompson Date: Wed Dec 20 18:47:39 2023 -0500 mlxbf_gige: fix receive packet race condition [ Upstream commit dcea1bd45e6d111cc8fc1aaefa7e31694089bda3 ] Under heavy traffic, the BlueField Gigabit interface can become unresponsive. This is due to a possible race condition in the mlxbf_gige_rx_packet function, where the function exits with producer and consumer indices equal but there are remaining packet(s) to be processed. In order to prevent this situation, read receive consumer index *before* the HW replenish so that the mlxbf_gige_rx_packet function returns an accurate return value even if a packet is received into just-replenished buffer prior to exiting this routine. If the just-replenished buffer is received and occupies the last RX ring entry, the interface would not recover and instead would encounter RX packet drops related to internal buffer shortages since the driver RX logic is not being triggered to drain the RX ring. This patch will address and prevent this "ring full" condition. Fixes: f92e1869d74e ("Add Mellanox BlueField Gigabit Ethernet driver") Reviewed-by: Asmaa Mnebhi Signed-off-by: David Thompson Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ad0ea7a29031f6629cb95cba7f00599cfc133d56 Author: Eugen Hristev Date: Fri Dec 29 13:43:42 2023 +0200 ASoC: mediatek: mt8186: fix AUD_PAD_TOP register and offset [ Upstream commit 38744c3fa00109c51076121c2deb4f02e2f09194 ] AUD_PAD_TOP widget's correct register is AFE_AUD_PAD_TOP , and not zero. Having a zero as register, it would mean that the `snd_soc_dapm_new_widgets` would try to read the register at offset zero when trying to get the power status of this widget, which is incorrect. Fixes: b65c466220b3 ("ASoC: mediatek: mt8186: support adda in platform driver") Signed-off-by: Eugen Hristev Link: https://lore.kernel.org/r/20231229114342.195867-1-eugen.hristev@collabora.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4deed2c6027b893e83fe41019460d36524e5d220 Author: Chancel Liu Date: Mon Dec 25 17:06:08 2023 +0900 ASoC: fsl_rpmsg: Fix error handler with pm_runtime_enable [ Upstream commit f9d378fc68c43fd41b35133edec9cd902ec334ec ] There is error message when defer probe happens: fsl_rpmsg rpmsg_audio: Unbalanced pm_runtime_enable! Fix the error handler with pm_runtime_enable. Fixes: b73d9e6225e8 ("ASoC: fsl_rpmsg: Add CPU DAI driver for audio base on rpmsg") Signed-off-by: Chancel Liu Acked-by: Shengjiu Wang Link: https://lore.kernel.org/r/20231225080608.967953-1-chancel.liu@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 38036a739ef146927224aab9bb0e0f2a89c423f3 Author: Kurt Kanzenbach Date: Wed Dec 6 15:07:18 2023 +0100 igc: Check VLAN EtherType mask [ Upstream commit 7afd49a38e73afd57ff62c8d1cf5af760c4d49c0 ] Currently the driver accepts VLAN EtherType steering rules regardless of the configured mask. And things might fail silently or with confusing error messages to the user. The VLAN EtherType can only be matched by full mask. Therefore, add a check for that. For instance the following rule is invalid, but the driver accepts it and ignores the user specified mask: |root@host:~# ethtool -N enp3s0 flow-type ether vlan-etype 0x8100 \ | m 0x00ff action 0 |Added rule with ID 63 |root@host:~# ethtool --show-ntuple enp3s0 |4 RX rings available |Total 1 rules | |Filter: 63 | Flow Type: Raw Ethernet | Src MAC addr: 00:00:00:00:00:00 mask: FF:FF:FF:FF:FF:FF | Dest MAC addr: 00:00:00:00:00:00 mask: FF:FF:FF:FF:FF:FF | Ethertype: 0x0 mask: 0xFFFF | VLAN EtherType: 0x8100 mask: 0x0 | VLAN: 0x0 mask: 0xffff | User-defined: 0x0 mask: 0xffffffffffffffff | Action: Direct to queue 0 After: |root@host:~# ethtool -N enp3s0 flow-type ether vlan-etype 0x8100 \ | m 0x00ff action 0 |rmgr: Cannot insert RX class rule: Operation not supported Fixes: 2b477d057e33 ("igc: Integrate flex filter into ethtool ops") Suggested-by: Suman Ghosh Signed-off-by: Kurt Kanzenbach Acked-by: Vinicius Costa Gomes Reviewed-by: Simon Horman Tested-by: Naama Meir Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 08144bac8d2372fe0477292d66424116af63db80 Author: Kurt Kanzenbach Date: Fri Dec 1 08:50:43 2023 +0100 igc: Check VLAN TCI mask [ Upstream commit b5063cbe148b829e8eb97672c2cbccc058835476 ] Currently the driver accepts VLAN TCI steering rules regardless of the configured mask. And things might fail silently or with confusing error messages to the user. There are two ways to handle the VLAN TCI mask: 1. Match on the PCP field using a VLAN prio filter 2. Match on complete TCI field using a flex filter Therefore, add checks and code for that. For instance the following rule is invalid and will be converted into a VLAN prio rule which is not correct: |root@host:~# ethtool -N enp3s0 flow-type ether vlan 0x0001 m 0xf000 \ | action 1 |Added rule with ID 61 |root@host:~# ethtool --show-ntuple enp3s0 |4 RX rings available |Total 1 rules | |Filter: 61 | Flow Type: Raw Ethernet | Src MAC addr: 00:00:00:00:00:00 mask: FF:FF:FF:FF:FF:FF | Dest MAC addr: 00:00:00:00:00:00 mask: FF:FF:FF:FF:FF:FF | Ethertype: 0x0 mask: 0xFFFF | VLAN EtherType: 0x0 mask: 0xffff | VLAN: 0x1 mask: 0x1fff | User-defined: 0x0 mask: 0xffffffffffffffff | Action: Direct to queue 1 After: |root@host:~# ethtool -N enp3s0 flow-type ether vlan 0x0001 m 0xf000 \ | action 1 |rmgr: Cannot insert RX class rule: Operation not supported Fixes: 7991487ecb2d ("igc: Allow for Flex Filters to be installed") Signed-off-by: Kurt Kanzenbach Acked-by: Vinicius Costa Gomes Reviewed-by: Simon Horman Tested-by: Naama Meir Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 4109b21e785c4bf9d73c6b029232a94a38e2ed12 Author: Kurt Kanzenbach Date: Fri Dec 1 08:50:42 2023 +0100 igc: Report VLAN EtherType matching back to user [ Upstream commit 088464abd48cf3735aee91f9e211b32da9d81117 ] Currently the driver allows to configure matching by VLAN EtherType. However, the retrieval function does not report it back to the user. Add it. Before: |root@host:~# ethtool -N enp3s0 flow-type ether vlan-etype 0x8100 action 0 |Added rule with ID 63 |root@host:~# ethtool --show-ntuple enp3s0 |4 RX rings available |Total 1 rules | |Filter: 63 | Flow Type: Raw Ethernet | Src MAC addr: 00:00:00:00:00:00 mask: FF:FF:FF:FF:FF:FF | Dest MAC addr: 00:00:00:00:00:00 mask: FF:FF:FF:FF:FF:FF | Ethertype: 0x0 mask: 0xFFFF | Action: Direct to queue 0 After: |root@host:~# ethtool -N enp3s0 flow-type ether vlan-etype 0x8100 action 0 |Added rule with ID 63 |root@host:~# ethtool --show-ntuple enp3s0 |4 RX rings available |Total 1 rules | |Filter: 63 | Flow Type: Raw Ethernet | Src MAC addr: 00:00:00:00:00:00 mask: FF:FF:FF:FF:FF:FF | Dest MAC addr: 00:00:00:00:00:00 mask: FF:FF:FF:FF:FF:FF | Ethertype: 0x0 mask: 0xFFFF | VLAN EtherType: 0x8100 mask: 0x0 | VLAN: 0x0 mask: 0xffff | User-defined: 0x0 mask: 0xffffffffffffffff | Action: Direct to queue 0 Fixes: 2b477d057e33 ("igc: Integrate flex filter into ethtool ops") Signed-off-by: Kurt Kanzenbach Acked-by: Vinicius Costa Gomes Reviewed-by: Simon Horman Tested-by: Naama Meir Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 0ec87fc8be9534cd65310b383312b6ffea5bba26 Author: Sudheer Mogilappagari Date: Wed Nov 29 11:23:11 2023 +0100 i40e: Fix filter input checks to prevent config with invalid values [ Upstream commit 3e48041d9820c17e0a51599d12e66c6e12a8d08d ] Prevent VF from configuring filters with unsupported actions or use REDIRECT action with invalid tc number. Current checks could cause out of bounds access on PF side. Fixes: e284fc280473 ("i40e: Add and delete cloud filter") Reviewed-by: Andrii Staikov Signed-off-by: Sudheer Mogilappagari Signed-off-by: Aleksandr Loktionov Reviewed-by: Simon Horman Tested-by: Bharathi Sreenivas Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit a659ce14c7763c3a3b9a465792c26b37563a8c32 Author: Ngai-Mint Kwan Date: Fri Dec 15 12:01:57 2023 +0100 ice: Shut down VSI with "link-down-on-close" enabled [ Upstream commit 6d05ff55ef4f4954d28551236239f297bd52ea48 ] Disabling netdev with ethtool private flag "link-down-on-close" enabled can cause NULL pointer dereference bug. Shut down VSI regardless of "link-down-on-close" state. Fixes: 8ac7132704f3 ("ice: Fix interface being down after reset with link-down-on-close flag on") Reviewed-by: Przemek Kitszel Signed-off-by: Ngai-Mint Kwan Signed-off-by: Wojciech Drewek Tested-by: Pucha Himasekhar Reddy (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 49b1e2aa233c5035efcfaee26474730ba2a9c7e8 Author: Katarzyna Wieczerzycka Date: Fri Dec 15 12:01:56 2023 +0100 ice: Fix link_down_on_close message [ Upstream commit 6a8d8bb55e7001de2d50920381cc858f3a3e9fb7 ] The driver should not report an error message when for a medialess port the link_down_on_close flag is enabled and the physical link cannot be set down. Fixes: 8ac7132704f3 ("ice: Fix interface being down after reset with link-down-on-close flag on") Reviewed-by: Przemek Kitszel Signed-off-by: Katarzyna Wieczerzycka Signed-off-by: Wojciech Drewek Tested-by: Pucha Himasekhar Reddy (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 03ed388f9bb84c58060bf612af52188822ba8f1c Author: Umesh Nerlige Ramappa Date: Mon Dec 18 16:05:43 2023 -0800 drm/i915/perf: Update handling of MMIO triggered reports [ Upstream commit ee11d2d37f5c05bd7bf5ccc820a58f48423d032b ] On XEHP platforms user is not able to find MMIO triggered reports in the OA buffer since i915 squashes the context ID fields. These context ID fields hold the MMIO trigger markers. Update logic to not squash the context ID fields of MMIO triggered reports. Fixes: cba94bbcff08 ("drm/i915/perf: Determine context valid in OA reports") Signed-off-by: Umesh Nerlige Ramappa Reviewed-by: Ashutosh Dixit Link: https://patchwork.freedesktop.org/patch/msgid/20231219000543.1087706-1-umesh.nerlige.ramappa@intel.com (cherry picked from commit 0c68132df6e66244acec1bb5b9e19b0751414389) Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit c3d24a3d380b1e2b49a8e4c5ce7ba64aa08892e4 Author: Khaled Almahallawy Date: Wed Dec 13 13:15:42 2023 -0800 drm/i915/dp: Fix passing the correct DPCD_REV for drm_dp_set_phy_test_pattern [ Upstream commit 2bd7a06a1208aaacb4e7a2a5436c23bce8d70801 ] Using link_status to get DPCD_REV fails when disabling/defaulting phy pattern. Use intel_dp->dpcd to access DPCD_REV correctly. Fixes: 8cdf72711928 ("drm/i915/dp: Program vswing, pre-emphasis, test-pattern") Cc: Jani Nikula Cc: Imre Deak Cc: Lee Shawn C Signed-off-by: Khaled Almahallawy Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20231213211542.3585105-3-khaled.almahallawy@intel.com (cherry picked from commit 3ee302ec22d6e1d7d1e6d381b0d507ee80f2135c) Signed-off-by: Sasha Levin commit 029d4ab2b7722a1e7b386b4a254e9102c10cd1ba Author: Suman Ghosh Date: Tue Dec 19 19:56:33 2023 +0530 octeontx2-af: Fix marking couple of structure as __packed [ Upstream commit 0ee2384a5a0f3b4eeac8d10bb01a0609d245a4d1 ] Couple of structures was not marked as __packed. This patch fixes the same and mark them as __packed. Fixes: 42006910b5ea ("octeontx2-af: cleanup KPU config data") Signed-off-by: Suman Ghosh Reviewed-by: Jacob Keller Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit fb195df90544f4559eebf6a99f4531cfed1bfcb2 Author: Siddh Raman Pant Date: Tue Dec 19 23:19:43 2023 +0530 nfc: llcp_core: Hold a ref to llcp_local->dev when holding a ref to llcp_local [ Upstream commit c95f919567d6f1914f13350af61a1b044ac85014 ] llcp_sock_sendmsg() calls nfc_llcp_send_ui_frame() which in turn calls nfc_alloc_send_skb(), which accesses the nfc_dev from the llcp_sock for getting the headroom and tailroom needed for skb allocation. Parallelly the nfc_dev can be freed, as the refcount is decreased via nfc_free_device(), leading to a UAF reported by Syzkaller, which can be summarized as follows: (1) llcp_sock_sendmsg() -> nfc_llcp_send_ui_frame() -> nfc_alloc_send_skb() -> Dereference *nfc_dev (2) virtual_ncidev_close() -> nci_free_device() -> nfc_free_device() -> put_device() -> nfc_release() -> Free *nfc_dev When a reference to llcp_local is acquired, we do not acquire the same for the nfc_dev. This leads to freeing even when the llcp_local is in use, and this is the case with the UAF described above too. Thus, when we acquire a reference to llcp_local, we should acquire a reference to nfc_dev, and release the references appropriately later. References for llcp_local is initialized in nfc_llcp_register_device() (which is called by nfc_register_device()). Thus, we should acquire a reference to nfc_dev there. nfc_unregister_device() calls nfc_llcp_unregister_device() which in turn calls nfc_llcp_local_put(). Thus, the reference to nfc_dev is appropriately released later. Reported-and-tested-by: syzbot+bbe84a4010eeea00982d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=bbe84a4010eeea00982d Fixes: c7aa12252f51 ("NFC: Take a reference on the LLCP local pointer when creating a socket") Reviewed-by: Suman Ghosh Signed-off-by: Siddh Raman Pant Reviewed-by: Krzysztof Kozlowski Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d27e2798e3ea48d528ae163c8b831b27b739fdba Author: Pablo Neira Ayuso Date: Thu Dec 14 11:50:12 2023 +0100 netfilter: nf_tables: set transport offset from mac header for netdev/egress [ Upstream commit 0ae8e4cca78781401b17721bfb72718fdf7b4912 ] Before this patch, transport offset (pkt->thoff) provides an offset relative to the network header. This is fine for the inet families because skb->data points to the network header in such case. However, from netdev/egress, skb->data points to the mac header (if available), thus, pkt->thoff is missing the mac header length. Add skb_network_offset() to the transport offset (pkt->thoff) for netdev, so transport header mangling works as expected. Adjust payload fast eval function to use skb->data now that pkt->thoff provides an absolute offset. This explains why users report that matching on egress/netdev works but payload mangling does not. This patch implicitly fixes payload mangling for IPv4 packets in netdev/egress given skb_store_bits() requires an offset from skb->data to reach the transport header. I suspect that nft_exthdr and the trace infra were also broken from netdev/egress because they also take skb->data as start, and pkt->thoff was not correct. Note that IPv6 is fine because ipv6_find_hdr() already provides a transport offset starting from skb->data, which includes skb_network_offset(). The bridge family also uses nft_set_pktinfo_ipv4_validate(), but there skb_network_offset() is zero, so the update in this patch does not alter the existing behaviour. Fixes: 42df6e1d221d ("netfilter: Introduce egress hook") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 8b410abf172994205a0a4341a8cc0a1bc14c5a3d Author: Douglas Anderson Date: Mon Dec 18 09:04:54 2023 -0800 drm/bridge: ps8640: Fix size mismatch warning w/ len [ Upstream commit 35ba6bd582cf926a082296b7e9a876ec81136cb1 ] After commit 26195af57798 ("drm/bridge: ps8640: Drop the ability of ps8640 to fetch the EDID"), I got an error compiling: error: comparison of distinct pointer types ('typeof (len) *' (aka 'unsigned int *') and 'typeof (msg->size) *' (aka 'unsigned long *')) [-Werror,-Wcompare-distinct-pointer-types] Fix it by declaring the `len` as size_t. The above error only shows up on downstream kernels without commit d03eba99f5bf ("minmax: allow min()/max()/clamp() if the arguments have the same signedness."), but since commit 26195af57798 ("drm/bridge: ps8640: Drop the ability of ps8640 to fetch the EDID") is a "Fix" that will likely be backported it seems nice to make it easy. ...plus it's more correct to declare `len` as size_t anyway. Fixes: 26195af57798 ("drm/bridge: ps8640: Drop the ability of ps8640 to fetch the EDID") Reviewed-by: Stephen Boyd Signed-off-by: Douglas Anderson Link: https://patchwork.freedesktop.org/patch/msgid/20231218090454.1.I5c6eb80b2f746439c4b58efab788e00701d08759@changeid Signed-off-by: Sasha Levin commit 1688af7d86ed83d98854ac8f302326a7d1a806a9 Author: Douglas Anderson Date: Thu Dec 14 12:37:52 2023 -0800 drm/bridge: ti-sn65dsi86: Never store more than msg->size bytes in AUX xfer [ Upstream commit aca58eac52b88138ab98c814afb389a381725cd7 ] For aux reads, the value `msg->size` indicates the size of the buffer provided by `msg->buffer`. We should never in any circumstances write more bytes to the buffer since it may overflow the buffer. In the ti-sn65dsi86 driver there is one code path that reads the transfer length from hardware. Even though it's never been seen to be a problem, we should make extra sure that the hardware isn't increasing the length since doing so would cause us to overrun the buffer. Fixes: 982f589bde7a ("drm/bridge: ti-sn65dsi86: Update reply on aux failures") Reviewed-by: Stephen Boyd Reviewed-by: Guenter Roeck Signed-off-by: Douglas Anderson Link: https://patchwork.freedesktop.org/patch/msgid/20231214123752.v3.2.I7b83c0f31aeedc6b1dc98c7c741d3e1f94f040f8@changeid Signed-off-by: Sasha Levin commit ce5b06e2a7bb7890abd56e053d36a7f643e602f2 Author: Douglas Anderson Date: Thu Dec 14 12:37:51 2023 -0800 drm/bridge: parade-ps8640: Never store more than msg->size bytes in AUX xfer [ Upstream commit 3164c8a70073d43629b4e11e083d3d2798f7750f ] While testing, I happened to notice a random crash that looked like: Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: drm_dp_dpcd_probe+0x120/0x120 Analysis of drm_dp_dpcd_probe() shows that we pass in a 1-byte buffer (allocated on the stack) to the aux->transfer() function. Presumably if the aux->transfer() writes more than one byte to this buffer then we're in a bad shape. Dropping into kgdb, I noticed that "aux->transfer" pointed at ps8640_aux_transfer(). Reading through ps8640_aux_transfer(), I can see that there are cases where it could write more bytes to msg->buffer than were specified by msg->size. This could happen if the hardware reported back something bogus to us. Let's fix this so we never write more than msg->size bytes. We'll still read all the bytes from the hardware just in case the hardware requires it since the aux transfer data comes through an auto-incrementing register. NOTE: I have no actual way to reproduce this issue but it seems likely this is what was happening in the crash I looked at. Fixes: 13afcdd7277e ("drm/bridge: parade-ps8640: Add support for AUX channel") Reviewed-by: Stephen Boyd Reviewed-by: Guenter Roeck Signed-off-by: Douglas Anderson Link: https://patchwork.freedesktop.org/patch/msgid/20231214123752.v3.1.I9d1afcaad76a3e2c0ca046dc4adbc2b632c22eda@changeid Signed-off-by: Sasha Levin commit ad1220bb4bcfdf75552cc00da6c9962035c55628 Author: Johannes Berg Date: Fri Dec 15 11:13:34 2023 +0100 wifi: iwlwifi: pcie: don't synchronize IRQs from IRQ [ Upstream commit 400f6ebbc175286576c7f7fddf3c347d09d12310 ] On older devices (before unified image!) we can end up calling stop_device from an rfkill interrupt. However, in stop_device we attempt to synchronize IRQs, which then of course deadlocks. Avoid this by checking the context, if running from the IRQ thread then don't synchronize. This wouldn't be correct on a new device since RSS is supported, but older devices only have a single interrupt/queue. Fixes: 37fb29bd1f90 ("wifi: iwlwifi: pcie: synchronize IRQs before NAPI") Reviewed-by: Miri Korenblit Reviewed-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Kalle Valo Link: https://msgid.link/20231215111335.59aab00baed7.Iadfe154d6248e7f9dfd69522e5429dbbd72925d7@changeid Signed-off-by: Sasha Levin commit f8d0c6d1992c6e91413883091dc8dd978c72d0b3 Author: Jeffrey Hugo Date: Fri Dec 8 09:31:01 2023 -0700 accel/qaic: Implement quirk for SOC_HW_VERSION [ Upstream commit 4c8874c2a6512b9fe7285cab1a6910d9211a6cfb ] The SOC_HW_VERSION register in the BHI space is not correctly initialized by the device and in many cases contains uninitialized data. The register could contain 0xFFFFFFFF which is a special value to indicate a link error in PCIe, therefore if observed, we could incorrectly think the device is down. Intercept reads for this register, and provide the correct value - every production instance would read 0x60110200 if the device was operating as intended. Fixes: a36bf7af868b ("accel/qaic: Add MHI controller") Signed-off-by: Jeffrey Hugo Reviewed-by: Pranjal Ramajor Asha Kanojiya Reviewed-by: Jacek Lawrynowicz Link: https://patchwork.freedesktop.org/patch/msgid/20231208163101.1295769-3-quic_jhugo@quicinc.com Signed-off-by: Sasha Levin commit efcedd56998b4f863fdd76740f65cb49f7dc8e2b Author: Pranjal Ramajor Asha Kanojiya Date: Fri Dec 8 09:31:00 2023 -0700 accel/qaic: Fix GEM import path code [ Upstream commit c8b6f4ad2ff9c6d88cdeb9acf16d0c4a323dd499 ] Do not modify the size of dmabuf as it is immutable. Fixes: ff13be830333 ("accel/qaic: Add datapath") Signed-off-by: Pranjal Ramajor Asha Kanojiya Reviewed-by: Jeffrey Hugo Signed-off-by: Jeffrey Hugo Reviewed-by: Jacek Lawrynowicz Link: https://patchwork.freedesktop.org/patch/msgid/20231208163101.1295769-2-quic_jhugo@quicinc.com Signed-off-by: Sasha Levin commit 30912a7f64de49408c9c0596937717770f1e7a63 Author: Paolo Bonzini Date: Thu Jan 4 16:15:17 2024 +0100 KVM: x86/pmu: fix masking logic for MSR_CORE_PERF_GLOBAL_CTRL commit 971079464001c6856186ca137778e534d983174a upstream. When commit c59a1f106f5c ("KVM: x86/pmu: Add IA32_PEBS_ENABLE MSR emulation for extended PEBS") switched the initialization of cpuc->guest_switch_msrs to use compound literals, it screwed up the boolean logic: + u64 pebs_mask = cpuc->pebs_enabled & x86_pmu.pebs_capable; ... - arr[0].guest = intel_ctrl & ~cpuc->intel_ctrl_host_mask; - arr[0].guest &= ~(cpuc->pebs_enabled & x86_pmu.pebs_capable); + .guest = intel_ctrl & (~cpuc->intel_ctrl_host_mask | ~pebs_mask), Before the patch, the value of arr[0].guest would have been intel_ctrl & ~cpuc->intel_ctrl_host_mask & ~pebs_mask. The intent is to always treat PEBS events as host-only because, while the guest runs, there is no way to tell the processor about the virtual address where to put PEBS records intended for the host. Unfortunately, the new expression can be expanded to (intel_ctrl & ~cpuc->intel_ctrl_host_mask) | (intel_ctrl & ~pebs_mask) which makes no sense; it includes any bit that isn't *both* marked as exclude_guest and using PEBS. So, reinstate the old logic. Another way to write it could be "intel_ctrl & ~(cpuc->intel_ctrl_host_mask | pebs_mask)", presumably the intention of the author of the faulty. However, I personally find the repeated application of A AND NOT B to be a bit more readable. This shows up as guest failures when running concurrent long-running perf workloads on the host, and was reported to happen with rcutorture. All guests on a given host would die simultaneously with something like an instruction fault or a segmentation violation. Reported-by: Paul E. McKenney Analyzed-by: Sean Christopherson Tested-by: Paul E. McKenney Cc: stable@vger.kernel.org Fixes: c59a1f106f5c ("KVM: x86/pmu: Add IA32_PEBS_ENABLE MSR emulation for extended PEBS") Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 30aae98b75b40e7196ffad18072c42fdb42891ea Author: Shyam Prasad N Date: Fri Dec 29 11:16:16 2023 +0000 cifs: do not depend on release_iface for maintaining iface_list commit 09eeb0723f219fbd96d8865bf9b935e03ee2ec22 upstream. parse_server_interfaces should be in complete charge of maintaining the iface_list linked list. Today, iface entries are removed from the list only when the last refcount is dropped. i.e. in release_iface. However, this can result in undercounting of refcount if the server stops advertising interfaces (which Azure SMB server does). This change puts parse_server_interfaces in full charge of maintaining the iface_list. So if an empty list is returned by the server, the entries in the list will immediately be removed. This way, a following call to the same function will not find entries in the list. Fixes: aa45dadd34e4 ("cifs: change iface_list from array to sorted linked list") Cc: stable@vger.kernel.org Signed-off-by: Shyam Prasad N Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 40fc7dfd17ecd67bede8aa321033a24703d91928 Author: Shyam Prasad N Date: Fri Dec 29 11:16:15 2023 +0000 cifs: cifs_chan_is_iface_active should be called with chan_lock held commit 7257bcf3bdc785eabc4eef1f329a59815b032508 upstream. cifs_chan_is_iface_active checks the channels of a session to see if the associated iface is active. This should always happen with chan_lock held. However, these two callers of this function were missing this locking. This change makes sure the function calls are protected with proper locking. Fixes: b54034a73baf ("cifs: during reconnect, update interface if necessary") Fixes: fa1d0508bdd4 ("cifs: account for primary channel in the interface list") Cc: stable@vger.kernel.org Signed-off-by: Shyam Prasad N Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit feef4dc27da02444f612a00367042af058f835fb Author: Jocelyn Falempe Date: Thu Dec 14 17:38:06 2023 +0100 drm/mgag200: Fix gamma lut not initialized for G200ER, G200EV, G200SE commit 11f9eb899ecc8c02b769cf8d2532ba12786a7af7 upstream. When mgag200 switched from simple KMS to regular atomic helpers, the initialization of the gamma settings was lost. This leads to a black screen, if the bios/uefi doesn't use the same pixel color depth. This has been fixed with commit ad81e23426a6 ("drm/mgag200: Fix gamma lut not initialized.") for most G200, but G200ER, G200EV, G200SE use their own version of crtc_helper_atomic_enable() and need to be fixed too. Fixes: 1baf9127c482 ("drm/mgag200: Replace simple-KMS with regular atomic helpers") Cc: #v6.1+ Reported-by: Roger Sewell Suggested-by: Roger Sewell Signed-off-by: Jocelyn Falempe Reviewed-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20231214163849.359691-1-jfalempe@redhat.com Signed-off-by: Greg Kroah-Hartman commit 8cc22ba3f77c59df5f1ac47d62df51efb28cd868 Author: Bjorn Helgaas Date: Mon Jan 1 12:08:18 2024 -0600 Revert "PCI/ASPM: Remove pcie_aspm_pm_state_change()" commit f93e71aea6c60ebff8adbd8941e678302d377869 upstream. This reverts commit 08d0cc5f34265d1a1e3031f319f594bd1970976c. Michael reported that when attempting to resume from suspend to RAM on ASUS mini PC PN51-BB757MDE1 (DMI model: MINIPC PN51-E1), 08d0cc5f3426 ("PCI/ASPM: Remove pcie_aspm_pm_state_change()") caused a 12-second delay with no output, followed by a reboot. Workarounds include: - Reverting 08d0cc5f3426 ("PCI/ASPM: Remove pcie_aspm_pm_state_change()") - Booting with "pcie_aspm=off" - Booting with "pcie_aspm.policy=performance" - "echo 0 | sudo tee /sys/bus/pci/devices/0000:03:00.0/link/l1_aspm" before suspending - Connecting a USB flash drive Link: https://lore.kernel.org/r/20240102232550.1751655-1-helgaas@kernel.org Fixes: 08d0cc5f3426 ("PCI/ASPM: Remove pcie_aspm_pm_state_change()") Reported-by: Michael Schaller Link: https://lore.kernel.org/r/76c61361-b8b4-435f-a9f1-32b716763d62@5challer.de Signed-off-by: Bjorn Helgaas Cc: Signed-off-by: Greg Kroah-Hartman commit c25546cac381ac14dac8e52837a8277054a75051 Author: Paolo Abeni Date: Tue Dec 26 13:10:18 2023 +0100 mptcp: prevent tcp diag from closing listener subflows commit 4c0288299fd09ee7c6fbe2f57421f314d8c981db upstream. The MPTCP protocol does not expect that any other entity could change the first subflow status when such socket is listening. Unfortunately the TCP diag interface allows aborting any TCP socket, including MPTCP listeners subflows. As reported by syzbot, that trigger a WARN() and could lead to later bigger trouble. The MPTCP protocol needs to do some MPTCP-level cleanup actions to properly shutdown the listener. To keep the fix simple, prevent entirely the diag interface from stopping such listeners. We could refine the diag callback in a later, larger patch targeting net-next. Fixes: 57fc0f1ceaa4 ("mptcp: ensure listener is unhashed before updating the sk status") Cc: stable@vger.kernel.org Reported-by: Closes: https://lore.kernel.org/netdev/0000000000004f4579060c68431b@google.com/ Signed-off-by: Paolo Abeni Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts Link: https://lore.kernel.org/r/20231226-upstream-net-20231226-mptcp-prevent-warn-v1-2-1404dcc431ea@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 67df4c4a4854c13b154e53430ac14c55eecb41dc Author: Wayne Lin Date: Mon Dec 4 10:09:33 2023 +0800 drm/amd/display: pbn_div need be updated for hotplug event commit 9cdef4f720376ef0fb0febce1ed2377c19e531f9 upstream. link_rate sometime will be changed when DP MST connector hotplug, so pbn_div also need be updated; otherwise, it will mismatch with link_rate, causes no output in external monitor. This is a backport to 6.7 and older. Cc: stable@vger.kernel.org Tested-by: Daniel Wheeler Reviewed-by: Jerry Zuo Acked-by: Rodrigo Siqueira Signed-off-by: Wade Wang Signed-off-by: Wayne Lin Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 0c0192321762862c3f8bd9edd99c013a3a870e73 Author: Siddhesh Dharme Date: Thu Jan 4 11:37:36 2024 +0530 ALSA: hda/realtek: Fix mute and mic-mute LEDs for HP ProBook 440 G6 commit b6ce6e6c79e4ec650887f1fe391a70e54972001a upstream. LEDs in 'HP ProBook 440 G6' laptop are controlled by ALC236 codec. Enable already existing quirk 'ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF' to fix mute and mic-mute LEDs. Signed-off-by: Siddhesh Dharme Cc: Link: https://lore.kernel.org/r/20240104060736.5149-1-siddheshdharme18@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 855c75f35020b225f41952b645cf648d4c1d87a4 Author: Andy Chi Date: Tue Jan 2 10:49:15 2024 +0800 ALSA: hda/realtek: fix mute/micmute LEDs for a HP ZBook commit 18a434f32fa61b3fda8ddcd9a63d5274569c6a41 upstream. There is a HP ZBook which using ALC236 codec and need the ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF quirk to make mute LED and micmute LED work. [ confirmed that the new entries are for new models that have no proper name, so the strings are left as "HP" which will be updated eventually later -- tiwai ] Signed-off-by: Andy Chi Cc: Link: https://lore.kernel.org/r/20240102024916.19093-1-andy.chi@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 0fc0d040f4302e0edc03925095327e5e794f4581 Author: Aabish Malik Date: Fri Dec 29 22:33:54 2023 +0530 ALSA: hda/realtek: enable SND_PCI_QUIRK for hp pavilion 14-ec1xxx series commit 13a5b21197587a3d9cac9e1a00de9b91526a55e4 upstream. The HP Pavilion 14 ec1xxx series uses the HP mainboard 8A0F with the ALC287 codec. The mute led can be enabled using the already existing ALC287_FIXUP_HP_GPIO_LED quirk. Tested on an HP Pavilion ec1003AU Signed-off-by: Aabish Malik Cc: Link: https://lore.kernel.org/r/20231229170352.742261-3-aabishmalik3337@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 0ccbd44d7d72e3e1a06c3394a86b1e03da834261 Author: Gergo Koteles Date: Fri Dec 22 01:34:48 2023 +0100 ALSA: hda/tas2781: remove sound controls in unbind commit 4e7914eb1dae377b8e6de59c96b0653aacb47646 upstream. Remove sound controls in hda_unbind to make module loadable after module unload. Add a driver specific struct (tas2781_hda) to store the controls. This patch depends on patch: ALSA: hda/tas2781: do not use regcache Fixes: 5be27f1e3ec9 ("ALSA: hda/tas2781: Add tas2781 HDA driver") CC: stable@vger.kernel.org Signed-off-by: Gergo Koteles Link: https://lore.kernel.org/r/362aa3e2f81b9259a3e5222f576bec5debfc5e88.1703204848.git.soyer@irl.hu Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit cb7a397dbb7ef14676147d0575c3ed2f35b49c80 Author: Gergo Koteles Date: Fri Dec 22 01:34:47 2023 +0100 ALSA: hda/tas2781: move set_drv_data outside tasdevice_init commit e7aa105657f7f62f54a493480588895cc8a9a1a7 upstream. allow driver specific driver data in tas2781-hda-i2c and tas2781-i2c Fixes: ef3bcde75d06 ("ASoC: tas2781: Add tas2781 driver") CC: stable@vger.kernel.org Signed-off-by: Gergo Koteles Link: https://lore.kernel.org/r/1398bd8bf3e935b1595a99128320e4a1913e210a.1703204848.git.soyer@irl.hu Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit aee67bbe969d4c640e101e206300249ec0fadb73 Author: Gergo Koteles Date: Fri Dec 22 00:48:56 2023 +0100 ALSA: hda/tas2781: do not use regcache commit 6dad45f4d28977bd1948973107cf325d431e5b7e upstream. There are two problems with using regcache in this module. The amplifier has 3 addressing levels (BOOK, PAGE, REG). The firmware contains blocks that must be written to BOOK 0x8C. The regcache doesn't know anything about BOOK, so regcache_sync writes invalid values to the actual BOOK. The module handles 2 or more separate amplifiers. The amplifiers have different register values, and the module uses only one regmap/regcache for all the amplifiers. The regcache_sync only writes the last amplifier used. The module successfully restores all the written register values (RC profile, program, configuration, calibration) without regcache. Remove regcache functions and set regmap cache_type to REGCACHE_NONE. Link: https://lore.kernel.org/r/21a183b5a08cb23b193af78d4b1114cc59419272.1701906455.git.soyer@irl.hu/ Fixes: 5be27f1e3ec9 ("ALSA: hda/tas2781: Add tas2781 HDA driver") Acked-by: Mark Brown CC: stable@vger.kernel.org Signed-off-by: Gergo Koteles Link: https://lore.kernel.org/r/491aeed0e2eecc3b704ec856f815db21bad3ba0e.1703202126.git.soyer@irl.hu Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit da89365158f6f656b28bcdbcbbe9eaf97c63c474 Author: Edward Adam Davis Date: Sun Dec 24 00:02:49 2023 +0000 keys, dns: Fix missing size check of V1 server-list header commit 1997b3cb4217b09e49659b634c94da47f0340409 upstream. The dns_resolver_preparse() function has a check on the size of the payload for the basic header of the binary-style payload, but is missing a check for the size of the V1 server-list payload header after determining that's what we've been given. Fix this by getting rid of the the pointer to the basic header and just assuming that we have a V1 server-list payload and moving the V1 server list pointer inside the if-statement. Dealing with other types and versions can be left for when such have been defined. This can be tested by doing the following with KASAN enabled: echo -n -e '\x0\x0\x1\x2' | keyctl padd dns_resolver foo @p and produces an oops like the following: BUG: KASAN: slab-out-of-bounds in dns_resolver_preparse+0xc9f/0xd60 net/dns_resolver/dns_key.c:127 Read of size 1 at addr ffff888028894084 by task syz-executor265/5069 ... Call Trace: dns_resolver_preparse+0xc9f/0xd60 net/dns_resolver/dns_key.c:127 __key_create_or_update+0x453/0xdf0 security/keys/key.c:842 key_create_or_update+0x42/0x50 security/keys/key.c:1007 __do_sys_add_key+0x29c/0x450 security/keys/keyctl.c:134 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x62/0x6a This patch was originally by Edward Adam Davis, but was modified by Linus. Fixes: b946001d3bb1 ("keys, dns: Allow key types (eg. DNS) to be reclaimed immediately on expiry") Reported-and-tested-by: syzbot+94bbb75204a05da3d89f@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/0000000000009b39bc060c73e209@google.com/ Suggested-by: Linus Torvalds Signed-off-by: Edward Adam Davis Signed-off-by: David Howells Tested-by: David Howells Cc: Edward Adam Davis Cc: Jarkko Sakkinen Cc: Jeffrey E Altman Cc: Wang Lei Cc: Jeff Layton Cc: Steve French Cc: Marc Dionne Cc: "David S. Miller" Cc: Eric Dumazet Cc: Jakub Kicinski Cc: Paolo Abeni Reviewed-by: Simon Horman Signed-off-by: Linus Torvalds Cc: Jeffrey E Altman Signed-off-by: Greg Kroah-Hartman