commit 9bc5c94e278f780af15b3f6e13ae08310aeae880 Author: Greg Kroah-Hartman Date: Thu Apr 10 14:44:49 2025 +0200 Linux 6.14.2 Link: https://lore.kernel.org/r/20250408104914.247897328@linuxfoundation.org Tested-by: Christian Heusel Tested-by: Ronald Warsow Link: https://lore.kernel.org/r/20250408154144.815882523@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Peter Schneider Tested-by: Shuah Khan Link: https://lore.kernel.org/r/20250408195232.204375459@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Jon Hunter Tested-by: Takeshi Ogasawara Tested-by: Salvatore Bonaccorso Link: https://lore.kernel.org/r/20250409115934.968141886@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Miguel Ojeda Tested-by: SeongJae Park Tested-by: Shuah Khan Tested-by: Mark Brown Tested-by: Jon Hunter Tested-by: Florian Fainelli Tested-by: Peter Schneider Tested-by: Takeshi Ogasawara Signed-off-by: Greg Kroah-Hartman commit 4bf228566e9e72de10f82b1b2d2e36927dbba868 Author: Louis-Alexis Eyraud Date: Fri Feb 28 11:32:19 2025 +0100 ASoC: mediatek: mt6359: Fix DT parse error due to wrong child node name commit 79c080c75cdd0a5ba38be039f6f9bb66ec53b0c4 upstream. A recent dtbs_check error fix in mt6359.dtsi file changed a node name (from "mt6359codec" to "audio-codec") without modifying the mt6539 codec code that uses it. It leads to a probe failure after devicetree parsing returns in error: ``` [ 1.354025] mt6359-sound mt6359-sound: mt6359_platform_driver_probe() failed to parse dts [ 1.355066] mt6359-sound mt6359-sound: probe with driver mt6359-sound failed with error -22 ``` So, add the child node retrieval with the new name and if not found, try with the older one for backward compatibility. Fixes: 76b35f59bbe6 ("arm64: dts: mediatek: mt6359: fix dtbs_check error for audio-codec") Signed-off-by: Louis-Alexis Eyraud Reviewed-by: Nícolas F. R. A. Prado Link: https://patch.msgid.link/20250228-mt6359-fix-probe-failed-v1-1-64941d387b2c@collabora.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit ab48e742e575121f8e92cf66d8bc6ef54e60a555 Author: Steven Rostedt Date: Sun Mar 23 15:21:51 2025 -0400 tracing: Do not use PERF enums when perf is not defined commit 8eb1518642738c6892bd629b46043513a3bf1a6a upstream. An update was made to up the module ref count when a synthetic event is registered for both trace and perf events. But if perf is not configured in, the perf enums used will cause the kernel to fail to build. Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Douglas Raillard Link: https://lore.kernel.org/20250323152151.528b5ced@batman.local.home Fixes: 21581dd4e7ff ("tracing: Ensure module defining synth event cannot be unloaded while tracing") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202503232230.TeREVy8R-lkp@intel.com/ Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 3735e6ea6def0f8b38d97ce8aea5f9a64e8301a2 Author: Juri Lelli Date: Thu Mar 13 18:13:29 2025 +0100 include/{topology,cpuset}: Move dl_rebuild_rd_accounting to cpuset.h commit 34929a070b7fd06c386080c926b61ee844e6ad34 upstream. dl_rebuild_rd_accounting() is defined in cpuset.c, so it makes more sense to move related declarations to cpuset.h. Implement the move. Suggested-by: Waiman Long Signed-off-by: Juri Lelli Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Waiman Long Reviewed-by: Valentin Schneider Reviewed-by: Dietmar Eggemann Tested-by: Waiman Long Tested-by: Jon Hunter Tested-by: Dietmar Eggemann Link: https://lore.kernel.org/r/Z9MSOVMpU7jpVrMU@jlelli-thinkpadt14gen4.remote.csb Signed-off-by: Greg Kroah-Hartman commit 198f2b471c4252b0d1abc5490620e526d080cdf2 Author: Ian Rogers Date: Fri Jan 31 23:43:18 2025 -0800 perf pmu: Rename name matching for no suffix or wildcard variants commit 63e287131cf0c59b026053d6d63fe271604ffa7e upstream. Wildcard PMU naming will match a name like pmu_1 to a PMU name like pmu_10 but not to a PMU name like pmu_2 as the suffix forms part of the match. No suffix matching will match pmu_10 to either pmu_1 or pmu_2. Add or rename matching functions on PMU to make it clearer what kind of matching is being performed. Signed-off-by: Ian Rogers Reviewed-by: Kan Liang Link: https://lore.kernel.org/r/20250201074320.746259-4-irogers@google.com Signed-off-by: Namhyung Kim Signed-off-by: Greg Kroah-Hartman commit 094462af693f5b3e46ee77a09ff6a42db18215b7 Author: Chuck Lever Date: Tue Jan 14 17:09:24 2025 -0500 NFSD: Skip sending CB_RECALL_ANY when the backchannel isn't up commit 8a388c1fabeb6606e16467b23242416c0dbeffad upstream. NFSD sends CB_RECALL_ANY to clients when the server is low on memory or that client has a large number of delegations outstanding. We've seen cases where NFSD attempts to send CB_RECALL_ANY requests to disconnected clients, and gets confused. These calls never go anywhere if a backchannel transport to the target client isn't available. Before the server can send any backchannel operation, the client has to connect first and then do a BIND_CONN_TO_SESSION. This patch doesn't address the root cause of the confusion, but there's no need to queue up these optional operations if they can't go anywhere. Fixes: 44df6f439a17 ("NFSD: add delegation reaper to react to low memory condition") Reviewed-by: Jeff Layton Cc: stable@vger.kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit a9d4c12fb07f6eb8b64c5c8589df517870c818db Author: Chuck Lever Date: Sun Jan 26 16:50:18 2025 -0500 NFSD: Never return NFS4ERR_FILE_OPEN when removing a directory commit 370345b4bd184a49ac68d6591801e5e3605b355a upstream. RFC 8881 Section 18.25.4 paragraph 5 tells us that the server should return NFS4ERR_FILE_OPEN only if the target object is an opened file. This suggests that returning this status when removing a directory will confuse NFS clients. This is a version-specific issue; nfsd_proc_remove/rmdir() and nfsd3_proc_remove/rmdir() already return nfserr_access as appropriate. Unfortunately there is no quick way for nfsd4_remove() to determine whether the target object is a file or not, so the check is done in in nfsd_unlink() for now. Reported-by: Trond Myklebust Fixes: 466e16f0920f ("nfsd: check for EBUSY from vfs_rmdir/vfs_unink.") Reviewed-by: Jeff Layton Cc: stable@vger.kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit c2ed21ae4731bae8bf62d29fe2184b1cba745d85 Author: Chuck Lever Date: Sun Jan 26 16:50:17 2025 -0500 NFSD: nfsd_unlink() clobbers non-zero status returned from fh_fill_pre_attrs() commit d7d8e3169b56e7696559a2427c922c0d55debcec upstream. If fh_fill_pre_attrs() returns a non-zero status, the error flow takes it through out_unlock, which then overwrites the returned status code with err = nfserrno(host_err); Fixes: a332018a91c4 ("nfsd: handle failure to collect pre/post-op attrs more sanely") Reviewed-by: Jeff Layton Cc: stable@vger.kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 0f42df0ab2b11ea6b2884bdaf6dbc3be6dde7e82 Author: Olga Kornievskaia Date: Fri Jan 17 11:32:58 2025 -0500 nfsd: fix management of listener transports commit d093c90892607be505e801469d6674459e69ab89 upstream. Currently, when no active threads are running, a root user using nfsdctl command can try to remove a particular listener from the list of previously added ones, then start the server by increasing the number of threads, it leads to the following problem: [ 158.835354] refcount_t: addition on 0; use-after-free. [ 158.835603] WARNING: CPU: 2 PID: 9145 at lib/refcount.c:25 refcount_warn_saturate+0x160/0x1a0 [ 158.836017] Modules linked in: rpcrdma rdma_cm iw_cm ib_cm ib_core nfsd auth_rpcgss nfs_acl lockd grace overlay isofs uinput snd_seq_dummy snd_hrtimer nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 rfkill ip_set nf_tables qrtr sunrpc vfat fat uvcvideo videobuf2_vmalloc videobuf2_memops uvc videobuf2_v4l2 videodev videobuf2_common snd_hda_codec_generic mc e1000e snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd soundcore sg loop dm_multipath dm_mod nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs libcrc32c crct10dif_ce ghash_ce vmwgfx sha2_ce sha256_arm64 sr_mod sha1_ce cdrom nvme drm_client_lib drm_ttm_helper ttm nvme_core drm_kms_helper nvme_auth drm fuse [ 158.840093] CPU: 2 UID: 0 PID: 9145 Comm: nfsd Kdump: loaded Tainted: G B W 6.13.0-rc6+ #7 [ 158.840624] Tainted: [B]=BAD_PAGE, [W]=WARN [ 158.840802] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024 [ 158.841220] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 158.841563] pc : refcount_warn_saturate+0x160/0x1a0 [ 158.841780] lr : refcount_warn_saturate+0x160/0x1a0 [ 158.842000] sp : ffff800089be7d80 [ 158.842147] x29: ffff800089be7d80 x28: ffff00008e68c148 x27: ffff00008e68c148 [ 158.842492] x26: ffff0002e3b5c000 x25: ffff600011cd1829 x24: ffff00008653c010 [ 158.842832] x23: ffff00008653c000 x22: 1fffe00011cd1829 x21: ffff00008653c028 [ 158.843175] x20: 0000000000000002 x19: ffff00008653c010 x18: 0000000000000000 [ 158.843505] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 158.843836] x14: 0000000000000000 x13: 0000000000000001 x12: ffff600050a26493 [ 158.844143] x11: 1fffe00050a26492 x10: ffff600050a26492 x9 : dfff800000000000 [ 158.844475] x8 : 00009fffaf5d9b6e x7 : ffff000285132493 x6 : 0000000000000001 [ 158.844823] x5 : ffff000285132490 x4 : ffff600050a26493 x3 : ffff8000805e72bc [ 158.845174] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000098588000 [ 158.845528] Call trace: [ 158.845658] refcount_warn_saturate+0x160/0x1a0 (P) [ 158.845894] svc_recv+0x58c/0x680 [sunrpc] [ 158.846183] nfsd+0x1fc/0x348 [nfsd] [ 158.846390] kthread+0x274/0x2f8 [ 158.846546] ret_from_fork+0x10/0x20 [ 158.846714] ---[ end trace 0000000000000000 ]--- nfsd_nl_listener_set_doit() would manipulate the list of transports of server's sv_permsocks and close the specified listener but the other list of transports (server's sp_xprts list) would not be changed leading to the problem above. Instead, determined if the nfsdctl is trying to remove a listener, in which case, delete all the existing listener transports and re-create all-but-the-removed ones. Fixes: 16a471177496 ("NFSD: add listener-{set,get} netlink command") Signed-off-by: Olga Kornievskaia Reviewed-by: Jeff Layton Cc: stable@vger.kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 5f15a20f3fffa029c1010b998d3585116b0b42de Author: Chuck Lever Date: Tue Mar 11 23:06:38 2025 -0400 NFSD: Add a Kconfig setting to enable delegated timestamps commit 26a80762153ba0dc98258b5e6d2e9741178c5114 upstream. After three tries, we still see test failures with delegated timestamps. Disable them by default, but leave the implementation intact so that development can continue. Cc: stable@vger.kernel.org # v6.14 Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 133f5e2a37ce08c82d24e8fba65e0a81deae4609 Author: Li Lingfeng Date: Thu Feb 13 22:42:20 2025 +0800 nfsd: put dl_stid if fail to queue dl_recall commit 230ca758453c63bd38e4d9f4a21db698f7abada8 upstream. Before calling nfsd4_run_cb to queue dl_recall to the callback_wq, we increment the reference count of dl_stid. We expect that after the corresponding work_struct is processed, the reference count of dl_stid will be decremented through the callback function nfsd4_cb_recall_release. However, if the call to nfsd4_run_cb fails, the incremented reference count of dl_stid will not be decremented correspondingly, leading to the following nfs4_stid leak: unreferenced object 0xffff88812067b578 (size 344): comm "nfsd", pid 2761, jiffies 4295044002 (age 5541.241s) hex dump (first 32 bytes): 01 00 00 00 6b 6b 6b 6b b8 02 c0 e2 81 88 ff ff ....kkkk........ 00 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 ad 4e ad de .kkkkkkk.....N.. backtrace: kmem_cache_alloc+0x4b9/0x700 nfsd4_process_open1+0x34/0x300 nfsd4_open+0x2d1/0x9d0 nfsd4_proc_compound+0x7a2/0xe30 nfsd_dispatch+0x241/0x3e0 svc_process_common+0x5d3/0xcc0 svc_process+0x2a3/0x320 nfsd+0x180/0x2e0 kthread+0x199/0x1d0 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1b/0x30 unreferenced object 0xffff8881499f4d28 (size 368): comm "nfsd", pid 2761, jiffies 4295044005 (age 5541.239s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 30 4d 9f 49 81 88 ff ff ........0M.I.... 30 4d 9f 49 81 88 ff ff 20 00 00 00 01 00 00 00 0M.I.... ....... backtrace: kmem_cache_alloc+0x4b9/0x700 nfs4_alloc_stid+0x29/0x210 alloc_init_deleg+0x92/0x2e0 nfs4_set_delegation+0x284/0xc00 nfs4_open_delegation+0x216/0x3f0 nfsd4_process_open2+0x2b3/0xee0 nfsd4_open+0x770/0x9d0 nfsd4_proc_compound+0x7a2/0xe30 nfsd_dispatch+0x241/0x3e0 svc_process_common+0x5d3/0xcc0 svc_process+0x2a3/0x320 nfsd+0x180/0x2e0 kthread+0x199/0x1d0 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1b/0x30 Fix it by checking the result of nfsd4_run_cb and call nfs4_put_stid if fail to queue dl_recall. Cc: stable@vger.kernel.org Signed-off-by: Li Lingfeng Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 5bcb44e650bc4ec7eac23df90c5e011a77fa2beb Author: Jeff Layton Date: Thu Feb 13 09:08:29 2025 -0500 nfsd: allow SC_STATUS_FREEABLE when searching via nfs4_lookup_stateid() commit d1bc15b147d35b4cb7ca99a9a7d79d41ca342c13 upstream. The pynfs DELEG8 test fails when run against nfsd. It acquires a delegation and then lets the lease time out. It then tries to use the deleg stateid and expects to see NFS4ERR_DELEG_REVOKED, but it gets bad NFS4ERR_BAD_STATEID instead. When a delegation is revoked, it's initially marked with SC_STATUS_REVOKED, or SC_STATUS_ADMIN_REVOKED and later, it's marked with the SC_STATUS_FREEABLE flag, which denotes that it is waiting for s FREE_STATEID call. nfs4_lookup_stateid() accepts a statusmask that includes the status flags that a found stateid is allowed to have. Currently, that mask never includes SC_STATUS_FREEABLE, which means that revoked delegations are (almost) never found. Add SC_STATUS_FREEABLE to the always-allowed status flags, and remove it from nfsd4_delegreturn() since it's now always implied. Fixes: 8dd91e8d31fe ("nfsd: fix race between laundromat and free_stateid") Cc: stable@vger.kernel.org Signed-off-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 9d9456185fd5f1891c74354ee297f19538141ead Author: Jeff Layton Date: Thu Feb 6 13:12:13 2025 -0500 nfsd: don't ignore the return code of svc_proc_register() commit 930b64ca0c511521f0abdd1d57ce52b2a6e3476b upstream. Currently, nfsd_proc_stat_init() ignores the return value of svc_proc_register(). If the procfile creation fails, then the kernel will WARN when it tries to remove the entry later. Fix nfsd_proc_stat_init() to return the same type of pointer as svc_proc_register(), and fix up nfsd_net_init() to check that and fail the nfsd_net construction if it occurs. svc_proc_register() can fail if the dentry can't be allocated, or if an identical dentry already exists. The second case is pretty unlikely in the nfsd_net construction codepath, so if this happens, return -ENOMEM. Reported-by: syzbot+e34ad04f27991521104c@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-nfs/67a47501.050a0220.19061f.05f9.GAE@google.com/ Cc: stable@vger.kernel.org # v6.9 Signed-off-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 8760da4b9d44c36b93b6e4cf401ec7fe520015bd Author: Murad Masimov Date: Mon Jan 13 13:51:30 2025 +0300 media: streamzap: fix race between device disconnection and urb callback commit f656cfbc7a293a039d6a0c7100e1c846845148c1 upstream. Syzkaller has reported a general protection fault at function ir_raw_event_store_with_filter(). This crash is caused by a NULL pointer dereference of dev->raw pointer, even though it is checked for NULL in the same function, which means there is a race condition. It occurs due to the incorrect order of actions in the streamzap_disconnect() function: rc_unregister_device() is called before usb_kill_urb(). The dev->raw pointer is freed and set to NULL in rc_unregister_device(), and only after that usb_kill_urb() waits for in-progress requests to finish. If rc_unregister_device() is called while streamzap_callback() handler is not finished, this can lead to accessing freed resources. Thus rc_unregister_device() should be called after usb_kill_urb(). Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 8e9e60640067 ("V4L/DVB: staging/lirc: port lirc_streamzap to ir-core") Cc: stable@vger.kernel.org Reported-by: syzbot+34008406ee9a31b13c73@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=34008406ee9a31b13c73 Signed-off-by: Murad Masimov Signed-off-by: Sean Young Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 7a58d4c4cf8ff60ab1f93399deefaf6057da91c7 Author: Nikita Zhandarovich Date: Sun Mar 2 17:58:25 2025 +0300 media: vimc: skip .s_stream() for stopped entities commit 36cef585e2a31e4ddf33a004b0584a7a572246de upstream. Syzbot reported [1] a warning prompted by a check in call_s_stream() that checks whether .s_stream() operation is warranted for unstarted or stopped subdevs. Add a simple fix in vimc_streamer_pipeline_terminate() ensuring that entities skip a call to .s_stream() unless they have been previously properly started. [1] Syzbot report: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5933 at drivers/media/v4l2-core/v4l2-subdev.c:460 call_s_stream+0x2df/0x350 drivers/media/v4l2-core/v4l2-subdev.c:460 Modules linked in: CPU: 0 UID: 0 PID: 5933 Comm: syz-executor330 Not tainted 6.13.0-rc2-syzkaller-00362-g2d8308bf5b67 #0 ... Call Trace: vimc_streamer_pipeline_terminate+0x218/0x320 drivers/media/test-drivers/vimc/vimc-streamer.c:62 vimc_streamer_pipeline_init drivers/media/test-drivers/vimc/vimc-streamer.c:101 [inline] vimc_streamer_s_stream+0x650/0x9a0 drivers/media/test-drivers/vimc/vimc-streamer.c:203 vimc_capture_start_streaming+0xa1/0x130 drivers/media/test-drivers/vimc/vimc-capture.c:256 vb2_start_streaming+0x15f/0x5a0 drivers/media/common/videobuf2/videobuf2-core.c:1789 vb2_core_streamon+0x2a7/0x450 drivers/media/common/videobuf2/videobuf2-core.c:2348 vb2_streamon drivers/media/common/videobuf2/videobuf2-v4l2.c:875 [inline] vb2_ioctl_streamon+0xf4/0x170 drivers/media/common/videobuf2/videobuf2-v4l2.c:1118 __video_do_ioctl+0xaf0/0xf00 drivers/media/v4l2-core/v4l2-ioctl.c:3122 video_usercopy+0x4d2/0x1620 drivers/media/v4l2-core/v4l2-ioctl.c:3463 v4l2_ioctl+0x1ba/0x250 drivers/media/v4l2-core/v4l2-dev.c:366 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl fs/ioctl.c:892 [inline] __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f2b85c01b19 ... Reported-by: syzbot+5bcd7c809d365e14c4df@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=5bcd7c809d365e14c4df Fixes: adc589d2a208 ("media: vimc: Add vimc-streamer for stream control") Cc: stable@vger.kernel.org Signed-off-by: Nikita Zhandarovich Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit b519f2e5800fe2391b7545ba6889df795828e885 Author: Oleg Nesterov Date: Mon Mar 24 17:00:03 2025 +0100 exec: fix the racy usage of fs_struct->in_exec commit af7bb0d2ca459f15cb5ca604dab5d9af103643f0 upstream. check_unsafe_exec() sets fs->in_exec under cred_guard_mutex, then execve() paths clear fs->in_exec lockless. This is fine if exec succeeds, but if it fails we have the following race: T1 sets fs->in_exec = 1, fails, drops cred_guard_mutex T2 sets fs->in_exec = 1 T1 clears fs->in_exec T2 continues with fs->in_exec == 0 Change fs/exec.c to clear fs->in_exec with cred_guard_mutex held. Reported-by: syzbot+1c486d0b62032c82a968@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/67dc67f0.050a0220.25ae54.001f.GAE@google.com/ Cc: stable@vger.kernel.org Signed-off-by: Oleg Nesterov Link: https://lore.kernel.org/r/20250324160003.GA8878@redhat.com Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit 717d9c35deff6c33235693171bacbb03e9643fa4 Author: Yosry Ahmed Date: Wed Feb 26 18:56:25 2025 +0000 mm: zswap: fix crypto_free_acomp() deadlock in zswap_cpu_comp_dead() commit c11bcbc0a517acf69282c8225059b2a8ac5fe628 upstream. Currently, zswap_cpu_comp_dead() calls crypto_free_acomp() while holding the per-CPU acomp_ctx mutex. crypto_free_acomp() then holds scomp_lock (through crypto_exit_scomp_ops_async()). On the other hand, crypto_alloc_acomp_node() holds the scomp_lock (through crypto_scomp_init_tfm()), and then allocates memory. If the allocation results in reclaim, we may attempt to hold the per-CPU acomp_ctx mutex. The above dependencies can cause an ABBA deadlock. For example in the following scenario: (1) Task A running on CPU #1: crypto_alloc_acomp_node() Holds scomp_lock Enters reclaim Reads per_cpu_ptr(pool->acomp_ctx, 1) (2) Task A is descheduled (3) CPU #1 goes offline zswap_cpu_comp_dead(CPU #1) Holds per_cpu_ptr(pool->acomp_ctx, 1)) Calls crypto_free_acomp() Waits for scomp_lock (4) Task A running on CPU #2: Waits for per_cpu_ptr(pool->acomp_ctx, 1) // Read on CPU #1 DEADLOCK Since there is no requirement to call crypto_free_acomp() with the per-CPU acomp_ctx mutex held in zswap_cpu_comp_dead(), move it after the mutex is unlocked. Also move the acomp_request_free() and kfree() calls for consistency and to avoid any potential sublte locking dependencies in the future. With this, only setting acomp_ctx fields to NULL occurs with the mutex held. This is similar to how zswap_cpu_comp_prepare() only initializes acomp_ctx fields with the mutex held, after performing all allocations before holding the mutex. Opportunistically, move the NULL check on acomp_ctx so that it takes place before the mutex dereference. Link: https://lkml.kernel.org/r/20250226185625.2672936-1-yosry.ahmed@linux.dev Fixes: 12dcb0ef5406 ("mm: zswap: properly synchronize freeing resources during CPU hotunplug") Signed-off-by: Herbert Xu Co-developed-by: Herbert Xu Signed-off-by: Yosry Ahmed Reported-by: syzbot+1a517ccfcbc6a7ab0f82@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/67bcea51.050a0220.bbfd1.0096.GAE@google.com/ Acked-by: Herbert Xu Reviewed-by: Chengming Zhou Reviewed-by: Nhat Pham Tested-by: Nhat Pham Cc: David S. Miller Cc: Eric Biggers Cc: Johannes Weiner Cc: Chris Murphy Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 3ba8b4e97f6cf425f249524f77f8e6dcf99b476a Author: Roman Smirnov Date: Wed Feb 26 11:25:22 2025 +0300 jfs: add index corruption check to DT_GETPAGE() commit a8dfb2168906944ea61acfc87846b816eeab882d upstream. If the file system is corrupted, the header.stblindex variable may become greater than 127. Because of this, an array access out of bounds may occur: ------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dtree.c:3096:10 index 237 is out of range for type 'struct dtslot[128]' CPU: 0 UID: 0 PID: 5822 Comm: syz-executor740 Not tainted 6.13.0-rc4-syzkaller-00110-g4099a71718b0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_out_of_bounds+0x121/0x150 lib/ubsan.c:429 dtReadFirst+0x622/0xc50 fs/jfs/jfs_dtree.c:3096 dtReadNext fs/jfs/jfs_dtree.c:3147 [inline] jfs_readdir+0x9aa/0x3c50 fs/jfs/jfs_dtree.c:2862 wrap_directory_iterator+0x91/0xd0 fs/readdir.c:65 iterate_dir+0x571/0x800 fs/readdir.c:108 __do_sys_getdents64 fs/readdir.c:403 [inline] __se_sys_getdents64+0x1e2/0x4b0 fs/readdir.c:389 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f ---[ end trace ]--- Add a stblindex check for corruption. Reported-by: syzbot Closes: https://syzkaller.appspot.com/bug?extid=9120834fc227768625ba Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Roman Smirnov Signed-off-by: Dave Kleikamp Signed-off-by: Greg Kroah-Hartman commit 5263822558a8a7c0d0248d5679c2dcf4d5cda61f Author: Qasim Ijaz Date: Thu Feb 13 21:05:53 2025 +0000 jfs: fix slab-out-of-bounds read in ea_get() commit fdf480da5837c23b146c4743c18de97202fcab37 upstream. During the "size_check" label in ea_get(), the code checks if the extended attribute list (xattr) size matches ea_size. If not, it logs "ea_get: invalid extended attribute" and calls print_hex_dump(). Here, EALIST_SIZE(ea_buf->xattr) returns 4110417968, which exceeds INT_MAX (2,147,483,647). Then ea_size is clamped: int size = clamp_t(int, ea_size, 0, EALIST_SIZE(ea_buf->xattr)); Although clamp_t aims to bound ea_size between 0 and 4110417968, the upper limit is treated as an int, causing an overflow above 2^31 - 1. This leads "size" to wrap around and become negative (-184549328). The "size" is then passed to print_hex_dump() (called "len" in print_hex_dump()), it is passed as type size_t (an unsigned type), this is then stored inside a variable called "int remaining", which is then assigned to "int linelen" which is then passed to hex_dump_to_buffer(). In print_hex_dump() the for loop, iterates through 0 to len-1, where len is 18446744073525002176, calling hex_dump_to_buffer() on each iteration: for (i = 0; i < len; i += rowsize) { linelen = min(remaining, rowsize); remaining -= rowsize; hex_dump_to_buffer(ptr + i, linelen, rowsize, groupsize, linebuf, sizeof(linebuf), ascii); ... } The expected stopping condition (i < len) is effectively broken since len is corrupted and very large. This eventually leads to the "ptr+i" being passed to hex_dump_to_buffer() to get closer to the end of the actual bounds of "ptr", eventually an out of bounds access is done in hex_dump_to_buffer() in the following for loop: for (j = 0; j < len; j++) { if (linebuflen < lx + 2) goto overflow2; ch = ptr[j]; ... } To fix this we should validate "EALIST_SIZE(ea_buf->xattr)" before it is utilised. Reported-by: syzbot Tested-by: syzbot Closes: https://syzkaller.appspot.com/bug?extid=4e6e7e4279d046613bc5 Fixes: d9f9d96136cb ("jfs: xattr: check invalid xattr size more strictly") Cc: stable@vger.kernel.org Signed-off-by: Qasim Ijaz Signed-off-by: Dave Kleikamp Signed-off-by: Greg Kroah-Hartman commit 1181924af78e5299ddec6e457789c02dd5966559 Author: Lukas Wunner Date: Sat Mar 22 19:52:08 2025 +0100 PCI/bwctrl: Fix NULL pointer dereference on bus number exhaustion commit 667f053b05f00a007738cd7ed6fa1901de19dc7e upstream. When BIOS neglects to assign bus numbers to PCI bridges, the kernel attempts to correct that during PCI device enumeration. If it runs out of bus numbers, no pci_bus is allocated and the "subordinate" pointer in the bridge's pci_dev remains NULL. The PCIe bandwidth controller erroneously does not check for a NULL subordinate pointer and dereferences it on probe. Bandwidth control of unusable devices below the bridge is of questionable utility, so simply error out instead. This mirrors what PCIe hotplug does since commit 62e4492c3063 ("PCI: Prevent NULL dereference during pciehp probe"). The PCI core emits a message with KERN_INFO severity if it has run out of bus numbers. PCIe hotplug emits an additional message with KERN_ERR severity to inform the user that hotplug functionality is disabled at the bridge. A similar message for bandwidth control does not seem merited, given that its only purpose so far is to expose an up-to-date link speed in sysfs and throttle the link speed on certain laptops with limited Thermal Design Power. So error out silently. User-visible messages: pci 0000:16:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring [...] pci_bus 0000:45: busn_res: [bus 45-74] end is updated to 74 pci 0000:16:02.0: devices behind bridge are unusable because [bus 45-74] cannot be assigned for them [...] pcieport 0000:16:02.0: pciehp: Hotplug bridge without secondary bus, ignoring [...] BUG: kernel NULL pointer dereference RIP: pcie_update_link_speed pcie_bwnotif_enable pcie_bwnotif_probe pcie_port_probe_service really_probe Fixes: 665745f27487 ("PCI/bwctrl: Re-add BW notification portdrv as PCIe BW controller") Reported-by: Wouter Bijlsma Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219906 Signed-off-by: Lukas Wunner Signed-off-by: Krzysztof Wilczyński Tested-by: Wouter Bijlsma Cc: stable@vger.kernel.org # v6.13+ Link: https://lore.kernel.org/r/3b6c8d973aedc48860640a9d75d20528336f1f3c.1742669372.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman commit 53bc45da8d8da92ec07877f5922b130562eb4b00 Author: Acs, Jakub Date: Thu Mar 20 15:46:49 2025 +0000 ext4: fix OOB read when checking dotdot dir commit d5e206778e96e8667d3bde695ad372c296dc9353 upstream. Mounting a corrupted filesystem with directory which contains '.' dir entry with rec_len == block size results in out-of-bounds read (later on, when the corrupted directory is removed). ext4_empty_dir() assumes every ext4 directory contains at least '.' and '..' as directory entries in the first data block. It first loads the '.' dir entry, performs sanity checks by calling ext4_check_dir_entry() and then uses its rec_len member to compute the location of '..' dir entry (in ext4_next_entry). It assumes the '..' dir entry fits into the same data block. If the rec_len of '.' is precisely one block (4KB), it slips through the sanity checks (it is considered the last directory entry in the data block) and leaves "struct ext4_dir_entry_2 *de" point exactly past the memory slot allocated to the data block. The following call to ext4_check_dir_entry() on new value of de then dereferences this pointer which results in out-of-bounds mem access. Fix this by extending __ext4_check_dir_entry() to check for '.' dir entries that reach the end of data block. Make sure to ignore the phony dir entries for checksum (by checking name_len for non-zero). Note: This is reported by KASAN as use-after-free in case another structure was recently freed from the slot past the bound, but it is really an OOB read. This issue was found by syzkaller tool. Call Trace: [ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710 [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375 [ 38.595158] [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1 [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 38.595304] Call Trace: [ 38.595308] [ 38.595311] dump_stack_lvl+0xa7/0xd0 [ 38.595325] print_address_description.constprop.0+0x2c/0x3f0 [ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595349] print_report+0xaa/0x250 [ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595368] ? kasan_addr_to_slab+0x9/0x90 [ 38.595378] kasan_report+0xab/0xe0 [ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595400] __ext4_check_dir_entry+0x67e/0x710 [ 38.595410] ext4_empty_dir+0x465/0x990 [ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10 [ 38.595432] ext4_rmdir.part.0+0x29a/0xd10 [ 38.595441] ? __dquot_initialize+0x2a7/0xbf0 [ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10 [ 38.595464] ? __pfx___dquot_initialize+0x10/0x10 [ 38.595478] ? down_write+0xdb/0x140 [ 38.595487] ? __pfx_down_write+0x10/0x10 [ 38.595497] ext4_rmdir+0xee/0x140 [ 38.595506] vfs_rmdir+0x209/0x670 [ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190 [ 38.595529] do_rmdir+0x363/0x3c0 [ 38.595537] ? __pfx_do_rmdir+0x10/0x10 [ 38.595544] ? strncpy_from_user+0x1ff/0x2e0 [ 38.595561] __x64_sys_unlinkat+0xf0/0x130 [ 38.595570] do_syscall_64+0x5b/0x180 [ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: ac27a0ec112a0 ("[PATCH] ext4: initial copy of files from ext3") Signed-off-by: Jakub Acs Cc: Theodore Ts'o Cc: Andreas Dilger Cc: linux-ext4@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Mahmoud Adam Cc: stable@vger.kernel.org Cc: security@kernel.org Link: https://patch.msgid.link/b3ae36a6794c4a01944c7d70b403db5b@amazon.de Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit c891bc9bbd2dd626a92cddf4a689c3150b8ed20a Author: Theodore Ts'o Date: Fri Mar 14 00:38:42 2025 -0400 ext4: don't over-report free space or inodes in statvfs commit f87d3af7419307ae26e705a2b2db36140db367a2 upstream. This fixes an analogus bug that was fixed in xfs in commit 4b8d867ca6e2 ("xfs: don't over-report free space or inodes in statvfs") where statfs can report misleading / incorrect information where project quota is enabled, and the free space is less than the remaining quota. This commit will resolve a test failure in generic/762 which tests for this bug. Cc: stable@kernel.org Fixes: 689c958cbe6b ("ext4: add project quota support") Signed-off-by: Theodore Ts'o Reviewed-by: "Darrick J. Wong" Signed-off-by: Greg Kroah-Hartman commit 5a57f8eb2a17d469d65cd1186cea26b798221d4a Author: Ming Yen Hsieh Date: Tue Feb 18 11:33:42 2025 +0800 wifi: mt76: mt7921: fix kernel panic due to null pointer dereference commit adc3fd2a2277b7cc0b61692463771bf9bd298036 upstream. Address a kernel panic caused by a null pointer dereference in the `mt792x_rx_get_wcid` function. The issue arises because the `deflink` structure is not properly initialized with the `sta` context. This patch ensures that the `deflink` structure is correctly linked to the `sta` context, preventing the null pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000400 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 UID: 0 PID: 470 Comm: mt76-usb-rx phy Not tainted 6.12.13-gentoo-dist #1 Hardware name: /AMD HUDSON-M1, BIOS 4.6.4 11/15/2011 RIP: 0010:mt792x_rx_get_wcid+0x48/0x140 [mt792x_lib] RSP: 0018:ffffa147c055fd98 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff8e9ecb652000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8e9ecb652000 RBP: 0000000000000685 R08: ffff8e9ec6570000 R09: 0000000000000000 R10: ffff8e9ecd2ca000 R11: ffff8e9f22a217c0 R12: 0000000038010119 R13: 0000000080843801 R14: ffff8e9ec6570000 R15: ffff8e9ecb652000 FS: 0000000000000000(0000) GS:ffff8e9f22a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000400 CR3: 000000000d2ea000 CR4: 00000000000006f0 Call Trace: ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15a/0x2f0 ? search_module_extables+0x19/0x60 ? search_bpf_extables+0x5f/0x80 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? mt792x_rx_get_wcid+0x48/0x140 [mt792x_lib] mt7921_queue_rx_skb+0x1c6/0xaa0 [mt7921_common] mt76u_alloc_queues+0x784/0x810 [mt76_usb] ? __pfx___mt76_worker_fn+0x10/0x10 [mt76] __mt76_worker_fn+0x4f/0x80 [mt76] kthread+0xd2/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]--- Reported-by: Nick Morrow Closes: https://github.com/morrownr/USB-WiFi/issues/577 Cc: stable@vger.kernel.org Fixes: 90c10286b176 ("wifi: mt76: mt7925: Update mt792x_rx_get_wcid for per-link STA") Signed-off-by: Ming Yen Hsieh Tested-by: Salah Coronya Link: https://patch.msgid.link/20250218033343.1999648-1-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit ecf798573bbe0805803f7764e12a34b4bcc65074 Author: Angelos Oikonomopoulos Date: Tue Apr 1 10:51:50 2025 +0200 arm64: Don't call NULL in do_compat_alignment_fixup() commit c28f31deeacda307acfee2f18c0ad904e5123aac upstream. do_alignment_t32_to_handler() only fixes up alignment faults for specific instructions; it returns NULL otherwise (e.g. LDREX). When that's the case, signal to the caller that it needs to proceed with the regular alignment fault handling (i.e. SIGBUS). Without this patch, the kernel panics: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000006 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=00000800164aa000 [0000000000000000] pgd=0800081fdbd22003, p4d=0800081fdbd22003, pud=08000815d51c6003, pmd=0000000000000000 Internal error: Oops: 0000000086000006 [#1] SMP Modules linked in: cfg80211 rfkill xt_nat xt_tcpudp xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat br_netfilter veth nvme_fa> libcrc32c crc32c_generic raid0 multipath linear dm_mod dax raid1 md_mod xhci_pci nvme xhci_hcd nvme_core t10_pi usbcore igb crc64_rocksoft crc64 crc_t10dif crct10dif_generic crct10dif_ce crct10dif_common usb_common i2c_algo_bit i2c> CPU: 2 PID: 3932954 Comm: WPEWebProcess Not tainted 6.1.0-31-arm64 #1 Debian 6.1.128-1 Hardware name: GIGABYTE MP32-AR1-00/MP32-AR1-00, BIOS F18v (SCP: 1.08.20211002) 12/01/2021 pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : do_compat_alignment_fixup+0xd8/0x3dc sp : ffff80000f973dd0 x29: ffff80000f973dd0 x28: ffff081b42526180 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 x23: 0000000000000004 x22: 0000000000000000 x21: 0000000000000001 x20: 00000000e8551f00 x19: ffff80000f973eb0 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffaebc949bc488 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000400000 x4 : 0000fffffffffffe x3 : 0000000000000000 x2 : ffff80000f973eb0 x1 : 00000000e8551f00 x0 : 0000000000000001 Call trace: 0x0 do_alignment_fault+0x40/0x50 do_mem_abort+0x4c/0xa0 el0_da+0x48/0xf0 el0t_32_sync_handler+0x110/0x140 el0t_32_sync+0x190/0x194 Code: bad PC value ---[ end trace 0000000000000000 ]--- Signed-off-by: Angelos Oikonomopoulos Fixes: 3fc24ef32d3b ("arm64: compat: Implement misalignment fixups for multiword loads") Cc: # 6.1.x Reviewed-by: Anshuman Khandual Link: https://lore.kernel.org/r/20250401085150.148313-1-angelos@igalia.com Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit fd900832e8440046627b60697687ab5d04398008 Author: David Hildenbrand Date: Mon Feb 10 20:37:43 2025 +0100 mm/gup: reject FOLL_SPLIT_PMD with hugetlb VMAs commit 8977752c8056a6a094a279004a49722da15bace3 upstream. Patch series "mm: fixes for device-exclusive entries (hmm)", v2. Discussing the PageTail() call in make_device_exclusive_range() with Willy, I recently discovered [1] that device-exclusive handling does not properly work with THP, making the hmm-tests selftests fail if THPs are enabled on the system. Looking into more details, I found that hugetlb is not properly fenced, and I realized that something that was bugging me for longer -- how device-exclusive entries interact with mapcounts -- completely breaks migration/swapout/split/hwpoison handling of these folios while they have device-exclusive PTEs. The program below can be used to allocate 1 GiB worth of pages and making them device-exclusive on a kernel with CONFIG_TEST_HMM. Once they are device-exclusive, these folios cannot get swapped out (proc$pid/smaps_rollup will always indicate 1 GiB RSS no matter how much one forces memory reclaim), and when having a memory block onlined to ZONE_MOVABLE, trying to offline it will loop forever and complain about failed migration of a page that should be movable. # echo offline > /sys/devices/system/memory/memory136/state # echo online_movable > /sys/devices/system/memory/memory136/state # ./hmm-swap & ... wait until everything is device-exclusive # echo offline > /sys/devices/system/memory/memory136/state [ 285.193431][T14882] page: refcount:2 mapcount:0 mapping:0000000000000000 index:0x7f20671f7 pfn:0x442b6a [ 285.196618][T14882] memcg:ffff888179298000 [ 285.198085][T14882] anon flags: 0x5fff0000002091c(referenced|uptodate| dirty|active|owner_2|swapbacked|node=1|zone=3|lastcpupid=0x7ff) [ 285.201734][T14882] raw: ... [ 285.204464][T14882] raw: ... [ 285.207196][T14882] page dumped because: migration failure [ 285.209072][T14882] page_owner tracks the page as allocated [ 285.210915][T14882] page last allocated via order 0, migratetype Movable, gfp_mask 0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_COMP|__GFP_ZERO), id 14926, tgid 14926 (hmm-swap), ts 254506295376, free_ts 227402023774 [ 285.216765][T14882] post_alloc_hook+0x197/0x1b0 [ 285.218874][T14882] get_page_from_freelist+0x76e/0x3280 [ 285.220864][T14882] __alloc_frozen_pages_noprof+0x38e/0x2740 [ 285.223302][T14882] alloc_pages_mpol+0x1fc/0x540 [ 285.225130][T14882] folio_alloc_mpol_noprof+0x36/0x340 [ 285.227222][T14882] vma_alloc_folio_noprof+0xee/0x1a0 [ 285.229074][T14882] __handle_mm_fault+0x2b38/0x56a0 [ 285.230822][T14882] handle_mm_fault+0x368/0x9f0 ... This series fixes all issues I found so far. There is no easy way to fix without a bigger rework/cleanup. I have a bunch of cleanups on top (some previous sent, some the result of the discussion in v1) that I will send out separately once this landed and I get to it. I wish we could just use some special present PROT_NONE PTEs instead of these (non-present, non-none) fake-swap entries; but that just results in the same problem we keep having (lack of spare PTE bits), and staring at other similar fake-swap entries, that ship has sailed. With this series, make_device_exclusive() doesn't actually belong into mm/rmap.c anymore, but I'll leave moving that for another day. I only tested this series with the hmm-tests selftests due to lack of HW, so I'd appreciate some testing, especially if the interaction between two GPUs wanting a device-exclusive entry works as expected. #include #include #include #include #include #include #include #include #include #include #define HMM_DMIRROR_EXCLUSIVE _IOWR('H', 0x05, struct hmm_dmirror_cmd) struct hmm_dmirror_cmd { __u64 addr; __u64 ptr; __u64 npages; __u64 cpages; __u64 faults; }; const size_t size = 1 * 1024 * 1024 * 1024ul; const size_t chunk_size = 2 * 1024 * 1024ul; int main(void) { struct hmm_dmirror_cmd cmd; size_t cur_size; int fd, ret; char *addr, *mirror; fd = open("/dev/hmm_dmirror1", O_RDWR, 0); if (fd < 0) { perror("open failed\n"); exit(1); } addr = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if (addr == MAP_FAILED) { perror("mmap failed\n"); exit(1); } madvise(addr, size, MADV_NOHUGEPAGE); memset(addr, 1, size); mirror = malloc(chunk_size); for (cur_size = 0; cur_size < size; cur_size += chunk_size) { cmd.addr = (uintptr_t)addr + cur_size; cmd.ptr = (uintptr_t)mirror; cmd.npages = chunk_size / getpagesize(); ret = ioctl(fd, HMM_DMIRROR_EXCLUSIVE, &cmd); if (ret) { perror("ioctl failed\n"); exit(1); } } pause(); return 0; } [1] https://lkml.kernel.org/r/25e02685-4f1d-47fa-be5b-01ff85bb0ce2@redhat.com This patch (of 17): We only have two FOLL_SPLIT_PMD users. While uprobe refuses hugetlb early, make_device_exclusive_range() can end up getting called on hugetlb VMAs. Right now, this means that with a PMD-sized hugetlb page, we can end up calling split_huge_pmd(), because pmd_trans_huge() also succeeds with hugetlb PMDs. For example, using a modified hmm-test selftest one can trigger: [ 207.017134][T14945] ------------[ cut here ]------------ [ 207.018614][T14945] kernel BUG at mm/page_table_check.c:87! [ 207.019716][T14945] Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI [ 207.021072][T14945] CPU: 3 UID: 0 PID: ... [ 207.023036][T14945] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 [ 207.024834][T14945] RIP: 0010:page_table_check_clear.part.0+0x488/0x510 [ 207.026128][T14945] Code: ... [ 207.029965][T14945] RSP: 0018:ffffc9000cb8f348 EFLAGS: 00010293 [ 207.031139][T14945] RAX: 0000000000000000 RBX: 00000000ffffffff RCX: ffffffff8249a0cd [ 207.032649][T14945] RDX: ffff88811e883c80 RSI: ffffffff8249a357 RDI: ffff88811e883c80 [ 207.034183][T14945] RBP: ffff888105c0a050 R08: 0000000000000005 R09: 0000000000000000 [ 207.035688][T14945] R10: 00000000ffffffff R11: 0000000000000003 R12: 0000000000000001 [ 207.037203][T14945] R13: 0000000000000200 R14: 0000000000000001 R15: dffffc0000000000 [ 207.038711][T14945] FS: 00007f2783275740(0000) GS:ffff8881f4980000(0000) knlGS:0000000000000000 [ 207.040407][T14945] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 207.041660][T14945] CR2: 00007f2782c00000 CR3: 0000000132356000 CR4: 0000000000750ef0 [ 207.043196][T14945] PKRU: 55555554 [ 207.043880][T14945] Call Trace: [ 207.044506][T14945] [ 207.045086][T14945] ? __die+0x51/0x92 [ 207.045864][T14945] ? die+0x29/0x50 [ 207.046596][T14945] ? do_trap+0x250/0x320 [ 207.047430][T14945] ? do_error_trap+0xe7/0x220 [ 207.048346][T14945] ? page_table_check_clear.part.0+0x488/0x510 [ 207.049535][T14945] ? handle_invalid_op+0x34/0x40 [ 207.050494][T14945] ? page_table_check_clear.part.0+0x488/0x510 [ 207.051681][T14945] ? exc_invalid_op+0x2e/0x50 [ 207.052589][T14945] ? asm_exc_invalid_op+0x1a/0x20 [ 207.053596][T14945] ? page_table_check_clear.part.0+0x1fd/0x510 [ 207.054790][T14945] ? page_table_check_clear.part.0+0x487/0x510 [ 207.055993][T14945] ? page_table_check_clear.part.0+0x488/0x510 [ 207.057195][T14945] ? page_table_check_clear.part.0+0x487/0x510 [ 207.058384][T14945] __page_table_check_pmd_clear+0x34b/0x5a0 [ 207.059524][T14945] ? __pfx___page_table_check_pmd_clear+0x10/0x10 [ 207.060775][T14945] ? __pfx___mutex_unlock_slowpath+0x10/0x10 [ 207.061940][T14945] ? __pfx___lock_acquire+0x10/0x10 [ 207.062967][T14945] pmdp_huge_clear_flush+0x279/0x360 [ 207.064024][T14945] split_huge_pmd_locked+0x82b/0x3750 ... Before commit 9cb28da54643 ("mm/gup: handle hugetlb in the generic follow_page_mask code"), we would have ignored the flag; instead, let's simply refuse the combination completely in check_vma_flags(): the caller is likely not prepared to handle any hugetlb folios. We'll teach make_device_exclusive_range() separately to ignore any hugetlb folios as a future-proof safety net. Link: https://lkml.kernel.org/r/20250210193801.781278-1-david@redhat.com Link: https://lkml.kernel.org/r/20250210193801.781278-2-david@redhat.com Fixes: 9cb28da54643 ("mm/gup: handle hugetlb in the generic follow_page_mask code") Signed-off-by: David Hildenbrand Reviewed-by: John Hubbard Reviewed-by: Alistair Popple Tested-by: Alistair Popple Cc: Alex Shi Cc: Danilo Krummrich Cc: Dave Airlie Cc: Jann Horn Cc: Jason Gunthorpe Cc: Jerome Glisse Cc: Jonathan Corbet Cc: Karol Herbst Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Lyude Cc: "Masami Hiramatsu (Google)" Cc: Oleg Nesterov Cc: Pasha Tatashin Cc: Peter Xu Cc: Peter Zijlstra (Intel) Cc: SeongJae Park Cc: Vlastimil Babka Cc: Yanteng Si Cc: Simona Vetter Cc: Barry Song Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit c7204fd1758c0caf1938e8a59809a1fdf28a8114 Author: Steven Rostedt Date: Thu Mar 27 19:53:11 2025 -0400 tracing: Verify event formats that have "%*p.." commit ea8d7647f9ddf1f81e2027ed305299797299aa03 upstream. The trace event verifier checks the formats of trace events to make sure that they do not point at memory that is not in the trace event itself or in data that will never be freed. If an event references data that was allocated when the event triggered and that same data is freed before the event is read, then the kernel can crash by reading freed memory. The verifier runs at boot up (or module load) and scans the print formats of the events and checks their arguments to make sure that dereferenced pointers are safe. If the format uses "%*p.." the verifier will ignore it, and that could be dangerous. Cover this case as well. Also add to the sample code a use case of "%*pbl". Link: https://lore.kernel.org/all/bcba4d76-2c3f-4d11-baf0-02905db953dd@oracle.com/ Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Fixes: 5013f454a352c ("tracing: Add check of trace event print fmts for dereferencing pointers") Link: https://lore.kernel.org/20250327195311.2d89ec66@gandalf.local.home Reported-by: Libo Chen Reviewed-by: Libo Chen Tested-by: Libo Chen Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit b20259e693a3f3f2be6b0ee6de61a45536cd591f Author: Ran Xiaokai Date: Fri Mar 21 09:52:49 2025 +0000 tracing/osnoise: Fix possible recursive locking for cpus_read_lock() commit 7e6b3fcc9c5294aeafed0dbe1a09a1bc899bd0f2 upstream. Lockdep reports this deadlock log: osnoise: could not start sampling thread ============================================ WARNING: possible recursive locking detected -------------------------------------------- CPU0 ---- lock(cpu_hotplug_lock); lock(cpu_hotplug_lock); Call Trace: print_deadlock_bug+0x282/0x3c0 __lock_acquire+0x1610/0x29a0 lock_acquire+0xcb/0x2d0 cpus_read_lock+0x49/0x120 stop_per_cpu_kthreads+0x7/0x60 start_kthread+0x103/0x120 osnoise_hotplug_workfn+0x5e/0x90 process_one_work+0x44f/0xb30 worker_thread+0x33e/0x5e0 kthread+0x206/0x3b0 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x11/0x20 This is the deadlock scenario: osnoise_hotplug_workfn() guard(cpus_read_lock)(); // first lock call start_kthread(cpu) if (IS_ERR(kthread)) { stop_per_cpu_kthreads(); { cpus_read_lock(); // second lock call. Cause the AA deadlock } } It is not necessary to call stop_per_cpu_kthreads() which stops osnoise kthread for every other CPUs in the system if a failure occurs during hotplug of a certain CPU. For start_per_cpu_kthreads(), if the start_kthread() call fails, this function calls stop_per_cpu_kthreads() to handle the error. Therefore, similarly, there is no need to call stop_per_cpu_kthreads() again within start_kthread(). So just remove stop_per_cpu_kthreads() from start_kthread to solve this issue. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/20250321095249.2739397-1-ranxiaokai627@163.com Fixes: c8895e271f79 ("trace/osnoise: Support hotplug operations") Signed-off-by: Ran Xiaokai Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit bd949bcd126fb32418b2482d41b5e4b7ce68df3e Author: Douglas Raillard Date: Tue Mar 25 16:52:02 2025 +0000 tracing: Fix synth event printk format for str fields commit 4d38328eb442dc06aec4350fd9594ffa6488af02 upstream. The printk format for synth event uses "%.*s" to print string fields, but then only passes the pointer part as var arg. Replace %.*s with %s as the C string is guaranteed to be null-terminated. The output in print fmt should never have been updated as __get_str() handles the string limit because it can access the length of the string in the string meta data that is saved in the ring buffer. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Fixes: 8db4d6bfbbf92 ("tracing: Change synthetic event string format to limit printed length") Link: https://lore.kernel.org/20250325165202.541088-1-douglas.raillard@arm.com Signed-off-by: Douglas Raillard Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit ef8e7191dba3036ba56c894a267acab54853204d Author: Douglas Raillard Date: Tue Mar 18 18:09:05 2025 +0000 tracing: Ensure module defining synth event cannot be unloaded while tracing commit 21581dd4e7ff6c07d0ab577e3c32b13a74b31522 upstream. Currently, using synth_event_delete() will fail if the event is being used (tracing in progress), but that is normally done in the module exit function. At that stage, failing is problematic as returning a non-zero status means the module will become locked (impossible to unload or reload again). Instead, ensure the module exit function does not get called in the first place by increasing the module refcnt when the event is enabled. Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers Fixes: 35ca5207c2d11 ("tracing: Add synthetic event command generation functions") Link: https://lore.kernel.org/20250318180906.226841-1-douglas.raillard@arm.com Signed-off-by: Douglas Raillard Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 70be951bc01e4a0e10d443f3510bb17426f257fb Author: Tengda Wu Date: Thu Mar 20 12:21:37 2025 +0000 tracing: Fix use-after-free in print_graph_function_flags during tracer switching commit 7f81f27b1093e4895e87b74143c59c055c3b1906 upstream. Kairui reported a UAF issue in print_graph_function_flags() during ftrace stress testing [1]. This issue can be reproduced if puting a 'mdelay(10)' after 'mutex_unlock(&trace_types_lock)' in s_start(), and executing the following script: $ echo function_graph > current_tracer $ cat trace > /dev/null & $ sleep 5 # Ensure the 'cat' reaches the 'mdelay(10)' point $ echo timerlat > current_tracer The root cause lies in the two calls to print_graph_function_flags within print_trace_line during each s_show(): * One through 'iter->trace->print_line()'; * Another through 'event->funcs->trace()', which is hidden in print_trace_fmt() before print_trace_line returns. Tracer switching only updates the former, while the latter continues to use the print_line function of the old tracer, which in the script above is print_graph_function_flags. Moreover, when switching from the 'function_graph' tracer to the 'timerlat' tracer, s_start only calls graph_trace_close of the 'function_graph' tracer to free 'iter->private', but does not set it to NULL. This provides an opportunity for 'event->funcs->trace()' to use an invalid 'iter->private'. To fix this issue, set 'iter->private' to NULL immediately after freeing it in graph_trace_close(), ensuring that an invalid pointer is not passed to other tracers. Additionally, clean up the unnecessary 'iter->private = NULL' during each 'cat trace' when using wakeup and irqsoff tracers. [1] https://lore.kernel.org/all/20231112150030.84609-1-ryncsn@gmail.com/ Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Zheng Yejian Link: https://lore.kernel.org/20250320122137.23635-1-wutengda@huaweicloud.com Fixes: eecb91b9f98d ("tracing: Fix memleak due to race between current_tracer and trace") Closes: https://lore.kernel.org/all/CAMgjq7BW79KDSCyp+tZHjShSzHsScSiJxn5ffskp-QzVM06fxw@mail.gmail.com/ Reported-by: Kairui Song Signed-off-by: Tengda Wu Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit c467697de63cd1eff28b61b6024975544d8cfeb4 Author: Sungjong Seo Date: Wed Mar 26 23:48:48 2025 +0900 exfat: fix potential wrong error return from get_block commit 59c30e31425833385e6644ad33151420e37eabe1 upstream. If there is no error, get_block() should return 0. However, when bh_read() returns 1, get_block() also returns 1 in the same manner. Let's set err to 0, if there is no error from bh_read() Fixes: 11a347fb6cef ("exfat: change to get file size from DataLength") Cc: stable@vger.kernel.org Signed-off-by: Sungjong Seo Reviewed-by: Yuezhang Mo Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit f807a6bf2005740fa26b4f59c4a003dc966b9afd Author: Sungjong Seo Date: Fri Mar 21 15:34:42 2025 +0900 exfat: fix random stack corruption after get_block commit 1bb7ff4204b6d4927e982cd256286c09ed4fd8ca upstream. When get_block is called with a buffer_head allocated on the stack, such as do_mpage_readpage, stack corruption due to buffer_head UAF may occur in the following race condition situation. mpage_read_folio <> do_mpage_readpage exfat_get_block bh_read __bh_read get_bh(bh) submit_bh wait_on_buffer ... end_buffer_read_sync __end_buffer_read_notouch unlock_buffer <> ... ... ... ... <> . . another_function <> put_bh(bh) atomic_dec(bh->b_count) * stack corruption here * This patch returns -EAGAIN if a folio does not have buffers when bh_read needs to be called. By doing this, the caller can fallback to functions like block_read_full_folio(), create a buffer_head in the folio, and then call get_block again. Let's do not call bh_read() with on-stack buffer_head. Fixes: 11a347fb6cef ("exfat: change to get file size from DataLength") Cc: stable@vger.kernel.org Tested-by: Yeongjin Gil Signed-off-by: Sungjong Seo Reviewed-by: Yuezhang Mo Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit b8eb243e670ecf30e91524dd12f7260dac07d335 Author: Namjae Jeon Date: Wed Apr 2 09:11:23 2025 +0900 ksmbd: fix null pointer dereference in alloc_preauth_hash() commit c8b5b7c5da7d0c31c9b7190b4a7bba5281fc4780 upstream. The Client send malformed smb2 negotiate request. ksmbd return error response. Subsequently, the client can send smb2 session setup even thought conn->preauth_info is not allocated. This patch add KSMBD_SESS_NEED_SETUP status of connection to ignore session setup request if smb2 negotiate phase is not complete. Cc: stable@vger.kernel.org Tested-by: Steve French Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-26505 Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit c8bfe1954a0b89e7b29b3a3e7f4c5e0ebd295e20 Author: Norbert Szetei Date: Sat Mar 29 16:06:01 2025 +0000 ksmbd: validate zero num_subauth before sub_auth is accessed commit bf21e29d78cd2c2371023953d9c82dfef82ebb36 upstream. Access psid->sub_auth[psid->num_subauth - 1] without checking if num_subauth is non-zero leads to an out-of-bounds read. This patch adds a validation step to ensure num_subauth != 0 before sub_auth is accessed. Cc: stable@vger.kernel.org Signed-off-by: Norbert Szetei Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 443b373a4df5a2cb9f7b8c4658b2afedeb16397f Author: Norbert Szetei Date: Sat Mar 29 06:58:15 2025 +0000 ksmbd: fix overflow in dacloffset bounds check commit beff0bc9d69bc8e733f9bca28e2d3df5b3e10e42 upstream. The dacloffset field was originally typed as int and used in an unchecked addition, which could overflow and bypass the existing bounds check in both smb_check_perm_dacl() and smb_inherit_dacl(). This could result in out-of-bounds memory access and a kernel crash when dereferencing the DACL pointer. This patch converts dacloffset to unsigned int and uses check_add_overflow() to validate access to the DACL. Cc: stable@vger.kernel.org Signed-off-by: Norbert Szetei Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 7dfbd4c43eed91dd2548a95236908025707a8dfd Author: Namjae Jeon Date: Thu Mar 27 21:22:51 2025 +0900 ksmbd: fix session use-after-free in multichannel connection commit fa4cdb8cbca7d6cb6aa13e4d8d83d1103f6345db upstream. There is a race condition between session setup and ksmbd_sessions_deregister. The session can be freed before the connection is added to channel list of session. This patch check reference count of session before freeing it. Cc: stable@vger.kernel.org Reported-by: Sean Heelan Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 33cc29e221df7a3085ae413e8c26c4e81a151153 Author: Namjae Jeon Date: Sat Mar 22 09:20:19 2025 +0900 ksmbd: fix use-after-free in ksmbd_sessions_deregister() commit 15a9605f8d69dc85005b1a00c31a050b8625e1aa upstream. In multichannel mode, UAF issue can occur in session_deregister when the second channel sets up a session through the connection of the first channel. session that is freed through the global session table can be accessed again through ->sessions of connection. Cc: stable@vger.kernel.org Reported-by: Norbert Szetei Tested-by: Norbert Szetei Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 9a1b6ea955e6c7b29939a6d98701202f9d9644ec Author: Norbert Szetei Date: Sat Mar 15 12:19:28 2025 +0900 ksmbd: add bounds check for create lease context commit bab703ed8472aa9d109c5f8c1863921533363dae upstream. Add missing bounds check for create lease context. Cc: stable@vger.kernel.org Reported-by: Norbert Szetei Tested-by: Norbert Szetei Signed-off-by: Norbert Szetei Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit f0db3d9d416e332a0d6f045a1509539d3a4cd898 Author: Namjae Jeon Date: Fri Mar 14 18:21:47 2025 +0900 ksmbd: add bounds check for durable handle context commit 542027e123fc0bfd61dd59e21ae0ee4ef2101b29 upstream. Add missing bounds check for durable handle context. Cc: stable@vger.kernel.org Reported-by: Norbert Szetei Tested-by: Norbert Szetei Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit c5961f62265de86ff31879d10331f7419348af6d Author: Sean Christopherson Date: Wed Feb 26 17:25:35 2025 -0800 KVM: SVM: Don't change target vCPU state on AP Creation VMGEXIT error commit d26638bfcdfc5c8c4e085dc3f5976a0443abab3c upstream. If KVM rejects an AP Creation event, leave the target vCPU state as-is. Nothing in the GHCB suggests the hypervisor is *allowed* to muck with vCPU state on failure, let alone required to do so. Furthermore, kicking only in the !ON_INIT case leads to divergent behavior, and even the "kick" case is non-deterministic. E.g. if an ON_INIT request fails, the guest can successfully retry if the fixed AP Creation request is made prior to sending INIT. And if a !ON_INIT fails, the guest can successfully retry if the fixed AP Creation request is handled before the target vCPU processes KVM's KVM_REQ_UPDATE_PROTECTED_GUEST_STATE. Fixes: e366f92ea99e ("KVM: SEV: Support SEV-SNP AP Creation NAE event") Cc: stable@vger.kernel.org Reviewed-by: Tom Lendacky Reviewed-by: Pankaj Gupta Link: https://lore.kernel.org/r/20250227012541.3234589-5-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 8bc4675dab5b1e7b39b87febea6f82ab06e24bed Author: Ulf Hansson Date: Wed Mar 12 13:17:12 2025 +0100 mmc: sdhci-omap: Disable MMC_CAP_AGGRESSIVE_PM for eMMC/SD commit 49d162635151d0dd04935070d7cf67137ab863aa upstream. We have received reports about cards can become corrupt related to the aggressive PM support. Let's make a partial revert of the change that enabled the feature. Reported-by: David Owens Reported-by: Romain Naour Reported-by: Robert Nelson Tested-by: Robert Nelson Fixes: 3edf588e7fe0 ("mmc: sdhci-omap: Allow SDIO card power off and enable aggressive PM") Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Acked-by: Adrian Hunter Reviewed-by: Tony Lindgren Link: https://lore.kernel.org/r/20250312121712.1168007-1-ulf.hansson@linaro.org Signed-off-by: Greg Kroah-Hartman commit a22c219362c872ba35755c3a22e0bdf6bba456f3 Author: Karel Balej Date: Mon Mar 10 15:07:04 2025 +0100 mmc: sdhci-pxav3: set NEED_RSP_BUSY capability commit a41fcca4b342811b473bbaa4b44f1d34d87fcce6 upstream. Set the MMC_CAP_NEED_RSP_BUSY capability for the sdhci-pxav3 host to prevent conversion of R1B responses to R1. Without this, the eMMC card in the samsung,coreprimevelte smartphone using the Marvell PXA1908 SoC with this mmc host doesn't probe with the ETIMEDOUT error originating in __mmc_poll_for_busy. Note that the other issues reported for this phone and host, namely floods of "Tuning failed, falling back to fixed sampling clock" dmesg messages for the eMMC and unstable SDIO are not mitigated by this change. Link: https://lore.kernel.org/r/20200310153340.5593-1-ulf.hansson@linaro.org/ Link: https://lore.kernel.org/r/D7204PWIGQGI.1FRFQPPIEE2P9@matfyz.cz/ Link: https://lore.kernel.org/r/20250115-pxa1908-lkml-v14-0-847d24f3665a@skole.hr/ Cc: stable@vger.kernel.org Signed-off-by: Karel Balej Acked-by: Adrian Hunter Tested-by: Duje Mihanović Link: https://lore.kernel.org/r/20250310140707.23459-1-balejk@matfyz.cz Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit b7e75561a83911be407fc4b33021903c26bfdf33 Author: Miaoqian Lin Date: Tue Mar 18 22:02:25 2025 +0800 mmc: omap: Fix memory leak in mmc_omap_new_slot commit 3834a759afb817e23a7a2f09c2c9911b0ce5c588 upstream. Add err_free_host label to properly pair mmc_alloc_host() with mmc_free_host() in GPIO error paths. The allocated host memory was leaked when GPIO lookups failed. Fixes: e519f0bb64ef ("ARM/mmc: Convert old mmci-omap to GPIO descriptors") Signed-off-by: Miaoqian Lin Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250318140226.19650-1-linmq006@gmail.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 706b116a7b627b6bfe7334ed343bbd57e65547b8 Author: Candice Li Date: Wed Mar 26 13:41:01 2025 +0800 Remove unnecessary firmware version check for gc v9_4_2 commit 5b3c08ae9ed324743f5f7286940d45caeb656e6e upstream. GC v9_4_2 uses a new versioning scheme for CP firmware, making the warning ("CP firmware version too old, please update!") irrelevant. Signed-off-by: Candice Li Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 0e1ff9f04164498d7bbd9b0f27398c0917f6aa82 Author: Robin Murphy Date: Mon Oct 28 17:58:36 2024 +0000 media: omap3isp: Handle ARM dma_iommu_mapping commit 6bc076eec6f85f778f33a8242b438e1bd9fcdd59 upstream. It's no longer practical for the OMAP IOMMU driver to trick arm_setup_iommu_dma_ops() into ignoring its presence, so let's use the same tactic as other IOMMU API users on 32-bit ARM and explicitly kick the arch code's dma_iommu_mapping out of the way to avoid problems. Fixes: 4720287c7bf7 ("iommu: Remove struct iommu_ops *iommu from arch_setup_dma_ops()") Cc: stable@vger.kernel.org Signed-off-by: Robin Murphy Tested-by: Sicelo A. Mhlongo Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit c0fbc0a2006c10e3b175cc6e237cb876cf886604 Author: Christian Eggers Date: Thu Mar 20 22:33:51 2025 +0100 ARM: 9444/1: add KEEP() keyword to ARM_VECTORS commit c3d944a367c0d9e4e125c7006e52f352e75776dc upstream. Without this, the vectors are removed if LD_DEAD_CODE_DATA_ELIMINATION is enabled. At startup, the CPU (silently) hangs in the undefined instruction exception as soon as the first timer interrupt arrives. On my setup, the system also boots fine without the 2nd and 3rd KEEP() statements, so I cannot tell whether these are actually required. [nathan: Use OVERLAY_KEEP() to avoid breaking old ld.lld versions] Cc: stable@vger.kernel.org Fixes: ed0f94102251 ("ARM: 9404/1: arm32: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION") Signed-off-by: Christian Eggers Reviewed-by: Linus Walleij Signed-off-by: Nathan Chancellor Signed-off-by: Russell King (Oracle) Signed-off-by: Greg Kroah-Hartman commit a90301ac681254b2f9eb5d781ea96bc3c80d644c Author: Nathan Chancellor Date: Thu Mar 20 22:33:49 2025 +0100 ARM: 9443/1: Require linker to support KEEP within OVERLAY for DCE commit e7607f7d6d81af71dcc5171278aadccc94d277cd upstream. ld.lld prior to 21.0.0 does not support using the KEEP keyword within an overlay description, which may be needed to avoid discarding necessary sections within an overlay with '--gc-sections', which can be enabled for the kernel via CONFIG_LD_DEAD_CODE_DATA_ELIMINATION. Disallow CONFIG_LD_DEAD_CODE_DATA_ELIMINATION without support for KEEP within OVERLAY and introduce a macro, OVERLAY_KEEP, that can be used to conditionally add KEEP when it is properly supported to avoid breaking old versions of ld.lld. Cc: stable@vger.kernel.org Link: https://github.com/llvm/llvm-project/commit/381599f1fe973afad3094e55ec99b1620dba7d8c Reviewed-by: Linus Walleij Signed-off-by: Nathan Chancellor Signed-off-by: Russell King (Oracle) Signed-off-by: Greg Kroah-Hartman commit 2a61383b44098bfb33ca92efa9c674e8f36ff296 Author: Gergo Koteles Date: Fri Mar 28 22:08:56 2025 +0100 ACPI: video: Handle fetching EDID as ACPI_TYPE_PACKAGE commit ebca08fef88febdb0a898cefa7c99b9e25b3a984 upstream. The _DDC method should return a buffer, or an integer in case of an error. But some Lenovo laptops incorrectly return EDID as buffer in ACPI package. Calling _DDC generates this ACPI Warning: ACPI Warning: \_SB.PCI0.GP17.VGA.LCD._DDC: Return type mismatch - \ found Package, expected Integer/Buffer (20240827/nspredef-254) Use the first element of the package to get the EDID buffer. The DSDT: Name (AUOP, Package (0x01) { Buffer (0x80) { ... } }) ... Method (_DDC, 1, NotSerialized) // _DDC: Display Data Current { If ((PAID == AUID)) { Return (AUOP) /* \_SB_.PCI0.GP17.VGA_.LCD_.AUOP */ } ElseIf ((PAID == IVID)) { Return (IVOP) /* \_SB_.PCI0.GP17.VGA_.LCD_.IVOP */ } ElseIf ((PAID == BOID)) { Return (BOEP) /* \_SB_.PCI0.GP17.VGA_.LCD_.BOEP */ } ElseIf ((PAID == SAID)) { Return (SUNG) /* \_SB_.PCI0.GP17.VGA_.LCD_.SUNG */ } Return (Zero) } Link: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/Apx_B_Video_Extensions/output-device-specific-methods.html#ddc-return-the-edid-for-this-device Cc: stable@vger.kernel.org Fixes: c6a837088bed ("drm/amd/display: Fetch the EDID from _DDC if available for eDP") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4085 Signed-off-by: Gergo Koteles Reviewed-by: Hans de Goede Reviewed-by: Mario Limonciello Link: https://patch.msgid.link/61c3df83ab73aba0bc7a941a443cd7faf4cf7fb0.1743195250.git.soyer@irl.hu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit de57027fa1cfe75cbd95a5cc544413045d50e6c3 Author: Paul Menzel Date: Tue Mar 18 17:09:02 2025 +0100 ACPI: resource: Skip IRQ override on ASUS Vivobook 14 X1404VAP commit 2da31ea2a085cd189857f2db0f7b78d0162db87a upstream. Like the ASUS Vivobook X1504VAP and Vivobook X1704VAP, the ASUS Vivobook 14 X1404VAP has its keyboard IRQ (1) described as ActiveLow in the DSDT, which the kernel overrides to EdgeHigh breaking the keyboard. $ sudo dmidecode […] System Information Manufacturer: ASUSTeK COMPUTER INC. Product Name: ASUS Vivobook 14 X1404VAP_X1404VA […] $ grep -A 30 PS2K dsdt.dsl | grep IRQ -A 1 IRQ (Level, ActiveLow, Exclusive, ) {1} Add the X1404VAP to the irq1_level_low_skip_override[] quirk table to fix this. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219224 Cc: All applicable Signed-off-by: Paul Menzel Reviewed-by: Hans de Goede Tested-by: Anton Shyndin Link: https://patch.msgid.link/20250318160903.77107-1-pmenzel@molgen.mpg.de Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 85f11291658ab907c4294319c8102450cc75bb96 Author: Murad Masimov Date: Thu Jan 23 19:39:45 2025 +0300 acpi: nfit: fix narrowing conversion in acpi_nfit_ctl commit 2ff0e408db36c21ed3fa5e3c1e0e687c82cf132f upstream. Syzkaller has reported a warning in to_nfit_bus_uuid(): "only secondary bus families can be translated". This warning is emited if the argument is equal to NVDIMM_BUS_FAMILY_NFIT == 0. Function acpi_nfit_ctl() first verifies that a user-provided value call_pkg->nd_family of type u64 is not equal to 0. Then the value is converted to int, and only after that is compared to NVDIMM_BUS_FAMILY_MAX. This can lead to passing an invalid argument to acpi_nfit_ctl(), if call_pkg->nd_family is non-zero, while the lower 32 bits are zero. Furthermore, it is best to return EINVAL immediately upon seeing the invalid user input. The WARNING is insufficient to prevent further undefined behavior based on other invalid user input. All checks of the input value should be applied to the original variable call_pkg->nd_family. [iweiny: update commit message] Fixes: 6450ddbd5d8e ("ACPI: NFIT: Define runtime firmware activation commands") Cc: stable@vger.kernel.org Reported-by: syzbot+c80d8dc0d9fa81a3cd8c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c80d8dc0d9fa81a3cd8c Signed-off-by: Murad Masimov Link: https://patch.msgid.link/20250123163945.251-1-m.masimov@mt-integration.ru Signed-off-by: Ira Weiny Signed-off-by: Greg Kroah-Hartman commit 44153deabd246b34259ca8291b14f6e33f01fea7 Author: Ming Yen Hsieh Date: Tue Mar 4 19:36:47 2025 +0800 wifi: mt76: mt7925: remove unused acpi function for clc commit b4ea6fdfc08375aae59c7e7059653b9877171fe4 upstream. The code for handling ACPI configuration in CLC was copied from the mt7921 driver but is not utilized in the mt7925 implementation. So removes the unused functionality to clean up the codebase. Cc: stable@vger.kernel.org Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Signed-off-by: Ming Yen Hsieh Link: https://patch.msgid.link/20250304113649.867387-4-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit 2e6674dfefd856713e880208a7f33b2e2768e899 Author: Nathan Chancellor Date: Mon Feb 10 21:28:25 2025 -0500 ACPI: platform-profile: Fix CFI violation when accessing sysfs files commit dd4f730b557ce701a2cd4f604bf1e57667bd8b6e upstream. When an attribute group is created with sysfs_create_group(), the ->sysfs_ops() callback is set to kobj_sysfs_ops, which sets the ->show() and ->store() callbacks to kobj_attr_show() and kobj_attr_store() respectively. These functions use container_of() to get the respective callback from the passed attribute, meaning that these callbacks need to be of the same type as the callbacks in 'struct kobj_attribute'. However, ->show() and ->store() in the platform_profile driver are defined for struct device_attribute with the help of DEVICE_ATTR_RO() and DEVICE_ATTR_RW(), which results in a CFI violation when accessing platform_profile or platform_profile_choices under /sys/firmware/acpi because the types do not match: CFI failure at kobj_attr_show+0x19/0x30 (target: platform_profile_choices_show+0x0/0x140; expected type: 0x7a69590c) There is no functional issue from the type mismatch because the layout of 'struct kobj_attribute' and 'struct device_attribute' are the same, so the container_of() cast does not break anything aside from CFI. Change the type of platform_profile_choices_show() and platform_profile_{show,store}() to match the callbacks in 'struct kobj_attribute' and update the attribute variables to match, which resolves the CFI violation. Cc: All applicable Fixes: a2ff95e018f1 ("ACPI: platform: Add platform profile support") Reported-by: John Rowley Closes: https://github.com/ClangBuiltLinux/linux/issues/2047 Tested-by: John Rowley Reviewed-by: Sami Tolvanen Signed-off-by: Nathan Chancellor Acked-by: Greg Kroah-Hartman Reviewed-by: Mark Pearson Tested-by: Mark Pearson Link: https://patch.msgid.link/20250210-acpi-platform_profile-fix-cfi-violation-v3-1-ed9e9901c33a@kernel.org [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 78d6f9a9eb2a5da6fcbd76d6191d24b0dcc321be Author: Jann Horn Date: Fri Jan 3 19:39:38 2025 +0100 x86/mm: Fix flush_tlb_range() when used for zapping normal PMDs commit 3ef938c3503563bfc2ac15083557f880d29c2e64 upstream. On the following path, flush_tlb_range() can be used for zapping normal PMD entries (PMD entries that point to page tables) together with the PTE entries in the pointed-to page table: collapse_pte_mapped_thp pmdp_collapse_flush flush_tlb_range The arm64 version of flush_tlb_range() has a comment describing that it can be used for page table removal, and does not use any last-level invalidation optimizations. Fix the X86 version by making it behave the same way. Currently, X86 only uses this information for the following two purposes, which I think means the issue doesn't have much impact: - In native_flush_tlb_multi() for checking if lazy TLB CPUs need to be IPI'd to avoid issues with speculative page table walks. - In Hyper-V TLB paravirtualization, again for lazy TLB stuff. The patch "x86/mm: only invalidate final translations with INVLPGB" which is currently under review (see ) would probably be making the impact of this a lot worse. Fixes: 016c4d92cd16 ("x86/mm/tlb: Add freed_tables argument to flush_tlb_mm_range") Signed-off-by: Jann Horn Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20250103-x86-collapse-flush-fix-v1-1-3c521856cfa6@google.com Signed-off-by: Greg Kroah-Hartman commit 915261a7b90c9b7b6dba3f71922ccf976f6d8570 Author: Guilherme G. Piccoli Date: Sat Feb 15 17:58:16 2025 -0300 x86/tsc: Always save/restore TSC sched_clock() on suspend/resume commit d90c9de9de2f1712df56de6e4f7d6982d358cabe upstream. TSC could be reset in deep ACPI sleep states, even with invariant TSC. That's the reason we have sched_clock() save/restore functions, to deal with this situation. But what happens is that such functions are guarded with a check for the stability of sched_clock - if not considered stable, the save/restore routines aren't executed. On top of that, we have a clear comment in native_sched_clock() saying that *even* with TSC unstable, we continue using TSC for sched_clock due to its speed. In other words, if we have a situation of TSC getting detected as unstable, it marks the sched_clock as unstable as well, so subsequent S3 sleep cycles could bring bogus sched_clock values due to the lack of the save/restore mechanism, causing warnings like this: [22.954918] ------------[ cut here ]------------ [22.954923] Delta way too big! 18446743750843854390 ts=18446744072977390405 before=322133536015 after=322133536015 write stamp=18446744072977390405 [22.954923] If you just came from a suspend/resume, [22.954923] please switch to the trace global clock: [22.954923] echo global > /sys/kernel/tracing/trace_clock [22.954923] or add trace_clock=global to the kernel command line [22.954937] WARNING: CPU: 2 PID: 5728 at kernel/trace/ring_buffer.c:2890 rb_add_timestamp+0x193/0x1c0 Notice that the above was reproduced even with "trace_clock=global". The fix for that is to _always_ save/restore the sched_clock on suspend cycle _if TSC is used_ as sched_clock - only if we fallback to jiffies the sched_clock_stable() check becomes relevant to save/restore the sched_clock. Debugged-by: Thadeu Lima de Souza Cascardo Signed-off-by: Guilherme G. Piccoli Signed-off-by: Ingo Molnar Cc: stable@vger.kernel.org Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Linus Torvalds Link: https://lore.kernel.org/r/20250215210314.351480-1-gpiccoli@igalia.com Signed-off-by: Greg Kroah-Hartman commit dfa1c6e6b97f4e3e0d3f4b6472b184b9f3d91d4e Author: Arnd Bergmann Date: Wed Feb 26 22:37:05 2025 +0100 x86/Kconfig: Add cmpxchg8b support back to Geode CPUs commit 6ac43f2be982ea54b75206dccd33f4cf81bfdc39 upstream. An older cleanup of mine inadvertently removed geode-gx1 and geode-lx from the list of CPUs that are known to support a working cmpxchg8b. Fixes: 88a2b4edda3d ("x86/Kconfig: Rework CONFIG_X86_PAE dependency") Signed-off-by: Arnd Bergmann Signed-off-by: Ingo Molnar Cc: Linus Torvalds Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250226213714.4040853-2-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman commit 558317a5c61045d460a37372181e7b43c0c002bb Author: Kent Overstreet Date: Sat Mar 29 19:01:09 2025 -0400 bcachefs: bch2_ioctl_subvolume_destroy() fixes [ Upstream commit 707549600c4a012ed71c0204a7992a679880bf33 ] bch2_evict_subvolume_inodes() was getting stuck - due to incorrectly pruning the dcache. Also, fix missing permissions checks. Reported-by: Alexander Viro Signed-off-by: Kent Overstreet Signed-off-by: Greg Kroah-Hartman commit d4e48b8d59fe162938a5004ace698c847e6a3207 Author: Jiri Olsa Date: Wed Feb 12 23:04:33 2025 +0100 uprobes/x86: Harden uretprobe syscall trampoline check commit fa6192adc32f4fdfe5b74edd5b210e12afd6ecc0 upstream. Jann reported a possible issue when trampoline_check_ip returns address near the bottom of the address space that is allowed to call into the syscall if uretprobes are not set up: https://lore.kernel.org/bpf/202502081235.5A6F352985@keescook/T/#m9d416df341b8fbc11737dacbcd29f0054413cbbf Though the mmap minimum address restrictions will typically prevent creating mappings there, let's make sure uretprobe syscall checks for that. Fixes: ff474a78cef5 ("uprobe: Add uretprobe syscall to speed up return probe") Reported-by: Jann Horn Signed-off-by: Jiri Olsa Signed-off-by: Ingo Molnar Reviewed-by: Oleg Nesterov Reviewed-by: Kees Cook Acked-by: Andrii Nakryiko Acked-by: Masami Hiramatsu (Google) Acked-by: Alexei Starovoitov Cc: Andy Lutomirski Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250212220433.3624297-1-jolsa@kernel.org Signed-off-by: Greg Kroah-Hartman commit d8370aa704bd7e384918c8f466856374725c0585 Author: Kan Liang Date: Tue Jan 21 07:23:01 2025 -0800 perf/x86/intel: Avoid disable PMU if !cpuc->enabled in sample read commit f9bdf1f953392c9edd69a7f884f78c0390127029 upstream. The WARN_ON(this_cpu_read(cpu_hw_events.enabled)) in the intel_pmu_save_and_restart_reload() is triggered, when sampling read topdown events. In a NMI handler, the cpu_hw_events.enabled is set and used to indicate the status of core PMU. The generic pmu->pmu_disable_count, updated in the perf_pmu_disable/enable pair, is not touched. However, the perf_pmu_disable/enable pair is invoked when sampling read in a NMI handler. The cpuc->enabled is mistakenly set by the perf_pmu_enable(). Avoid disabling PMU if the core PMU is already disabled. Merge the logic together. Fixes: 7b2c05a15d29 ("perf/x86/intel: Generic support for hardware TopDown metrics") Suggested-by: Peter Zijlstra (Intel) Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20250121152303.3128733-2-kan.liang@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 60a50197732b21631f29875ecc9b4161b680a044 Author: Peter Zijlstra (Intel) Date: Tue Jan 21 07:23:00 2025 -0800 perf/x86/intel: Apply static call for drain_pebs commit 314dfe10576912e1d786b13c5d4eee8c51b63caa upstream. The x86_pmu_drain_pebs static call was introduced in commit 7c9903c9bf71 ("x86/perf, static_call: Optimize x86_pmu methods"), but it's not really used to replace the old method. Apply the static call for drain_pebs. Fixes: 7c9903c9bf71 ("x86/perf, static_call: Optimize x86_pmu methods") Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20250121152303.3128733-1-kan.liang@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 60bff1eeebb5e17891f69db6f3fb06138b42438f Author: Markus Elfring Date: Mon Sep 23 10:38:11 2024 +0200 ntb_perf: Delete duplicate dmaengine_unmap_put() call in perf_copy_chunk() commit 4279e72cab31dd3eb8c89591eb9d2affa90ab6aa upstream. The function call “dmaengine_unmap_put(unmap)” was used in an if branch. The same call was immediately triggered by a subsequent goto statement. Thus avoid such a call repetition. This issue was detected by using the Coccinelle software. Fixes: 5648e56d03fa ("NTB: ntb_perf: Add full multi-port NTB API support") Cc: stable@vger.kernel.org Signed-off-by: Markus Elfring Signed-off-by: Jon Mason Signed-off-by: Greg Kroah-Hartman commit 95164b965fd98e106a0a92cb6ffadd7228d81245 Author: Srinivas Pandruvada Date: Fri Mar 28 15:47:49 2025 -0700 platform/x86: ISST: Correct command storage data length commit 9462e74c5c983cce34019bfb27f734552bebe59f upstream. After resume/online turbo limit ratio (TRL) is restored partially if the admin explicitly changed TRL from user space. A hash table is used to store SST mail box and MSR settings when modified to restore those settings after resume or online. This uses a struct isst_cmd field "data" to store these settings. This is a 64 bit field. But isst_store_new_cmd() is only assigning as u32. This results in truncation of 32 bits. Change the argument to u64 from u32. Fixes: f607874f35cb ("platform/x86: ISST: Restore state on resume") Signed-off-by: Srinivas Pandruvada Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250328224749.2691272-1-srinivas.pandruvada@linux.intel.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit 537da29aef6d3d0c7834e9f72898785638cce80b Author: Eduard Christian Dumitrescu Date: Mon Mar 24 11:24:42 2025 -0400 platform/x86: thinkpad_acpi: disable ACPI fan access for T495* and E560 commit 2b9f84e7dc863afd63357b867cea246aeedda036 upstream. T495, T495s, and E560 laptops have the FANG+FANW ACPI methods (therefore fang_handle and fanw_handle are not NULL) but they do not actually work, which results in a "No such device or address" error. The DSDT table code for the FANG+FANW methods doesn't seem to do anything special regarding the fan being secondary. The bug was introduced in commit 57d0557dfa49 ("platform/x86: thinkpad_acpi: Add Thinkpad Edge E531 fan support"), which added a new fan control method via the FANG+FANW ACPI methods. Add a quirk for T495, T495s, and E560 to avoid the FANG+FANW methods. Fan access and control is restored after forcing the legacy non-ACPI fan control method by setting both fang_handle and fanw_handle to NULL. Reported-by: Vlastimil Holer Fixes: 57d0557dfa49 ("platform/x86: thinkpad_acpi: Add Thinkpad Edge E531 fan support") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219643 Cc: stable@vger.kernel.org Tested-by: Alireza Elikahi Reviewed-by: Kurt Borja Signed-off-by: Eduard Christian Dumitrescu Co-developed-by: Seyediman Seyedarab Signed-off-by: Seyediman Seyedarab Link: https://lore.kernel.org/r/20250324152442.106113-1-ImanDevel@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman commit db7ed2f6feec069fd8ea485742d80531a89616ed Author: Hans de Goede Date: Tue Mar 25 22:04:50 2025 +0100 ACPI: x86: Extend Lenovo Yoga Tab 3 quirk with skip GPIO event-handlers commit 2fa87c71d2adb4b82c105f9191e6120340feff00 upstream. Depending on the secureboot signature on EFI\BOOT\BOOTX86.EFI the Lenovo Yoga Tab 3 UEFI will switch its OSID ACPI variable between 1 (Windows) and 4 (Android(GMIN)). In Windows mode a GPIO event handler gets installed for GPO1 pin 5, causing Linux' x86-android-tables code which deals with the general brokenness of this device's ACPI tables to fail to probe with: [ 17.853705] x86_android_tablets: error -16 getting GPIO INT33FF:01 5 [ 17.859623] x86_android_tablets x86_android_tablets: probe with driver which renders sound, the touchscreen, charging-management, battery-monitoring and more non functional. Add ACPI_QUIRK_SKIP_GPIO_EVENT_HANDLERS to the existing quirks for this device to fix this. Reported-by: Agoston Lorincz Closes: https://lore.kernel.org/platform-driver-x86/CAMEzqD+DNXrAvUOHviB2O2bjtcbmo3xH=kunKr4nubuMLbb_0A@mail.gmail.com/ Cc: All applicable Fixes: fe820db35275 ("ACPI: x86: Add skip i2c clients quirk for Lenovo Yoga Tab 3 Pro (YT3-X90F)") Signed-off-by: Hans de Goede Link: https://patch.msgid.link/20250325210450.358506-1-hdegoede@redhat.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit f0f9fa3759f71a3bb800fc0956b701df7f324de4 Author: Vishal Annapurve Date: Fri Feb 28 01:44:15 2025 +0000 x86/tdx: Fix arch_safe_halt() execution for TDX VMs commit 9f98a4f4e7216dbe366010b4cdcab6b220f229c4 upstream. Direct HLT instruction execution causes #VEs for TDX VMs which is routed to hypervisor via TDCALL. If HLT is executed in STI-shadow, resulting #VE handler will enable interrupts before TDCALL is routed to hypervisor leading to missed wakeup events, as current TDX spec doesn't expose interruptibility state information to allow #VE handler to selectively enable interrupts. Commit bfe6ed0c6727 ("x86/tdx: Add HLT support for TDX guests") prevented the idle routines from executing HLT instruction in STI-shadow. But it missed the paravirt routine which can be reached via this path as an example: kvm_wait() => safe_halt() => raw_safe_halt() => arch_safe_halt() => irq.safe_halt() => pv_native_safe_halt() To reliably handle arch_safe_halt() for TDX VMs, introduce explicit dependency on CONFIG_PARAVIRT and override paravirt halt()/safe_halt() routines with TDX-safe versions that execute direct TDCALL and needed interrupt flag updates. Executing direct TDCALL brings in additional benefit of avoiding HLT related #VEs altogether. As tested by Ryan Afranji: "Tested with the specjbb2015 benchmark. It has heavy lock contention which leads to many halt calls. TDX VMs suffered a poor score before this patchset. Verified the major performance improvement with this patchset applied." Fixes: bfe6ed0c6727 ("x86/tdx: Add HLT support for TDX guests") Signed-off-by: Vishal Annapurve Signed-off-by: Ingo Molnar Reviewed-by: Kirill A. Shutemov Tested-by: Ryan Afranji Cc: Andy Lutomirski Cc: Brian Gerst Cc: Juergen Gross Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Josh Poimboeuf Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250228014416.3925664-3-vannapurve@google.com Signed-off-by: Greg Kroah-Hartman commit b51638da8d59d5be091c2851bfe4141cf05867ed Author: Kirill A. Shutemov Date: Fri Feb 28 01:44:14 2025 +0000 x86/paravirt: Move halt paravirt calls under CONFIG_PARAVIRT commit 22cc5ca5de52bbfc36a7d4a55323f91fb4492264 upstream. CONFIG_PARAVIRT_XXL is mainly defined/used by XEN PV guests. For other VM guest types, features supported under CONFIG_PARAVIRT are self sufficient. CONFIG_PARAVIRT mainly provides support for TLB flush operations and time related operations. For TDX guest as well, paravirt calls under CONFIG_PARVIRT meets most of its requirement except the need of HLT and SAFE_HLT paravirt calls, which is currently defined under CONFIG_PARAVIRT_XXL. Since enabling CONFIG_PARAVIRT_XXL is too bloated for TDX guest like platforms, move HLT and SAFE_HLT paravirt calls under CONFIG_PARAVIRT. Moving HLT and SAFE_HLT paravirt calls are not fatal and should not break any functionality for current users of CONFIG_PARAVIRT. Fixes: bfe6ed0c6727 ("x86/tdx: Add HLT support for TDX guests") Co-developed-by: Kuppuswamy Sathyanarayanan Signed-off-by: Kuppuswamy Sathyanarayanan Signed-off-by: Kirill A. Shutemov Signed-off-by: Vishal Annapurve Signed-off-by: Ingo Molnar Reviewed-by: Andi Kleen Reviewed-by: Tony Luck Reviewed-by: Juergen Gross Tested-by: Ryan Afranji Cc: Andy Lutomirski Cc: Brian Gerst Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Josh Poimboeuf Cc: stable@kernel.org Link: https://lore.kernel.org/r/20250228014416.3925664-2-vannapurve@google.com Signed-off-by: Greg Kroah-Hartman commit 0b8388e97ba6a8c033f9a8b5565af41af07f9345 Author: Shuai Xue Date: Wed Mar 12 19:28:50 2025 +0800 x86/mce: use is_copy_from_user() to determine copy-from-user context commit 1a15bb8303b6b104e78028b6c68f76a0d4562134 upstream. Patch series "mm/hwpoison: Fix regressions in memory failure handling", v4. ## 1. What am I trying to do: This patchset resolves two critical regressions related to memory failure handling that have appeared in the upstream kernel since version 5.17, as compared to 5.10 LTS. - copyin case: poison found in user page while kernel copying from user space - instr case: poison found while instruction fetching in user space ## 2. What is the expected outcome and why - For copyin case: Kernel can recover from poison found where kernel is doing get_user() or copy_from_user() if those places get an error return and the kernel return -EFAULT to the process instead of crashing. More specifily, MCE handler checks the fixup handler type to decide whether an in kernel #MC can be recovered. When EX_TYPE_UACCESS is found, the PC jumps to recovery code specified in _ASM_EXTABLE_FAULT() and return a -EFAULT to user space. - For instr case: If a poison found while instruction fetching in user space, full recovery is possible. User process takes #PF, Linux allocates a new page and fills by reading from storage. ## 3. What actually happens and why - For copyin case: kernel panic since v5.17 Commit 4c132d1d844a ("x86/futex: Remove .fixup usage") introduced a new extable fixup type, EX_TYPE_EFAULT_REG, and later patches updated the extable fixup type for copy-from-user operations, changing it from EX_TYPE_UACCESS to EX_TYPE_EFAULT_REG. It breaks previous EX_TYPE_UACCESS handling when posion found in get_user() or copy_from_user(). - For instr case: user process is killed by a SIGBUS signal due to #CMCI and #MCE race When an uncorrected memory error is consumed there is a race between the CMCI from the memory controller reporting an uncorrected error with a UCNA signature, and the core reporting and SRAR signature machine check when the data is about to be consumed. ### Background: why *UN*corrected errors tied to *C*MCI in Intel platform [1] Prior to Icelake memory controllers reported patrol scrub events that detected a previously unseen uncorrected error in memory by signaling a broadcast machine check with an SRAO (Software Recoverable Action Optional) signature in the machine check bank. This was overkill because it's not an urgent problem that no core is on the verge of consuming that bad data. It's also found that multi SRAO UCE may cause nested MCE interrupts and finally become an IERR. Hence, Intel downgrades the machine check bank signature of patrol scrub from SRAO to UCNA (Uncorrected, No Action required), and signal changed to #CMCI. Just to add to the confusion, Linux does take an action (in uc_decode_notifier()) to try to offline the page despite the UC*NA* signature name. ### Background: why #CMCI and #MCE race when poison is consuming in Intel platform [1] Having decided that CMCI/UCNA is the best action for patrol scrub errors, the memory controller uses it for reads too. But the memory controller is executing asynchronously from the core, and can't tell the difference between a "real" read and a speculative read. So it will do CMCI/UCNA if an error is found in any read. Thus: 1) Core is clever and thinks address A is needed soon, issues a speculative read. 2) Core finds it is going to use address A soon after sending the read request 3) The CMCI from the memory controller is in a race with MCE from the core that will soon try to retire the load from address A. Quite often (because speculation has got better) the CMCI from the memory controller is delivered before the core is committed to the instruction reading address A, so the interrupt is taken, and Linux offlines the page (marking it as poison). ## Why user process is killed for instr case Commit 046545a661af ("mm/hwpoison: fix error page recovered but reported "not recovered"") tries to fix noise message "Memory error not recovered" and skips duplicate SIGBUSs due to the race. But it also introduced a bug that kill_accessing_process() return -EHWPOISON for instr case, as result, kill_me_maybe() send a SIGBUS to user process. # 4. The fix, in my opinion, should be: - For copyin case: The key point is whether the error context is in a read from user memory. We do not care about the ex-type if we know its a MOV reading from userspace. is_copy_from_user() return true when both of the following two checks are true: - the current instruction is copy - source address is user memory If copy_user is true, we set m->kflags |= MCE_IN_KERNEL_COPYIN | MCE_IN_KERNEL_RECOV; Then do_machine_check() will try fixup_exception() first. - For instr case: let kill_accessing_process() return 0 to prevent a SIGBUS. - For patch 3: The return value of memory_failure() is quite important while discussed instr case regression with Tony and Miaohe for patch 2, so add comment about the return value. This patch (of 3): Commit 4c132d1d844a ("x86/futex: Remove .fixup usage") introduced a new extable fixup type, EX_TYPE_EFAULT_REG, and commit 4c132d1d844a ("x86/futex: Remove .fixup usage") updated the extable fixup type for copy-from-user operations, changing it from EX_TYPE_UACCESS to EX_TYPE_EFAULT_REG. The error context for copy-from-user operations no longer functions as an in-kernel recovery context. Consequently, the error context for copy-from-user operations no longer functions as an in-kernel recovery context, resulting in kernel panics with the message: "Machine check: Data load in unrecoverable area of kernel." To address this, it is crucial to identify if an error context involves a read operation from user memory. The function is_copy_from_user() can be utilized to determine: - the current operation is copy - when reading user memory When these conditions are met, is_copy_from_user() will return true, confirming that it is indeed a direct copy from user memory. This check is essential for correctly handling the context of errors in these operations without relying on the extable fixup types that previously allowed for in-kernel recovery. So, use is_copy_from_user() to determine if a context is copy user directly. Link: https://lkml.kernel.org/r/20250312112852.82415-1-xueshuai@linux.alibaba.com Link: https://lkml.kernel.org/r/20250312112852.82415-2-xueshuai@linux.alibaba.com Fixes: 4c132d1d844a ("x86/futex: Remove .fixup usage") Signed-off-by: Shuai Xue Suggested-by: Peter Zijlstra Acked-by: Borislav Petkov (AMD) Tested-by: Tony Luck Cc: Baolin Wang Cc: Borislav Betkov Cc: Catalin Marinas Cc: Dave Hansen Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Josh Poimboeuf Cc: Miaohe Lin Cc: Naoya Horiguchi Cc: Ruidong Tian Cc: Thomas Gleinxer Cc: Yazen Ghannam Cc: Jane Chu Cc: Jarkko Sakkinen Cc: Jonathan Cameron Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 7f705a45f130a85fbf31c2abdc999c65644c8307 Author: Boris Ostrovsky Date: Thu Mar 27 19:05:02 2025 -0400 x86/microcode/AMD: Fix __apply_microcode_amd()'s return value commit 31ab12df723543047c3fc19cb8f8c4498ec6267f upstream. When verify_sha256_digest() fails, __apply_microcode_amd() should propagate the failure by returning false (and not -1 which is promoted to true). Fixes: 50cef76d5cb0 ("x86/microcode/AMD: Load only SHA256-checksummed patches") Signed-off-by: Boris Ostrovsky Signed-off-by: Borislav Petkov (AMD) Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250327230503.1850368-2-boris.ostrovsky@oracle.com Signed-off-by: Greg Kroah-Hartman commit 6e014ba68055933331bca4719cb2e6d64a6288ac Author: Paolo Bonzini Date: Thu Mar 6 21:29:22 2025 +0100 KVM: x86: block KVM_CAP_SYNC_REGS if guest state is protected commit 74c1807f6c4feddb3c3cb1056c54531d4adbaea6 upstream. KVM_CAP_SYNC_REGS does not make sense for VMs with protected guest state, since the register values cannot actually be written. Return 0 when using the VM-level KVM_CHECK_EXTENSION ioctl, and accordingly return -EINVAL from KVM_RUN if the valid/dirty fields are nonzero. However, on exit from KVM_RUN userspace could have placed a nonzero value into kvm_run->kvm_valid_regs, so check guest_state_protected again and skip store_regs() in that case. Cc: stable@vger.kernel.org Fixes: 517987e3fb19 ("KVM: x86: add fields to struct kvm_arch for CoCo features") Signed-off-by: Paolo Bonzini Message-ID: <20250306202923.646075-1-pbonzini@redhat.com> Reviewed-by: Pankaj Gupta Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 575b5c55caacc6c61c8c30f1e0dced685fb11848 Author: Tianyu Lan Date: Thu Mar 13 04:52:17 2025 -0400 x86/hyperv: Fix check of return value from snp_set_vmsa() commit e792d843aa3c9d039074cdce728d5803262e57a7 upstream. snp_set_vmsa() returns 0 as success result and so fix it. Cc: stable@vger.kernel.org Fixes: 44676bb9d566 ("x86/hyperv: Add smp support for SEV-SNP guest") Signed-off-by: Tianyu Lan Reviewed-by: Michael Kelley Link: https://lore.kernel.org/r/20250313085217.45483-1-ltykernel@gmail.com Signed-off-by: Wei Liu Message-ID: <20250313085217.45483-1-ltykernel@gmail.com> Signed-off-by: Greg Kroah-Hartman commit a4635e451c2764122a63223188a6dbfad65b1a40 Author: Hengqi Chen Date: Sun Mar 30 16:31:09 2025 +0800 LoongArch: BPF: Use move_addr() for BPF_PSEUDO_FUNC commit 52266f1015a8b5aabec7d127f83d105f702b388e upstream. Vincent reported that running XDP synproxy program on LoongArch results in the following error: JIT doesn't support bpf-to-bpf calls With dmesg: multi-func JIT bug 1391 != 1390 The root cause is that verifier will refill the imm with the correct addresses of bpf_calls for BPF_PSEUDO_FUNC instructions and then run the last pass of JIT. So we generate different JIT code for the same instruction in two passes (one for placeholder and the other for the real address). Let's use move_addr() instead. See commit 64f50f6575721ef0 ("LoongArch, bpf: Use 4 instructions for function address in JIT") for a similar fix. Cc: stable@vger.kernel.org Fixes: 69c087ba6225 ("bpf: Add bpf_for_each_map_elem() helper") Fixes: bb035ef0cc91 ("LoongArch: BPF: Support mixing bpf2bpf and tailcalls") Reported-by: Vincent Li Tested-by: Vincent Li Closes: https://lore.kernel.org/loongarch/CAK3+h2yfM9FTNiXvEQBkvtuoJrvzmN4c_NZsFXqEk4Cj1tsBNA@mail.gmail.com/T/#u Signed-off-by: Hengqi Chen Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 996e90ab446641553e8e21707b38b9709605e0e0 Author: Hengqi Chen Date: Sun Mar 30 16:31:09 2025 +0800 LoongArch: BPF: Don't override subprog's return value commit 60f3caff1492e5b8616b9578c4bedb5c0a88ed14 upstream. The verifier test `calls: div by 0 in subprog` triggers a panic at the ld.bu instruction. The ld.bu insn is trying to load byte from memory address returned by the subprog. The subprog actually set the correct address at the a5 register (dedicated register for BPF return values). But at commit 73c359d1d356 ("LoongArch: BPF: Sign-extend return values") we also sign extended a5 to the a0 register (return value in LoongArch). For function call insn, we later propagate the a0 register back to a5 register. This is right for native calls but wrong for bpf2bpf calls which expect zero-extended return value in a5 register. So only move a0 to a5 for native calls (i.e. non-BPF_PSEUDO_CALL). Cc: stable@vger.kernel.org Fixes: 73c359d1d356 ("LoongArch: BPF: Sign-extend return values") Signed-off-by: Hengqi Chen Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 48b904de2408af5f936f0e03f48dfcddeab58aa0 Author: Hengqi Chen Date: Sun Mar 30 16:31:09 2025 +0800 LoongArch: BPF: Fix off-by-one error in build_prologue() commit 7e2586991e36663c9bc48c828b83eab180ad30a9 upstream. Vincent reported that running BPF progs with tailcalls on LoongArch causes kernel hard lockup. Debugging the issues shows that the JITed image missing a jirl instruction at the end of the epilogue. There are two passes in JIT compiling, the first pass set the flags and the second pass generates JIT code based on those flags. With BPF progs mixing bpf2bpf and tailcalls, build_prologue() generates N insns in the first pass and then generates N+1 insns in the second pass. This makes epilogue_offset off by one and we will jump to some unexpected insn and cause lockup. Fix this by inserting a nop insn. Cc: stable@vger.kernel.org Fixes: 5dc615520c4d ("LoongArch: Add BPF JIT support") Fixes: bb035ef0cc91 ("LoongArch: BPF: Support mixing bpf2bpf and tailcalls") Reported-by: Vincent Li Tested-by: Vincent Li Closes: https://lore.kernel.org/loongarch/CAK3+h2w6WESdBN3UCr3WKHByD7D6Q_Ve1EDAjotVrnx6Or_c8g@mail.gmail.com/ Closes: https://lore.kernel.org/bpf/CAK3+h2woEjG_N=-XzqEGaAeCmgu2eTCUc7p6bP4u8Q+DFHm-7g@mail.gmail.com/ Signed-off-by: Hengqi Chen Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 69d6fdc9efbe737f4288d94de8c3d4c4cb372c95 Author: Huacai Chen Date: Sun Mar 30 16:31:09 2025 +0800 LoongArch: Increase MAX_IO_PICS up to 8 commit ec105cadff5d8c0a029a3dc1084cae46cf3f799d upstream. Begin with Loongson-3C6000, the number of PCI host can be as many as 8 for multi-chip machines, and this number should be the same for I/O interrupt controllers. To support these machines we also increase the MAX_IO_PICS up to 8. Cc: stable@vger.kernel.org Tested-by: Mingcong Bai Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 8b82aea3666f8f2c78f86148d78aea99c46e0f82 Author: Huacai Chen Date: Sun Mar 30 16:31:09 2025 +0800 LoongArch: Increase ARCH_DMA_MINALIGN up to 16 commit 4103cfe9dcb88010ae4911d3ff417457d1b6a720 upstream. ARCH_DMA_MINALIGN is 1 by default, but some LoongArch-specific devices (such as APBDMA) require 16 bytes alignment. When the data buffer length is too small, the hardware may make an error writing cacheline. Thus, it is dangerous to allocate a small memory buffer for DMA. It's always safe to define ARCH_DMA_MINALIGN as L1_CACHE_BYTES but unnecessary (kmalloc() need small memory objects). Therefore, just increase it to 16. Cc: stable@vger.kernel.org Tested-by: Binbin Zhou Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 1cb3d1fa90b65fe705dd708ff3e41e2458740ff5 Author: WANG Rui Date: Sun Mar 30 16:30:20 2025 +0800 rust: Fix enabling Rust and building with GCC for LoongArch commit 13c23cb4ed09466d73f1beae8956810b95add6ef upstream. This patch fixes a build issue on LoongArch when Rust is enabled and compiled with GCC by explicitly setting the bindgen target and skipping C flags that Clang doesn't support. Cc: stable@vger.kernel.org Acked-by: Miguel Ojeda Signed-off-by: WANG Rui Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit fd9ee3f0d6a53844f65efde581c91bbb0ff749ac Author: Ying Lu Date: Wed Apr 2 16:58:59 2025 +0800 usbnet:fix NPE during rx_complete commit 51de3600093429e3b712e5f091d767babc5dd6df upstream. Missing usbnet_going_away Check in Critical Path. The usb_submit_urb function lacks a usbnet_going_away validation, whereas __usbnet_queue_skb includes this check. This inconsistency creates a race condition where: A URB request may succeed, but the corresponding SKB data fails to be queued. Subsequent processes: (e.g., rx_complete → defer_bh → __skb_unlink(skb, list)) attempt to access skb->next, triggering a NULL pointer dereference (Kernel Panic). Fixes: 04e906839a05 ("usbnet: fix cyclical race on disconnect with work queue") Cc: stable@vger.kernel.org Signed-off-by: Ying Lu Link: https://patch.msgid.link/4c9ef2efaa07eb7f9a5042b74348a67e5a3a7aea.1743584159.git.luying1@xiaomi.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 80a72e6380fd2402475e7f747ce4952aac3e17be Author: Sherry Sun Date: Fri Mar 7 14:54:46 2025 +0800 tty: serial: lpuart: only disable CTS instead of overwriting the whole UARTMODIR register [ Upstream commit e98ab45ec5182605d2e00114cba3bbf46b0ea27f ] No need to overwrite the whole UARTMODIR register before waiting the transmit engine complete, actually our target here is only to disable CTS flow control to avoid the dirty data in TX FIFO may block the transmit engine complete. Also delete the following duplicate CTS disable configuration. Fixes: d5a2e0834364 ("tty: serial: lpuart: disable flow control while waiting for the transmit engine to complete") Cc: stable Signed-off-by: Sherry Sun Link: https://lore.kernel.org/r/20250307065446.1122482-1-sherry.sun@nxp.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit fa00a5fccd0ce42a444b69119601737ef36e62df Author: Sherry Sun Date: Mon Mar 24 10:10:51 2025 +0800 tty: serial: fsl_lpuart: Fix unused variable 'sport' build warning commit 9f8fe348ac9544f6855f82565e754bf085d81f88 upstream. Remove the unused variable 'sport' to avoid the kernel build warning. Fixes: 3cc16ae096f1 ("tty: serial: fsl_lpuart: use port struct directly to simply code") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202503210614.2qGlnbIq-lkp@intel.com/ Signed-off-by: Sherry Sun Link: https://lore.kernel.org/r/20250324021051.162676-1-sherry.sun@nxp.com Signed-off-by: Greg Kroah-Hartman commit 2526110174c7b5e33f3ebac3e1540443b0715dbe Author: Sherry Sun Date: Wed Mar 12 10:39:03 2025 +0800 tty: serial: fsl_lpuart: use port struct directly to simply code commit 3cc16ae096f164ae0c6b98416c25a01db5f3a529 upstream. Most lpuart functions have the parameter struct uart_port *port, but still use the &sport->port to get the uart_port instead of use it directly, let's simply the code logic, directly use this struct instead of covert it from struct sport. Signed-off-by: Sherry Sun Link: https://lore.kernel.org/r/20250312023904.1343351-3-sherry.sun@nxp.com Signed-off-by: Greg Kroah-Hartman commit 7b0b0c70de2f68c75a5da2c76c2a2856cd9847df Author: Sherry Sun Date: Wed Mar 12 10:39:02 2025 +0800 tty: serial: fsl_lpuart: Use u32 and u8 for register variables [ Upstream commit b6a8f6ab2c53e5ea3c7f2a3978db378a89bb7595 ] Use u32 and u8 rather than unsigned long or unsigned char for register variables for clarity and consistency. Signed-off-by: Sherry Sun Link: https://lore.kernel.org/r/20250312023904.1343351-2-sherry.sun@nxp.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: e98ab45ec518 ("tty: serial: lpuart: only disable CTS instead of overwriting the whole UARTMODIR register") Signed-off-by: Sasha Levin commit 50ef6e45bec79da4c5a01fad4dc23466ba255099 Author: Dave Penkler Date: Sat Feb 22 21:45:15 2025 +0100 staging: gpib: Fix Oops after disconnect in agilent usb [ Upstream commit 8491e73a5223acb0a4b4d78c3f8b96aa9c5e774d ] If the agilent usb dongle is disconnected subsequent calls to the driver cause a NULL dereference Oops as the bus_interface is set to NULL on disconnect. This problem was introduced by setting usb_dev from the bus_interface for dev_xxx messages. Previously bus_interface was checked for NULL only in the functions directly calling usb_fill_bulk_urb or usb_control_msg. Check for valid bus_interface on all interface entry points and return -ENODEV if it is NULL. Fixes: fbae7090f30c ("staging: gpib: Update messaging and usb_device refs in agilent_usb") Cc: stable Signed-off-by: Dave Penkler Link: https://lore.kernel.org/r/20250222204515.5104-1-dpenkler@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1de197342e9d8d2e2f476dac6d82cb12e9e5ff8a Author: Dave Penkler Date: Fri Feb 14 12:46:53 2025 +0100 staging: gpib: agilent usb console messaging cleanup [ Upstream commit 50a6ed0494bc082227c38f427b40731bca9bdf15 ] Enable module name to be printed in pr_xxx and dev_xxx Use DRV_NAME defined as KBUILD_MODNAME instead of hard coded string in usb_driver struct. Remove __func__ parameter in dev_dbg messages as this can be enabled with dynamic debug. Remove __func__ parameter in dev_err messages as they are not needed. The module name is sufficient. Change pr_info to dev_dbg where needed and remove the rest where possible. Remove test and error messages for buffer over run in write and read_registers as these are just trying to catch bugs in the driver. Remove agilent_82357a string prefix in error messages. Return -EIO for too many reads in read_registers instead of continuing after printing an error message. Change pr_warn to dev_warn. Remove warning on calls for unsupported functionality. Remove test and message for buffer overflow in agilent_82357_init and agilent_82357a_go_idle which are just checking for a driver bug. Use actual indeces in the array instead of i and then incrementing i so that the code is clear and there is no need to check for overflow or print a message. Signed-off-by: Dave Penkler Link: https://lore.kernel.org/r/20250214114708.28947-3-dpenkler@gmail.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 8491e73a5223 ("staging: gpib: Fix Oops after disconnect in agilent usb") Signed-off-by: Sasha Levin commit 5dc98ba6f7304c188b267ef481281849638447bf Author: Dave Penkler Date: Sat Feb 22 17:58:17 2025 +0100 staging: gpib: Fix Oops after disconnect in ni_usb [ Upstream commit a239c6e91b665f1837cf57b97fe638ef1baf2e78 ] If the usb dongle is disconnected subsequent calls to the driver cause a NULL dereference Oops as the bus_interface is set to NULL on disconnect. This problem was introduced by setting usb_dev from the bus_interface for dev_xxx messages. Previously bus_interface was checked for NULL only in the the functions directly calling usb_fill_bulk_urb or usb_control_msg. Check for valid bus_interface on all interface entry points and return -ENODEV if it is NULL. Fixes: 4934b98bb243 ("staging: gpib: Update messaging and usb_device refs in ni_usb") Cc: stable Signed-off-by: Dave Penkler Link: https://lore.kernel.org/r/20250222165817.12856-1-dpenkler@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0ccd208aacd016cf7467a3e8b645945b3f619de4 Author: Dave Penkler Date: Fri Feb 14 12:47:05 2025 +0100 staging: gpib: ni_usb console messaging cleanup [ Upstream commit 18ce5b5d9167bffce02550a85c7c3316a05ea598 ] Enable module name to be printed in pr_xxx and dev_xxx Use DRV_NAME defined as KBUILD_MODNAME instead of hard coded string "ni_usb_gpib" in usb_driver struct. Remove __func__ parameter from pr_err and dev_err. Remove __func__ parameter from dev_dbg as this can be enabled by dynamic debug. Remove commented printk's and dev_err's. Remove kmalloc failed messages. Remove buffer over run bug dev_err message as this just checks for a bug in the driver which does not exist. Remove read/write length too long messages and return -EINVAL Change dev_info to dev_dbg where possible. Move attach message to the end of attach function. Remove buffer overrun message. Use actual array indeces instead of i and i++ to make code clear and check redundnant. Remove module init and exit pr_info's. Signed-off-by: Dave Penkler Link: https://lore.kernel.org/r/20250214114708.28947-15-dpenkler@gmail.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: a239c6e91b66 ("staging: gpib: Fix Oops after disconnect in ni_usb") Signed-off-by: Sasha Levin commit 727d331fd8de76510c4fa11df845307125cbc736 Author: Zhang Rui Date: Wed Mar 19 08:53:07 2025 +0800 tools/power turbostat: Restore GFX sysfs fflush() call [ Upstream commit f8b136ef2605c1bf62020462d10e35228760aa19 ] Do fflush() to discard the buffered data, before each read of the graphics sysfs knobs. Fixes: ba99a4fc8c24 ("tools/power turbostat: Remove unnecessary fflush() call") Signed-off-by: Zhang Rui Signed-off-by: Len Brown Signed-off-by: Sasha Levin commit d54f0fa0e0e167dfd7f1b270a9b09a9514ec09bb Author: Len Brown Date: Sun Apr 6 11:18:39 2025 -0400 tools/power turbostat: report CoreThr per measurement interval [ Upstream commit f729775f79a9c942c6c82ed6b44bd030afe10423 ] The CoreThr column displays total thermal throttling events since boot time. Change it to report events during the measurement interval. This is more useful for showing a user the current conditions. Total events since boot time are still available to the user via /sys/devices/system/cpu/cpu*/thermal_throttle/* Document CoreThr on turbostat.8 Fixes: eae97e053fe30 ("turbostat: Support thermal throttle count print") Reported-by: Arjan van de Ven Signed-off-by: Len Brown Cc: Chen Yu Signed-off-by: Sasha Levin commit 83d96b6440d03d84d7c5f288b88644cc37792760 Author: Yeoreum Yun Date: Wed Mar 26 08:20:03 2025 +0000 perf/core: Fix child_total_time_enabled accounting bug at task exit [ Upstream commit a3c3c66670cee11eb13aa43905904bf29cb92d32 ] The perf events code fails to account for total_time_enabled of inactive events. Here is a failure case for accounting total_time_enabled for CPU PMU events: sudo ./perf stat -vvv -e armv8_pmuv3_0/event=0x08/ -e armv8_pmuv3_1/event=0x08/ -- stress-ng --pthread=2 -t 2s ... armv8_pmuv3_0/event=0x08/: 1138698008 2289429840 2174835740 armv8_pmuv3_1/event=0x08/: 1826791390 1950025700 847648440 ` ` ` ` ` > total_time_running with child ` > total_time_enabled with child > count with child Performance counter stats for 'stress-ng --pthread=2 -t 2s': 1,138,698,008 armv8_pmuv3_0/event=0x08/ (94.99%) 1,826,791,390 armv8_pmuv3_1/event=0x08/ (43.47%) The two events above are opened on two different CPU PMUs, for example, each event is opened for a cluster in an Arm big.LITTLE system, they will never run on the same CPU. In theory, the total enabled time should be same for both events, as two events are opened and closed together. As the result show, the two events' total enabled time including child event is different (2289429840 vs 1950025700). This is because child events are not accounted properly if a event is INACTIVE state when the task exits: perf_event_exit_event() `> perf_remove_from_context() `> __perf_remove_from_context() `> perf_child_detach() -> Accumulate child_total_time_enabled `> list_del_event() -> Update child event's time The problem is the time accumulation happens prior to child event's time updating. Thus, it misses to account the last period's time when the event exits. The perf core layer follows the rule that timekeeping is tied to state change. To address the issue, make __perf_remove_from_context() handle the task exit case by passing 'DETACH_EXIT' to it and invoke perf_event_state() for state alongside with accounting the time. Then, perf_child_detach() populates the time into the parent's time metrics. After this patch, the bug is fixed: sudo ./perf stat -vvv -e armv8_pmuv3_0/event=0x08/ -e armv8_pmuv3_1/event=0x08/ -- stress-ng --pthread=2 -t 10s ... armv8_pmuv3_0/event=0x08/: 15396770398 32157963940 21898169000 armv8_pmuv3_1/event=0x08/: 22428964974 32157963940 10259794940 Performance counter stats for 'stress-ng --pthread=2 -t 10s': 15,396,770,398 armv8_pmuv3_0/event=0x08/ (68.10%) 22,428,964,974 armv8_pmuv3_1/event=0x08/ (31.90%) [ mingo: Clarified the changelog. ] Fixes: ef54c1a476aef ("perf: Rework perf_event_exit_event()") Suggested-by: Peter Zijlstra Signed-off-by: Yeoreum Yun Signed-off-by: Ingo Molnar Tested-by: Leo Yan Link: https://lore.kernel.org/r/20250326082003.1630986-1-yeoreum.yun@arm.com Signed-off-by: Sasha Levin commit 3ef373616f8f952837b0cc477dad36bd949367db Author: Alex Deucher Date: Thu Mar 20 12:09:11 2025 -0400 drm/amdgpu/gfx12: fix num_mec [ Upstream commit dce8bd9137b88735dd0efc4e2693213d98c15913 ] GC12 only has 1 mec. Fixes: 52cb80c12e8a ("drm/amdgpu: Add gfx v12_0 ip block support (v6)") Reviewed-by: Sunil Khatri Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 4d95711eea2166220bc5cab183a178e459e1a77b Author: Alex Deucher Date: Wed Mar 26 09:35:02 2025 -0400 drm/amdgpu/gfx11: fix num_mec [ Upstream commit 4161050d47e1b083a7e1b0b875c9907e1a6f1f1f ] GC11 only has 1 mec. Fixes: 3d879e81f0f9 ("drm/amdgpu: add init support for GFX11 (v2)") Reviewed-by: Sunil Khatri Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0b8a80c2d2fed2e4c1fe81678110018633bde804 Author: Yue Haibing Date: Sun Mar 23 19:41:03 2025 +0800 drm/xe: Fix unmet direct dependencies warning [ Upstream commit 5e66cf6edddb5f6237e3afb07475ace57ecb56bc ] WARNING: unmet direct dependencies detected for FB_IOMEM_HELPERS Depends on [n]: HAS_IOMEM [=y] && FB_CORE [=n] Selected by [m]: - DRM_XE_DISPLAY [=y] && HAS_IOMEM [=y] && DRM [=m] && DRM_XE [=m] && DRM_XE [=m]=m [=m] && HAS_IOPORT [=y] DRM_XE_DISPLAY requires FB_IOMEM_HELPERS, but the dependency FB_CORE is missing, selecting FB_IOMEM_HELPERS if DRM_FBDEV_EMULATION is set as other drm drivers. Fixes: 44e694958b95 ("drm/xe/display: Implement display support") Signed-off-by: Yue Haibing Reviewed-by: Lucas De Marchi Link: https://patchwork.freedesktop.org/patch/msgid/20250323114103.1960511-1-yuehaibing@huawei.com Signed-off-by: Lucas De Marchi (cherry picked from commit 689582882802cd64986c1eb584c9f5184d67f0cf) Signed-off-by: Lucas De Marchi Signed-off-by: Sasha Levin commit 02965bda33deada382c550c3505c6087cc23557b Author: Alexandru Gagniuc Date: Fri Mar 14 13:10:53 2025 +0000 kbuild: deb-pkg: don't set KBUILD_BUILD_VERSION unconditionally [ Upstream commit 62604063621fb075c7966286bdddcb057d883fa8 ] In ThinPro, we use the convention +hp for the kernel package. This does not have a dash in the name or version. This is built by editing ".version" before a build, and setting EXTRAVERSION="+hp" and KDEB_PKGVERSION make variables: echo 68 > .version make -j EXTRAVERSION="+hp" bindeb-pkg KDEB_PKGVERSION=6.12.2+hp69 .deb name: linux-image-6.12.2+hp_6.12.2+hp69_amd64.deb Since commit 7d4f07d5cb71 ("kbuild: deb-pkg: squash scripts/package/deb-build-option to debian/rules"), this no longer works. The deb build logic changed, even though, the commit message implies that the logic should be unmodified. Before, KBUILD_BUILD_VERSION was not set if the KDEB_PKGVERSION did not contain a dash. After the change KBUILD_BUILD_VERSION is always set to KDEB_PKGVERSION. Since this determines UTS_VERSION, the uname output to look off: (now) uname -a: version 6.12.2+hp ... #6.12.2+hp69 (expected) uname -a: version 6.12.2+hp ... #69 Update the debian/rules logic to restore the original behavior. Fixes: 7d4f07d5cb71 ("kbuild: deb-pkg: squash scripts/package/deb-build-option to debian/rules") Signed-off-by: Alexandru Gagniuc Reviewed-by: Nicolas Schier Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 81fc7e1f11b995409b9b96bd901e04cf0d38e11f Author: Zhang Rui Date: Sat Feb 8 10:44:26 2025 +0800 tools/power turbostat: Allow Zero return value for some RAPL registers [ Upstream commit b312d880fb462d4759396950865ec914de9d253c ] turbostat aborted with below messages on a dual-package system, turbostat: turbostat.c:3744: rapl_counter_accumulate: Assertion `dst->unit == src->unit' failed. Aborted This is because 1. the MSR_DRAM_PERF_STATUS returns Zero for one package, and non-Zero for another package 2. probe_msr() treats Zero return value as a failure so this feature is enabled on one package, and disabled for another package. 3. turbostat aborts because the feature is invalid on some package Unlike the RAPL energy counter registers, MSR_DRAM_PERF_STATUS can return Zero value, and this should not be treated as a failure. Fix the problem by allowing Zero return value for RAPL registers other than the energy counters. Fixes: 7c6fee25bdf5 ("tools/power turbostat: Check for non-zero value when MSR probing") Reported-by: Artem Bityutskiy Signed-off-by: Zhang Rui Signed-off-by: Len Brown Signed-off-by: Sasha Levin commit 58190b5622fdb7f3ed0be3762448a20986e0d11f Author: Jakub Kicinski Date: Wed Apr 2 18:37:06 2025 -0700 netlink: specs: rt_route: pull the ifa- prefix out of the names [ Upstream commit 1a1eba0e9899c286914032c78708c614b016704b ] YAML specs don't normally include the C prefix name in the name of the YAML attr. Remove the ifa- prefix from all attributes in route-attrs and metrics and specify name-prefix instead. This is a bit risky, hopefully there aren't many users out there. Fixes: 023289b4f582 ("doc/netlink: Add spec for rt route messages") Reviewed-by: Donald Hunter Link: https://patch.msgid.link/20250403013706.2828322-5-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0a2470e3ecde64fc7e3781dc474923193621ae67 Author: Dave Marquardt Date: Wed Apr 2 10:44:03 2025 -0500 net: ibmveth: make veth_pool_store stop hanging [ Upstream commit 053f3ff67d7feefc75797863f3d84b47ad47086f ] v2: - Created a single error handling unlock and exit in veth_pool_store - Greatly expanded commit message with previous explanatory-only text Summary: Use rtnl_mutex to synchronize veth_pool_store with itself, ibmveth_close and ibmveth_open, preventing multiple calls in a row to napi_disable. Background: Two (or more) threads could call veth_pool_store through writing to /sys/devices/vio/30000002/pool*/*. You can do this easily with a little shell script. This causes a hang. I configured LOCKDEP, compiled ibmveth.c with DEBUG, and built a new kernel. I ran this test again and saw: Setting pool0/active to 0 Setting pool1/active to 1 [ 73.911067][ T4365] ibmveth 30000002 eth0: close starting Setting pool1/active to 1 Setting pool1/active to 0 [ 73.911367][ T4366] ibmveth 30000002 eth0: close starting [ 73.916056][ T4365] ibmveth 30000002 eth0: close complete [ 73.916064][ T4365] ibmveth 30000002 eth0: open starting [ 110.808564][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification. [ 230.808495][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification. [ 243.683786][ T123] INFO: task stress.sh:4365 blocked for more than 122 seconds. [ 243.683827][ T123] Not tainted 6.14.0-01103-g2df0c02dab82-dirty #8 [ 243.683833][ T123] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 243.683838][ T123] task:stress.sh state:D stack:28096 pid:4365 tgid:4365 ppid:4364 task_flags:0x400040 flags:0x00042000 [ 243.683852][ T123] Call Trace: [ 243.683857][ T123] [c00000000c38f690] [0000000000000001] 0x1 (unreliable) [ 243.683868][ T123] [c00000000c38f840] [c00000000001f908] __switch_to+0x318/0x4e0 [ 243.683878][ T123] [c00000000c38f8a0] [c000000001549a70] __schedule+0x500/0x12a0 [ 243.683888][ T123] [c00000000c38f9a0] [c00000000154a878] schedule+0x68/0x210 [ 243.683896][ T123] [c00000000c38f9d0] [c00000000154ac80] schedule_preempt_disabled+0x30/0x50 [ 243.683904][ T123] [c00000000c38fa00] [c00000000154dbb0] __mutex_lock+0x730/0x10f0 [ 243.683913][ T123] [c00000000c38fb10] [c000000001154d40] napi_enable+0x30/0x60 [ 243.683921][ T123] [c00000000c38fb40] [c000000000f4ae94] ibmveth_open+0x68/0x5dc [ 243.683928][ T123] [c00000000c38fbe0] [c000000000f4aa20] veth_pool_store+0x220/0x270 [ 243.683936][ T123] [c00000000c38fc70] [c000000000826278] sysfs_kf_write+0x68/0xb0 [ 243.683944][ T123] [c00000000c38fcb0] [c0000000008240b8] kernfs_fop_write_iter+0x198/0x2d0 [ 243.683951][ T123] [c00000000c38fd00] [c00000000071b9ac] vfs_write+0x34c/0x650 [ 243.683958][ T123] [c00000000c38fdc0] [c00000000071bea8] ksys_write+0x88/0x150 [ 243.683966][ T123] [c00000000c38fe10] [c0000000000317f4] system_call_exception+0x124/0x340 [ 243.683973][ T123] [c00000000c38fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec ... [ 243.684087][ T123] Showing all locks held in the system: [ 243.684095][ T123] 1 lock held by khungtaskd/123: [ 243.684099][ T123] #0: c00000000278e370 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x50/0x248 [ 243.684114][ T123] 4 locks held by stress.sh/4365: [ 243.684119][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150 [ 243.684132][ T123] #1: c000000041aea888 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x154/0x2d0 [ 243.684143][ T123] #2: c0000000366fb9a8 (kn->active#64){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x160/0x2d0 [ 243.684155][ T123] #3: c000000035ff4cb8 (&dev->lock){+.+.}-{3:3}, at: napi_enable+0x30/0x60 [ 243.684166][ T123] 5 locks held by stress.sh/4366: [ 243.684170][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150 [ 243.684183][ T123] #1: c00000000aee2288 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x154/0x2d0 [ 243.684194][ T123] #2: c0000000366f4ba8 (kn->active#64){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x160/0x2d0 [ 243.684205][ T123] #3: c000000035ff4cb8 (&dev->lock){+.+.}-{3:3}, at: napi_disable+0x30/0x60 [ 243.684216][ T123] #4: c0000003ff9bbf18 (&rq->__lock){-.-.}-{2:2}, at: __schedule+0x138/0x12a0 From the ibmveth debug, two threads are calling veth_pool_store, which calls ibmveth_close and ibmveth_open. Here's the sequence: T4365 T4366 ----------------- ----------------- --------- veth_pool_store veth_pool_store ibmveth_close ibmveth_close napi_disable napi_disable ibmveth_open napi_enable <- HANG ibmveth_close calls napi_disable at the top and ibmveth_open calls napi_enable at the top. https://docs.kernel.org/networking/napi.html]] says The control APIs are not idempotent. Control API calls are safe against concurrent use of datapath APIs but an incorrect sequence of control API calls may result in crashes, deadlocks, or race conditions. For example, calling napi_disable() multiple times in a row will deadlock. In the normal open and close paths, rtnl_mutex is acquired to prevent other callers. This is missing from veth_pool_store. Use rtnl_mutex in veth_pool_store fixes these hangs. Signed-off-by: Dave Marquardt Fixes: 860f242eb534 ("[PATCH] ibmveth change buffer pools dynamically") Reviewed-by: Nick Child Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250402154403.386744-1-davemarq@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 887226163504494ea7e58033a97c2d2ab12e05d4 Author: Henry Martin Date: Wed Apr 2 21:50:36 2025 +0800 arcnet: Add NULL check in com20020pci_probe() [ Upstream commit fda8c491db2a90ff3e6fbbae58e495b4ddddeca3 ] devm_kasprintf() returns NULL when memory allocation fails. Currently, com20020pci_probe() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue and ensure no resources are left allocated. Fixes: 6b17a597fc2f ("arcnet: restoring support for multiple Sohard Arcnet cards") Signed-off-by: Henry Martin Link: https://patch.msgid.link/20250402135036.44697-1-bsdhenrymartin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d25edde8087bb53a5fc30e2068341796a3f3a330 Author: Ido Schimmel Date: Wed Apr 2 14:42:24 2025 +0300 ipv6: Do not consider link down nexthops in path selection [ Upstream commit 8b8e0dd357165e0258d9f9cdab5366720ed2f619 ] Nexthops whose link is down are not supposed to be considered during path selection when the "ignore_routes_with_linkdown" sysctl is set. This is done by assigning them a negative region boundary. However, when comparing the computed hash (unsigned) with the region boundary (signed), the negative region boundary is treated as unsigned, resulting in incorrect nexthop selection. Fix by treating the computed hash as signed. Note that the computed hash is always in range of [0, 2^31 - 1]. Fixes: 3d709f69a3e7 ("ipv6: Use hash-threshold instead of modulo-N") Signed-off-by: Ido Schimmel Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20250402114224.293392-3-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit de7735a977edf5ef4765020300e5cb0403b799db Author: Ido Schimmel Date: Wed Apr 2 14:42:23 2025 +0300 ipv6: Start path selection from the first nexthop [ Upstream commit 4d0ab3a6885e3e9040310a8d8f54503366083626 ] Cited commit transitioned IPv6 path selection to use hash-threshold instead of modulo-N. With hash-threshold, each nexthop is assigned a region boundary in the multipath hash function's output space and a nexthop is chosen if the calculated hash is smaller than the nexthop's region boundary. Hash-threshold does not work correctly if path selection does not start with the first nexthop. For example, if fib6_select_path() is always passed the last nexthop in the group, then it will always be chosen because its region boundary covers the entire hash function's output space. Fix this by starting the selection process from the first nexthop and do not consider nexthops for which rt6_score_route() provided a negative score. Fixes: 3d709f69a3e7 ("ipv6: Use hash-threshold instead of modulo-N") Reported-by: Stanislav Fomichev Closes: https://lore.kernel.org/netdev/Z9RIyKZDNoka53EO@mini-arch/ Signed-off-by: Ido Schimmel Link: https://patch.msgid.link/20250402114224.293392-2-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4d606069bdd3c76f8ab1f06796c97ef7f4746807 Author: Lin Ma Date: Thu Apr 3 00:56:32 2025 +0800 net: fix geneve_opt length integer overflow [ Upstream commit b27055a08ad4b415dcf15b63034f9cb236f7fb40 ] struct geneve_opt uses 5 bit length for each single option, which means every vary size option should be smaller than 128 bytes. However, all current related Netlink policies cannot promise this length condition and the attacker can exploit a exact 128-byte size option to *fake* a zero length option and confuse the parsing logic, further achieve heap out-of-bounds read. One example crash log is like below: [ 3.905425] ================================================================== [ 3.905925] BUG: KASAN: slab-out-of-bounds in nla_put+0xa9/0xe0 [ 3.906255] Read of size 124 at addr ffff888005f291cc by task poc/177 [ 3.906646] [ 3.906775] CPU: 0 PID: 177 Comm: poc-oob-read Not tainted 6.1.132 #1 [ 3.907131] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 3.907784] Call Trace: [ 3.907925] [ 3.908048] dump_stack_lvl+0x44/0x5c [ 3.908258] print_report+0x184/0x4be [ 3.909151] kasan_report+0xc5/0x100 [ 3.909539] kasan_check_range+0xf3/0x1a0 [ 3.909794] memcpy+0x1f/0x60 [ 3.909968] nla_put+0xa9/0xe0 [ 3.910147] tunnel_key_dump+0x945/0xba0 [ 3.911536] tcf_action_dump_1+0x1c1/0x340 [ 3.912436] tcf_action_dump+0x101/0x180 [ 3.912689] tcf_exts_dump+0x164/0x1e0 [ 3.912905] fw_dump+0x18b/0x2d0 [ 3.913483] tcf_fill_node+0x2ee/0x460 [ 3.914778] tfilter_notify+0xf4/0x180 [ 3.915208] tc_new_tfilter+0xd51/0x10d0 [ 3.918615] rtnetlink_rcv_msg+0x4a2/0x560 [ 3.919118] netlink_rcv_skb+0xcd/0x200 [ 3.919787] netlink_unicast+0x395/0x530 [ 3.921032] netlink_sendmsg+0x3d0/0x6d0 [ 3.921987] __sock_sendmsg+0x99/0xa0 [ 3.922220] __sys_sendto+0x1b7/0x240 [ 3.922682] __x64_sys_sendto+0x72/0x90 [ 3.922906] do_syscall_64+0x5e/0x90 [ 3.923814] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 3.924122] RIP: 0033:0x7e83eab84407 [ 3.924331] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf [ 3.925330] RSP: 002b:00007ffff505e370 EFLAGS: 00000202 ORIG_RAX: 000000000000002c [ 3.925752] RAX: ffffffffffffffda RBX: 00007e83eaafa740 RCX: 00007e83eab84407 [ 3.926173] RDX: 00000000000001a8 RSI: 00007ffff505e3c0 RDI: 0000000000000003 [ 3.926587] RBP: 00007ffff505f460 R08: 00007e83eace1000 R09: 000000000000000c [ 3.926977] R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffff505f3c0 [ 3.927367] R13: 00007ffff505f5c8 R14: 00007e83ead1b000 R15: 00005d4fbbe6dcb8 Fix these issues by enforing correct length condition in related policies. Fixes: 925d844696d9 ("netfilter: nft_tunnel: add support for geneve opts") Fixes: 4ece47787077 ("lwtunnel: add options setting and dumping for geneve") Fixes: 0ed5269f9e41 ("net/sched: add tunnel option support to act_tunnel_key") Fixes: 0a6e77784f49 ("net/sched: allow flower to match tunnel options") Signed-off-by: Lin Ma Reviewed-by: Xin Long Acked-by: Cong Wang Link: https://patch.msgid.link/20250402165632.6958-1-linma@zju.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d79c676f698109e276bc2b30270ddd150cac8ca6 Author: David Oberhollenzer Date: Tue Apr 1 15:56:37 2025 +0200 net: dsa: mv88e6xxx: propperly shutdown PPU re-enable timer on destroy [ Upstream commit a58d882841a0750da3c482cd3d82432b1c7edb77 ] The mv88e6xxx has an internal PPU that polls PHY state. If we want to access the internal PHYs, we need to disable the PPU first. Because that is a slow operation, a 10ms timer is used to re-enable it, canceled with every access, so bulk operations effectively only disable it once and re-enable it some 10ms after the last access. If a PHY is accessed and then the mv88e6xxx module is removed before the 10ms are up, the PPU re-enable ends up accessing a dangling pointer. This especially affects probing during bootup. The MDIO bus and PHY registration may succeed, but registration with the DSA framework may fail later on (e.g. because the CPU port depends on another, very slow device that isn't done probing yet, returning -EPROBE_DEFER). In this case, probe() fails, but the MDIO subsystem may already have accessed the MIDO bus or PHYs, arming the timer. This is fixed as follows: - If probe fails after mv88e6xxx_phy_init(), make sure we also call mv88e6xxx_phy_destroy() before returning - In mv88e6xxx_remove(), make sure we do the teardown in the correct order, calling mv88e6xxx_phy_destroy() after unregistering the switch device. - In mv88e6xxx_phy_destroy(), destroy both the timer and the work item that the timer might schedule, synchronously waiting in case one of the callbacks already fired and destroying the timer first, before waiting for the work item. - Access to the PPU is guarded by a mutex, the worker acquires it with a mutex_trylock(), not proceeding with the expensive shutdown if that fails. We grab the mutex in mv88e6xxx_phy_destroy() to make sure the slow PPU shutdown is already done or won't even enter, when we wait for the work item. Fixes: 2e5f032095ff ("dsa: add support for the Marvell 88E6131 switch chip") Signed-off-by: David Oberhollenzer Reviewed-by: Vladimir Oltean Link: https://patch.msgid.link/20250401135705.92760-1-david.oberhollenzer@sigma-star.at Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4374b658522ddb5d0e7806579c4a8d2c67c23c98 Author: Fernando Fernandez Mancera Date: Wed Apr 2 14:17:51 2025 +0200 ipv6: fix omitted netlink attributes when using RTEXT_FILTER_SKIP_STATS [ Upstream commit 7ac6ea4a3e0898db76aecccd68fb2c403eb7d24e ] Using RTEXT_FILTER_SKIP_STATS is incorrectly skipping non-stats IPv6 netlink attributes on link dump. This causes issues on userspace tools, e.g iproute2 is not rendering address generation mode as it should due to missing netlink attribute. Move the filling of IFLA_INET6_STATS and IFLA_INET6_ICMP6STATS to a helper function guarded by a flag check to avoid hitting the same situation in the future. Fixes: d5566fd72ec1 ("rtnetlink: RTEXT_FILTER_SKIP_STATS support to avoid dumping inet/inet6 stats") Signed-off-by: Fernando Fernandez Mancera Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250402121751.3108-1-ffmancera@riseup.net Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e56391011381d6d029da377a65ac314cb3d5def2 Author: Edward Cree Date: Tue Apr 1 23:54:39 2025 +0100 sfc: fix NULL dereferences in ef100_process_design_param() [ Upstream commit 8241ecec1cdc6699ae197d52d58e76bddd995fa5 ] Since cited commit, ef100_probe_main() and hence also ef100_check_design_params() run before efx->net_dev is created; consequently, we cannot netif_set_tso_max_size() or _segs() at this point. Move those netif calls to ef100_probe_netdev(), and also replace netif_err within the design params code with pci_err. Reported-by: Kyungwook Boo Fixes: 98ff4c7c8ac7 ("sfc: Separate netdev probe/remove from PCI probe/remove") Signed-off-by: Edward Cree Reviewed-by: Michal Swiatkowski Link: https://patch.msgid.link/20250401225439.2401047-1-edward.cree@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 18914efa83fb4af59db4110e3e11057991a94486 Author: Edward Cree Date: Thu Mar 20 17:57:10 2025 +0000 sfc: rip out MDIO support [ Upstream commit c339fcdd738be78c540407ae78fef5601ba5092a ] Unlike Siena, no EF10 board ever had an external PHY, and consequently MDIO handling isn't even built into the firmware. Since Siena has been split out into its own driver, the MDIO code can be deleted from the sfc driver. Signed-off-by: Edward Cree Link: https://patch.msgid.link/aa689d192ddaef7abe82709316c2be648a7bd66e.1742493017.git.ecree.xilinx@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: 8241ecec1cdc ("sfc: fix NULL dereferences in ef100_process_design_param()") Signed-off-by: Sasha Levin commit 708e268acb3a446ad2a8a3d2e9bd41cc23660cd6 Author: Lin Ma Date: Thu Apr 3 01:00:26 2025 +0800 netfilter: nft_tunnel: fix geneve_opt type confusion addition [ Upstream commit 1b755d8eb1ace3870789d48fbd94f386ad6e30be ] When handling multiple NFTA_TUNNEL_KEY_OPTS_GENEVE attributes, the parsing logic should place every geneve_opt structure one by one compactly. Hence, when deciding the next geneve_opt position, the pointer addition should be in units of char *. However, the current implementation erroneously does type conversion before the addition, which will lead to heap out-of-bounds write. [ 6.989857] ================================================================== [ 6.990293] BUG: KASAN: slab-out-of-bounds in nft_tunnel_obj_init+0x977/0xa70 [ 6.990725] Write of size 124 at addr ffff888005f18974 by task poc/178 [ 6.991162] [ 6.991259] CPU: 0 PID: 178 Comm: poc-oob-write Not tainted 6.1.132 #1 [ 6.991655] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 6.992281] Call Trace: [ 6.992423] [ 6.992586] dump_stack_lvl+0x44/0x5c [ 6.992801] print_report+0x184/0x4be [ 6.993790] kasan_report+0xc5/0x100 [ 6.994252] kasan_check_range+0xf3/0x1a0 [ 6.994486] memcpy+0x38/0x60 [ 6.994692] nft_tunnel_obj_init+0x977/0xa70 [ 6.995677] nft_obj_init+0x10c/0x1b0 [ 6.995891] nf_tables_newobj+0x585/0x950 [ 6.996922] nfnetlink_rcv_batch+0xdf9/0x1020 [ 6.998997] nfnetlink_rcv+0x1df/0x220 [ 6.999537] netlink_unicast+0x395/0x530 [ 7.000771] netlink_sendmsg+0x3d0/0x6d0 [ 7.001462] __sock_sendmsg+0x99/0xa0 [ 7.001707] ____sys_sendmsg+0x409/0x450 [ 7.002391] ___sys_sendmsg+0xfd/0x170 [ 7.003145] __sys_sendmsg+0xea/0x170 [ 7.004359] do_syscall_64+0x5e/0x90 [ 7.005817] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 7.006127] RIP: 0033:0x7ec756d4e407 [ 7.006339] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf [ 7.007364] RSP: 002b:00007ffed5d46760 EFLAGS: 00000202 ORIG_RAX: 000000000000002e [ 7.007827] RAX: ffffffffffffffda RBX: 00007ec756cc4740 RCX: 00007ec756d4e407 [ 7.008223] RDX: 0000000000000000 RSI: 00007ffed5d467f0 RDI: 0000000000000003 [ 7.008620] RBP: 00007ffed5d468a0 R08: 0000000000000000 R09: 0000000000000000 [ 7.009039] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 [ 7.009429] R13: 00007ffed5d478b0 R14: 00007ec756ee5000 R15: 00005cbd4e655cb8 Fix this bug with correct pointer addition and conversion in parse and dump code. Fixes: 925d844696d9 ("netfilter: nft_tunnel: add support for geneve opts") Signed-off-by: Lin Ma Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit e833e7ad64eb2f63867f65303be49ca30ee8819e Author: Antoine Tenart Date: Wed Mar 26 18:36:32 2025 +0100 net: decrease cached dst counters in dst_release [ Upstream commit 3a0a3ff6593d670af2451ec363ccb7b18aec0c0a ] Upstream fix ac888d58869b ("net: do not delay dst_entries_add() in dst_release()") moved decrementing the dst count from dst_destroy to dst_release to avoid accessing already freed data in case of netns dismantle. However in case CONFIG_DST_CACHE is enabled and OvS+tunnels are used, this fix is incomplete as the same issue will be seen for cached dsts: Unable to handle kernel paging request at virtual address ffff5aabf6b5c000 Call trace: percpu_counter_add_batch+0x3c/0x160 (P) dst_release+0xec/0x108 dst_cache_destroy+0x68/0xd8 dst_destroy+0x13c/0x168 dst_destroy_rcu+0x1c/0xb0 rcu_do_batch+0x18c/0x7d0 rcu_core+0x174/0x378 rcu_core_si+0x18/0x30 Fix this by invalidating the cache, and thus decrementing cached dst counters, in dst_release too. Fixes: d71785ffc7e7 ("net: add dst_cache to ovs vxlan lwtunnel") Signed-off-by: Antoine Tenart Link: https://patch.msgid.link/20250326173634.31096-1-atenart@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 7ada892ef9938666d5d2f5d39284bde7e3bfe394 Author: Wang Liang Date: Thu Feb 27 16:10:52 2025 +0800 xsk: Fix __xsk_generic_xmit() error code when cq is full [ Upstream commit 5d0b204654de25615cf712be86c3192eca68ed80 ] When the cq reservation is failed, the error code is not set which is initialized to zero in __xsk_generic_xmit(). That means the packet is not send successfully but sendto() return ok. Considering the impact on uapi, return -EAGAIN is a good idea. The cq is full usually because it is not released in time, try to send msg again is appropriate. The bug was at the very early implementation of xsk, so the Fixes tag targets the commit that introduced the changes in xsk_cq_reserve_addr_locked where this fix depends on. Fixes: e6c4047f5122 ("xsk: Use xsk_buff_pool directly for cq functions") Suggested-by: Magnus Karlsson Signed-off-by: Wang Liang Signed-off-by: Martin KaFai Lau Acked-by: Stanislav Fomichev Link: https://patch.msgid.link/20250227081052.4096337-1-wangliang74@huawei.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 2afae03ca2dd353814b85c7fadce2192a0841c47 Author: Guillaume Nault Date: Sat Mar 29 01:33:44 2025 +0100 tunnels: Accept PACKET_HOST in skb_tunnel_check_pmtu(). [ Upstream commit 8930424777e43257f5bf6f0f0f53defd0d30415c ] Because skb_tunnel_check_pmtu() doesn't handle PACKET_HOST packets, commit 30a92c9e3d6b ("openvswitch: Set the skbuff pkt_type for proper pmtud support.") forced skb->pkt_type to PACKET_OUTGOING for openvswitch packets that are sent using the OVS_ACTION_ATTR_OUTPUT action. This allowed such packets to invoke the iptunnel_pmtud_check_icmp() or iptunnel_pmtud_check_icmpv6() helpers and thus trigger PMTU update on the input device. However, this also broke other parts of PMTU discovery. Since these packets don't have the PACKET_HOST type anymore, they won't trigger the sending of ICMP Fragmentation Needed or Packet Too Big messages to remote hosts when oversized (see the skb_in->pkt_type condition in __icmp_send() for example). These two skb->pkt_type checks are therefore incompatible as one requires skb->pkt_type to be PACKET_HOST, while the other requires it to be anything but PACKET_HOST. It makes sense to not trigger ICMP messages for non-PACKET_HOST packets as these messages should be generated only for incoming l2-unicast packets. However there doesn't seem to be any reason for skb_tunnel_check_pmtu() to ignore PACKET_HOST packets. Allow both cases to work by allowing skb_tunnel_check_pmtu() to work on PACKET_HOST packets and not overriding skb->pkt_type in openvswitch anymore. Fixes: 30a92c9e3d6b ("openvswitch: Set the skbuff pkt_type for proper pmtud support.") Fixes: 4cb47a8644cc ("tunnels: PMTU discovery support for directly bridged IP packets") Signed-off-by: Guillaume Nault Reviewed-by: Stefano Brivio Reviewed-by: Aaron Conole Tested-by: Aaron Conole Link: https://patch.msgid.link/eac941652b86fddf8909df9b3bf0d97bc9444793.1743208264.git.gnault@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 04cc1e8ff7843a60729cc5e5b3798389539f8036 Author: Stefano Garzarella Date: Fri Mar 28 15:15:28 2025 +0100 vsock: avoid timeout during connect() if the socket is closing [ Upstream commit fccd2b711d9628c7ce0111d5e4938652101ee30a ] When a peer attempts to establish a connection, vsock_connect() contains a loop that waits for the state to be TCP_ESTABLISHED. However, the other peer can be fast enough to accept the connection and close it immediately, thus moving the state to TCP_CLOSING. When this happens, the peer in the vsock_connect() is properly woken up, but since the state is not TCP_ESTABLISHED, it goes back to sleep until the timeout expires, returning -ETIMEDOUT. If the socket state is TCP_CLOSING, waiting for the timeout is pointless. vsock_connect() can return immediately without errors or delay since the connection actually happened. The socket will be in a closing state, but this is not an issue, and subsequent calls will fail as expected. We discovered this issue while developing a test that accepts and immediately closes connections to stress the transport switch between two connect() calls, where the first one was interrupted by a signal (see Closes link). Reported-by: Luigi Leonardi Closes: https://lore.kernel.org/virtualization/bq6hxrolno2vmtqwcvb5bljfpb7mvwb3kohrvaed6auz5vxrfv@ijmd2f3grobn/ Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Signed-off-by: Stefano Garzarella Acked-by: Paolo Abeni Tested-by: Luigi Leonardi Reviewed-by: Luigi Leonardi Link: https://patch.msgid.link/20250328141528.420719-1-sgarzare@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3836029448e76c1e6f77cc5fe0adc09b018b5fa8 Author: Kuniyuki Iwashima Date: Tue Apr 1 11:44:43 2025 -0700 udp: Fix memory accounting leak. [ Upstream commit df207de9d9e7a4d92f8567e2c539d9c8c12fd99d ] Matt Dowling reported a weird UDP memory usage issue. Under normal operation, the UDP memory usage reported in /proc/net/sockstat remains close to zero. However, it occasionally spiked to 524,288 pages and never dropped. Moreover, the value doubled when the application was terminated. Finally, it caused intermittent packet drops. We can reproduce the issue with the script below [0]: 1. /proc/net/sockstat reports 0 pages # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 0 2. Run the script till the report reaches 524,288 # python3 test.py & sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 524288 <-- (INT_MAX + 1) >> PAGE_SHIFT 3. Kill the socket and confirm the number never drops # pkill python3 && sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 524288 4. (necessary since v6.0) Trigger proto_memory_pcpu_drain() # python3 test.py & sleep 1 && pkill python3 5. The number doubles # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 1048577 The application set INT_MAX to SO_RCVBUF, which triggered an integer overflow in udp_rmem_release(). When a socket is close()d, udp_destruct_common() purges its receive queue and sums up skb->truesize in the queue. This total is calculated and stored in a local unsigned integer variable. The total size is then passed to udp_rmem_release() to adjust memory accounting. However, because the function takes a signed integer argument, the total size can wrap around, causing an overflow. Then, the released amount is calculated as follows: 1) Add size to sk->sk_forward_alloc. 2) Round down sk->sk_forward_alloc to the nearest lower multiple of PAGE_SIZE and assign it to amount. 3) Subtract amount from sk->sk_forward_alloc. 4) Pass amount >> PAGE_SHIFT to __sk_mem_reduce_allocated(). When the issue occurred, the total in udp_destruct_common() was 2147484480 (INT_MAX + 833), which was cast to -2147482816 in udp_rmem_release(). At 1) sk->sk_forward_alloc is changed from 3264 to -2147479552, and 2) sets -2147479552 to amount. 3) reverts the wraparound, so we don't see a warning in inet_sock_destruct(). However, udp_memory_allocated ends up doubling at 4). Since commit 3cd3399dd7a8 ("net: implement per-cpu reserves for memory_allocated"), memory usage no longer doubles immediately after a socket is close()d because __sk_mem_reduce_allocated() caches the amount in udp_memory_per_cpu_fw_alloc. However, the next time a UDP socket receives a packet, the subtraction takes effect, causing UDP memory usage to double. This issue makes further memory allocation fail once the socket's sk->sk_rmem_alloc exceeds net.ipv4.udp_rmem_min, resulting in packet drops. To prevent this issue, let's use unsigned int for the calculation and call sk_forward_alloc_add() only once for the small delta. Note that first_packet_length() also potentially has the same problem. [0]: from socket import * SO_RCVBUFFORCE = 33 INT_MAX = (2 ** 31) - 1 s = socket(AF_INET, SOCK_DGRAM) s.bind(('', 0)) s.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX) c = socket(AF_INET, SOCK_DGRAM) c.connect(s.getsockname()) data = b'a' * 100 while True: c.send(data) Fixes: f970bd9e3a06 ("udp: implement memory accounting helpers") Reported-by: Matt Dowling Signed-off-by: Kuniyuki Iwashima Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20250401184501.67377-3-kuniyu@amazon.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7571aadd20289e9ea10ebfed0986f39ed8b3c16b Author: Kuniyuki Iwashima Date: Tue Apr 1 11:44:42 2025 -0700 udp: Fix multiple wraparounds of sk->sk_rmem_alloc. [ Upstream commit 5a465a0da13ee9fbd7d3cd0b2893309b0fe4b7e3 ] __udp_enqueue_schedule_skb() has the following condition: if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf) goto drop; sk->sk_rcvbuf is initialised by net.core.rmem_default and later can be configured by SO_RCVBUF, which is limited by net.core.rmem_max, or SO_RCVBUFFORCE. If we set INT_MAX to sk->sk_rcvbuf, the condition is always false as sk->sk_rmem_alloc is also signed int. Then, the size of the incoming skb is added to sk->sk_rmem_alloc unconditionally. This results in integer overflow (possibly multiple times) on sk->sk_rmem_alloc and allows a single socket to have skb up to net.core.udp_mem[1]. For example, if we set a large value to udp_mem[1] and INT_MAX to sk->sk_rcvbuf and flood packets to the socket, we can see multiple overflows: # cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 7956736 <-- (7956736 << 12) bytes > INT_MAX * 15 ^- PAGE_SHIFT # ss -uam State Recv-Q ... UNCONN -1757018048 ... <-- flipping the sign repeatedly skmem:(r2537949248,rb2147483646,t0,tb212992,f1984,w0,o0,bl0,d0) Previously, we had a boundary check for INT_MAX, which was removed by commit 6a1f12dd85a8 ("udp: relax atomic operation on sk->sk_rmem_alloc"). A complete fix would be to revert it and cap the right operand by INT_MAX: rmem = atomic_add_return(size, &sk->sk_rmem_alloc); if (rmem > min(size + (unsigned int)sk->sk_rcvbuf, INT_MAX)) goto uncharge_drop; but we do not want to add the expensive atomic_add_return() back just for the corner case. Casting rmem to unsigned int prevents multiple wraparounds, but we still allow a single wraparound. # cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 524288 <-- (INT_MAX + 1) >> 12 # ss -uam State Recv-Q ... UNCONN -2147482816 ... <-- INT_MAX + 831 bytes skmem:(r2147484480,rb2147483646,t0,tb212992,f3264,w0,o0,bl0,d14468947) So, let's define rmem and rcvbuf as unsigned int and check skb->truesize only when rcvbuf is large enough to lower the overflow possibility. Note that we still have a small chance to see overflow if multiple skbs to the same socket are processed on different core at the same time and each size does not exceed the limit but the total size does. Note also that we must ignore skb->truesize for a small buffer as explained in commit 363dc73acacb ("udp: be less conservative with sock rmem accounting"). Fixes: 6a1f12dd85a8 ("udp: relax atomic operation on sk->sk_rmem_alloc") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20250401184501.67377-2-kuniyu@amazon.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ed546836fc103fb8b168726a9aa32dab3b539e09 Author: Kuniyuki Iwashima Date: Tue Apr 1 12:07:08 2025 -0700 rtnetlink: Use register_pernet_subsys() in rtnl_net_debug_init(). [ Upstream commit 1b7fdc702c031134c619b74c4f311c590e50ca3d ] rtnl_net_debug_init() registers rtnl_net_debug_net_ops by register_pernet_device() but calls unregister_pernet_subsys() in case register_netdevice_notifier() fails. It corrupts pernet_list because first_device is updated in register_pernet_device() but not unregister_pernet_subsys(). Let's fix it by calling register_pernet_subsys() instead. The _subsys() one fits better for the use case because it keeps the notifier alive until default_device_exit_net(), giving it more chance to test NETDEV_UNREGISTER. Fixes: 03fa53485659 ("rtnetlink: Add ASSERT_RTNL_NET() placeholder for netdev notifier.") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250401190716.70437-1-kuniyu@amazon.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 46c1e23e34c9d1eaadf37f88216d9d8ce0d0bcee Author: Tobias Waldekranz Date: Tue Apr 1 08:58:04 2025 +0200 net: mvpp2: Prevent parser TCAM memory corruption [ Upstream commit 96844075226b49af25a69a1d084b648ec2d9b08d ] Protect the parser TCAM/SRAM memory, and the cached (shadow) SRAM information, from concurrent modifications. Both the TCAM and SRAM tables are indirectly accessed by configuring an index register that selects the row to read or write to. This means that operations must be atomic in order to, e.g., avoid spreading writes across multiple rows. Since the shadow SRAM array is used to find free rows in the hardware table, it must also be protected in order to avoid TOCTOU errors where multiple cores allocate the same row. This issue was detected in a situation where `mvpp2_set_rx_mode()` ran concurrently on two CPUs. In this particular case the MVPP2_PE_MAC_UC_PROMISCUOUS entry was corrupted, causing the classifier unit to drop all incoming unicast - indicated by the `rx_classifier_drops` counter. Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network unit") Signed-off-by: Tobias Waldekranz Reviewed-by: Maxime Chevallier Tested-by: Maxime Chevallier Link: https://patch.msgid.link/20250401065855.3113635-1-tobias@waldekranz.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f23381568c485164ef0f5d9776cf01f663d1e180 Author: Lorenzo Bianconi Date: Mon Mar 31 18:17:31 2025 +0200 net: airoha: Fix ETS priomap validation [ Upstream commit 367579274f60cb23c570ae5348966ab51e1509a4 ] ETS Qdisc schedules SP bands in a priority order assigning band-0 the highest priority (band-0 > band-1 > .. > band-n) while EN7581 arranges SP bands in a priority order assigning band-7 the highest priority (band-7 > band-6, .. > band-n). Fix priomap check in airoha_qdma_set_tx_ets_sched routine in order to align ETS Qdisc and airoha_eth driver SP priority ordering. Fixes: b56e4d660a96 ("net: airoha: Enforce ETS Qdisc priomap") Signed-off-by: Lorenzo Bianconi Reviewed-by: Simon Horman Reviewed-by: Davide Caratti Link: https://patch.msgid.link/20250331-airoha-ets-validate-priomap-v1-1-60a524488672@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d7f76197e49e46a8c082a6fededaa8a07e69a860 Author: Lorenzo Bianconi Date: Mon Mar 31 08:52:53 2025 +0200 net: airoha: Fix qid report in airoha_tc_get_htb_get_leaf_queue() [ Upstream commit 57b290d97c6150774bf929117ca737a26d8fc33d ] Fix the following kernel warning deleting HTB offloaded leafs and/or root HTB qdisc in airoha_eth driver properly reporting qid in airoha_tc_get_htb_get_leaf_queue routine. $tc qdisc replace dev eth1 root handle 10: htb offload $tc class add dev eth1 arent 10: classid 10:4 htb rate 100mbit ceil 100mbit $tc qdisc replace dev eth1 parent 10:4 handle 4: ets bands 8 \ quanta 1514 3028 4542 6056 7570 9084 10598 12112 $tc qdisc del dev eth1 root [ 55.827864] ------------[ cut here ]------------ [ 55.832493] WARNING: CPU: 3 PID: 2678 at 0xffffffc0798695a4 [ 55.956510] CPU: 3 PID: 2678 Comm: tc Tainted: G O 6.6.71 #0 [ 55.963557] Hardware name: Airoha AN7581 Evaluation Board (DT) [ 55.969383] pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 55.976344] pc : 0xffffffc0798695a4 [ 55.979851] lr : 0xffffffc079869a20 [ 55.983358] sp : ffffffc0850536a0 [ 55.986665] x29: ffffffc0850536a0 x28: 0000000000000024 x27: 0000000000000001 [ 55.993800] x26: 0000000000000000 x25: ffffff8008b19000 x24: ffffff800222e800 [ 56.000935] x23: 0000000000000001 x22: 0000000000000000 x21: ffffff8008b19000 [ 56.008071] x20: ffffff8002225800 x19: ffffff800379d000 x18: 0000000000000000 [ 56.015206] x17: ffffffbf9ea59000 x16: ffffffc080018000 x15: 0000000000000000 [ 56.022342] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000001 [ 56.029478] x11: ffffffc081471008 x10: ffffffc081575a98 x9 : 0000000000000000 [ 56.036614] x8 : ffffffc08167fd40 x7 : ffffffc08069e104 x6 : ffffff8007f86000 [ 56.043748] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000001 [ 56.050884] x2 : 0000000000000000 x1 : 0000000000000250 x0 : ffffff800222c000 [ 56.058020] Call trace: [ 56.060459] 0xffffffc0798695a4 [ 56.063618] 0xffffffc079869a20 [ 56.066777] __qdisc_destroy+0x40/0xa0 [ 56.070528] qdisc_put+0x54/0x6c [ 56.073748] qdisc_graft+0x41c/0x648 [ 56.077324] tc_get_qdisc+0x168/0x2f8 [ 56.080978] rtnetlink_rcv_msg+0x230/0x330 [ 56.085076] netlink_rcv_skb+0x5c/0x128 [ 56.088913] rtnetlink_rcv+0x14/0x1c [ 56.092490] netlink_unicast+0x1e0/0x2c8 [ 56.096413] netlink_sendmsg+0x198/0x3c8 [ 56.100337] ____sys_sendmsg+0x1c4/0x274 [ 56.104261] ___sys_sendmsg+0x7c/0xc0 [ 56.107924] __sys_sendmsg+0x44/0x98 [ 56.111492] __arm64_sys_sendmsg+0x20/0x28 [ 56.115580] invoke_syscall.constprop.0+0x58/0xfc [ 56.120285] do_el0_svc+0x3c/0xbc [ 56.123592] el0_svc+0x18/0x4c [ 56.126647] el0t_64_sync_handler+0x118/0x124 [ 56.131005] el0t_64_sync+0x150/0x154 [ 56.134660] ---[ end trace 0000000000000000 ]--- Fixes: ef1ca9271313b ("net: airoha: Add sched HTB offload support") Signed-off-by: Lorenzo Bianconi Acked-by: Paolo Abeni Link: https://patch.msgid.link/20250331-airoha-htb-qdisc-offload-del-fix-v1-1-4ea429c2c968@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d3d7675d77622f6ca1aae14c51f80027b36283f8 Author: Eric Dumazet Date: Mon Mar 31 09:15:32 2025 +0000 sctp: add mutual exclusion in proc_sctp_do_udp_port() [ Upstream commit 10206302af856791fbcc27a33ed3c3eb09b2793d ] We must serialize calls to sctp_udp_sock_stop() and sctp_udp_sock_start() or risk a crash as syzbot reported: Oops: general protection fault, probably for non-canonical address 0xdffffc000000000d: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f] CPU: 1 UID: 0 PID: 6551 Comm: syz.1.44 Not tainted 6.14.0-syzkaller-g7f2ff7b62617 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 RIP: 0010:kernel_sock_shutdown+0x47/0x70 net/socket.c:3653 Call Trace: udp_tunnel_sock_release+0x68/0x80 net/ipv4/udp_tunnel_core.c:181 sctp_udp_sock_stop+0x71/0x160 net/sctp/protocol.c:930 proc_sctp_do_udp_port+0x264/0x450 net/sctp/sysctl.c:553 proc_sys_call_handler+0x3d0/0x5b0 fs/proc/proc_sysctl.c:601 iter_file_splice_write+0x91c/0x1150 fs/splice.c:738 do_splice_from fs/splice.c:935 [inline] direct_splice_actor+0x18f/0x6c0 fs/splice.c:1158 splice_direct_to_actor+0x342/0xa30 fs/splice.c:1102 do_splice_direct_actor fs/splice.c:1201 [inline] do_splice_direct+0x174/0x240 fs/splice.c:1227 do_sendfile+0xafd/0xe50 fs/read_write.c:1368 __do_sys_sendfile64 fs/read_write.c:1429 [inline] __se_sys_sendfile64 fs/read_write.c:1415 [inline] __x64_sys_sendfile64+0x1d8/0x220 fs/read_write.c:1415 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] Fixes: 046c052b475e ("sctp: enable udp tunneling socks") Reported-by: syzbot+fae49d997eb56fa7c74d@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/67ea5c01.050a0220.1547ec.012b.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Cc: Marcelo Ricardo Leitner Acked-by: Xin Long Link: https://patch.msgid.link/20250331091532.224982-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 034b293bf17c124fec0f0e663f81203b00aa7a50 Author: Cong Wang Date: Sat Mar 29 15:25:35 2025 -0700 net_sched: skbprio: Remove overly strict queue assertions [ Upstream commit ce8fe975fd99b49c29c42e50f2441ba53112b2e8 ] In the current implementation, skbprio enqueue/dequeue contains an assertion that fails under certain conditions when SKBPRIO is used as a child qdisc under TBF with specific parameters. The failure occurs because TBF sometimes peeks at packets in the child qdisc without actually dequeuing them when tokens are unavailable. This peek operation creates a discrepancy between the parent and child qdisc queue length counters. When TBF later receives a high-priority packet, SKBPRIO's queue length may show a different value than what's reflected in its internal priority queue tracking, triggering the assertion. The fix removes this overly strict assertions in SKBPRIO, they are not necessary at all. Reported-by: syzbot+a3422a19b05ea96bee18@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a3422a19b05ea96bee18 Fixes: aea5f654e6b7 ("net/sched: add skbprio scheduler") Cc: Nishanth Devarajan Signed-off-by: Cong Wang Acked-by: Paolo Abeni Link: https://patch.msgid.link/20250329222536.696204-2-xiyou.wangcong@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 172a8a996a337206970467e871dd995ac07640b1 Author: Debin Zhu Date: Tue Apr 1 20:40:18 2025 +0800 netlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 sockets [ Upstream commit 078aabd567de3d63d37d7673f714e309d369e6e2 ] When calling netlbl_conn_setattr(), addr->sa_family is used to determine the function behavior. If sk is an IPv4 socket, but the connect function is called with an IPv6 address, the function calipso_sock_setattr() is triggered. Inside this function, the following code is executed: sk_fullsock(__sk) ? inet_sk(__sk)->pinet6 : NULL; Since sk is an IPv4 socket, pinet6 is NULL, leading to a null pointer dereference. This patch fixes the issue by checking if inet6_sk(sk) returns a NULL pointer before accessing pinet6. Signed-off-by: Debin Zhu Signed-off-by: Bitao Ouyang <1985755126@qq.com> Acked-by: Paul Moore Fixes: ceba1832b1b2 ("calipso: Set the calipso socket label to match the secattr.") Link: https://patch.msgid.link/20250401124018.4763-1-mowenroot@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ce571eba07d54e3637bf334bc48376fbfa55defe Author: Florian Westphal Date: Tue Apr 1 14:36:47 2025 +0200 netfilter: nf_tables: don't unregister hook when table is dormant [ Upstream commit 688c15017d5cd5aac882400782e7213d40dc3556 ] When nf_tables_updchain encounters an error, hook registration needs to be rolled back. This should only be done if the hook has been registered, which won't happen when the table is flagged as dormant (inactive). Just move the assignment into the registration block. Reported-by: syzbot+53ed3a6440173ddbf499@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=53ed3a6440173ddbf499 Fixes: b9703ed44ffb ("netfilter: nf_tables: support for adding new devices to an existing netdev chain") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 368043dcbf23e7c76a6b5047205df0b11c8d17e5 Author: Pablo Neira Ayuso Date: Fri Mar 21 23:24:20 2025 +0100 netfilter: nft_set_hash: GC reaps elements with conncount for dynamic sets only [ Upstream commit 9d74da1177c800eb3d51c13f9821b7b0683845a5 ] conncount has its own GC handler which determines when to reap stale elements, this is convenient for dynamic sets. However, this also reaps non-dynamic sets with static configurations coming from control plane. Always run connlimit gc handler but honor feedback to reap element if this set is dynamic. Fixes: 290180e2448c ("netfilter: nf_tables: add connlimit support") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 9fc9b3dc0d0c189ed205acf1e5fbd73e0becc4d6 Author: Emil Tantilov Date: Mon Mar 17 22:42:02 2025 -0700 idpf: fix adapter NULL pointer dereference on reboot [ Upstream commit 4c9106f4906a85f6b13542d862e423bcdc118cc3 ] With SRIOV enabled, idpf ends up calling into idpf_remove() twice. First via idpf_shutdown() and then again when idpf_remove() calls into sriov_disable(), because the VF devices use the idpf driver, hence the same remove routine. When that happens, it is possible for the adapter to be NULL from the first call to idpf_remove(), leading to a NULL pointer dereference. echo 1 > /sys/class/net//device/sriov_numvfs reboot BUG: kernel NULL pointer dereference, address: 0000000000000020 ... RIP: 0010:idpf_remove+0x22/0x1f0 [idpf] ... ? idpf_remove+0x22/0x1f0 [idpf] ? idpf_remove+0x1e4/0x1f0 [idpf] pci_device_remove+0x3f/0xb0 device_release_driver_internal+0x19f/0x200 pci_stop_bus_device+0x6d/0x90 pci_stop_and_remove_bus_device+0x12/0x20 pci_iov_remove_virtfn+0xbe/0x120 sriov_disable+0x34/0xe0 idpf_sriov_configure+0x58/0x140 [idpf] idpf_remove+0x1b9/0x1f0 [idpf] idpf_shutdown+0x12/0x30 [idpf] pci_device_shutdown+0x35/0x60 device_shutdown+0x156/0x200 ... Replace the direct idpf_remove() call in idpf_shutdown() with idpf_vc_core_deinit() and idpf_deinit_dflt_mbx(), which perform the bulk of the cleanup, such as stopping the init task, freeing IRQs, destroying the vports and freeing the mailbox. This avoids the calls to sriov_disable() in addition to a small netdev cleanup, and destroying workqueues, which don't seem to be required on shutdown. Reported-by: Yuying Ma Fixes: e850efed5e15 ("idpf: add module register and probe functionality") Reviewed-by: Madhu Chittim Signed-off-by: Emil Tantilov Reviewed-by: Simon Horman Tested-by: Samuel Salin Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 4bc8ef4aadd23b646d34c942b3916a5f10b0e873 Author: Piotr Kwapulinski Date: Fri Feb 21 16:49:17 2025 +0100 ixgbe: fix media type detection for E610 device [ Upstream commit 40206599beec98cfeb01913ee417f015e3f6190c ] The commit 23c0e5a16bcc ("ixgbe: Add link management support for E610 device") introduced incorrect media type detection for E610 device. It reproduces when advertised speed is modified after driver reload. Clear the previous outdated PHY type high value. Reproduction steps: modprobe ixgbe ethtool -s eth0 advertise 0x1000000000000 modprobe -r ixgbe modprobe ixgbe ethtool -s eth0 advertise 0x1000000000000 Result before the fix: netlink error: link settings update failed netlink error: Invalid argument Result after the fix: No output error Fixes: 23c0e5a16bcc ("ixgbe: Add link management support for E610 device") Reviewed-by: Przemek Kitszel Reviewed-by: Paul Menzel Signed-off-by: Piotr Kwapulinski Reviewed-by: Simon Horman Tested-by: Bharath R Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 85f6414167da39e0da30bf370f1ecda5a58c6f7b Author: Vitaly Lifshits Date: Thu Mar 13 16:05:56 2025 +0200 e1000e: change k1 configuration on MTP and later platforms [ Upstream commit efaaf344bc2917cbfa5997633bc18a05d3aed27f ] Starting from Meteor Lake, the Kumeran interface between the integrated MAC and the I219 PHY works at a different frequency. This causes sporadic MDI errors when accessing the PHY, and in rare circumstances could lead to packet corruption. To overcome this, introduce minor changes to the Kumeran idle state (K1) parameters during device initialization. Hardware reset reverts this configuration, therefore it needs to be applied in a few places. Fixes: cc23f4f0b6b9 ("e1000e: Add support for Meteor Lake") Signed-off-by: Vitaly Lifshits Tested-by: Avigail Dahan Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 22c3d1eab273bab690e60005978bfaabd8272aa9 Author: Zdenek Bouska Date: Wed Mar 19 15:18:48 2025 +0100 igc: Fix TX drops in XDP ZC [ Upstream commit d931cf9b38da0f533cacfe51c863a9912e67822f ] Fixes TX frame drops in AF_XDP zero copy mode when budget < 4. xsk_tx_peek_desc() consumed TX frame and it was ignored because of low budget. Not even AF_XDP completion was done for dropped frames. It can be reproduced on i226 by sending 100000x 60 B frames with launch time set to minimal IPG (672 ns between starts of frames) on 1Gbit/s. Always 1026 frames are not sent and are missing a completion. Fixes: 9acf59a752d4c ("igc: Enable TX via AF_XDP zero-copy") Signed-off-by: Zdenek Bouska Reviewed-by: Song Yoong Siang Reviewed-by: Florian Bezdeka Tested-by: Mor Bar-Gabay Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit b21b7b8175f53807df38a391295f94721769e478 Author: Song Yoong Siang Date: Sun Feb 16 17:34:30 2025 +0800 igc: Add launch time support to XDP ZC [ Upstream commit d7c3a7ff75028bea9e4879bd3dcd04a6dc3e33c8 ] Enable Launch Time Control (LTC) support for XDP zero copy via XDP Tx metadata framework. This patch has been tested with tools/testing/selftests/bpf/xdp_hw_metadata on Intel I225-LM Ethernet controller. Below are the test steps and result. Test 1: Send a single packet with the launch time set to 1 s in the future. Test steps: 1. On the DUT, start the xdp_hw_metadata selftest application: $ sudo ./xdp_hw_metadata enp2s0 -l 1000000000 -L 1 2. On the Link Partner, send a UDP packet with VLAN priority 1 to port 9091 of the DUT. Result: When the launch time is set to 1 s in the future, the delta between the launch time and the transmit hardware timestamp is 0.016 us, as shown in printout of the xdp_hw_metadata application below. 0x562ff5dc8880: rx_desc[4]->addr=84110 addr=84110 comp_addr=84110 EoP rx_hash: 0xE343384 with RSS type:0x1 HW RX-time: 1734578015467548904 (sec:1734578015.4675) delta to User RX-time sec:0.0002 (183.103 usec) XDP RX-time: 1734578015467651698 (sec:1734578015.4677) delta to User RX-time sec:0.0001 (80.309 usec) No rx_vlan_tci or rx_vlan_proto, err=-95 0x562ff5dc8880: ping-pong with csum=561c (want c7dd) csum_start=34 csum_offset=6 HW RX-time: 1734578015467548904 (sec:1734578015.4675) delta to HW Launch-time sec:1.0000 (1000000.000 usec) 0x562ff5dc8880: complete tx idx=4 addr=4018 HW Launch-time: 1734578016467548904 (sec:1734578016.4675) delta to HW TX-complete-time sec:0.0000 (0.016 usec) HW TX-complete-time: 1734578016467548920 (sec:1734578016.4675) delta to User TX-complete-time sec:0.0000 (32.546 usec) XDP RX-time: 1734578015467651698 (sec:1734578015.4677) delta to User TX-complete-time sec:0.9999 (999929.768 usec) HW RX-time: 1734578015467548904 (sec:1734578015.4675) delta to HW TX-complete-time sec:1.0000 (1000000.016 usec) 0x562ff5dc8880: complete rx idx=132 addr=84110 Test 2: Send 1000 packets with a 10 ms interval and the launch time set to 500 us in the future. Test steps: 1. On the DUT, start the xdp_hw_metadata selftest application: $ sudo chrt -f 99 ./xdp_hw_metadata enp2s0 -l 500000 -L 1 > \ /dev/shm/result.log 2. On the Link Partner, send 1000 UDP packets with a 10 ms interval and VLAN priority 1 to port 9091 of the DUT. Result: When the launch time is set to 500 us in the future, the average delta between the launch time and the transmit hardware timestamp is 0.016 us, as shown in the analysis of /dev/shm/result.log below. The XDP launch time works correctly in sending 1000 packets continuously. Min delta: 0.005 us Avr delta: 0.016 us Max delta: 0.031 us Total packets forwarded: 1000 Signed-off-by: Song Yoong Siang Signed-off-by: Martin KaFai Lau Reviewed-by: Faizal Rahim Reviewed-by: Maciej Fijalkowski Link: https://patch.msgid.link/20250216093430.957880-6-yoong.siang.song@intel.com Stable-dep-of: d931cf9b38da ("igc: Fix TX drops in XDP ZC") Signed-off-by: Sasha Levin commit dcfd219477359d59fe9f0d637e8e40faabb3243d Author: Song Yoong Siang Date: Sun Feb 16 17:34:29 2025 +0800 igc: Refactor empty frame insertion for launch time support [ Upstream commit f9b53bb13923f0a6ed2e784a35301cfb4c28f4f4 ] Refactor the code for inserting an empty frame into a new function igc_insert_empty_frame(). This change extracts the logic for inserting an empty packet from igc_xmit_frame_ring() into a separate function, allowing it to be reused in future implementations, such as the XDP zero copy transmit function. Remove the igc_desc_unused() checking in igc_init_tx_empty_descriptor() because the number of descriptors needed is guaranteed. Ensure that skb allocation and DMA mapping work for the empty frame, before proceeding to fill in igc_tx_buffer info, context descriptor, and data descriptor. Rate limit the error messages for skb allocation and DMA mapping failures. Update the comment to indicate that the 2 descriptors needed by the empty frame are already taken into consideration in igc_xmit_frame_ring(). Handle the case where the insertion of an empty frame fails and explain the reason behind this handling. Signed-off-by: Song Yoong Siang Signed-off-by: Martin KaFai Lau Reviewed-by: Faizal Rahim Reviewed-by: Maciej Fijalkowski Link: https://patch.msgid.link/20250216093430.957880-5-yoong.siang.song@intel.com Stable-dep-of: d931cf9b38da ("igc: Fix TX drops in XDP ZC") Signed-off-by: Sasha Levin commit d9d736c416c9a85f84e15435ba82a177262e745b Author: Song Yoong Siang Date: Sun Feb 16 17:34:26 2025 +0800 xsk: Add launch time hardware offload support to XDP Tx metadata [ Upstream commit ca4419f15abd19ba8be1e109661b60f9f5b6c9f0 ] Extend the XDP Tx metadata framework so that user can requests launch time hardware offload, where the Ethernet device will schedule the packet for transmission at a pre-determined time called launch time. The value of launch time is communicated from user space to Ethernet driver via launch_time field of struct xsk_tx_metadata. Suggested-by: Stanislav Fomichev Signed-off-by: Song Yoong Siang Signed-off-by: Martin KaFai Lau Acked-by: Stanislav Fomichev Acked-by: Jakub Kicinski Link: https://patch.msgid.link/20250216093430.957880-2-yoong.siang.song@intel.com Stable-dep-of: d931cf9b38da ("igc: Fix TX drops in XDP ZC") Signed-off-by: Sasha Levin commit 8a70cfe445fab255806c3c746da99624b92a7bc3 Author: Florian Fainelli Date: Tue Apr 1 16:36:03 2025 -0700 spi: bcm2835: Restore native CS probing when pinctrl-bcm2835 is absent [ Upstream commit e19c1272c80a5ecce387c1b0c3b995f4edf9c525 ] The lookup table forces the use of the "pinctrl-bcm2835" GPIO chip provider and essentially assumes that there is going to be such a provider, and if not, we will fail to set-up the SPI device. While this is true on Raspberry Pi based systems (2835/36/37, 2711, 2712), this is not true on 7712/77122 Broadcom STB systems which use the SPI driver, but not the GPIO driver. There used to be an early check: chip = gpiochip_find("pinctrl-bcm2835", chip_match_name); if (!chip) return 0; which would accomplish that nicely, bring something similar back by checking for the compatible strings matched by the pinctrl-bcm2835.c driver, if there is no Device Tree node matching those compatible strings, then we won't find any GPIO provider registered by the "pinctrl-bcm2835" driver. Fixes: 21f252cd29f0 ("spi: bcm2835: reduce the abuse of the GPIO API") Signed-off-by: Florian Fainelli Link: https://patch.msgid.link/20250401233603.2938955-1-florian.fainelli@broadcom.com Acked-by: Bartosz Golaszewski Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 07e72b76f8108a3035549499b74e782bb192cfdd Author: Takashi Iwai Date: Wed Apr 2 09:42:07 2025 +0200 ALSA: hda/realtek: Fix built-in mic on another ASUS VivoBook model [ Upstream commit 8983dc1b66c0e1928a263b8af0bb06f6cb9229c4 ] There is another VivoBook model which built-in mic got broken recently by the fix of the pin sort. Apply the correct quirk ALC256_FIXUP_ASUS_MIC_NO_PRESENCE to this model for addressing the regression, too. Fixes: 3b4309546b48 ("ALSA: hda: Fix headset detection failure due to unstable sort") Closes: https://lore.kernel.org/Z95s5T6OXFPjRnKf@eldamar.lan Link: https://patch.msgid.link/20250402074208.7347-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 290833b8a9f4c37eb764c9afb3581d9aa0439e8e Author: Florian Fainelli Date: Tue Apr 1 15:42:38 2025 -0700 spi: bcm2835: Do not call gpiod_put() on invalid descriptor [ Upstream commit d6691010523fe1016f482a1e1defcc6289eeea48 ] If we are unable to lookup the chip-select GPIO, the error path will call bcm2835_spi_cleanup() which unconditionally calls gpiod_put() on the cs->gpio variable which we just determined was invalid. Fixes: 21f252cd29f0 ("spi: bcm2835: reduce the abuse of the GPIO API") Signed-off-by: Florian Fainelli Link: https://patch.msgid.link/20250401224238.2854256-1-florian.fainelli@broadcom.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit dd2bbb9564d0d24a2643ad90008a79840368c4b4 Author: Henry Martin Date: Tue Apr 1 22:25:10 2025 +0800 ASoC: imx-card: Add NULL check in imx_card_probe() [ Upstream commit 93d34608fd162f725172e780b1c60cc93a920719 ] devm_kasprintf() returns NULL when memory allocation fails. Currently, imx_card_probe() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue. Fixes: aa736700f42f ("ASoC: imx-card: Add imx-card machine driver") Signed-off-by: Henry Martin Reviewed-by: Frank Li Link: https://patch.msgid.link/20250401142510.29900-1-bsdhenrymartin@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c2e44807ff0cea5fd64139224f83c6160c49b078 Author: Maurizio Lombardi Date: Mon Mar 31 18:28:59 2025 +0200 nvme-pci: skip nvme_write_sq_db on empty rqlist [ Upstream commit 288ff0d10beb069355036355d5f7612579dc869c ] nvme_submit_cmds() should check the rqlist before calling nvme_write_sq_db(); if the list is empty, it must return immediately. Fixes: beadf0088501 ("nvme-pci: reverse request order in nvme_queue_rqs") Signed-off-by: Maurizio Lombardi Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit c5a10d8a601f78ae483c8befc98333d9d8e93812 Author: Caleb Sander Mateos Date: Fri Mar 28 09:46:45 2025 -0600 nvme/ioctl: don't warn on vectorized uring_cmd with fixed buffer [ Upstream commit eada75467fca0b016b9b22212637c07216135c20 ] The vectorized io_uring NVMe passthru opcodes don't yet support fixed buffers. But since userspace can trigger this condition based on the io_uring SQE parameters, it shouldn't cause a kernel warning. Signed-off-by: Caleb Sander Mateos Reviewed-by: Jens Axboe Reviewed-by: Chaitanya Kulkarni Reviewed-by: Christoph Hellwig Fixes: 23fd22e55b76 ("nvme: wire up fixed buffer support for nvme passthrough") Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 0b12563214fb3174800512c397bd25f7c64e9c2f Author: Björn Töpel Date: Fri Mar 28 09:53:11 2025 +0100 riscv/purgatory: 4B align purgatory_start [ Upstream commit 3f7023171df43641a8a8a1c9a12124501e589010 ] When a crashkernel is launched on RISC-V, the entry to purgatory is done by trapping via the stvec CSR. From riscv_kexec_norelocate(): | ... | /* | * Switch to physical addressing | * This will also trigger a jump to CSR_STVEC | * which in this case is the address of the new | * kernel. | */ | csrw CSR_STVEC, a2 | csrw CSR_SATP, zero stvec requires that the address is 4B aligned, which was not the case, e.g.: | Loaded purgatory at 0xffffc000 | kexec_file: kexec_file_load: type:1, start:0xffffd232 head:0x4 flags:0x6 The address 0xffffd232 not 4B aligned. Correct by adding proper function alignment. With this change, crashkernels loaded with kexec-file will be able to properly enter the purgatory. Fixes: 736e30af583fb ("RISC-V: Add purgatory") Signed-off-by: Björn Töpel Reviewed-by: Alexandre Ghiti Link: https://lore.kernel.org/r/20250328085313.1193815-1-bjorn@kernel.org Signed-off-by: Alexandre Ghiti Signed-off-by: Sasha Levin commit 80d0afc71691aa770b6f9546ae3ea9c51a9c674a Author: Yao Zi Date: Wed Mar 26 05:14:46 2025 +0000 riscv/kexec_file: Handle R_RISCV_64 in purgatory relocator [ Upstream commit 28093cfef5dd62f4cbd537f2bdf6f0bf85309c45 ] Commit 58ff537109ac ("riscv: Omit optimized string routines when using KASAN") introduced calls to EXPORT_SYMBOL() in assembly string routines, which result in R_RISCV_64 relocations against .export_symbol section. As these rountines are reused by RISC-V purgatory and our relocator doesn't recognize these relocations, this fails kexec-file-load with dmesg like [ 11.344251] kexec_image: Unknown rela relocation: 2 [ 11.345972] kexec_image: Error loading purgatory ret=-8 Let's support R_RISCV_64 relocation to fix kexec on 64-bit RISC-V. 32-bit variant isn't covered since KEXEC_FILE and KEXEC_PURGATORY isn't available. Fixes: 58ff537109ac ("riscv: Omit optimized string routines when using KASAN") Signed-off-by: Yao Zi Tested-by: Björn Töpel Reviewed-by: Björn Töpel Link: https://lore.kernel.org/r/20250326051445.55131-2-ziyao@disroot.org Signed-off-by: Alexandre Ghiti Signed-off-by: Sasha Levin commit b921328d8178a083a4129123b9f8efa2b3517a6e Author: Alexandre Ghiti Date: Mon Mar 17 08:25:51 2025 +0100 riscv: Fix hugetlb retrieval of number of ptes in case of !present pte [ Upstream commit 83d78ac677b9fdd8ea763507c6fe02d6bf415f3a ] Ryan sent a fix [1] for arm64 that applies to riscv too: in some hugetlb functions, we must not use the pte value to get the size of a mapping because the pte may not be present. So use the already present size parameter for huge_pte_clear() and the newly introduced size parameter for huge_ptep_get_and_clear(). And make sure to gather A/D bits only on present ptes. Fixes: 82a1a1f3bfb6 ("riscv: mm: support Svnapot in hugetlb page") Link: https://lore.kernel.org/all/20250217140419.1702389-1-ryan.roberts@arm.com/ [1] Link: https://lore.kernel.org/r/20250317072551.572169-1-alexghiti@rivosinc.com Signed-off-by: Alexandre Ghiti Signed-off-by: Sasha Levin commit 645f1813fe0dc96381c36b834131e643b798fd73 Author: Josh Poimboeuf Date: Mon Mar 31 08:33:32 2025 -0700 spi: cadence: Fix out-of-bounds array access in cdns_mrvl_xspi_setup_clock() [ Upstream commit 7ba0847fa1c22e7801cebfe5f7b75aee4fae317e ] If requested_clk > 128, cdns_mrvl_xspi_setup_clock() iterates over the entire cdns_mrvl_xspi_clk_div_list array without breaking out early, causing 'i' to go beyond the array bounds. Fix that by stopping the loop when it gets to the last entry, clamping the clock to the minimum 6.25 MHz. Fixes the following warning with an UBSAN kernel: vmlinux.o: warning: objtool: cdns_mrvl_xspi_setup_clock: unexpected end of section .text.cdns_mrvl_xspi_setup_clock Fixes: 26d34fdc4971 ("spi: cadence: Add clock configuration for Marvell xSPI overlay") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202503282236.UhfRsF3B-lkp@intel.com/ Link: https://lore.kernel.org/r/gs2ooxfkblnee6cc5yfcxh7nu4wvoqnuv4lrllkhccxgcac2jg@7snmwd73jkhs Signed-off-by: Josh Poimboeuf Link: https://patch.msgid.link/h6bef6wof6zpjfp3jbhrkigqsnykdfy6j4qmmvb6gsabhianhj@k57a7hwpa3bj Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 49c48c8f37f1c85bf0026ee6998c5435241ed61d Author: Christophe JAILLET Date: Sat Mar 22 08:45:49 2025 +0100 ASoC: codecs: rt5665: Fix some error handling paths in rt5665_probe() [ Upstream commit 1ebd4944266e86a7ce274f197847f5a6399651e8 ] Should an error occur after a successful regulator_bulk_enable() call, regulator_bulk_disable() should be called, as already done in the remove function. Instead of adding an error handling path in the probe, switch from devm_regulator_bulk_get() to devm_regulator_bulk_get_enable() and simplify the remove function and some other places accordingly. Finally, add a missing const when defining rt5665_supply_names to please checkpatch and constify a few bytes. Fixes: 33ada14a26c8 ("ASoC: add rt5665 codec driver") Signed-off-by: Christophe JAILLET Link: https://patch.msgid.link/e3c2aa1b2fdfa646752d94f4af968630c0d58248.1742629525.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d3b3c430b2e212e6f0d190924c2b7a30c5863fca Author: Sven Schnelle Date: Thu Mar 20 13:25:38 2025 +0100 s390/entry: Fix setting _CIF_MCCK_GUEST with lowcore relocation [ Upstream commit 121df45b37a1016ee6828c2ca3ba825f3e18a8c1 ] When lowcore relocation is enabled, the machine check handler doesn't use the lowcore address when setting _CIF_MCCK_GUEST. Fix this by adding the missing base register. Fixes: 0001b7bbc53a ("s390/entry: Make mchk_int_handler() ready for lowcore relocation") Reported-by: Heiko Carstens Reviewed-by: Heiko Carstens Signed-off-by: Sven Schnelle Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 9158359015f0eda00e521e35b7bc7ebce176aebf Author: Ming Lei Date: Thu Mar 27 17:51:10 2025 +0800 ublk: make sure ubq->canceling is set when queue is frozen [ Upstream commit 8741d0737921ec1c03cf59aebf4d01400c2b461a ] Now ublk driver depends on `ubq->canceling` for deciding if the request can be dispatched via uring_cmd & io_uring_cmd_complete_in_task(). Once ubq->canceling is set, the uring_cmd can be done via ublk_cancel_cmd() and io_uring_cmd_done(). So set ubq->canceling when queue is frozen, this way makes sure that the flag can be observed from ublk_queue_rq() reliably, and avoids use-after-free on uring_cmd. Fixes: 216c8f5ef0f2 ("ublk: replace monitor with cancelable uring_cmd") Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20250327095123.179113-2-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit afec4a1b35ec5ff4b3489effec85e2e48009c69f Author: Herton R. Krzesinski Date: Thu Mar 20 11:22:13 2025 -0300 x86/uaccess: Improve performance by aligning writes to 8 bytes in copy_user_generic(), on non-FSRM/ERMS CPUs [ Upstream commit b5322b6ec06a6c58650f52abcd2492000396363b ] History of the performance regression: ====================================== Since the following series of user copy updates were merged upstream ~2 years ago via: a5624566431d ("Merge branch 'x86-rep-insns': x86 user copy clarifications") .. copy_user_generic() on x86_64 stopped doing alignment of the writes to the destination to a 8 byte boundary for the non FSRM case. Previously, this was done through the ALIGN_DESTINATION macro that was used in the now removed copy_user_generic_unrolled function. Turns out this change causes some loss of performance/throughput on some use cases and specific CPU/platforms without FSRM and ERMS. Lately I got two reports of performance/throughput issues after a RHEL 9 kernel pulled the same upstream series with updates to user copy functions. Both reports consisted of running specific networking/TCP related testing using iperf3. Partial upstream fix ==================== The first report was related to a Linux Bridge testing using VMs on a specific machine with an AMD CPU (EPYC 7402), and after a brief investigation it turned out that the later change via: ca96b162bfd2 ("x86: bring back rep movsq for user access on CPUs without ERMS") ... helped/fixed the performance issue. However, after the later commit/fix was applied, then I got another regression reported in a multistream TCP test on a 100Gbit mlx5 nic, also running on an AMD based platform (AMD EPYC 7302 CPU), again that was using iperf3 to run the test. That regression was after applying the later fix/commit, but only this didn't help in telling the whole history. Testing performed to pinpoint residual regression ================================================= So I narrowed down the second regression use case, but running it without traffic through a NIC, on localhost, in trying to narrow down CPU usage and not being limited by other factor like network bandwidth. I used another system also with an AMD CPU (AMD EPYC 7742). Basically, I run iperf3 in server and client mode in the same system, for example: - Start the server binding it to CPU core/thread 19: $ taskset -c 19 iperf3 -D -s -B 127.0.0.1 -p 12000 - Start the client always binding/running on CPU core/thread 17, using perf to get statistics: $ perf stat -o stat.txt taskset -c 17 iperf3 -c 127.0.0.1 -b 0/1000 -V \ -n 50G --repeating-payload -l 16384 -p 12000 --cport 12001 2>&1 \ > stat-19.txt For the client, always running/pinned to CPU 17. But for the iperf3 in server mode, I did test runs using CPUs 19, 21, 23 or not pinned to any specific CPU. So it basically consisted with four runs of the same commands, just changing the CPU which the server is pinned, or without pinning by removing the taskset call before the server command. The CPUs were chosen based on NUMA node they were on, this is the relevant output of lscpu on the system: $ lscpu ... Model name: AMD EPYC 7742 64-Core Processor ... Caches (sum of all): L1d: 2 MiB (64 instances) L1i: 2 MiB (64 instances) L2: 32 MiB (64 instances) L3: 256 MiB (16 instances) NUMA: NUMA node(s): 4 NUMA node0 CPU(s): 0,1,8,9,16,17,24,25,32,33,40,41,48,49,56,57,64,65,72,73,80,81,88,89,96,97,104,105,112,113,120,121 NUMA node1 CPU(s): 2,3,10,11,18,19,26,27,34,35,42,43,50,51,58,59,66,67,74,75,82,83,90,91,98,99,106,107,114,115,122,123 NUMA node2 CPU(s): 4,5,12,13,20,21,28,29,36,37,44,45,52,53,60,61,68,69,76,77,84,85,92,93,100,101,108,109,116,117,124,125 NUMA node3 CPU(s): 6,7,14,15,22,23,30,31,38,39,46,47,54,55,62,63,70,71,78,79,86,87,94,95,102,103,110,111,118,119,126,127 ... So for the server run, when picking a CPU, I chose CPUs to be not on the same node. The reason is with that I was able to get/measure relevant performance differences when changing the alignment of the writes to the destination in copy_user_generic. Testing shows up to +81% performance improvement under iperf3 ============================================================= Here's a summary of the iperf3 runs: # Vanilla upstream alignment: CPU RATE SYS TIME sender-receiver Server bind 19: 13.0Gbits/sec 28.371851000 33.233499566 86.9%-70.8% Server bind 21: 12.9Gbits/sec 28.283381000 33.586486621 85.8%-69.9% Server bind 23: 11.1Gbits/sec 33.660190000 39.012243176 87.7%-64.5% Server bind none: 18.9Gbits/sec 19.215339000 22.875117865 86.0%-80.5% # With the attached patch (aligning writes in non ERMS/FSRM case): CPU RATE SYS TIME sender-receiver Server bind 19: 20.8Gbits/sec 14.897284000 20.811101382 75.7%-89.0% Server bind 21: 20.4Gbits/sec 15.205055000 21.263165909 75.4%-89.7% Server bind 23: 20.2Gbits/sec 15.433801000 21.456175000 75.5%-89.8% Server bind none: 26.1Gbits/sec 12.534022000 16.632447315 79.8%-89.6% So I consistently got better results when aligning the write. The results above were run on 6.14.0-rc6/rc7 based kernels. The sys is sys time and then the total time to run/transfer 50G of data. The last field is the CPU usage of sender/receiver iperf3 process. It's also worth to note that each pair of iperf3 runs may get slightly different results on each run, but I always got consistent higher results with the write alignment for this specific test of running the processes on CPUs in different NUMA nodes. Linus Torvalds helped/provided this version of the patch. Initially I proposed a version which aligned writes for all cases in rep_movs_alternative, however it used two extra registers and thus Linus provided an enhanced version that only aligns the write on the large_movsq case, which is sufficient since the problem happens only on those AMD CPUs like ones mentioned above without ERMS/FSRM, and also doesn't require using extra registers. Also, I validated that aligning only on large_movsq case is really enough for getting the performance back. I also tested this patch on an old Intel based non-ERMS/FRMS system (with Xeon E5-2667 - Sandy Bridge based) and didn't get any problems: no performance enhancement but also no regression either, using the same iperf3 based benchmark. Also newer Intel processors after Sandy Bridge usually have ERMS and should not be affected by this change. [ mingo: Updated the changelog. ] Fixes: ca96b162bfd2 ("x86: bring back rep movsq for user access on CPUs without ERMS") Fixes: 034ff37d3407 ("x86: rewrite '__copy_user_nocache' function") Reported-by: Ondrej Lichtner Co-developed-by: Linus Torvalds Signed-off-by: Linus Torvalds Signed-off-by: Herton R. Krzesinski Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20250320142213.2623518-1-herton@redhat.com Signed-off-by: Sasha Levin commit da9c3744962dd18d3e39029ae60bc80d2dcfe309 Author: Palmer Dabbelt Date: Wed Mar 26 15:45:07 2025 -0700 RISC-V: errata: Use medany for relocatable builds [ Upstream commit bb58e1579f431d42469b6aed0f03eff383ba6db5 ] We're trying to mix non-PIC/PIE objects into the otherwise-PIE relocatable kernels, to avoid GOT/PLT references during early boot alternative resolution (which happens before the GOT/PLT are set up). riscv64-unknown-linux-gnu-ld: arch/riscv/errata/sifive/errata.o: relocation R_RISCV_HI20 against `tlb_flush_all_threshold' can not be used when making a shared object; recompile with -fPIC riscv64-unknown-linux-gnu-ld: arch/riscv/errata/thead/errata.o: relocation R_RISCV_HI20 against `riscv_cbom_block_size' can not be used when making a shared object; recompile with -fPIC Fixes: 8dc2a7e8027f ("riscv: Fix relocatable kernels with early alternatives using -fno-pie") Link: https://lore.kernel.org/r/20250326224506.27165-2-palmer@rivosinc.com Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 63527858ed87fb5b656c624ccb2ee868b278c738 Author: Takashi Iwai Date: Wed Mar 26 16:22:01 2025 +0100 ALSA: hda/realtek: Fix built-in mic breakage on ASUS VivoBook X515JA [ Upstream commit 84c3c08f5a6c2e2209428b76156bcaf349c3a62d ] ASUS VivoBook X515JA with PCI SSID 1043:14f2 also hits the same issue as other VivoBook model about the mic pin assignment, and the same workaround is required to apply ALC256_FIXUP_ASUS_MIC_NO_PRESENCE quirk. Fixes: 3b4309546b48 ("ALSA: hda: Fix headset detection failure due to unstable sort") Link: https://bugzilla.kernel.org/show_bug.cgi?id=219902 Link: https://patch.msgid.link/20250326152205.26733-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 8c6970541f6cdd6e114255bd7fbaa880aa04511a Author: Richard Fitzgerald Date: Sun Mar 23 17:05:29 2025 +0000 firmware: cs_dsp: Ensure cs_dsp_load[_coeff]() returns 0 on success [ Upstream commit 2593f7e0dc93a898a84220b3fb180d86f1ca8c60 ] Set ret = 0 on successful completion of the processing loop in cs_dsp_load() and cs_dsp_load_coeff() to ensure that the function returns 0 on success. All normal firmware files will have at least one data block, and processing this block will set ret == 0, from the result of either regmap_raw_write() or cs_dsp_parse_coeff(). The kunit tests create a dummy firmware file that contains only the header, without any data blocks. This gives cs_dsp a file to "load" that will not cause any side-effects. As there aren't any data blocks, the processing loop will not set ret == 0. Originally there was a line after the processing loop: ret = regmap_async_complete(regmap); which would set ret == 0 before the function returned. Commit fe08b7d5085a ("firmware: cs_dsp: Remove async regmap writes") changed the regmap write to a normal sync write, so the call to regmap_async_complete() wasn't necessary and was removed. It was overlooked that the ret here wasn't only to check the result of regmap_async_complete(), it also set the final return value of the function. Fixes: fe08b7d5085a ("firmware: cs_dsp: Remove async regmap writes") Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20250323170529.197205-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 87ef39ea46b5967cb1ff61d9482cbe9946f618c1 Author: Andrew Jones Date: Tue Mar 4 13:00:21 2025 +0100 riscv: Fix set up of vector cpu hotplug callback [ Upstream commit 2744ec472de31141ad354907ff98843dd6040917 ] Whether or not we have RISCV_PROBE_VECTOR_UNALIGNED_ACCESS we need to set up a cpu hotplug callback to check if we have vector at all, since, when we don't have vector, we need to set vector_misaligned_access to unsupported rather than leave it the default of unknown. Fixes: e7c9d66e313b ("RISC-V: Report vector unaligned access speed hwprobe") Reviewed-by: Alexandre Ghiti Signed-off-by: Andrew Jones Link: https://lore.kernel.org/r/20250304120014.143628-16-ajones@ventanamicro.com Signed-off-by: Alexandre Ghiti Signed-off-by: Sasha Levin commit bcc2dc40d98ba7be6abc7fbb8396b5d9a90ebebd Author: Andrew Jones Date: Tue Mar 4 13:00:20 2025 +0100 riscv: Fix set up of cpu hotplug callbacks [ Upstream commit 05ee21f0fcb8ca29bf42bd6cbce109f2e49c167f ] CPU hotplug callbacks should be set up even if we detected all current cpus emulate misaligned accesses, since we want to ensure our expectations of all cpus emulating is maintained. Fixes: 6e5ce7f2eae3 ("riscv: Decouple emulated unaligned accesses from access speed") Fixes: e7c9d66e313b ("RISC-V: Report vector unaligned access speed hwprobe") Reviewed-by: Clément Léger Reviewed-by: Alexandre Ghiti Signed-off-by: Andrew Jones Link: https://lore.kernel.org/r/20250304120014.143628-15-ajones@ventanamicro.com Signed-off-by: Alexandre Ghiti Signed-off-by: Sasha Levin commit c92a47023de4ca3a1875efd9e7f03ce4ab228fd7 Author: Andrew Jones Date: Tue Mar 4 13:00:19 2025 +0100 riscv: Change check_unaligned_access_speed_all_cpus to void [ Upstream commit 813d39baee3229d31420af61460b97f4fafdd352 ] The return value of check_unaligned_access_speed_all_cpus() is always zero, so make the function void so we don't need to concern ourselves with it. The change also allows us to tidy up check_unaligned_access_all_cpus() a bit. Reviewed-by: Clément Léger Reviewed-by: Alexandre Ghiti Signed-off-by: Andrew Jones Link: https://lore.kernel.org/r/20250304120014.143628-14-ajones@ventanamicro.com Signed-off-by: Alexandre Ghiti Stable-dep-of: 05ee21f0fcb8 ("riscv: Fix set up of cpu hotplug callbacks") Signed-off-by: Sasha Levin commit a83ed4e18db38b7b4a15425ccd63939806d106cf Author: Andrew Jones Date: Tue Mar 4 13:00:18 2025 +0100 riscv: Fix check_unaligned_access_all_cpus [ Upstream commit e6d0adf2eb5bb3244cb21a7a15899aa058bd384f ] check_vector_unaligned_access_emulated_all_cpus(), like its name suggests, will return true when all cpus emulate unaligned vector accesses. If the function returned false it may have been because vector isn't supported at all (!has_vector()) or because at least one cpu doesn't emulate unaligned vector accesses. Since false may be returned for two cases, checking for it isn't sufficient when attempting to determine if we should proceed with the vector speed check. Move the !has_vector() functionality to check_unaligned_access_all_cpus() in order for check_vector_unaligned_access_emulated_all_cpus() to return false for a single case. Fixes: e7c9d66e313b ("RISC-V: Report vector unaligned access speed hwprobe") Reviewed-by: Alexandre Ghiti Signed-off-by: Andrew Jones Link: https://lore.kernel.org/r/20250304120014.143628-13-ajones@ventanamicro.com Signed-off-by: Alexandre Ghiti Signed-off-by: Sasha Levin commit 9d24b6f44b2a7c0c8f5c46b252281c24f3560bfb Author: Andrew Jones Date: Tue Mar 4 13:00:17 2025 +0100 riscv: Fix riscv_online_cpu_vec [ Upstream commit 5af72a818612332a11171b16f27a62ec0a0f91d7 ] We shouldn't probe when we already know vector is unsupported and we should probe when we see we don't yet know whether it's supported. Furthermore, we should ensure we've set the access type to unsupported when we don't have vector at all. Fixes: e7c9d66e313b ("RISC-V: Report vector unaligned access speed hwprobe") Reviewed-by: Alexandre Ghiti Signed-off-by: Andrew Jones Link: https://lore.kernel.org/r/20250304120014.143628-12-ajones@ventanamicro.com Signed-off-by: Alexandre Ghiti Signed-off-by: Sasha Levin commit dfef32cf33f4e09a5bfdc8a57603e0de506bed47 Author: Andrew Jones Date: Tue Mar 4 13:00:16 2025 +0100 riscv: Annotate unaligned access init functions [ Upstream commit a00e022be5315c5a1f47521a1cc6d3b71c8e9c44 ] Several functions used in unaligned access probing are only run at init time. Annotate them appropriately. Fixes: f413aae96cda ("riscv: Set unaligned access speed at compile time") Reviewed-by: Alexandre Ghiti Signed-off-by: Andrew Jones Link: https://lore.kernel.org/r/20250304120014.143628-11-ajones@ventanamicro.com Signed-off-by: Alexandre Ghiti Signed-off-by: Sasha Levin commit 78b39c587b8f6c69140177108f9c08a75b1c7c37 Author: Pu Lehui Date: Mon Mar 17 03:12:14 2025 +0000 riscv: fgraph: Fix stack layout to match __arch_ftrace_regs argument of ftrace_return_to_handler [ Upstream commit 67a5ba8f742f247bc83e46dd2313c142b1383276 ] Naresh Kamboju reported a "Bad frame pointer" kernel warning while running LTP trace ftrace_stress_test.sh in riscv. We can reproduce the same issue with the following command: ``` $ cd /sys/kernel/debug/tracing $ echo 'f:myprobe do_nanosleep%return args1=$retval' > dynamic_events $ echo 1 > events/fprobes/enable $ echo 1 > tracing_on $ sleep 1 ``` And we can get the following kernel warning: [ 127.692888] ------------[ cut here ]------------ [ 127.693755] Bad frame pointer: expected ff2000000065be50, received ba34c141e9594000 [ 127.693755] from func do_nanosleep return to ffffffff800ccb16 [ 127.698699] WARNING: CPU: 1 PID: 129 at kernel/trace/fgraph.c:755 ftrace_return_to_handler+0x1b2/0x1be [ 127.699894] Modules linked in: [ 127.700908] CPU: 1 UID: 0 PID: 129 Comm: sleep Not tainted 6.14.0-rc3-g0ab191c74642 #32 [ 127.701453] Hardware name: riscv-virtio,qemu (DT) [ 127.701859] epc : ftrace_return_to_handler+0x1b2/0x1be [ 127.702032] ra : ftrace_return_to_handler+0x1b2/0x1be [ 127.702151] epc : ffffffff8013b5e0 ra : ffffffff8013b5e0 sp : ff2000000065bd10 [ 127.702221] gp : ffffffff819c12f8 tp : ff60000080853100 t0 : 6e00000000000000 [ 127.702284] t1 : 0000000000000020 t2 : 6e7566206d6f7266 s0 : ff2000000065bd80 [ 127.702346] s1 : ff60000081262000 a0 : 000000000000007b a1 : ffffffff81894f20 [ 127.702408] a2 : 0000000000000010 a3 : fffffffffffffffe a4 : 0000000000000000 [ 127.702470] a5 : 0000000000000000 a6 : 0000000000000008 a7 : 0000000000000038 [ 127.702530] s2 : ba34c141e9594000 s3 : 0000000000000000 s4 : ff2000000065bdd0 [ 127.702591] s5 : 00007fff8adcf400 s6 : 000055556dc1d8c0 s7 : 0000000000000068 [ 127.702651] s8 : 00007fff8adf5d10 s9 : 000000000000006d s10: 0000000000000001 [ 127.702710] s11: 00005555737377c8 t3 : ffffffff819d899e t4 : ffffffff819d899e [ 127.702769] t5 : ffffffff819d89a0 t6 : ff2000000065bb18 [ 127.702826] status: 0000000200000120 badaddr: 0000000000000000 cause: 0000000000000003 [ 127.703292] [] ftrace_return_to_handler+0x1b2/0x1be [ 127.703760] [] return_to_handler+0x16/0x26 [ 127.704009] [] return_to_handler+0x0/0x26 [ 127.704057] [] common_nsleep+0x42/0x54 [ 127.704117] [] __riscv_sys_clock_nanosleep+0xba/0x10a [ 127.704176] [] do_trap_ecall_u+0x188/0x218 [ 127.704295] [] handle_exception+0x14a/0x156 [ 127.705436] ---[ end trace 0000000000000000 ]--- The reason is that the stack layout for constructing argument for the ftrace_return_to_handler in the return_to_handler does not match the __arch_ftrace_regs structure of riscv, leading to unexpected results. Fixes: a3ed4157b7d8 ("fgraph: Replace fgraph_ret_regs with ftrace_regs") Reported-by: Linux Kernel Functional Testing Closes: https://lore.kernel.org/all/CA+G9fYvp_oAxeDFj88Tk2rfEZ7jtYKAKSwfYS66=57Db9TBdyA@mail.gmail.com Signed-off-by: Pu Lehui Reviewed-by: Alexandre Ghiti Tested-by: Björn Töpel Reviewed-by: Masami Hiramatsu (Google) Link: https://lore.kernel.org/r/20250317031214.4138436-2-pulehui@huaweicloud.com Signed-off-by: Alexandre Ghiti Signed-off-by: Sasha Levin commit 71260a21076a64d8773a3e49b44e440cb8f05df7 Author: Nikita Shubin Date: Thu Jun 6 11:15:19 2024 +0300 ntb: intel: Fix using link status DB's [ Upstream commit 8144e9c8f30fb23bb736a5d24d5c9d46965563c4 ] Make sure we are not using DB's which were remapped for link status. Fixes: f6e51c354b60 ("ntb: intel: split out the gen3 code") Signed-off-by: Nikita Shubin Reviewed-by: Dave Jiang Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit 0df2e03e4620548b41891b4e0d1bd9d2e0d8a39a Author: Yajun Deng Date: Wed Aug 16 16:33:05 2023 +0800 ntb_hw_switchtec: Fix shift-out-of-bounds in switchtec_ntb_mw_set_trans [ Upstream commit de203da734fae00e75be50220ba5391e7beecdf9 ] There is a kernel API ntb_mw_clear_trans() would pass 0 to both addr and size. This would make xlate_pos negative. [ 23.734156] switchtec switchtec0: MW 0: part 0 addr 0x0000000000000000 size 0x0000000000000000 [ 23.734158] ================================================================================ [ 23.734172] UBSAN: shift-out-of-bounds in drivers/ntb/hw/mscc/ntb_hw_switchtec.c:293:7 [ 23.734418] shift exponent -1 is negative Ensuring xlate_pos is a positive or zero before BIT. Fixes: 1e2fd202f859 ("ntb_hw_switchtec: Check for alignment of the buffer in mw_set_trans()") Signed-off-by: Yajun Deng Reviewed-by: Logan Gunthorpe Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit 31538ac654181ba451a293c488bc82ec00651b67 Author: Pu Lehui Date: Mon Mar 17 03:12:13 2025 +0000 riscv: fgraph: Select HAVE_FUNCTION_GRAPH_TRACER depends on HAVE_DYNAMIC_FTRACE_WITH_ARGS [ Upstream commit e8eb8e1bdae94b9e003f5909519fd311d0936890 ] Currently, fgraph on riscv relies on the infrastructure of DYNAMIC_FTRACE_WITH_ARGS. However, DYNAMIC_FTRACE_WITH_ARGS may be turned off on riscv, which will cause the enabled fgraph to be abnormal. Therefore, let's select HAVE_FUNCTION_GRAPH_TRACER depends on HAVE_DYNAMIC_FTRACE_WITH_ARGS. Fixes: a3ed4157b7d8 ("fgraph: Replace fgraph_ret_regs with ftrace_regs") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202503160820.dvqMpH0g-lkp@intel.com/ Signed-off-by: Pu Lehui Reviewed-by: Björn Töpel Link: https://lore.kernel.org/r/20250317031214.4138436-1-pulehui@huaweicloud.com Signed-off-by: Alexandre Ghiti Signed-off-by: Sasha Levin commit 3d72905d25af0c58e3c08cebc184daec83a91815 Author: Alexandre Ghiti Date: Fri Feb 28 10:06:13 2025 +0100 riscv: Fix missing __free_pages() in check_vector_unaligned_access() [ Upstream commit 33981b1c4e499021421686dcfa7b3d23a430d00e ] The locally allocated pages are never freed up, so add the corresponding __free_pages(). Fixes: e7c9d66e313b ("RISC-V: Report vector unaligned access speed hwprobe") Link: https://lore.kernel.org/r/20250228090613.345309-1-alexghiti@rivosinc.com Signed-off-by: Alexandre Ghiti Signed-off-by: Sasha Levin commit dc7f11838b55b6c5bc06505c86c11a380e0d8fa2 Author: Tingbo Liao Date: Fri Feb 28 01:08:01 2025 -0800 riscv: Fix the __riscv_copy_vec_words_unaligned implementation [ Upstream commit 475afa39b123699e910c61ad9a51cedce4a0d310 ] Correct the VEC_S macro definition to fix the implementation of vector words copy in the case of unalignment in RISC-V. Fixes: e7c9d66e313b ("RISC-V: Report vector unaligned access speed hwprobe") Reviewed-by: Alexandre Ghiti Signed-off-by: Tingbo Liao Link: https://lore.kernel.org/r/20250228090801.8334-1-tingbo.liao@starfivetech.com Signed-off-by: Alexandre Ghiti Signed-off-by: Sasha Levin commit 29838dedb0f069d27a9ad8b9b4f9ea0b7142715e Author: Juhan Jin Date: Thu Feb 6 13:28:36 2025 -0600 riscv: ftrace: Add parentheses in macro definitions of make_call_t0 and make_call_ra [ Upstream commit 5f1a58ed91a040d4625d854f9bb3dd4995919202 ] This patch adds parentheses to parameters caller and callee of macros make_call_t0 and make_call_ra. Every existing invocation of these two macros uses a single variable for each argument, so the absence of the parentheses seems okay. However, future invocations might use more complex expressions as arguments. For example, a future invocation might look like this: make_call_t0(a - b, c, call). Without parentheses in the macro definition, the macro invocation expands to: ... unsigned int offset = (unsigned long) c - (unsigned long) a - b; ... which is clearly wrong. The use of parentheses ensures arguments are correctly evaluated and potentially saves future users of make_call_t0 and make_call_ra debugging trouble. Fixes: 6724a76cff85 ("riscv: ftrace: Reduce the detour code size to half") Signed-off-by: Juhan Jin Reviewed-by: Alexandre Ghiti Link: https://lore.kernel.org/r/tencent_AE90AA59903A628E87E9F80E563DA5BA5508@qq.com Signed-off-by: Alexandre Ghiti Signed-off-by: Sasha Levin commit 6517b395cb1e43fbf3962dd93e6fb4a5e5ab100e Author: Christian Schoenebeck Date: Thu Mar 13 13:59:32 2025 +0100 fs/9p: fix NULL pointer dereference on mkdir [ Upstream commit 3f61ac7c65bdb26accb52f9db66313597e759821 ] When a 9p tree was mounted with option 'posixacl', parent directory had a default ACL set for its subdirectories, e.g.: setfacl -m default:group:simpsons:rwx parentdir then creating a subdirectory crashed 9p client, as v9fs_fid_add() call in function v9fs_vfs_mkdir_dotl() sets the passed 'fid' pointer to NULL (since dafbe689736) even though the subsequent v9fs_set_create_acl() call expects a valid non-NULL 'fid' pointer: [ 37.273191] BUG: kernel NULL pointer dereference, address: 0000000000000000 ... [ 37.322338] Call Trace: [ 37.323043] [ 37.323621] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 37.324448] ? page_fault_oops (arch/x86/mm/fault.c:714) [ 37.325532] ? search_module_extables (kernel/module/main.c:3733) [ 37.326742] ? p9_client_walk (net/9p/client.c:1165) 9pnet [ 37.328006] ? search_bpf_extables (kernel/bpf/core.c:804) [ 37.329142] ? exc_page_fault (./arch/x86/include/asm/paravirt.h:686 arch/x86/mm/fault.c:1488 arch/x86/mm/fault.c:1538) [ 37.330196] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:574) [ 37.331330] ? p9_client_walk (net/9p/client.c:1165) 9pnet [ 37.332562] ? v9fs_fid_xattr_get (fs/9p/xattr.c:30) 9p [ 37.333824] v9fs_fid_xattr_set (fs/9p/fid.h:23 fs/9p/xattr.c:121) 9p [ 37.335077] v9fs_set_acl (fs/9p/acl.c:276) 9p [ 37.336112] v9fs_set_create_acl (fs/9p/acl.c:307) 9p [ 37.337326] v9fs_vfs_mkdir_dotl (fs/9p/vfs_inode_dotl.c:411) 9p [ 37.338590] vfs_mkdir (fs/namei.c:4313) [ 37.339535] do_mkdirat (fs/namei.c:4336) [ 37.340465] __x64_sys_mkdir (fs/namei.c:4354) [ 37.341455] do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) [ 37.342447] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Fix this by simply swapping the sequence of these two calls in v9fs_vfs_mkdir_dotl(), i.e. calling v9fs_set_create_acl() before v9fs_fid_add(). Fixes: dafbe689736f ("9p fid refcount: cleanup p9_fid_put calls") Reported-by: syzbot+5b667f9a1fee4ba3775a@syzkaller.appspotmail.com Signed-off-by: Christian Schoenebeck Message-ID: Signed-off-by: Dominique Martinet Signed-off-by: Sasha Levin commit 4a7448c83e117ed68597952ecaede1cebc4427a7 Author: Al Viro Date: Wed Mar 12 19:38:28 2025 -0400 spufs: fix a leak in spufs_create_context() [ Upstream commit 0f5cce3fc55b08ee4da3372baccf4bcd36a98396 ] Leak fixes back in 2008 missed one case - if we are trying to set affinity and spufs_mkdir() fails, we need to drop the reference to neighbor. Fixes: 58119068cb27 "[POWERPC] spufs: Fix memory leak on SPU affinity" Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit fc646a6c6d14b5d581f162a7e32999f789e3a3ac Author: Al Viro Date: Wed Mar 12 19:18:39 2025 -0400 spufs: fix gang directory lifetimes [ Upstream commit c134deabf4784e155d360744d4a6a835b9de4dd4 ] prior to "[POWERPC] spufs: Fix gang destroy leaks" we used to have a problem with gang lifetimes - creation of a gang returns opened gang directory, which normally gets removed when that gets closed, but if somebody has created a context belonging to that gang and kept it alive until the gang got closed, removal failed and we ended up with a leak. Unfortunately, it had been fixed the wrong way. Dentry of gang directory was no longer pinned, and rmdir on close was gone. One problem was that failure of open kept calling simple_rmdir() as cleanup, which meant an unbalanced dput(). Another bug was in the success case - gang creation incremented link count on root directory, but that was no longer undone when gang got destroyed. Fix consists of * reverting the commit in question * adding a counter to gang, protected by ->i_rwsem of gang directory inode. * having it set to 1 at creation time, dropped in both spufs_dir_close() and spufs_gang_close() and bumped in spufs_create_context(), provided that it's not 0. * using simple_recursive_removal() to take the gang directory out when counter reaches zero. Fixes: 877907d37da9 "[POWERPC] spufs: Fix gang destroy leaks" Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 0bd56e4e72c354b65c0a7e5ac1c09eca81949d5b Author: Al Viro Date: Sat Mar 8 19:26:31 2025 -0500 spufs: fix a leak on spufs_new_file() failure [ Upstream commit d1ca8698ca1332625d83ea0d753747be66f9906d ] It's called from spufs_fill_dir(), and caller of that will do spufs_rmdir() in case of failure. That does remove everything we'd managed to create, but... the problem dentry is still negative. IOW, it needs to be explicitly dropped. Fixes: 3f51dd91c807 "[PATCH] spufs: fix spufs_fill_dir error path" Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 18d77303ca325ffddd82534563bae05d7dd2efe1 Author: Claudiu Beznea Date: Wed Feb 5 11:55:19 2025 +0200 rtc: renesas-rtca3: Disable interrupts only if the RTC is enabled [ Upstream commit 27b2fcbd6b98204b0dce62e9aa9540ca0a2b70f1 ] If the RTC is not enabled and the code attempts to disable the interrupt, the readb_poll_timeout_atomic() function in the rtca3_alarm_irq_set_helper() may timeout, leading to probe failures. This issue is reproducible on some devices because the initial values of the PIE and AIE bits in the RCR1 register are undefined. To prevent probe failures in this scenario, disable RTC interrupts only when the RTC is actually enabled. Fixes: d4488377609e ("rtc: renesas-rtca3: Add driver for RTCA-3 available on Renesas RZ/G3S SoC") Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/20250205095519.2031742-1-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit fb86fc9e7d34cee3684849d7cea1faf640c5d4dd Author: Dan Carpenter Date: Wed Apr 2 14:02:40 2025 +0300 nfs: Add missing release on error in nfs_lock_and_join_requests() [ Upstream commit 8e5419d6542fdf2dca9a0acdef2b8255f0e4ba69 ] Call nfs_release_request() on this error path before returning. Fixes: c3f2235782c3 ("nfs: fold nfs_folio_find_and_lock_request into nfs_lock_and_join_requests") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/3aaaa3d5-1c8a-41e4-98c7-717801ddd171@stanley.mountain Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit d100e5d7785401e6e4407f8fb54b2f46caaf92e4 Author: Josh Poimboeuf Date: Mon Mar 31 21:26:43 2025 -0700 objtool/loongarch: Add unwind hints in prepare_frametrace() [ Upstream commit 7c977393b8277ed319e92e4b598b26598c9d30c0 ] If 'regs' points to a local stack variable, prepare_frametrace() stores all registers to the stack. This confuses objtool as it expects them to be restored from the stack later. The stores don't affect stack tracing, so use unwind hints to hide them from objtool. Fixes the following warnings: arch/loongarch/kernel/traps.o: warning: objtool: show_stack+0xe0: stack state mismatch: reg1[22]=-1+0 reg2[22]=-2-160 arch/loongarch/kernel/traps.o: warning: objtool: show_stack+0xe0: stack state mismatch: reg1[23]=-1+0 reg2[23]=-2-152 Fixes: cb8a2ef0848c ("LoongArch: Add ORC stack unwinder support") Reported-by: kernel test robot Tested-by: Tiezhu Yang Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Cc: Linus Torvalds Link: https://lore.kernel.org/r/270cadd8040dda74db2307f23497bb68e65db98d.1743481539.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/oe-kbuild-all/202503280703.OARM8SrY-lkp@intel.com/ Signed-off-by: Sasha Levin commit e14c21ce775ad01d447c341c4f4327e24602a6e5 Author: Josh Poimboeuf Date: Mon Mar 31 21:26:46 2025 -0700 rcu-tasks: Always inline rcu_irq_work_resched() [ Upstream commit 6309a5c43b0dc629851f25b2e5ef8beff61d08e5 ] Thanks to CONFIG_DEBUG_SECTION_MISMATCH, empty functions can be generated out of line. rcu_irq_work_resched() can be called from noinstr code, so make sure it's always inlined. Fixes: 564506495ca9 ("rcu/context-tracking: Move deferred nocb resched to context tracking") Reported-by: Randy Dunlap Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Cc: Frederic Weisbecker Cc: Paul E. McKenney Cc: Linus Torvalds Link: https://lore.kernel.org/r/e84f15f013c07e4c410d972e75620c53b62c1b3e.1743481539.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/d1eca076-fdde-484a-b33e-70e0d167c36d@infradead.org Signed-off-by: Sasha Levin commit c4175cfda458e65880b78d02bd58f387e8ad80dd Author: Josh Poimboeuf Date: Mon Mar 31 21:26:45 2025 -0700 context_tracking: Always inline ct_{nmi,irq}_{enter,exit}() [ Upstream commit 9ac50f7311dc8b39e355582f14c1e82da47a8196 ] Thanks to CONFIG_DEBUG_SECTION_MISMATCH, empty functions can be generated out of line. These can be called from noinstr code, so make sure they're always inlined. Fixes the following warnings: vmlinux.o: warning: objtool: irqentry_nmi_enter+0xa2: call to ct_nmi_enter() leaves .noinstr.text section vmlinux.o: warning: objtool: irqentry_nmi_exit+0x16: call to ct_nmi_exit() leaves .noinstr.text section vmlinux.o: warning: objtool: irqentry_exit+0x78: call to ct_irq_exit() leaves .noinstr.text section Fixes: 6f0e6c1598b1 ("context_tracking: Take IRQ eqs entrypoints over RCU") Reported-by: Randy Dunlap Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Cc: Frederic Weisbecker Cc: Paul E. McKenney Cc: Linus Torvalds Link: https://lore.kernel.org/r/8509bce3f536bcd4ae7af3a2cf6930d48c5e631a.1743481539.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/d1eca076-fdde-484a-b33e-70e0d167c36d@infradead.org Signed-off-by: Sasha Levin commit b27b4e59e8f7dffd8f71549074eec69be1158381 Author: Josh Poimboeuf Date: Mon Mar 31 21:26:44 2025 -0700 sched/smt: Always inline sched_smt_active() [ Upstream commit 09f37f2d7b21ff35b8b533f9ab8cfad2fe8f72f6 ] sched_smt_active() can be called from noinstr code, so it should always be inlined. The CONFIG_SCHED_SMT version already has __always_inline. Do the same for its !CONFIG_SCHED_SMT counterpart. Fixes the following warning: vmlinux.o: error: objtool: intel_idle_ibrs+0x13: call to sched_smt_active() leaves .noinstr.text section Fixes: 321a874a7ef8 ("sched/smt: Expose sched_smt_present static key") Reported-by: kernel test robot Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Cc: Linus Torvalds Link: https://lore.kernel.org/r/1d03907b0a247cf7fb5c1d518de378864f603060.1743481539.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/r/202503311434.lyw2Tveh-lkp@intel.com/ Signed-off-by: Sasha Levin commit ffb8e7f715c4761774730b6efba2c113ec8b5da0 Author: David Laight Date: Mon Mar 31 21:26:42 2025 -0700 objtool: Fix verbose disassembly if CROSS_COMPILE isn't set [ Upstream commit e77956e4e5c11218e60a1fe8cdbccd02476f2e56 ] In verbose mode, when printing the disassembly of affected functions, if CROSS_COMPILE isn't set, the objdump command string gets prefixed with "(null)". Somehow this worked before. Maybe some versions of glibc return an empty string instead of NULL. Fix it regardless. [ jpoimboe: Rewrite commit log. ] Fixes: ca653464dd097 ("objtool: Add verbose option for disassembling affected functions") Signed-off-by: David Laight Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Cc: Linus Torvalds Link: https://lore.kernel.org/r/20250215142321.14081-1-david.laight.linux@gmail.com Link: https://lore.kernel.org/r/b931a4786bc0127aa4c94e8b35ed617dcbd3d3da.1743481539.git.jpoimboe@kernel.org Signed-off-by: Sasha Levin commit 9cd3b09d02fd59f015e16dc05a3eb25157487c96 Author: Geetha sowjanya Date: Thu Mar 27 15:10:54 2025 +0530 octeontx2-af: Free NIX_AF_INT_VEC_GEN irq [ Upstream commit 323d6db6dc7decb06f2545efb9496259ddacd4f4 ] Due to the incorrect initial vector number in rvu_nix_unregister_interrupts(), NIX_AF_INT_VEC_GEN is not geeting free. Fix the vector number to include NIX_AF_INT_VEC_GEN irq. Fixes: 5ed66306eab6 ("octeontx2-af: Add devlink health reporters for NIX") Signed-off-by: Geetha sowjanya Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250327094054.2312-1-gakula@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1db84e8917d231875cfc1001abed8ab935753638 Author: Geetha sowjanya Date: Thu Mar 27 14:44:41 2025 +0530 octeontx2-af: Fix mbox INTR handler when num VFs > 64 [ Upstream commit 0fdba88a211508984eb5df62008c29688692b134 ] When number of RVU VFs > 64, the vfs value passed to "rvu_queue_work" function is incorrect. Due to which mbox workqueue entries for VFs 0 to 63 never gets added to workqueue. Fixes: 9bdc47a6e328 ("octeontx2-af: Mbox communication support btw AF and it's VFs") Signed-off-by: Geetha sowjanya Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250327091441.1284-1-gakula@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4c0dc3b62cdb062679b21d5c4234798db0ca8f94 Author: Jim Liu Date: Thu Mar 27 14:29:42 2025 +0800 net: phy: broadcom: Correct BCM5221 PHY model detection [ Upstream commit 4f1eaabb4b66a1f7473f584e14e15b2ac19dfaf3 ] Correct detect condition is applied to the entire 5221 family of PHYs. Fixes: 3abbd0699b67 ("net: phy: broadcom: add support for BCM5221 phy") Signed-off-by: Jim Liu Reviewed-by: Michal Swiatkowski Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 315a33a6f944fefd750e3f117da32f47a621fda8 Author: Giovanni Gherdovich Date: Fri Mar 28 15:30:39 2025 +0100 ACPI: processor: idle: Return an error if both P_LVL{2,3} idle states are invalid [ Upstream commit 9e9b893404d43894d69a18dd2fc8fcf1c36abb7e ] Prior to commit 496121c02127 ("ACPI: processor: idle: Allow probing on platforms with one ACPI C-state"), the acpi_idle driver wouldn't load on systems without a valid C-State at least as deep as C2. The behavior was desirable for guests on hypervisors such as VMWare ESXi, which by default don't have the _CST ACPI method, and set the C2 and C3 latencies to 101 and 1001 microseconds respectively via the FADT, to signify they're unsupported. Since the above change though, these virtualized deployments end up loading acpi_idle, and thus entering the default C1 C-State set by acpi_processor_get_power_info_default(); this is undesirable for a system that's communicating to the OS it doesn't want C-States (missing _CST, and invalid C2/C3 in FADT). Make acpi_processor_get_power_info_fadt() return -ENODEV in that case, so that acpi_processor_get_cstate_info() exits early and doesn't set pr->flags.power = 1. Fixes: 496121c02127 ("ACPI: processor: idle: Allow probing on platforms with one ACPI C-state") Signed-off-by: Giovanni Gherdovich Reviewed-by: Zhang Rui Link: https://patch.msgid.link/20250328143040.9348-1-ggherdovich@suse.cz [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 6f57d40ab02b690cd48a5129902a0b95e65e2a26 Author: Yuli Wang Date: Sun Mar 30 16:31:09 2025 +0800 LoongArch: Rework the arch_kgdb_breakpoint() implementation [ Upstream commit 29c92a41c6d2879c1f62220fe4758dce191bb38f ] The arch_kgdb_breakpoint() function defines the kgdb_breakinst symbol using inline assembly. 1. There's a potential issue where the compiler might inline arch_kgdb_breakpoint(), which would then define the kgdb_breakinst symbol multiple times, leading to a linker error. To prevent this, declare arch_kgdb_breakpoint() as noinline. Fix follow error with LLVM-19 *only* when LTO_CLANG_FULL: LD vmlinux.o ld.lld-19: error: ld-temp.o :3:1: symbol 'kgdb_breakinst' is already defined kgdb_breakinst: break 2 ^ 2. Remove "nop" in the inline assembly because it's meaningless for LoongArch here. 3. Add "STACK_FRAME_NON_STANDARD" for arch_kgdb_breakpoint() to avoid the objtool warning. Fixes: e14dd076964e ("LoongArch: Add basic KGDB & KDB support") Tested-by: Binbin Zhou Co-developed-by: Winston Wen Signed-off-by: Winston Wen Co-developed-by: Wentao Guan Signed-off-by: Wentao Guan Signed-off-by: Yuli Wang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 495b847e1b2e3ab08ed18be1bc66260226c4a7af Author: Miaoqian Lin Date: Sun Mar 30 16:31:09 2025 +0800 LoongArch: Fix device node refcount leak in fdt_cpu_clk_init() [ Upstream commit 2e3bc71e4f394ecf8f499d21923cf556b4bfa1e7 ] Add missing of_node_put() to properly handle the reference count of the device node obtained from of_get_cpu_node(). Fixes: 44a01f1f726a ("LoongArch: Parsing CPU-related information from DTS") Signed-off-by: Miaoqian Lin Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit e9967da7feb3308366f8074a3736aaf67f79d221 Author: 谢致邦 (XIE Zhibang) Date: Sun Mar 30 16:31:09 2025 +0800 LoongArch: Fix help text of CMDLINE_EXTEND in Kconfig [ Upstream commit be216cbc1ddf99a51915414ce147311c0dfd50a2 ] It is the built-in command line appended to the bootloader command line, not the bootloader command line appended to the built-in command line. Fixes: fa96b57c1490 ("LoongArch: Add build infrastructure") Signed-off-by: 谢致邦 (XIE Zhibang) Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 556b6ccf0b9dbac2d5b4676cdcb4ba8567b44b0b Author: Josh Poimboeuf Date: Thu Mar 27 22:04:21 2025 -0700 objtool: Fix segfault in ignore_unreachable_insn() [ Upstream commit 69d41d6dafff0967565b971d950bd10443e4076c ] Check 'prev_insn' before dereferencing it. Fixes: bd841d6154f5 ("objtool: Fix CONFIG_UBSAN_TRAP unreachable warnings") Reported-by: Arnd Bergmann Reported-by: Ingo Molnar Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/5df4ff89c9e4b9e788b77b0531234ffa7ba03e9e.1743136205.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/d86b4cc6-0b97-4095-8793-a7384410b8ab@app.fastmail.com Closes: https://lore.kernel.org/Z-V_rruKY0-36pqA@gmail.com Signed-off-by: Sasha Levin commit 013a605afc902046772a6b1cef49e87b9377d095 Author: Feng Yang Date: Sun Feb 23 15:01:06 2025 +0800 ring-buffer: Fix bytes_dropped calculation issue [ Upstream commit c73f0b69648501978e8b3e8fa7eef7f4197d0481 ] The calculation of bytes-dropped and bytes_dropped_nested is reversed. Although it does not affect the final calculation of total_dropped, it should still be modified. Link: https://lore.kernel.org/20250223070106.6781-1-yangfeng59949@163.com Fixes: 6c43e554a2a5 ("ring-buffer: Add ring buffer startup selftest") Signed-off-by: Feng Yang Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit fdce289839ba34efcba65cda4f22fb11359988cc Author: Lama Kayal Date: Sun Mar 23 14:28:26 2025 +0200 net/mlx5e: SHAMPO, Make reserved size independent of page size [ Upstream commit fab05835688526f9de123d1e98e4d1f838da4e22 ] When hw-gro is enabled, the maximum number of header entries that are needed per wqe (hd_per_wqe) is calculated based on the size of the reservations among other parameters. Miscalculation of the size of reservations leads to incorrect calculation of hd_per_wqe as 0, particularly in the case of large page size like in aarch64, this prevents the SHAMPO header from being correctly initialized in the device, ultimately causing the following cqe err that indicates a violation of PD. mlx5_core 0000:00:08.0 eth2: ERR CQE on RQ: 0x1180 mlx5_core 0000:00:08.0 eth2: Error cqe on cqn 0x510, ci 0x0, qn 0x1180, opcode 0xe, syndrome 0x4, vendor syndrome 0x32 00000000: 00 00 00 00 04 4a 00 00 00 00 00 00 20 00 93 32 00000010: 55 00 00 00 fb cc 00 00 00 00 00 00 07 18 00 00 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4a 00000030: 00 00 00 9a 93 00 32 04 00 00 00 00 00 00 da e1 Use the correct formula for calculating the size of reservations, precisely it shouldn't be dependent on page size, instead use the correct multiply of MLX5E_SHAMPO_WQ_BASE_RESRV_SIZE. Fixes: e5ca8fb08ab2 ("net/mlx5e: Add control path for SHAMPO feature") Signed-off-by: Lama Kayal Reviewed-by: Dragos Tatulea Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/1742732906-166564-1-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c2ec33d46b4d1c8085dab5d02e00b21f4f0fb8a9 Author: Namjae Jeon Date: Tue Mar 25 00:00:24 2025 +0900 ksmbd: fix r_count dec/increment mismatch [ Upstream commit ddb7ea36ba7129c2ed107e2186591128618864e1 ] r_count is only increased when there is an oplock break wait, so r_count inc/decrement are not paired. This can cause r_count to become negative, which can lead to a problem where the ksmbd thread does not terminate. Fixes: 3aa660c05924 ("ksmbd: prevent connection release during oplock break notification") Reported-by: Norbert Szetei Tested-by: Norbert Szetei Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 336d351af3acdf3688ace5f29cfdc8b862dbeeb8 Author: Namjae Jeon Date: Mon Mar 24 20:19:20 2025 +0900 ksmbd: fix multichannel connection failure [ Upstream commit c1883049aa9b2b7dffd3a68c5fc67fa92c174bd9 ] ksmbd check that the session of second channel is in the session list of first connection. If it is in session list, multichannel connection should not be allowed. Fixes: b95629435b84 ("ksmbd: fix racy issue from session lookup and expire") Reported-by: Sean Heelan Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 46caeae23035192b9cc41872c827f30d0233f16e Author: Miaoqian Lin Date: Tue Mar 18 20:12:34 2025 +0800 ksmbd: use aead_request_free to match aead_request_alloc [ Upstream commit 6171063e9d046ffa46f51579b2ca4a43caef581a ] Use aead_request_free() instead of kfree() to properly free memory allocated by aead_request_alloc(). This ensures sensitive crypto data is zeroed before being freed. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Signed-off-by: Miaoqian Lin Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit d34963d968a6e5f5f98ceecc987fc9f221f1cac7 Author: Lubomir Rintel Date: Tue Mar 25 10:58:41 2025 +0100 rndis_host: Flag RNDIS modems as WWAN devices [ Upstream commit 67d1a8956d2d62fe6b4c13ebabb57806098511d8 ] Set FLAG_WWAN instead of FLAG_ETHERNET for RNDIS interfaces on Mobile Broadband Modems, as opposed to regular Ethernet adapters. Otherwise NetworkManager gets confused, misjudges the device type, and wouldn't know it should connect a modem to get the device to work. What would be the result depends on ModemManager version -- older ModemManager would end up disconnecting a device after an unsuccessful probe attempt (if it connected without needing to unlock a SIM), while a newer one might spawn a separate PPP connection over a tty interface instead, resulting in a general confusion and no end of chaos. The only way to get this work reliably is to fix the device type and have good enough version ModemManager (or equivalent). Fixes: 63ba395cd7a5 ("rndis_host: support Novatel Verizon USB730L") Signed-off-by: Lubomir Rintel Link: https://patch.msgid.link/20250325095842.1567999-1-lkundrak@v3.sk Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5f39454468329bb7fc7fc4895a6ba6ae3b95027e Author: Mark Zhang Date: Tue Mar 25 11:02:26 2025 +0200 rtnetlink: Allocate vfinfo size for VF GUIDs when supported [ Upstream commit 23f00807619d15063d676218f36c5dfeda1eb420 ] Commit 30aad41721e0 ("net/core: Add support for getting VF GUIDs") added support for getting VF port and node GUIDs in netlink ifinfo messages, but their size was not taken into consideration in the function that allocates the netlink message, causing the following warning when a netlink message is filled with many VF port and node GUIDs: # echo 64 > /sys/bus/pci/devices/0000\:08\:00.0/sriov_numvfs # ip link show dev ib0 RTNETLINK answers: Message too long Cannot send link get request: Message too long Kernel warning: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 1930 at net/core/rtnetlink.c:4151 rtnl_getlink+0x586/0x5a0 Modules linked in: xt_conntrack xt_MASQUERADE nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay mlx5_ib macsec mlx5_core tls rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm iw_cm ib_ipoib fuse ib_cm ib_core CPU: 2 UID: 0 PID: 1930 Comm: ip Not tainted 6.14.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:rtnl_getlink+0x586/0x5a0 Code: cb 82 e8 3d af 0a 00 4d 85 ff 0f 84 08 ff ff ff 4c 89 ff 41 be ea ff ff ff e8 66 63 5b ff 49 c7 07 80 4f cb 82 e9 36 fc ff ff <0f> 0b e9 16 fe ff ff e8 de a0 56 00 66 66 2e 0f 1f 84 00 00 00 00 RSP: 0018:ffff888113557348 EFLAGS: 00010246 RAX: 00000000ffffffa6 RBX: ffff88817e87aa34 RCX: dffffc0000000000 RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffff88817e87afb8 RBP: 0000000000000009 R08: ffffffff821f44aa R09: 0000000000000000 R10: ffff8881260f79a8 R11: ffff88817e87af00 R12: ffff88817e87aa00 R13: ffffffff8563d300 R14: 00000000ffffffa6 R15: 00000000ffffffff FS: 00007f63a5dbf280(0000) GS:ffff88881ee00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f63a5ba4493 CR3: 00000001700fe002 CR4: 0000000000772eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? __warn+0xa5/0x230 ? rtnl_getlink+0x586/0x5a0 ? report_bug+0x22d/0x240 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x14/0x50 ? asm_exc_invalid_op+0x16/0x20 ? skb_trim+0x6a/0x80 ? rtnl_getlink+0x586/0x5a0 ? __pfx_rtnl_getlink+0x10/0x10 ? rtnetlink_rcv_msg+0x1e5/0x860 ? __pfx___mutex_lock+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? __pfx_lock_acquire+0x10/0x10 ? stack_trace_save+0x90/0xd0 ? filter_irq_stacks+0x1d/0x70 ? kasan_save_stack+0x30/0x40 ? kasan_save_stack+0x20/0x40 ? kasan_save_track+0x10/0x30 rtnetlink_rcv_msg+0x21c/0x860 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? arch_stack_walk+0x9e/0xf0 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 ? rcu_is_watching+0x34/0x60 netlink_rcv_skb+0xe0/0x210 ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? __pfx_netlink_rcv_skb+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? __pfx___netlink_lookup+0x10/0x10 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0xfd/0x290 ? rcu_is_watching+0x34/0x60 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0x95/0x290 netlink_unicast+0x31f/0x480 ? __pfx_netlink_unicast+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 netlink_sendmsg+0x369/0x660 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 ? import_ubuf+0xb9/0xf0 ? __import_iovec+0x254/0x2b0 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 ____sys_sendmsg+0x559/0x5a0 ? __pfx_____sys_sendmsg+0x10/0x10 ? __pfx_copy_msghdr_from_user+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? do_read_fault+0x213/0x4a0 ? rcu_is_watching+0x34/0x60 ___sys_sendmsg+0xe4/0x150 ? __pfx____sys_sendmsg+0x10/0x10 ? do_fault+0x2cc/0x6f0 ? handle_pte_fault+0x2e3/0x3d0 ? __pfx_handle_pte_fault+0x10/0x10 ? preempt_count_sub+0x14/0xc0 ? __down_read_trylock+0x150/0x270 ? __handle_mm_fault+0x404/0x8e0 ? __pfx___handle_mm_fault+0x10/0x10 ? lock_release+0x62/0x200 ? __rcu_read_unlock+0x65/0x90 ? rcu_is_watching+0x34/0x60 __sys_sendmsg+0xd5/0x150 ? __pfx___sys_sendmsg+0x10/0x10 ? __up_read+0x192/0x480 ? lock_release+0x62/0x200 ? __rcu_read_unlock+0x65/0x90 ? rcu_is_watching+0x34/0x60 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f63a5b13367 Code: 0e 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10 RSP: 002b:00007fff8c726bc8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000067b687c2 RCX: 00007f63a5b13367 RDX: 0000000000000000 RSI: 00007fff8c726c30 RDI: 0000000000000004 RBP: 00007fff8c726cb8 R08: 0000000000000000 R09: 0000000000000034 R10: 00007fff8c726c7c R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000000 R14: 00007fff8c726cd0 R15: 00007fff8c726cd0 irq event stamp: 0 hardirqs last enabled at (0): [<0000000000000000>] 0x0 hardirqs last disabled at (0): [] copy_process+0xd08/0x2830 softirqs last enabled at (0): [] copy_process+0xd08/0x2830 softirqs last disabled at (0): [<0000000000000000>] 0x0 ---[ end trace 0000000000000000 ]--- Thus, when calculating ifinfo message size, take VF GUIDs sizes into account when supported. Fixes: 30aad41721e0 ("net/core: Add support for getting VF GUIDs") Signed-off-by: Mark Zhang Reviewed-by: Maher Sanalla Signed-off-by: Mark Bloch Reviewed-by: Sabrina Dubroca Link: https://patch.msgid.link/20250325090226.749730-1-mbloch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 539147585ca453db6e3d7a5cf3b9c9690513762d Author: Yuezhang Mo Date: Thu Mar 6 15:02:07 2025 +0800 exfat: fix missing shutdown check [ Upstream commit 47e35366bc6fa3cf189a8305bce63992495f3efa ] xfstests generic/730 test failed because after deleting the device that still had dirty data, the file could still be read without returning an error. The reason is the missing shutdown check in ->read_iter. I also noticed that shutdown checks were missing from ->write_iter, ->splice_read, and ->mmap. This commit adds shutdown checks to all of them. Fixes: f761fcdd289d ("exfat: Implement sops->shutdown and ioctl") Signed-off-by: Yuezhang Mo Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 081242d2cebf427b965953e73a181c7f9f4c096e Author: Yuezhang Mo Date: Mon Mar 17 10:53:10 2025 +0800 exfat: fix the infinite loop in exfat_find_last_cluster() [ Upstream commit b0522303f67255926b946aa66885a0104d1b2980 ] In exfat_find_last_cluster(), the cluster chain is traversed until the EOF cluster. If the cluster chain includes a loop due to file system corruption, the EOF cluster cannot be traversed, resulting in an infinite loop. If the number of clusters indicated by the file size is inconsistent with the cluster chain length, exfat_find_last_cluster() will return an error, so if this inconsistency is found, the traversal can be aborted without traversing to the EOF cluster. Reported-by: syzbot+f7d147e6db52b1e09dba@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f7d147e6db52b1e09dba Tested-by: syzbot+f7d147e6db52b1e09dba@syzkaller.appspotmail.com Fixes: 31023864e67a ("exfat: add fat entry operations") Signed-off-by: Yuezhang Mo Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 476617a4ca0123f0df677d547a82a110c27c8c74 Author: Wang Zhaolong Date: Tue Feb 18 22:30:05 2025 +0800 smb: client: Fix netns refcount imbalance causing leaks and use-after-free [ Upstream commit 4e7f1644f2ac6d01dc584f6301c3b1d5aac4eaef ] Commit ef7134c7fc48 ("smb: client: Fix use-after-free of network namespace.") attempted to fix a netns use-after-free issue by manually adjusting reference counts via sk->sk_net_refcnt and sock_inuse_add(). However, a later commit e9f2517a3e18 ("smb: client: fix TCP timers deadlock after rmmod") pointed out that the approach of manually setting sk->sk_net_refcnt in the first commit was technically incorrect, as sk->sk_net_refcnt should only be set for user sockets. It led to issues like TCP timers not being cleared properly on close. The second commit moved to a model of just holding an extra netns reference for server->ssocket using get_net(), and dropping it when the server is torn down. But there remain some gaps in the get_net()/put_net() balancing added by these commits. The incomplete reference handling in these fixes results in two issues: 1. Netns refcount leaks[1] The problem process is as follows: ``` mount.cifs cifsd cifs_do_mount cifs_mount cifs_mount_get_session cifs_get_tcp_session get_net() /* First get net. */ ip_connect generic_ip_connect /* Try port 445 */ get_net() ->connect() /* Failed */ put_net() generic_ip_connect /* Try port 139 */ get_net() /* Missing matching put_net() for this get_net().*/ cifs_get_smb_ses cifs_negotiate_protocol smb2_negotiate SMB2_negotiate cifs_send_recv wait_for_response cifs_demultiplex_thread cifs_read_from_socket cifs_readv_from_socket cifs_reconnect cifs_abort_connection sock_release(); server->ssocket = NULL; /* Missing put_net() here. */ generic_ip_connect get_net() ->connect() /* Failed */ put_net() sock_release(); server->ssocket = NULL; free_rsp_buf ... clean_demultiplex_info /* It's only called once here. */ put_net() ``` When cifs_reconnect() is triggered, the server->ssocket is released without a corresponding put_net() for the reference acquired in generic_ip_connect() before. it ends up calling generic_ip_connect() again to retry get_net(). After that, server->ssocket is set to NULL in the error path of generic_ip_connect(), and the net count cannot be released in the final clean_demultiplex_info() function. 2. Potential use-after-free The current refcounting scheme can lead to a potential use-after-free issue in the following scenario: ``` cifs_do_mount cifs_mount cifs_mount_get_session cifs_get_tcp_session get_net() /* First get net */ ip_connect generic_ip_connect get_net() bind_socket kernel_bind /* failed */ put_net() /* after out_err_crypto_release label */ put_net() /* after out_err label */ put_net() ``` In the exception handling process where binding the socket fails, the get_net() and put_net() calls are unbalanced, which may cause the server->net reference count to drop to zero and be prematurely released. To address both issues, this patch ties the netns reference counting to the server->ssocket and server lifecycles. The extra reference is now acquired when the server or socket is created, and released when the socket is destroyed or the server is torn down. [1]: https://bugzilla.kernel.org/show_bug.cgi?id=219792 Fixes: ef7134c7fc48 ("smb: client: Fix use-after-free of network namespace.") Fixes: e9f2517a3e18 ("smb: client: fix TCP timers deadlock after rmmod") Signed-off-by: Wang Zhaolong Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 03929bfa701044713d185b07a12af40d7122df5c Author: Trond Myklebust Date: Tue Mar 25 17:58:50 2025 -0400 NFS: Shut down the nfs_client only after all the superblocks [ Upstream commit 2d3e998a0bc7fe26a724f87a8ce217848040520e ] The nfs_client manages state for all the superblocks in the "cl_superblocks" list, so it must not be shut down until all of them are gone. Fixes: 7d3e26a054c8 ("NFS: Cancel all existing RPC tasks when shutdown") Reviewed-by: Benjamin Coddington Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 6cfe46036b163e5a0f07c6b705b518148e1a8b2f Author: Josh Poimboeuf Date: Mon Mar 24 14:56:06 2025 -0700 objtool, media: dib8000: Prevent divide-by-zero in dib8000_set_dds() [ Upstream commit e63d465f59011dede0a0f1d21718b59a64c3ff5c ] If dib8000_set_dds()'s call to dib8000_read32() returns zero, the result is a divide-by-zero. Prevent that from happening. Fixes the following warning with an UBSAN kernel: drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_tune() falls through to next function dib8096p_cfg_DibRx() Fixes: 173a64cb3fcf ("[media] dib8000: enhancement") Reported-by: kernel test robot Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Cc: Mauro Carvalho Chehab Cc: Linus Torvalds Link: https://lore.kernel.org/r/bd1d504d930ae3f073b1e071bcf62cae7708773c.1742852847.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/r/202503210602.fvH5DO1i-lkp@intel.com/ Signed-off-by: Sasha Levin commit 0cc0efc58d6c741b2868d4af24874d7fec28a575 Author: Josh Poimboeuf Date: Mon Mar 24 14:56:05 2025 -0700 objtool, nvmet: Fix out-of-bounds stack access in nvmet_ctrl_state_show() [ Upstream commit 107a23185d990e3df6638d9a84c835f963fe30a6 ] The csts_state_names[] array only has six sparse entries, but the iteration code in nvmet_ctrl_state_show() iterates seven, resulting in a potential out-of-bounds stack read. Fix that. Fixes the following warning with an UBSAN kernel: vmlinux.o: warning: objtool: .text.nvmet_ctrl_state_show: unexpected end of section Fixes: 649fd41420a8 ("nvmet: add debugfs support") Reported-by: kernel test robot Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Cc: Christoph Hellwig Cc: Sagi Grimberg Cc: Chaitanya Kulkarni Cc: Linus Torvalds Link: https://lore.kernel.org/r/f1f60858ee7a941863dc7f5506c540cb9f97b5f6.1742852847.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/oe-kbuild-all/202503171547.LlCTJLQL-lkp@intel.com/ Signed-off-by: Sasha Levin commit 7f2c746e09a3746bf937bc708129dc8af61d8f19 Author: Josh Poimboeuf Date: Mon Mar 24 14:56:04 2025 -0700 objtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq() [ Upstream commit 76e51db43fe4aaaebcc5ddda67b0807f7c9bdecc ] If speed_hz < AMD_SPI_MIN_HZ, amd_set_spi_freq() iterates over the entire amd_spi_freq array without breaking out early, causing 'i' to go beyond the array bounds. Fix that by stopping the loop when it gets to the last entry, so the low speed_hz value gets clamped up to AMD_SPI_MIN_HZ. Fixes the following warning with an UBSAN kernel: drivers/spi/spi-amd.o: error: objtool: amd_set_spi_freq() falls through to next function amd_spi_set_opcode() Fixes: 3fe26121dc3a ("spi: amd: Configure device speed") Reported-by: kernel test robot Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Acked-by: Mark Brown Cc: Raju Rangoju Cc: Linus Torvalds Link: https://lore.kernel.org/r/78fef0f2434f35be9095bcc9ffa23dd8cab667b9.1742852847.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/r/202503161828.RUk9EhWx-lkp@intel.com/ Signed-off-by: Sasha Levin commit 0a5f3815e13a4fc7a3883708b8417553f35a28f6 Author: xueqin Luo Date: Thu Feb 6 16:14:36 2025 +0800 thermal: core: Remove duplicate struct declaration [ Upstream commit 9e6ec8cf64e2973f0ec74f09023988cabd218426 ] The struct thermal_zone_device is already declared on line 32, so the duplicate declaration has been removed. Fixes: b1ae92dcfa8e ("thermal: core: Make struct thermal_zone_device definition internal") Signed-off-by: xueqin Luo Link: https://lore.kernel.org/r/20250206081436.51785-1-luoxueqin@kylinos.cn Signed-off-by: Daniel Lezcano Signed-off-by: Sasha Levin commit 88e923d140fa77cad6d5d6ea44d6fa6b55c59d7b Author: Josh Poimboeuf Date: Mon Mar 24 14:55:51 2025 -0700 objtool: Fix detection of consecutive jump tables on Clang 20 [ Upstream commit ef753d66051ca03bee1982ce047f9eaf90f81ab4 ] The jump table detection code assumes jump tables are in the same order as their corresponding indirect branches. That's apparently not always true with Clang 20. Fix that by changing how multiple jump tables are detected. In the first detection pass, mark the beginning of each jump table so the second pass can tell where one ends and the next one begins. Fixes the following warnings: vmlinux.o: warning: objtool: SiS_GetCRT2Ptr+0x1ad: stack state mismatch: cfa1=4+8 cfa2=5+16 sound/core/seq/snd-seq.o: warning: objtool: cc_ev_to_ump_midi2+0x589: return with modified stack frame Fixes: be2f0b1e1264 ("objtool: Get rid of reloc->jump_table_start") Reported-by: kernel test robot Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Cc: Nathan Chancellor Cc: Nick Desaulniers Cc: Linus Torvalds Link: https://lore.kernel.org/r/141752fff614eab962dba6bdfaa54aa67ff03bba.1742852846.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/oe-kbuild-all/202503171547.LlCTJLQL-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202503200535.J3hAvcjw-lkp@intel.com/ Signed-off-by: Sasha Levin commit a7a8e0ccaf730b25b36d63bd4260307e99c5cda8 Author: Tiezhu Yang Date: Tue Feb 11 19:50:12 2025 +0800 objtool: Handle PC relative relocation type [ Upstream commit c4b93b06230ae49870187189d9f7342f6ad4f14e ] For the most part, an absolute relocation type is used for rodata. In the case of STT_SECTION, reloc->sym->offset is always zero, for the other symbol types, reloc_addend(reloc) is always zero, thus it can use a simple statement "reloc->sym->offset + reloc_addend(reloc)" to obtain the symbol offset for various symbol types. When compiling on LoongArch, there exist PC relative relocation types for rodata, it needs to calculate the symbol offset with "S + A - PC" according to the spec of "ELF for the LoongArch Architecture". If there is only one jump table in the rodata, the "PC" is the entry address which is equal with the value of reloc_offset(reloc), at this time, reloc_offset(table) is 0. If there are many jump tables in the rodata, the "PC" is the offset of the jump table's base address which is equal with the value of reloc_offset(reloc) - reloc_offset(table). So for LoongArch, if the relocation type is PC relative, it can use a statement "reloc_offset(reloc) - reloc_offset(table)" to get the "PC" value when calculating the symbol offset with "S + A - PC" for one or many jump tables in the rodata. Add an arch-specific function arch_jump_table_sym_offset() to assign the symbol offset, for the most part that is an absolute relocation, the default value is "reloc->sym->offset + reloc_addend(reloc)" in the weak definition, it can be overridden by each architecture that has different requirements. Link: https://github.com/loongson/la-abi-specs/blob/release/laelf.adoc Signed-off-by: Tiezhu Yang Link: https://lore.kernel.org/r/20250211115016.26913-4-yangtiezhu@loongson.cn Acked-by: Huacai Chen Signed-off-by: Josh Poimboeuf Stable-dep-of: ef753d66051c ("objtool: Fix detection of consecutive jump tables on Clang 20") Signed-off-by: Sasha Levin commit 4f47818652684c185210a4c625e757f9e08d2e95 Author: Tiezhu Yang Date: Tue Feb 11 19:50:11 2025 +0800 objtool: Handle different entry size of rodata [ Upstream commit 091bf313f8a852a7f30c3a8dcef569edfd06f5dc ] In the most cases, the entry size of rodata is 8 bytes because the relocation type is 64 bit. There are also 32 bit relocation types, the entry size of rodata should be 4 bytes in this case. Add an arch-specific function arch_reloc_size() to assign the entry size of rodata for x86, powerpc and LoongArch. Signed-off-by: Tiezhu Yang Link: https://lore.kernel.org/r/20250211115016.26913-3-yangtiezhu@loongson.cn Acked-by: Huacai Chen Signed-off-by: Josh Poimboeuf Stable-dep-of: ef753d66051c ("objtool: Fix detection of consecutive jump tables on Clang 20") Signed-off-by: Sasha Levin commit 5c747362c357cd2c91331a0aee28576c8589c688 Author: Tiezhu Yang Date: Tue Feb 11 19:50:10 2025 +0800 objtool: Handle various symbol types of rodata [ Upstream commit ab6ce22b789622ca732e91cbb3a5cb5ba370cbd0 ] In the relocation section ".rela.rodata" of each .o file compiled with LoongArch toolchain, there are various symbol types such as STT_NOTYPE, STT_OBJECT, STT_FUNC in addition to the usual STT_SECTION, it needs to use reloc symbol offset instead of reloc addend to find the destination instruction in find_jump_table() and add_jump_table(). For the most part, an absolute relocation type is used for rodata. In the case of STT_SECTION, reloc->sym->offset is always zero, and for the other symbol types, reloc_addend(reloc) is always zero, thus it can use a simple statement "reloc->sym->offset + reloc_addend(reloc)" to obtain the symbol offset for various symbol types. Signed-off-by: Tiezhu Yang Link: https://lore.kernel.org/r/20250211115016.26913-2-yangtiezhu@loongson.cn Acked-by: Huacai Chen Signed-off-by: Josh Poimboeuf Stable-dep-of: ef753d66051c ("objtool: Fix detection of consecutive jump tables on Clang 20") Signed-off-by: Sasha Levin commit 4dc1f33bfac82af099731fc5b5243340bae2276f Author: Namhyung Kim Date: Fri Mar 7 14:09:21 2025 -0800 perf bpf-filter: Fix a parsing error with comma [ Upstream commit 35d13f841a3d8159ef20d5e32a9ed3faa27875bc ] The previous change to support cgroup filters introduced a bug that pathname can include commas. It confused the lexer to treat an item and the trailing comma as a single token. And it resulted in a parse error: $ sudo perf record -e cycles:P --filter 'period > 0, ip > 64' -- true perf_bpf_filter: Error: Unexpected item: 0, perf_bpf_filter: syntax error, unexpected BFT_ERROR, expecting BFT_NUM Usage: perf record [] [] or: perf record [] -- [] --filter event filter It should get "0" and "," separately. An easiest fix would be to remove "," from the possible pathname characters. As it's for cgroup names, probably ok to assume it won't have commas in the pathname. I found that the existing BPF filtering test didn't have any complex filter condition with commas. Let's update the group filter test which is supposed to test filter combinations like this. Link: https://lore.kernel.org/r/20250307220922.434319-1-namhyung@kernel.org Fixes: 91e88437d5156b20 ("perf bpf-filter: Support filtering on cgroups") Reported-by: Sally Shi Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 2e8251afe2af2d1582a22f27440761d480f14fec Author: Marcus Meissner Date: Sun Mar 23 09:53:45 2025 +0100 perf tools: annotate asm_pure_loop.S [ Upstream commit 9a352a90e88a041f4b26d359493e12a7f5ae1a6a ] Annotate so it is built with non-executable stack. Fixes: 8b97519711c3 ("perf test: Add asm pureloop test tool") Signed-off-by: Marcus Meissner Reviewed-by: Leo Yan Link: https://lore.kernel.org/r/20250323085410.23751-1-meissner@suse.de Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit f1e30175f3581fa6b66ceb8cab33c9977b3e1600 Author: Likhitha Korrapati Date: Fri Mar 21 15:37:26 2025 +0530 perf tools: Fix is_compat_mode build break in ppc64 [ Upstream commit 7e442be7015af524d2b5fb84f0ff04a44501542b ] Commit 54f9aa1092457 ("tools/perf/powerpc/util: Add support to handle compatible mode PVR for perf json events") introduced to select proper JSON events in case of compat mode using auxiliary vector. But this caused a compilation error in ppc64 Big Endian. arch/powerpc/util/header.c: In function 'is_compat_mode': arch/powerpc/util/header.c:20:21: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] 20 | if (!strcmp((char *)platform, (char *)base_platform)) | ^ arch/powerpc/util/header.c:20:39: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] 20 | if (!strcmp((char *)platform, (char *)base_platform)) | Commit saved the getauxval(AT_BASE_PLATFORM) and getauxval(AT_PLATFORM) return values in u64 which causes the compilation error. Patch fixes this issue by changing u64 to "unsigned long". Fixes: 54f9aa1092457 ("tools/perf/powerpc/util: Add support to handle compatible mode PVR for perf json events") Signed-off-by: Likhitha Korrapati Reviewed-by: Athira Rajeev Link: https://lore.kernel.org/r/20250321100726.699956-1-likhitha@linux.ibm.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 101cbee41be8e4cc05fb801f312e2c376db218f7 Author: Bart Van Assche Date: Wed Mar 19 14:02:22 2025 -0700 fs/procfs: fix the comment above proc_pid_wchan() [ Upstream commit 6287fbad1cd91f0c25cdc3a580499060828a8f30 ] proc_pid_wchan() used to report kernel addresses to user space but that is no longer the case today. Bring the comment above proc_pid_wchan() in sync with the implementation. Link: https://lkml.kernel.org/r/20250319210222.1518771-1-bvanassche@acm.org Fixes: b2f73922d119 ("fs/proc, core/debug: Don't expose absolute kernel addresses via wchan") Signed-off-by: Bart Van Assche Cc: Kees Cook Cc: Eric W. Biederman Cc: Alexey Dobriyan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit c4a645c4654513b107b6e274dc1049f929aa3bf4 Author: Ilkka Koskinen Date: Thu Mar 13 20:15:59 2025 +0000 perf vendor events arm64 AmpereOneX: Fix frontend_bound calculation [ Upstream commit 182f12f3193341c3400ae719a34c00a8a1204cff ] frontend_bound metrics was miscalculated due to different scaling in a couple of metrics it depends on. Change the scaling to match with AmpereOne. Fixes: 16438b652b46 ("perf vendor events arm64 AmpereOneX: Add core PMU events and metrics") Signed-off-by: Ilkka Koskinen Reviewed-by: James Clark Link: https://lore.kernel.org/r/20250313201559.11332-3-ilkka@os.amperecomputing.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 2870a978e8155f33cff92181016ed2a9a6e4ed09 Author: Jiri Slaby (SUSE) Date: Mon Mar 17 08:00:20 2025 +0100 tty: n_tty: use uint for space returned by tty_write_room() [ Upstream commit d97aa066678bd1e2951ee93db9690835dfe57ab6 ] tty_write_room() returns an "unsigned int". So in case some insane driver (like my tty test driver) returns (legitimate) UINT_MAX from its tty_operations::write_room(), n_tty is confused on several places. For example, in process_output_block(), the result of tty_write_room() is stored into (signed) "int". So this UINT_MAX suddenly becomes -1. And that is extended to ssize_t and returned from process_output_block(). This causes a write() to such a node to receive -EPERM (which is -1). Fix that by using proper "unsigned int" and proper "== 0" test. And return 0 constant directly in that "if", so that it is immediately clear what is returned ("space" equals to 0 at that point). Similarly for process_output() and __process_echoes(). Note this does not fix any in-tree driver as of now. If you want "Fixes: something", it would be commit 03b3b1a2405c ("tty: make tty_operations::write_room return uint"). I intentionally do not mark this patch by a real tag below. Signed-off-by: Jiri Slaby (SUSE) Link: https://lore.kernel.org/r/20250317070046.24386-6-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7f03c02141e6fe934ae0753a8926100769ea1441 Author: Stefan Wahren Date: Sun Mar 9 13:50:12 2025 +0100 staging: vchiq_arm: Stop kthreads if vchiq cdev register fails [ Upstream commit cfb320d990919836b49bd090c6c232c6c4d90b41 ] In case the vchiq character device cannot be registered during probe, all kthreads needs to be stopped to avoid resource leaks. Fixes: 863a756aaf49 ("staging: vc04_services: vchiq_core: Stop kthreads on vchiq module unload") Signed-off-by: Stefan Wahren Link: https://lore.kernel.org/r/20250309125014.37166-4-wahrenst@gmx.net Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit bd38395b901327f77a82112f006240de22cf2ceb Author: Stefan Wahren Date: Sun Mar 9 13:50:11 2025 +0100 staging: vchiq_arm: Fix possible NPR of keep-alive thread [ Upstream commit 3db89bc6d973e2bcaa852f6409c98c228f39a926 ] In case vchiq_platform_conn_state_changed() is never called or fails before driver removal, ka_thread won't be a valid pointer to a task_struct. So do the necessary checks before calling kthread_stop to avoid a crash. Fixes: 863a756aaf49 ("staging: vc04_services: vchiq_core: Stop kthreads on vchiq module unload") Signed-off-by: Stefan Wahren Link: https://lore.kernel.org/r/20250309125014.37166-3-wahrenst@gmx.net Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9fa73a5d79a6e5d6aeecdd6dacf74e65fffe0c5b Author: Stefan Wahren Date: Sun Mar 9 13:50:10 2025 +0100 staging: vchiq_arm: Register debugfs after cdev [ Upstream commit 63f4dbb196db60a8536ba3d1b835d597a83f6cbb ] The commit 2a4d15a4ae98 ("staging: vchiq: Refactor vchiq cdev code") moved the debugfs directory creation before vchiq character device registration. In case the latter fails, the debugfs directory won't be cleaned up. Fixes: 2a4d15a4ae98 ("staging: vchiq: Refactor vchiq cdev code") Signed-off-by: Stefan Wahren Link: https://lore.kernel.org/r/20250309125014.37166-2-wahrenst@gmx.net Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a5521ce10a6dc390889e1afce365ab2d63627388 Author: 谢致邦 (XIE Zhibang) Date: Sat Feb 22 19:36:17 2025 +0000 staging: rtl8723bs: select CONFIG_CRYPTO_LIB_AES [ Upstream commit b2a9a6a26b7e954297e51822e396572026480bad ] This fixes the following issue: ERROR: modpost: "aes_expandkey" [drivers/staging/rtl8723bs/r8723bs.ko] undefined! ERROR: modpost: "aes_encrypt" [drivers/staging/rtl8723bs/r8723bs.ko] undefined! Fixes: 7d40753d8820 ("staging: rtl8723bs: use in-kernel aes encryption in OMAC1 routines") Fixes: 3d3a170f6d80 ("staging: rtl8723bs: use in-kernel aes encryption") Signed-off-by: 谢致邦 (XIE Zhibang) Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/tencent_0BDDF3A721708D16A2E7C3DAFF0FEC79A105@qq.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d70e3e8a38928c3dc0aa605ba8731c3a0071c871 Author: Thomas Richter Date: Wed Mar 19 13:28:20 2025 +0100 perf pmu: Handle memory failure in tool_pmu__new() [ Upstream commit 431db90a7303cb394c5a881b4479946f64052727 ] On linux-next commit 72c6f57a4193 ("perf pmu: Dynamically allocate tool PMU") allocated PMU named "tool" dynamicly. However that allocation can fail and a NULL pointer is returned. That case is currently not handled and would result in an invalid address reference. Add a check for NULL pointer. Fixes: 72c6f57a4193 ("perf pmu: Dynamically allocate tool PMU") Signed-off-by: Thomas Richter Reviewed-by: James Clark Link: https://lore.kernel.org/r/20250319122820.2898333-1-tmricht@linux.ibm.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 3b77fa84b2f2cca1aafc11ca373a6c7009b11f8d Author: James Clark Date: Wed Mar 19 10:16:10 2025 +0000 perf: intel-tpebs: Fix incorrect usage of zfree() [ Upstream commit 6d2dcd635204c023eb5328ad7d38b198a5558c9b ] zfree() requires an address otherwise it frees what's in name, rather than name itself. Pass the address of name to fix it. This was the only incorrect occurrence in Perf found using a search. Fixes: 8db5cabcf1b6 ("perf stat: Fork and launch 'perf record' when 'perf stat' needs to get retire latency value for a metric.") Signed-off-by: James Clark Link: https://lore.kernel.org/r/20250319101614.190922-1-james.clark@linaro.org Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 408065a4db6e0a9daf24af1118fa335db42586a6 Author: Stephen Brennan Date: Tue Mar 18 16:00:11 2025 -0700 perf dso: fix dso__is_kallsyms() check [ Upstream commit ebf0b332732dcc64239119e554faa946562b0b93 ] Kernel modules for which we cannot find a file on-disk will have a dso->long_name that looks like "[module_name]". Prior to the commit listed in the fixes, the dso->kernel field would be zero (for user space), so dso__is_kallsyms() would return false. After the commit, kernel module DSOs are correctly labeled, but the result is that dso__is_kallsyms() erroneously returns true for those modules without a filesystem path. Later, build_id_cache__add() consults this value of is_kallsyms, and when true, it copies /proc/kallsyms into the cache. Users with many kernel modules without a filesystem path (e.g. ksplice or possibly kernel live patch modules) have reported excessive disk space usage in the build ID cache directory due to this behavior. To reproduce the issue, it's enough to build a trivial out-of-tree hello world kernel module, load it using insmod, and then use: perf record -ag -- sleep 1 In the build ID directory, there will be a directory for your module name containing a kallsyms file. Fix this up by changing dso__is_kallsyms() to consult the dso_binary_type enumeration, which is also symmetric to the above checks for dso__is_vmlinux() and dso__is_kcore(). With this change, kallsyms is not cached in the build-id cache for out-of-tree modules. Fixes: 02213cec64bbe ("perf maps: Mark module DSOs with kernel type") Signed-off-by: Stephen Brennan Link: https://lore.kernel.org/r/20250318230012.2038790-1-stephen.s.brennan@oracle.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 9de3f878757e493e4f651a0255d3b31e0e722c95 Author: Arnaldo Carvalho de Melo Date: Wed Mar 12 17:31:41 2025 -0300 perf python: Check if there is space to copy all the event [ Upstream commit 89aaeaf84231157288035b366cb6300c1c6cac64 ] The pyrf_event__new() method copies the event obtained from the perf ring buffer to a structure that will then be turned into a python object for further consumption, so it copies perf_event.header.size bytes to its 'event' member: $ pahole -C pyrf_event /tmp/build/perf-tools-next/python/perf.cpython-312-x86_64-linux-gnu.so struct pyrf_event { PyObject ob_base; /* 0 16 */ struct evsel * evsel; /* 16 8 */ struct perf_sample sample; /* 24 312 */ /* XXX last struct has 7 bytes of padding, 2 holes */ /* --- cacheline 5 boundary (320 bytes) was 16 bytes ago --- */ union perf_event event; /* 336 4168 */ /* size: 4504, cachelines: 71, members: 4 */ /* member types with holes: 1, total: 2 */ /* paddings: 1, sum paddings: 7 */ /* last cacheline: 24 bytes */ }; $ It was doing so without checking if the event just obtained has more than that space, fix it. This isn't a proper, final solution, as we need to support larger events, but for the time being we at least bounds check and document it. Fixes: 877108e42b1b9ba6 ("perf tools: Initial python binding") Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: Ian Rogers Link: https://lore.kernel.org/r/20250312203141.285263-7-acme@kernel.org Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit c7d1cd014452d1145fc068e3edf770fa333d4f7e Author: Arnaldo Carvalho de Melo Date: Wed Mar 12 17:31:40 2025 -0300 perf python: Don't keep a raw_data pointer to consumed ring buffer space [ Upstream commit f3fed3ae34d606819d87a63d970cc3092a5be7ab ] When processing tracepoints the perf python binding was parsing the event before calling perf_mmap__consume(&md->core) in pyrf_evlist__read_on_cpu(). But part of this event parsing was to set the perf_sample->raw_data pointer to the payload of the event, which then could be overwritten by other event before tracepoint fields were asked for via event.prev_comm in a python program, for instance. This also happened with other fields, but strings were were problems were surfacing, as there is UTF-8 validation for the potentially garbled data. This ended up showing up as (with some added debugging messages): ( field 'prev_comm' ret=0x7f7c31f65110, raw_size=68 ) ( field 'prev_pid' ret=0x7f7c23b1bed0, raw_size=68 ) ( field 'prev_prio' ret=0x7f7c239c0030, raw_size=68 ) ( field 'prev_state' ret=0x7f7c239c0250, raw_size=68 ) time 14771421785867 prev_comm= prev_pid=1919907691 prev_prio=796026219 prev_state=0x303a32313175 ==> ( XXX '��' len=16, raw_size=68) ( field 'next_comm' ret=(nil), raw_size=68 ) Traceback (most recent call last): File "/home/acme/git/perf-tools-next/tools/perf/python/tracepoint.py", line 51, in main() File "/home/acme/git/perf-tools-next/tools/perf/python/tracepoint.py", line 46, in main event.next_comm, ^^^^^^^^^^^^^^^ AttributeError: 'perf.sample_event' object has no attribute 'next_comm' When event.next_comm was asked for, the PyUnicode_FromString() python API would fail and that tracepoint field wouldn't be available, stopping the tools/perf/python/tracepoint.py test tool. But, since we already do a copy of the whole event in pyrf_event__new, just use it and while at it remove what was done in in e8968e654191390a ("perf python: Fix pyrf_evlist__read_on_cpu event consuming") because we don't really need to wait for parsing the sample before declaring the event as consumed. This copy is questionable as is now, as it limits the maximum event + sample_type and tracepoint payload to sizeof(union perf_event), this all has been "working" because 'struct perf_event_mmap2', the largest entry in 'union perf_event' is: $ pahole -C perf_event ~/bin/perf | grep mmap2 struct perf_record_mmap2 mmap2; /* 0 4168 */ $ Fixes: bae57e3825a3dded ("perf python: Add support to resolve tracepoint fields") Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: Ian Rogers Link: https://lore.kernel.org/r/20250312203141.285263-6-acme@kernel.org Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 37f4bd24acbb531c4006bc462441d1a18cee03bf Author: Arnaldo Carvalho de Melo Date: Wed Mar 12 17:31:39 2025 -0300 perf python: Decrement the refcount of just created event on failure [ Upstream commit 3de5a2bf5b4847f7a59a184568f969f8fe05d57f ] To avoid a leak if we have the python object but then something happens and we need to return the operation, decrement the offset of the newly created object. Fixes: 377f698db12150a1 ("perf python: Add struct evsel into struct pyrf_event") Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: Ian Rogers Link: https://lore.kernel.org/r/20250312203141.285263-5-acme@kernel.org Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 67f9b6b5ce0037ffdf71388cb867b485a8eab17e Author: Arnaldo Carvalho de Melo Date: Wed Mar 12 17:31:36 2025 -0300 perf python: Fixup description of sample.id event member [ Upstream commit 1376c195e8ad327bb9f2d32e0acc5ac39e7cb30a ] Some old cut'n'paste error, its "ip", so the description should be "event ip", not "event type". Fixes: 877108e42b1b9ba6 ("perf tools: Initial python binding") Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: Ian Rogers Link: https://lore.kernel.org/r/20250312203141.285263-2-acme@kernel.org Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 7fb60dcd9984b53ab34b1796d2d478875b321330 Author: Stanley Chu Date: Tue Mar 18 13:36:04 2025 +0800 i3c: master: svc: Fix missing the IBI rules [ Upstream commit 9cecad134d84d14dc72a0eea7a107691c3e5a837 ] The code does not add IBI rules for devices with controller capability. However, the secondary controller has the controller capability and works at target mode when the device is probed. Therefore, add IBI rules for such devices. Fixes: dd3c52846d59 ("i3c: master: svc: Add Silvaco I3C master driver") Signed-off-by: Stanley Chu Reviewed-by: Frank Li Link: https://lore.kernel.org/r/20250318053606.3087121-2-yschu@nuvoton.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 58e47f64d540c66081a6254b1610b64699914b4e Author: Benjamin Berg Date: Fri Feb 14 10:28:22 2025 +0100 um: hostfs: avoid issues on inode number reuse by host [ Upstream commit 0bc754d1e31f40f4a343b692096d9e092ccc0370 ] Some file systems (e.g. ext4) may reuse inode numbers once the inode is not in use anymore. Usually hostfs will keep an FD open for each inode, but this is not always the case. In the case of sockets, this cannot even be done properly. As such, the following sequence of events was possible: * application creates and deletes a socket * hostfs creates/deletes the socket on the host * inode is still in the hostfs cache * hostfs creates a new file * ext4 on the outside reuses the inode number * hostfs finds the socket inode for the newly created file * application receives -ENXIO when opening the file As mentioned, this can only happen if the deleted file is a special file that is never opened on the host (i.e. no .open fop). As such, to prevent issues, it is sufficient to check that the inode has the expected type. That said, also add a check for the inode birth time, just to be on the safe side. Fixes: 74ce793bcbde ("hostfs: Fix ephemeral inodes") Signed-off-by: Benjamin Berg Reviewed-by: Mickaël Salaün Tested-by: Mickaël Salaün Link: https://patch.msgid.link/20250214092822.1241575-1-benjamin@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit bb758c41bda94cbe73f36aea06f98ad8202e3bd2 Author: Benjamin Berg Date: Mon Feb 10 17:09:26 2025 +0100 um: remove copy_from_kernel_nofault_allowed [ Upstream commit 84a6fc378471fbeaf48f8604566a5a33a3d63c18 ] There is no need to override the default version of this function anymore as UML now has proper _nofault memory access functions. Doing this also fixes the fact that the implementation was incorrect as using mincore() will incorrectly flag pages as inaccessible if they were swapped out by the host. Fixes: f75b1b1bedfb ("um: Implement probe_kernel_read()") Signed-off-by: Benjamin Berg Link: https://patch.msgid.link/20250210160926.420133-3-benjamin@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit ae5bb2f1d09a96c7ccb4397031c42c373b0d3fea Author: David Gow Date: Mon Feb 10 18:53:51 2025 +0800 um: Pass the correct Rust target and options with gcc [ Upstream commit 5550187c4c21740942c32a9ae56f9f472a104cb4 ] In order to work around some issues with disabling SSE on older versions of gcc (compilation would fail upon seeing a function declaration containing a float, even if it was never called or defined), the corresponding CFLAGS and RUSTFLAGS were only set when using clang. However, this led to two problems: - Newer gcc versions also wouldn't get the correct flags, despite not having the bug. - The RUSTFLAGS for setting the rust target definition were not set, despite being unrelated. This works by chance for x86_64, as the built-in default target is close enough, but not for 32-bit x86. Move the target definition outside the conditional block, and update the condition to take into account the gcc version. Fixes: a3046a618a28 ("um: Only disable SSE on clang to work around old GCC bugs") Signed-off-by: David Gow Link: https://patch.msgid.link/20250210105353.2238769-2-davidgow@google.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit d6134179d85be732e794fa62290e1c483e796c91 Author: Cyan Yang Date: Wed Mar 12 12:38:40 2025 +0800 selftests/mm/cow: fix the incorrect error handling [ Upstream commit f841ad9ca5007167c02de143980c9dc703f90b3d ] Error handling doesn't check the correct return value. This patch will fix it. Link: https://lkml.kernel.org/r/20250312043840.71799-1-cyan.yang@sifive.com Fixes: f4b5fd6946e2 ("selftests/vm: anon_cow: THP tests") Signed-off-by: Cyan Yang Reviewed-by: Dev Jain Reviewed-by: Muhammad Usama Anjum Cc: David Hildenbrand Cc: Shuah Khan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit d78e716c8ee06cc6abda52b20438ccd367d06614 Author: Alistair Popple Date: Fri Feb 28 14:30:56 2025 +1100 fuse: fix dax truncate/punch_hole fault path [ Upstream commit 7851bf649d423edd7286b292739f2eefded3d35c ] Patch series "fs/dax: Fix ZONE_DEVICE page reference counts", v9. Device and FS DAX pages have always maintained their own page reference counts without following the normal rules for page reference counting. In particular pages are considered free when the refcount hits one rather than zero and refcounts are not added when mapping the page. Tracking this requires special PTE bits (PTE_DEVMAP) and a secondary mechanism for allowing GUP to hold references on the page (see get_dev_pagemap). However there doesn't seem to be any reason why FS DAX pages need their own reference counting scheme. By treating the refcounts on these pages the same way as normal pages we can remove a lot of special checks. In particular pXd_trans_huge() becomes the same as pXd_leaf(), although I haven't made that change here. It also frees up a valuable SW define PTE bit on architectures that have devmap PTE bits defined. It also almost certainly allows further clean-up of the devmap managed functions, but I have left that as a future improvment. It also enables support for compound ZONE_DEVICE pages which is one of my primary motivators for doing this work. This patch (of 20): FS DAX requires file systems to call into the DAX layout prior to unlinking inodes to ensure there is no ongoing DMA or other remote access to the direct mapped page. The fuse file system implements fuse_dax_break_layouts() to do this which includes a comment indicating that passing dmap_end == 0 leads to unmapping of the whole file. However this is not true - passing dmap_end == 0 will not unmap anything before dmap_start, and further more dax_layout_busy_page_range() will not scan any of the range to see if there maybe ongoing DMA access to the range. Fix this by passing -1 for dmap_end to fuse_dax_break_layouts() which will invalidate the entire file range to dax_layout_busy_page_range(). Link: https://lkml.kernel.org/r/cover.8068ad144a7eea4a813670301f4d2a86a8e68ec4.1740713401.git-series.apopple@nvidia.com Link: https://lkml.kernel.org/r/f09a34b6c40032022e4ddee6fadb7cc676f08867.1740713401.git-series.apopple@nvidia.com Fixes: 6ae330cad6ef ("virtiofs: serialize truncate/punch_hole and dax fault path") Signed-off-by: Alistair Popple Co-developed-by: Dan Williams Signed-off-by: Dan Williams Reviewed-by: Balbir Singh Tested-by: Alison Schofield Cc: Vivek Goyal Cc: Alexander Gordeev Cc: Asahi Lina Cc: Bjorn Helgaas Cc: Catalin Marinas Cc: Christian Borntraeger Cc: Christoph Hellwig Cc: Chunyan Zhang Cc: "Darrick J. Wong" Cc: Dave Chinner Cc: Dave Hansen Cc: Dave Jiang Cc: David Hildenbrand Cc: Gerald Schaefer Cc: Heiko Carstens Cc: Huacai Chen Cc: Ira Weiny Cc: Jan Kara Cc: Jason Gunthorpe Cc: Jason Gunthorpe Cc: John Hubbard Cc: linmiaohe Cc: Logan Gunthorpe Cc: Matthew Wilcow (Oracle) Cc: Michael "Camp Drill Sergeant" Ellerman Cc: Nicholas Piggin Cc: Peter Xu Cc: Sven Schnelle Cc: Ted Ts'o Cc: Vasily Gorbik Cc: Vishal Verma Cc: WANG Xuerui Cc: Will Deacon Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 4332c041da9f2e761403c9f53416fe9c58b18ac7 Author: NeilBrown Date: Wed Dec 4 13:53:09 2024 +1100 NFS: fix open_owner_id_maxsz and related fields. [ Upstream commit 43502f6e8d1e767d6736ea0676cc784025cf6eeb ] A recent change increased the size of an NFSv4 open owner, but didn't increase the corresponding max_sz defines. This is not know to have caused failure, but should be fixed. This patch also fixes some relates _maxsz fields that are wrong. Note that the XXX_owner_id_maxsz values now are only the size of the id and do NOT include the len field that will always preceed the id in xdr encoding. I think this is clearer. Reported-by: David Disseldorp Fixes: d98f72272500 ("nfs: simplify and guarantee owner uniqueness.") Signed-off-by: NeilBrown Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit d86972fd681bb09ee2dd65e0236f39ac48329da0 Author: Trond Myklebust Date: Tue Feb 18 18:37:51 2025 -0500 NFSv4: Avoid unnecessary scans of filesystems for delayed delegations [ Upstream commit e767b59e29b8327d25edde65efc743f479f30d0a ] The amount of looping through the list of delegations is occasionally leading to soft lockups. If the state manager was asked to manage the delayed return of delegations, then only scan those filesystems containing delegations that were marked as being delayed. Fixes: be20037725d1 ("NFSv4: Fix delegation return in cases where we have to retry") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 83006f5a8ca121fc4c7d4bb1906b2588cf03b6cd Author: Trond Myklebust Date: Tue Feb 18 19:03:21 2025 -0500 NFSv4: Avoid unnecessary scans of filesystems for expired delegations [ Upstream commit f163aa81a799e2d46d7f8f0b42a0e7770eaa0d06 ] The amount of looping through the list of delegations is occasionally leading to soft lockups. If the state manager was asked to reap the expired delegations, it should scan only those filesystems that hold delegations that need to be reaped. Fixes: 7f156ef0bf45 ("NFSv4: Clean up nfs_delegation_reap_expired()") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 93e4758362ccc03efb321cc7976cbcf1c7f0e7b1 Author: Trond Myklebust Date: Tue Feb 18 18:14:26 2025 -0500 NFSv4: Avoid unnecessary scans of filesystems for returning delegations [ Upstream commit 35a566a24e58f1b5f89737edf60b77de58719ed0 ] The amount of looping through the list of delegations is occasionally leading to soft lockups. If the state manager was asked to return delegations asynchronously, it should only scan those filesystems that hold delegations that need to be returned. Fixes: af3b61bf6131 ("NFSv4: Clean up nfs_client_return_marked_delegations()") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 6aacf9b556ecffb862f50e752238ac7a7892292e Author: Trond Myklebust Date: Tue Feb 18 16:50:30 2025 -0500 NFSv4: Don't trigger uneccessary scans for return-on-close delegations [ Upstream commit 47acca884f714f41d95dc654f802845544554784 ] The amount of looping through the list of delegations is occasionally leading to soft lockups. Avoid at least some loops by not requiring the NFSv4 state manager to scan for delegations that are marked for return-on-close. Instead, either mark them for immediate return (if possible) or else leave it up to nfs4_inode_return_delegation_on_close() to return them once the file is closed by the application. Fixes: b757144fd77c ("NFSv4: Be less aggressive about returning delegations for open files") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit d7a4462fda88ba6e15fe536add91766dd79f723c Author: Antonio Quartulli Date: Fri Feb 21 21:40:34 2025 +0100 scripts/gdb/linux/symbols.py: address changes to module_sect_attrs [ Upstream commit e0349c46cb4fbbb507fa34476bd70f9c82bad359 ] When loading symbols from kernel modules we used to iterate from 0 to module_sect_attrs::nsections, in order to retrieve their name and address. However module_sect_attrs::nsections has been removed from the struct by a previous commit. Re-arrange the iteration by accessing all items in module_sect_attrs::grp::bin_attrs[] until NULL is found (it's a NULL terminated array). At the same time the symbol address cannot be extracted from module_sect_attrs::attrs[]::address anymore because it has also been deleted. Fetch it from module_sect_attrs::grp::bin_attrs[]::private as described in 4b2c11e4aaf7. Link: https://lkml.kernel.org/r/20250221204034.4430-1-antonio@mandelbit.com Fixes: d8959b947a8d ("module: sysfs: Drop member 'module_sect_attrs::nsections'") Fixes: 4b2c11e4aaf7 ("module: sysfs: Drop member 'module_sect_attr::address'") Signed-off-by: Antonio Quartulli Reviewed-by: Jan Kiszka Cc: Thomas Weißschuh Cc: Kieran Bingham Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit a8cb51f9cb6125b8c92caf54ca2d6af39ff88883 Author: Tang Yizhou Date: Tue Mar 4 19:03:18 2025 +0800 writeback: fix calculations in trace_balance_dirty_pages() for cgwb [ Upstream commit 6cc4c3aa714bc58ec5d20f3054ca5f23534984d1 ] In the commit dcc25ae76eb7 ("writeback: move global_dirty_limit into wb_domain") of the cgroup writeback backpressure propagation patchset, Tejun made some adaptations to trace_balance_dirty_pages() for cgroup writeback. However, this adaptation was incomplete and Tejun missed further adaptation in the subsequent patches. In the cgroup writeback scenario, if sdtc in balance_dirty_pages() is assigned to mdtc, then upon entering trace_balance_dirty_pages(), __entry->limit should be assigned based on the dirty_limit of the corresponding memcg's wb_domain, rather than global_wb_domain. To address this issue and simplify the implementation, introduce a 'limit' field in struct dirty_throttle_control to store the hard_limit value computed in wb_position_ratio() by calling hard_dirty_limit(). This field will then be used in trace_balance_dirty_pages() to assign the value to __entry->limit. Link: https://lkml.kernel.org/r/20250304110318.159567-4-yizhou.tang@shopee.com Fixes: dcc25ae76eb7 ("writeback: move global_dirty_limit into wb_domain") Signed-off-by: Tang Yizhou Acked-by: Tejun Heo Cc: Alexei Starovoitov Cc: Christian Brauner Cc: Jan Kara Cc: "Masami Hiramatsu (Google)" Cc: Matthew Wilcow (Oracle) Cc: Steven Rostedt Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 64113ee8b8f1db9d6aab01a220703889c67eda3b Author: Tang Yizhou Date: Tue Mar 4 19:03:16 2025 +0800 writeback: let trace_balance_dirty_pages() take struct dtc as parameter [ Upstream commit f1ab2831e2a4312046bca79256b2efc41d373eaf ] Patch series "Fix calculations in trace_balance_dirty_pages() for cgwb", v2. In my experiment, I found that the output of trace_balance_dirty_pages() in the cgroup writeback scenario was strange because trace_balance_dirty_pages() always uses global_wb_domain.dirty_limit for related calculations instead of the dirty_limit of the corresponding memcg's wb_domain. The basic idea of the fix is to store the hard dirty limit value computed in wb_position_ratio() into struct dirty_throttle_control and use it for calculations in trace_balance_dirty_pages(). This patch (of 3): Currently, trace_balance_dirty_pages() already has 12 parameters. In the patch #3, I initially attempted to introduce an additional parameter. However, in include/linux/trace_events.h, bpf_trace_run12() only supports up to 12 parameters and bpf_trace_run13() does not exist. To reduce the number of parameters in trace_balance_dirty_pages(), we can make it accept a pointer to struct dirty_throttle_control as a parameter. To achieve this, we need to move the definition of struct dirty_throttle_control from mm/page-writeback.c to include/linux/writeback.h. Link: https://lkml.kernel.org/r/20250304110318.159567-1-yizhou.tang@shopee.com Link: https://lkml.kernel.org/r/20250304110318.159567-2-yizhou.tang@shopee.com Signed-off-by: Tang Yizhou Cc: Alexei Starovoitov Cc: Christian Brauner Cc: Steven Rostedt Cc: Jan Kara Cc: "Masami Hiramatsu (Google)" Cc: Matthew Wilcow (Oracle) Cc: Tang Yizhou Cc: Tejun Heo Signed-off-by: Andrew Morton Stable-dep-of: 6cc4c3aa714b ("writeback: fix calculations in trace_balance_dirty_pages() for cgwb") Signed-off-by: Sasha Levin commit cc9f774ced3b44bc3ebbe6a2d143e399a0305de2 Author: Anshuman Khandual Date: Wed Feb 26 17:54:01 2025 +0530 arch/powerpc: drop GENERIC_PTDUMP from mpc885_ads_defconfig [ Upstream commit 2c5e6ac2db64ace51f66a9f3b3b3ab9553d748e8 ] GENERIC_PTDUMP gets selected on powerpc explicitly and hence can be dropped off from mpc885_ads_defconfig. Replace with CONFIG_PTDUMP_DEBUGFS instead. Link: https://lkml.kernel.org/r/20250226122404.1927473-3-anshuman.khandual@arm.com Fixes: e084728393a5 ("powerpc/ptdump: Convert powerpc to GENERIC_PTDUMP") Signed-off-by: Anshuman Khandual Suggested-by: Christophe Leroy Reviewed-by: Christophe Leroy Cc: Madhavan Srinivasan Cc: Michael Ellerman Cc: Nicholas Piggin Cc: Catalin Marinas Cc: Heiko Carstens Cc: Ingo Molnar Cc: Jonathan Corbet Cc: Marc Zyngier Cc: Mark Rutland Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: Steven Price Cc: Thomas Gleixner Cc: Vasily Gorbik Cc: Will Deacon Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 0bbe6ce49bd9bc2918af836ce9bbb8a8bbaf164f Author: Ahmad Fatoum Date: Mon Feb 17 21:39:42 2025 +0100 reboot: reboot, not shutdown, on hw_protection_reboot timeout [ Upstream commit bbf0ec4f57e0a34983ca25f00ec90f4765572d78 ] hw_protection_shutdown() will kick off an orderly shutdown and if that takes longer than a configurable amount of time, an emergency shutdown will occur. Recently, hw_protection_reboot() was added for those systems that don't implement a proper shutdown and are better served by rebooting and having the boot firmware worry about doing something about the critical condition. On timeout of the orderly reboot of hw_protection_reboot(), the system would go into shutdown, instead of reboot. This is not a good idea, as going into shutdown was explicitly not asked for. Fix this by always doing an emergency reboot if hw_protection_reboot() is called and the orderly reboot takes too long. Link: https://lkml.kernel.org/r/20250217-hw_protection-reboot-v3-2-e1c09b090c0c@pengutronix.de Fixes: 79fa723ba84c ("reboot: Introduce thermal_zone_device_critical_reboot()") Signed-off-by: Ahmad Fatoum Reviewed-by: Tzung-Bi Shih Reviewed-by: Matti Vaittinen Cc: Benson Leung Cc: Daniel Lezcano Cc: Fabio Estevam Cc: Guenter Roeck Cc: Jonathan Corbet Cc: Liam Girdwood Cc: Lukasz Luba Cc: Mark Brown Cc: Matteo Croce Cc: "Rafael J. Wysocki" Cc: Rob Herring (Arm) Cc: Rui Zhang Cc: Sascha Hauer Cc: "Serge E. Hallyn" Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 91428ac798e6d60d75e123eedc0f8551d0b894aa Author: Ahmad Fatoum Date: Mon Feb 17 21:39:41 2025 +0100 reboot: replace __hw_protection_shutdown bool action parameter with an enum [ Upstream commit 318f05a057157c400a92f17c5f2fa3dd96f57c7e ] Patch series "reboot: support runtime configuration of emergency hw_protection action", v3. We currently leave the decision of whether to shutdown or reboot to protect hardware in an emergency situation to the individual drivers. This works out in some cases, where the driver detecting the critical failure has inside knowledge: It binds to the system management controller for example or is guided by hardware description that defines what to do. This is inadequate in the general case though as a driver reporting e.g. an imminent power failure can't know whether a shutdown or a reboot would be more appropriate for a given hardware platform. To address this, this series adds a hw_protection kernel parameter and sysfs toggle that can be used to change the action from the shutdown default to reboot. A new hw_protection_trigger API then makes use of this default action. My particular use case is unattended embedded systems that don't have support for shutdown and that power on automatically when power is supplied: - A brief power cycle gets detected by the driver - The kernel powers down the system and SoC goes into shutdown mode - Power is restored - The system remains oblivious to the restored power - System needs to be manually power cycled for a duration long enough to drain the capacitors With this series, such systems can configure the kernel with hw_protection=reboot to have the boot firmware worry about critical conditions. This patch (of 12): Currently __hw_protection_shutdown() either reboots or shuts down the system according to its shutdown argument. To make the logic easier to follow, both inside __hw_protection_shutdown and at caller sites, lets replace the bool parameter with an enum. This will be extra useful, when in a later commit, a third action is added to the enumeration. No functional change. Link: https://lkml.kernel.org/r/20250217-hw_protection-reboot-v3-0-e1c09b090c0c@pengutronix.de Link: https://lkml.kernel.org/r/20250217-hw_protection-reboot-v3-1-e1c09b090c0c@pengutronix.de Signed-off-by: Ahmad Fatoum Reviewed-by: Tzung-Bi Shih Cc: Benson Leung Cc: Mark Brown Cc: Daniel Lezcano Cc: Fabio Estevam Cc: Guenter Roeck Cc: Jonathan Corbet Cc: Liam Girdwood Cc: Lukasz Luba Cc: Matteo Croce Cc: Matti Vaittinen Cc: "Rafael J. Wysocki" Cc: Rob Herring Cc: Rui Zhang Cc: Sascha Hauer Cc: "Serge E. Hallyn" Signed-off-by: Andrew Morton Stable-dep-of: bbf0ec4f57e0 ("reboot: reboot, not shutdown, on hw_protection_reboot timeout") Signed-off-by: Sasha Levin commit e95d97c9c8cd0c239b7b59c79be0f6a9dcf7905c Author: Vasiliy Kovalev Date: Fri Feb 14 11:49:08 2025 +0300 ocfs2: validate l_tree_depth to avoid out-of-bounds access [ Upstream commit a406aff8c05115119127c962cbbbbd202e1973ef ] The l_tree_depth field is 16-bit (__le16), but the actual maximum depth is limited to OCFS2_MAX_PATH_DEPTH. Add a check to prevent out-of-bounds access if l_tree_depth has an invalid value, which may occur when reading from a corrupted mounted disk [1]. Link: https://lkml.kernel.org/r/20250214084908.736528-1-kovalev@altlinux.org Fixes: ccd979bdbce9 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem") Signed-off-by: Vasiliy Kovalev Reported-by: syzbot+66c146268dc88f4341fd@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=66c146268dc88f4341fd [1] Reviewed-by: Joseph Qi Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Jun Piao Cc: Kurt Hackel Cc: Mark Fasheh Cc: Vasiliy Kovalev Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit c7e29fdb50d73fafa273187f3fa6e191227bf084 Author: Sourabh Jain Date: Fri Jan 31 17:08:24 2025 +0530 kexec: initialize ELF lowest address to ULONG_MAX [ Upstream commit 9986fb5164c8b21f6439cfd45ba36d8cc80c9710 ] Patch series "powerpc/crash: use generic crashkernel reservation", v3. Commit 0ab97169aa05 ("crash_core: add generic function to do reservation") added a generic function to reserve crashkernel memory. So let's use the same function on powerpc and remove the architecture-specific code that essentially does the same thing. The generic crashkernel reservation also provides a way to split the crashkernel reservation into high and low memory reservations, which can be enabled for powerpc in the future. Additionally move powerpc to use generic APIs to locate memory hole for kexec segments while loading kdump kernel. This patch (of 7): kexec_elf_load() loads an ELF executable and sets the address of the lowest PT_LOAD section to the address held by the lowest_load_addr function argument. To determine the lowest PT_LOAD address, a local variable lowest_addr (type unsigned long) is initialized to UINT_MAX. After loading each PT_LOAD, its address is compared to lowest_addr. If a loaded PT_LOAD address is lower, lowest_addr is updated. However, setting lowest_addr to UINT_MAX won't work when the kernel image is loaded above 4G, as the returned lowest PT_LOAD address would be invalid. This is resolved by initializing lowest_addr to ULONG_MAX instead. This issue was discovered while implementing crashkernel high/low reservation on the PowerPC architecture. Link: https://lkml.kernel.org/r/20250131113830.925179-1-sourabhjain@linux.ibm.com Link: https://lkml.kernel.org/r/20250131113830.925179-2-sourabhjain@linux.ibm.com Fixes: a0458284f062 ("powerpc: Add support code for kexec_file_load()") Signed-off-by: Sourabh Jain Acked-by: Hari Bathini Acked-by: Baoquan He Cc: Madhavan Srinivasan Cc: Mahesh Salgaonkar Cc: Michael Ellerman Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 84bab01a078d15747c9142f895b0f5c0ace9489f Author: David Hildenbrand Date: Mon Feb 10 20:37:50 2025 +0100 kernel/events/uprobes: handle device-exclusive entries correctly in __replace_page() [ Upstream commit 096cbb80ab3fd85a9035ec17a1312c2a7db8bc8c ] Ever since commit b756a3b5e7ea ("mm: device exclusive memory access") we can return with a device-exclusive entry from page_vma_mapped_walk(). __replace_page() is not prepared for that, so teach it about these PFN swap PTEs. Note that device-private entries are so far not applicable on that path, because GUP would never have returned such folios (conversion to device-private happens by page migration, not in-place conversion of the PTE). There is a race between GUP and us locking the folio to look it up using page_vma_mapped_walk(), so this is likely a fix (unless something else could prevent that race, but it doesn't look like). pte_pfn() on something that is not a present pte could give use garbage, and we'd wrongly mess up the mapcount because it was already adjusted by calling folio_remove_rmap_pte() when making the entry device-exclusive. Link: https://lkml.kernel.org/r/20250210193801.781278-9-david@redhat.com Fixes: b756a3b5e7ea ("mm: device exclusive memory access") Signed-off-by: David Hildenbrand Tested-by: Alistair Popple Cc: Alex Shi Cc: Danilo Krummrich Cc: Dave Airlie Cc: Jann Horn Cc: Jason Gunthorpe Cc: Jerome Glisse Cc: John Hubbard Cc: Jonathan Corbet Cc: Karol Herbst Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Lyude Cc: "Masami Hiramatsu (Google)" Cc: Oleg Nesterov Cc: Pasha Tatashin Cc: Peter Xu Cc: Peter Zijlstra (Intel) Cc: SeongJae Park Cc: Simona Vetter Cc: Vlastimil Babka Cc: Yanteng Si Cc: Barry Song Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 8d84dbb7785d0300072f634397ab7d8b943cba9e Author: Veronika Molnarova Date: Sat Nov 23 00:12:33 2024 +0100 perf test stat_all_pmu.sh: Correctly check 'perf stat' result [ Upstream commit 02ba09c8ab9406f30c5c63b7cfd4b300c3c2c32c ] Test case "stat_all_pmu.sh" is not correctly checking 'perf stat' output due to a poor design. Firstly, having the 'set -e' option with a trap catching the sigexit causes the shell to exit immediately if 'perf stat' ends with any non-zero value, which is then caught by the trap reporting an unexpected signal. This causes events that should be parsed by the if-else statement to be caught by the trap handler and are reported as errors: $ perf test -vv "perf all pmu" Testing i915/actual-frequency/ Unexpected signal in main Error: Access to performance monitoring and observability operations is limited. Secondly, the if-else branches are not exclusive as the checking if the event is present in the output log covers also the "" events, which should be accepted, and also the "Bad name events", which should be rejected. Remove the "set -e" option from the test case, correctly parse the "perf stat" output log and check its return value. Add the missing outputs for the 'perf stat' result and also add logs messages to report the branch that parsed the event for more info. Fixes: 7e73ea40295620e7 ("perf test: Ignore security failures in all PMU test") Signed-off-by: Veronika Molnarova Tested-by: Qiao Zhao Link: https://lore.kernel.org/r/20241122231233.79509-1-vmolnaro@redhat.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit c9a5d7059792275d3ada279a31eec7462a978646 Author: Arnaldo Carvalho de Melo Date: Mon Mar 10 16:45:32 2025 -0300 perf units: Fix insufficient array space [ Upstream commit cf67629f7f637fb988228abdb3aae46d0c1748fe ] No need to specify the array size, let the compiler figure that out. This addresses this compiler warning that was noticed while build testing on fedora rawhide: 31 15.81 fedora:rawhide : FAIL gcc version 15.0.1 20250225 (Red Hat 15.0.1-0) (GCC) util/units.c: In function 'unit_number__scnprintf': util/units.c:67:24: error: initializer-string for array of 'char' is too long [-Werror=unterminated-string-initialization] 67 | char unit[4] = "BKMG"; | ^~~~~~ cc1: all warnings being treated as errors Fixes: 9808143ba2e54818 ("perf tools: Add unit_number__scnprintf function") Signed-off-by: Arnaldo Carvalho de Melo Link: https://lore.kernel.org/r/20250310194534.265487-3-acme@kernel.org Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 8db9d4258f2be5a7df77def519f19cb14b5ff612 Author: Dapeng Mi Date: Thu Mar 6 18:39:03 2025 -0800 perf x86/topdown: Fix topdown leader sampling test error on hybrid [ Upstream commit b74683b3bb224eccb644cf260753dfc82e802d92 ] When running topdown leader smapling test on Intel hybrid platforms, such as LNL/ARL, we see the below error. Topdown leader sampling test Topdown leader sampling [Failed topdown events not reordered correctly] It indciates the below command fails. perf record -o "${perfdata}" -e "{instructions,slots,topdown-retiring}:S" true The root cause is that perf tool creats a perf event for each PMU type if it can create. As for this command, there would be 5 perf events created, cpu_atom/instructions/,cpu_atom/topdown_retiring/, cpu_core/slots/,cpu_core/instructions/,cpu_core/topdown-retiring/ For these 5 events, the 2 cpu_atom events are in a group and the other 3 cpu_core events are in another group. When arch_topdown_sample_read() traverses all these 5 events, events cpu_atom/instructions/ and cpu_core/slots/ don't have a same group leade, and then return false directly and lead to cpu_core/slots/ event is used to sample and this is not allowed by PMU driver. It's a overkill to return false directly if "evsel->core.leader != leader->core.leader" since there could be multiple groups in the event list. Just "continue" instead of "return false" to fix this issue. Fixes: 1e53e9d1787b ("perf x86/topdown: Correct leader selection with sample_read enabled") Signed-off-by: Dapeng Mi Tested-by: Thomas Falcon Tested-by: Ian Rogers Link: https://lore.kernel.org/r/20250307023906.1135613-2-irogers@google.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 233bbeaea91ce500161585630daf98efa17b0dab Author: Ian Rogers Date: Fri Feb 28 14:23:00 2025 -0800 perf evsel: tp_format accessing improvements [ Upstream commit eb7e83a7ca2dba01671c711e1711705e1a15626d ] Ensure evsel__clone copies the tp_sys and tp_name variables. In evsel__tp_format, if tp_sys isn't set, use the config value to find the tp_format. This succeeds in python code where pyrf__tracepoint has already found the format. Reviewed-by: Howard Chu Signed-off-by: Ian Rogers Reviewed-by: Arnaldo Carvalho de Melo Link: https://lore.kernel.org/r/20250228222308.626803-4-irogers@google.com Fixes: 6c8310e8380d472c ("perf evsel: Allow evsel__newtp without libtraceevent") Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 04c7d4424691a0b0714d3fa8e1ed4dc829ac2658 Author: Ian Rogers Date: Fri Feb 28 14:22:59 2025 -0800 perf evlist: Add success path to evlist__create_syswide_maps [ Upstream commit fe0ce8a9d85a48642880c9b78944cb0d23e779c5 ] Over various refactorings evlist__create_syswide_maps has been made to only ever return with -ENOMEM. Fix this so that when perf_evlist__set_maps is successfully called, 0 is returned. Reviewed-by: Howard Chu Signed-off-by: Ian Rogers Reviewed-by: Arnaldo Carvalho de Melo Link: https://lore.kernel.org/r/20250228222308.626803-3-irogers@google.com Fixes: 8c0498b6891d7ca5 ("perf evlist: Fix create_syswide_maps() not propagating maps") Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit a4c70eb0502dca4a3027645f6e694afb407643b0 Author: Ian Rogers Date: Fri Feb 28 14:22:58 2025 -0800 perf debug: Avoid stack overflow in recursive error message [ Upstream commit bda840191d2aae3b7cadc3ac21835dcf29487191 ] In debug_file, pr_warning_once is called on error. As that function calls debug_file the function will yield a stack overflow. Switch the location of the call so the recursion is avoided. Reviewed-by: Howard Chu Signed-off-by: Ian Rogers Reviewed-by: Arnaldo Carvalho de Melo Link: https://lore.kernel.org/r/20250228222308.626803-2-irogers@google.com Fixes: ec49230cf6dda704 ("perf debug: Expose debug file") Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 9c40a68b7f97fa487e6c7e67fcf4f846a1f96692 Author: Karan Sanghavi Date: Thu Feb 20 17:34:36 2025 +0000 iio: light: Add check for array bounds in veml6075_read_int_time_ms [ Upstream commit ee735aa33db16c1fb5ebccbaf84ad38f5583f3cc ] The array contains only 5 elements, but the index calculated by veml6075_read_int_time_index can range from 0 to 7, which could lead to out-of-bounds access. The check prevents this issue. Coverity Issue CID 1574309: (#1 of 1): Out-of-bounds read (OVERRUN) overrun-local: Overrunning array veml6075_it_ms of 5 4-byte elements at element index 7 (byte offset 31) using index int_index (which evaluates to 7) This is hardening against potentially broken hardware. Good to have but not necessary to backport. Fixes: 3b82f43238ae ("iio: light: add VEML6075 UVA and UVB light sensor driver") Signed-off-by: Karan Sanghavi Reviewed-by: Javier Carrasco Link: https://patch.msgid.link/Z7dnrEpKQdRZ2qFU@Emma Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 9199d2bb588b644ab860bf20647868e765f2873e Author: Jonathan Santos Date: Thu Mar 6 18:00:43 2025 -0300 iio: adc: ad7768-1: set MOSI idle state to prevent accidental reset [ Upstream commit 2416cec859299be04d021b4cf98eff814f345af7 ] Datasheet recommends Setting the MOSI idle state to high in order to prevent accidental reset of the device when SCLK is free running. This happens when the controller clocks out a 1 followed by 63 zeros while the CS is held low. Check if SPI controller supports SPI_MOSI_IDLE_HIGH flag and set it. Fixes: a5f8c7da3dbe ("iio: adc: Add AD7768-1 ADC basic support") Signed-off-by: Jonathan Santos Reviewed-by: Marcelo Schmitt Link: https://patch.msgid.link/c2a2b0f3d54829079763a5511359a1fa80516cfb.1741268122.git.Jonathan.Santos@analog.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 99bc9d6985d82ce65c9de1231870058ded76cdcb Author: Uwe Kleine-König Date: Mon Mar 3 12:47:02 2025 +0100 iio: adc: ad7173: Fix comparison of channel configs [ Upstream commit 7b6033ed5a9e1a369a9cf58018388ae4c5f17e41 ] Checking the binary representation of two structs (of the same type) for equality doesn't have the same semantic as comparing all members for equality. The former might find a difference where the latter doesn't in the presence of padding or when ambiguous types like float or bool are involved. (Floats typically have different representations for single values, like -0.0 vs +0.0, or 0.5 * 2² vs 0.25 * 2³. The type bool has at least 8 bits and the raw values 1 and 2 (probably) both evaluate to true, but memcmp finds a difference.) When searching for a channel that already has the configuration we need, the comparison by member is the one that is needed. Convert the comparison accordingly to compare the members one after another. Also add a static_assert guard to (somewhat) ensure that when struct ad7173_channel_config::config_props is expanded, the comparison is adapted, too. This issue is somewhat theoretic, but using memcmp() on a struct is a bad pattern that is worth fixing. Fixes: 76a1e6a42802 ("iio: adc: ad7173: add AD7173 driver") Signed-off-by: Uwe Kleine-König Link: https://patch.msgid.link/20250303114659.1672695-14-u.kleine-koenig@baylibre.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 9bf3287f19571ce27b4e3f40c437fa868d2e7ed7 Author: Uwe Kleine-König Date: Mon Mar 3 12:47:01 2025 +0100 iio: adc: ad7124: Fix comparison of channel configs [ Upstream commit 05a5d874f7327b75e9bc4359618017e047cc129c ] Checking the binary representation of two structs (of the same type) for equality doesn't have the same semantic as comparing all members for equality. The former might find a difference where the latter doesn't in the presence of padding or when ambiguous types like float or bool are involved. (Floats typically have different representations for single values, like -0.0 vs +0.0, or 0.5 * 2² vs 0.25 * 2³. The type bool has at least 8 bits and the raw values 1 and 2 (probably) both evaluate to true, but memcmp finds a difference.) When searching for a channel that already has the configuration we need, the comparison by member is the one that is needed. Convert the comparison accordingly to compare the members one after another. Also add a static_assert guard to (somewhat) ensure that when struct ad7124_channel_config::config_props is expanded, the comparison is adapted, too. This issue is somewhat theoretic, but using memcmp() on a struct is a bad pattern that is worth fixing. Fixes: 7b8d045e497a ("iio: adc: ad7124: allow more than 8 channels") Signed-off-by: Uwe Kleine-König Link: https://patch.msgid.link/20250303114659.1672695-13-u.kleine-koenig@baylibre.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 09655c6dbff4f4cc9cf9bdcab476c77c008746e1 Author: Uwe Kleine-König Date: Mon Mar 3 12:47:00 2025 +0100 iio: adc: ad4130: Fix comparison of channel setups [ Upstream commit 280acb19824663d55a3f4d09087c76fabe86fa3c ] Checking the binary representation of two structs (of the same type) for equality doesn't have the same semantic as comparing all members for equality. The former might find a difference where the latter doesn't in the presence of padding or when ambiguous types like float or bool are involved. (Floats typically have different representations for single values, like -0.0 vs +0.0, or 0.5 * 2² vs 0.25 * 2³. The type bool has at least 8 bits and the raw values 1 and 2 (probably) both evaluate to true, but memcmp finds a difference.) When searching for a channel that already has the configuration we need, the comparison by member is the one that is needed. Convert the comparison accordingly to compare the members one after another. Also add a static_assert guard to (somewhat) ensure that when struct ad4130_setup_info is expanded, the comparison is adapted, too. This issue is somewhat theoretic, but using memcmp() on a struct is a bad pattern that is worth fixing. Fixes: 62094060cf3a ("iio: adc: ad4130: add AD4130 driver") Signed-off-by: Uwe Kleine-König Link: https://patch.msgid.link/20250303114659.1672695-12-u.kleine-koenig@baylibre.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 9300ff01d6b19a7a2795bf4fb4bf8d9d89be48a1 Author: Uwe Kleine-König Date: Mon Mar 3 12:46:59 2025 +0100 iio: adc: ad_sigma_delta: Disable channel after calibration [ Upstream commit fb3a0811a7bc12d51cba4b75d6b123ab62e2fe4d ] The function ad_sd_calibrate() enables the channel to calibrate at function entry but doesn't disable it on exit. This is problematic because if two (or more) channels are calibrated in a row, the second calibration isn't executed as intended as the first (still enabled) channel is recalibrated and after the first irq (i.e. when the calibration of the first channel completed) the calibration is aborted. This currently affects ad7173 only, as the other drivers using ad_sd_calibrate() never have more than one channel enabled at a time. To fix this, disable the calibrated channel after calibration. Fixes: 031bdc8aee01 ("iio: adc: ad7173: add calibration support") Signed-off-by: Uwe Kleine-König Link: https://patch.msgid.link/20250303114659.1672695-11-u.kleine-koenig@baylibre.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 1488abd2b201e41c69bf5d6144398237ae4f03e0 Author: Basavaraj Natikar Date: Mon Feb 3 21:55:11 2025 +0530 dmaengine: ptdma: Utilize the AE4DMA engine's multi-queue functionality [ Upstream commit 6565439894570a07b00dba0b739729fe6b56fba4 ] As AE4DMA offers multi-channel functionality compared to PTDMA’s single queue, utilize multi-queue, which supports higher speeds than PTDMA, to achieve higher performance using the AE4DMA workqueue based mechanism. Fixes: 69a47b16a51b ("dmaengine: ptdma: Extend ptdma to support multi-channel and version") Signed-off-by: Basavaraj Natikar Link: https://lore.kernel.org/r/20250203162511.911946-4-Basavaraj.Natikar@amd.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 2f22413a27eb487c786096aec602eecd391dd7d9 Author: Basavaraj Natikar Date: Mon Feb 3 21:55:10 2025 +0530 dmaengine: ae4dma: Use the MSI count and its corresponding IRQ number [ Upstream commit feba04e6fdf4daccc83fc09d499a3e32c178edb4 ] Instead of using the defined maximum hardware queue, which can lead to incorrect values if the counts mismatch, use the exact supported MSI count and its corresponding IRQ number. Fixes: 90a30e268d9b ("dmaengine: ae4dma: Add AMD ae4dma controller driver") Signed-off-by: Basavaraj Natikar Link: https://lore.kernel.org/r/20250203162511.911946-3-Basavaraj.Natikar@amd.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit f3834d2d68749e4760c27325149765930ad876fd Author: Peng Fan Date: Fri Feb 28 15:17:20 2025 +0800 dmaengine: fsl-edma: free irq correctly in remove path [ Upstream commit fa70c4c3c580c239a0f9e83a14770ab026e8d820 ] Add fsl_edma->txirq/errirq check to avoid below warning because no errirq at i.MX9 platform. Otherwise there will be kernel dump: WARNING: CPU: 0 PID: 11 at kernel/irq/devres.c:144 devm_free_irq+0x74/0x80 Modules linked in: CPU: 0 UID: 0 PID: 11 Comm: kworker/u8:0 Not tainted 6.12.0-rc7#18 Hardware name: NXP i.MX93 11X11 EVK board (DT) Workqueue: events_unbound deferred_probe_work_func pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : devm_free_irq+0x74/0x80 lr : devm_free_irq+0x48/0x80 Call trace: devm_free_irq+0x74/0x80 (P) devm_free_irq+0x48/0x80 (L) fsl_edma_remove+0xc4/0xc8 platform_remove+0x28/0x44 device_remove+0x4c/0x80 Fixes: 44eb827264de ("dmaengine: fsl-edma: request per-channel IRQ only when channel is allocated") Reviewed-by: Frank Li Signed-off-by: Peng Fan Link: https://lore.kernel.org/r/20250228071720.3780479-2-peng.fan@oss.nxp.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit ea6bbc8a4d3ea0cc6cd0bccbf4147b314cb0f91b Author: Peng Fan Date: Fri Feb 28 15:17:19 2025 +0800 dmaengine: fsl-edma: cleanup chan after dma_async_device_unregister [ Upstream commit c9c59da76ce9cb3f215b66eb3708cda1134a5206 ] There is kernel dump when do module test: sysfs: cannot create duplicate filename /devices/platform/soc@0/44000000.bus/44000000.dma-controller/dma/dma0chan0 __dma_async_device_channel_register+0x128/0x19c dma_async_device_register+0x150/0x454 fsl_edma_probe+0x6cc/0x8a0 platform_probe+0x68/0xc8 fsl_edma_cleanup_vchan will unlink vchan.chan.device_node, while dma_async_device_unregister needs the link to do __dma_async_device_channel_unregister. So need move fsl_edma_cleanup_vchan after dma_async_device_unregister to make sure channel could be freed. So clean up chan after dma_async_device_unregister to address this. Fixes: 6f93b93b2a1b ("dmaengine: fsl-edma: kill the tasklets upon exit") Reviewed-by: Frank Li Signed-off-by: Peng Fan Link: https://lore.kernel.org/r/20250228071720.3780479-1-peng.fan@oss.nxp.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit bf917d11eda3b1bbf2040a13013c6f1c8d50e5e1 Author: Bard Liao Date: Mon Mar 10 15:36:53 2025 +0800 soundwire: take in count the bandwidth of a prepared stream [ Upstream commit 08ae0d61c3d79bb5d52ae30ad4fc12442e966a23 ] When a stream's state is marked as prepared, it is ready for playback/capture. Therefore, we need to include the stream's bandwidth when we calculate the required bandwidth of a bus. Fixes: 25befdf32aa40 ("soundwire: generic_bandwidth_allocation: count the bandwidth of active streams only") Signed-off-by: Bard Liao Link: https://github.com/thesofproject/linux/issues/5334 Reviewed-by: Richard Fitzgerald Reviewed-by: Ranjani Sridharan Link: https://lore.kernel.org/r/20250310073653.56476-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 464c3feec5f39556cced53adbd2c163acba3b334 Author: Chuck Lever Date: Mon Feb 10 12:03:32 2025 -0500 NFSD: Fix callback decoder status codes [ Upstream commit 8ce35dcaf3aed7113cd692759dc0a26cec8cd0c3 ] fs/nfsd/nfs4callback.c implements a callback client. Thus its XDR decoders are decoding replies, not calls. NFS4ERR_BAD_XDR is an on-the-wire status code that reports that the client sent a corrupted RPC /call/. It's not used as the internal error code when a /reply/ can't be decoded, since that kind of failure is never reported to the sender of that RPC message. Instead, a reply decoder should return -EIO, as the reply decoders in the NFS client do. Fixes: 6487a13b5c6b ("NFSD: add support for CB_GETATTR callback") Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 4b1914eb3ecd4c85afaf2fcc6a3618df1faf2d53 Author: Ian Rogers Date: Wed Feb 26 15:01:09 2025 -0800 perf tests: Fix data symbol test with LTO builds [ Upstream commit 36e7748d33bf6a82e558009e03448e9321465e05 ] With LTO builds, although regular builds could also see this as all the code is in one file, the datasym workload can realize the buf1.reserved data is never accessed. The compiler moves the variable to bss and only keeps the data1 and data2 parts as separate variables. This causes the symbol check to fail in the test. Make the variable volatile to disable the more aggressive optimization. Rename the variable to make which buf1 in perf is being referred to. Before: $ perf test -vv "data symbol" 126: Test data symbol: --- start --- test child forked, pid 299808 perf does not have symbol 'buf1' perf is missing symbols - skipping test ---- end(-2) ---- 126: Test data symbol : Skip $ nm perf|grep buf1 0000000000a5fa40 b buf1.0 0000000000a5fa48 b buf1.1 After: $ nm perf|grep buf1 0000000000a53a00 d buf1 $ perf test -vv "data symbol"126: Test data symbol: --- start --- test child forked, pid 302166 a53a00-a53a39 l buf1 perf does have symbol 'buf1' Recording workload... Waiting for "perf record has started" message OK Cleaning up files... ---- end(0) ---- 126: Test data symbol : Ok Fixes: 3dfc01fe9d12 ("perf test: Add 'datasym' test workload") Signed-off-by: Ian Rogers Link: https://lore.kernel.org/r/20250226230109.314580-1-irogers@google.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 71f2f4b5c227b196e1f57d0492273ff0acb041e4 Author: Namhyung Kim Date: Mon Mar 3 18:28:36 2025 -0800 perf test: Add timeout to datasym workload [ Upstream commit f04c7ef35256beea57a598a7ea06dd2242ae9ae6 ] Unlike others it has an infinite loop that make it annoying to call. Make it finish after 1 second and handle command-line argument to change the setting. Reviewed-by: Leo Yan Tested-by: Thomas Richter Tested-by: Thomas Falcon Cc: Thomas Richter Cc: Leo Yan Link: https://lore.kernel.org/r/20250304022837.1877845-6-namhyung@kernel.org Signed-off-by: Namhyung Kim Stable-dep-of: 36e7748d33bf ("perf tests: Fix data symbol test with LTO builds") Signed-off-by: Sasha Levin commit b9982065b82b4177ba3a7a72ce18c84921f7494d Author: Dan Carpenter Date: Sun Feb 16 23:52:10 2025 +0300 fs/ntfs3: Prevent integer overflow in hdr_first_de() [ Upstream commit 6bb81b94f7a9cba6bde9a905cef52a65317a8b04 ] The "de_off" and "used" variables come from the disk so they both need to check. The problem is that on 32bit systems if they're both greater than UINT_MAX - 16 then the check does work as intended because of an integer overflow. Fixes: 60ce8dfde035 ("fs/ntfs3: Fix wrong if in hdr_first_de") Signed-off-by: Dan Carpenter Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 4d0f4f42922a832388a0c2fe5204c0a1037ff786 Author: Dan Carpenter Date: Sun Feb 16 23:52:00 2025 +0300 fs/ntfs3: Fix a couple integer overflows on 32bit systems [ Upstream commit 5ad414f4df2294b28836b5b7b69787659d6aa708 ] On 32bit systems the "off + sizeof(struct NTFS_DE)" addition can have an integer wrapping issue. Fix it by using size_add(). Fixes: 82cae269cfa9 ("fs/ntfs3: Add initialization of super block") Signed-off-by: Dan Carpenter Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit e0f7dcd19f10454e790335722504a3b771bd9589 Author: Niklas Neronin Date: Thu Mar 6 16:49:47 2025 +0200 usb: xhci: correct debug message page size calculation [ Upstream commit 55741c723318905e6d5161bf1e12749020b161e3 ] The ffs() function returns the index of the first set bit, starting from 1. If no bits are set, it returns zero. This behavior causes an off-by-one page size in the debug message, as the page size calculation [1] is zero-based, while ffs() is one-based. Fix this by subtracting one from the result of ffs(). Note that since variable 'val' is unsigned, subtracting one from zero will result in the maximum unsigned integer value. Consequently, the condition 'if (val < 16)' will still function correctly. [1], Page size: (2^(n+12)), where 'n' is the set page size bit. Fixes: 81720ec5320c ("usb: host: xhci: use ffs() in xhci_mem_init()") Signed-off-by: Niklas Neronin Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20250306144954.3507700-9-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 12f171c69ed1f9c91a57154541383b79de33ecba Author: Namhyung Kim Date: Fri Feb 28 18:17:31 2025 -0300 perf machine: Fixup kernel maps ends after adding extra maps [ Upstream commit f7a46e028c394cd422326caa7a2ad6ba0cd87915 ] I just noticed it would add extra kernel maps after modules. I think it should fixup end address of the kernel maps after adding all maps first. Fixes: 876e80cf83d10585 ("perf tools: Fixup end address of modules") Reported-by: Arnaldo Carvalho de Melo Tested-by: Arnaldo Carvalho de Melo Reviewed-by: Ian Rogers Link: https://lore.kernel.org/lkml/Z7TvZGjVix2asYWI@x1 Link: https://lore.kernel.org/lkml/Z712hzvv22Ni63f1@google.com Link: https://lore.kernel.org/r/20250228211734.33781-4-acme@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit b0b29d3c79227d1b9147818798b242c6adc68acb Author: Thomas Richter Date: Tue Mar 4 10:23:49 2025 +0100 perf bench: Fix perf bench syscall loop count [ Upstream commit 957d194163bf983da98bf7ec7e4f86caff8cd0eb ] Command 'perf bench syscall fork -l 100000' offers option -l to run for a specified number of iterations. However this option is not always observed. The number is silently limited to 10000 iterations as can be seen: Output before: # perf bench syscall fork -l 100000 # Running 'syscall/fork' benchmark: # Executed 10,000 fork() calls Total time: 23.388 [sec] 2338.809800 usecs/op 427 ops/sec # When explicitly specified with option -l or --loops, also observe higher number of iterations: Output after: # perf bench syscall fork -l 100000 # Running 'syscall/fork' benchmark: # Executed 100,000 fork() calls Total time: 716.982 [sec] 7169.829510 usecs/op 139 ops/sec # This patch fixes the issue for basic execve fork and getpgid. Fixes: ece7f7c0507c ("perf bench syscall: Add fork syscall benchmark") Signed-off-by: Thomas Richter Acked-by: Sumanth Korikkar Tested-by: Athira Rajeev Cc: Tiezhu Yang Link: https://lore.kernel.org/r/20250304092349.2618082-1-tmricht@linux.ibm.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 1bbb6c096cad4764a2e25fbd456b001dc5c91859 Author: Leo Yan Date: Tue Mar 4 11:12:34 2025 +0000 perf arm-spe: Fix load-store operation checking [ Upstream commit e1d47850bbf79a541c9b3bacdd562f5e0112274d ] The ARM_SPE_OP_LD and ARM_SPE_OP_ST operations are secondary operation type, they are overlapping with other second level's operation types belonging to SVE and branch operations. As a result, a non load-store operation can be parsed for data source and memory sample. To fix the issue, this commit introduces a is_ldst_op() macro for checking LDST operation, and apply the checking when synthesize data source and memory samples. Fixes: a89dbc9b988f ("perf arm-spe: Set sample's data source field") Signed-off-by: Leo Yan Reviewed-by: James Clark Link: https://lore.kernel.org/r/20250304111240.3378214-7-leo.yan@arm.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 58df1edf65a91e6287dbb22225ed52ab0a44b917 Author: Uwe Kleine-König Date: Thu Feb 27 12:35:28 2025 +0100 iio: adc: ad7192: Grab direct mode for calibration [ Upstream commit 08808b3ef384974b1eaf4975de707f93f8cda62d ] While a calibration is running, better don't make the device do anything else. To enforce that, grab direct mode during calibration. Fixes: 42776c14c692 ("staging: iio: adc: ad7192: Add system calibration support") Signed-off-by: Uwe Kleine-König Link: https://patch.msgid.link/8aade802afca6a89641e24c1ae1d4b8d82cff58d.1740655250.git.u.kleine-koenig@baylibre.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit e301160aa64b94f41670fccbf5854f4cbd7030a8 Author: Uwe Kleine-König Date: Thu Feb 27 12:35:27 2025 +0100 iio: adc: ad7173: Grab direct mode for calibration [ Upstream commit 7021d97fb89b216557561ca8cdf68144c016993b ] While a calibration is running, better don't make the device do anything else. To enforce that, grab direct mode during calibration. Fixes: 031bdc8aee01 ("iio: adc: ad7173: add calibration support") Signed-off-by: Uwe Kleine-König Link: https://patch.msgid.link/8319fa2dc881c9899d60db4eba7fe8e984716617.1740655250.git.u.kleine-koenig@baylibre.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit b5601c3d8c83da71f15b1333f3aeff37a69b3a68 Author: Jonathan Cameron Date: Sun Feb 9 18:05:58 2025 +0000 iio: core: Rework claim and release of direct mode to work with sparse. [ Upstream commit d795e38df4b7ebac1072bbf7d8a5500c1ea83332 ] Initial thought was to do something similar to __cond_lock() do_iio_device_claim_direct_mode(iio_dev) ? : ({ __acquire(iio_dev); 0; }) + Appropriate static inline iio_device_release_direct_mode() However with that, sparse generates false positives. E.g. drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c:1811:17: warning: context imbalance in 'st_lsm6dsx_read_raw' - unexpected unlock So instead, this patch rethinks the return type and makes it more 'conditional lock like' (which is part of what is going on under the hood anyway) and return a boolean - true for successfully acquired, false for did not acquire. To allow a migration path given the rework is now non trivial, take a leaf out of the naming of the conditional guard we currently have for IIO device direct mode and drop the _mode postfix from the new functions giving iio_device_claim_direct() and iio_device_release_direct() Whilst the kernel supports __cond_acquires() upstream sparse does not yet do so. Hence rely on sparse expanding a static inline wrapper to explicitly see whether __acquire() is called. Note that even with the solution here, sparse sometimes gives false positives. However in the few cases seen they were complex code structures that benefited from simplification anyway. Reviewed-by: David Lechner Reviewed-by: Nuno Sa Link: https://patch.msgid.link/20250209180624.701140-2-jic23@kernel.org Signed-off-by: Jonathan Cameron Stable-dep-of: 7021d97fb89b ("iio: adc: ad7173: Grab direct mode for calibration") Signed-off-by: Sasha Levin commit fd791c81f410ab1c554686a6f486dc7a176dfe35 Author: Nuno Sá Date: Tue Feb 18 10:31:25 2025 +0000 iio: backend: make sure to NULL terminate stack buffer [ Upstream commit 035b4989211dc1c8626e186d655ae8ca5141bb73 ] Make sure to NULL terminate the buffer in iio_backend_debugfs_write_reg() before passing it to sscanf(). It is a stack variable so we should not assume it will 0 initialized. Fixes: cdf01e0809a4 ("iio: backend: add debugFs interface") Signed-off-by: Nuno Sá Reviewed-by: David Lechner Link: https://patch.msgid.link/20250218-dev-iio-misc-v1-1-bf72b20a1eb8@analog.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 947d4f8c88496e59d6841ce38ba5b3bd208a4eff Author: Jonathan Cameron Date: Mon Feb 17 14:01:33 2025 +0000 iio: accel: msa311: Fix failure to release runtime pm if direct mode claim fails. [ Upstream commit 60a0cf2ebab92011055ab7db6553c0fc3c546938 ] Reorder the claiming of direct mode and runtime pm calls to simplify handling a little. For correct error handling, after the reorder iio_device_release_direct_mode() must be claimed in an error occurs in pm_runtime_resume_and_get() Fixes: 1ca2cfbc0c33 ("iio: add MEMSensing MSA311 3-axis accelerometer driver") Reviewed-by: David Lechner Link: https://patch.msgid.link/20250217140135.896574-7-jic23@kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 43b211475651b20ba4168e4b10fee3f687717560 Author: Jonathan Cameron Date: Mon Feb 17 14:01:28 2025 +0000 iio: accel: mma8452: Ensure error return on failure to matching oversampling ratio [ Upstream commit df330c808182a8beab5d0f84a6cbc9cff76c61fc ] If a match was not found, then the write_raw() callback would return the odr index, not an error. Return -EINVAL if this occurs. To avoid similar issues in future, introduce j, a new indexing variable rather than using ret for this purpose. Fixes: 79de2ee469aa ("iio: accel: mma8452: claim direct mode during write raw") Reviewed-by: David Lechner Link: https://patch.msgid.link/20250217140135.896574-2-jic23@kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit a21c6735c74248d6356c3cbf9c6cdab3feeb3751 Author: Mario Limonciello Date: Thu Feb 20 23:40:03 2025 -0600 ucsi_ccg: Don't show failed to get FW build information error [ Upstream commit c16006852732dc4fe37c14b81f9b4458df05b832 ] The error `failed to get FW build information` is added for what looks to be for misdetection of the device property firmware-name. If the property is missing (such as on non-nvidia HW) this error shows up. Move the error into the scope of the property parser for "firmware-name" to avoid showing errors on systems without the firmware-name property. Fixes: 5c9ae5a87573d ("usb: typec: ucsi: ccg: add firmware flashing support") Signed-off-by: Mario Limonciello Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20250221054137.1631765-2-superm1@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1e46e11b6885e84f94c57becfc2766ec8fb3927a Author: Luca Ceresoli Date: Fri Jan 24 14:06:08 2025 +0100 perf build: Fix in-tree build due to symbolic link [ Upstream commit 75100d848ef4b8ca39bb6dd3a21181e37dea27e2 ] Building perf in-tree is broken after commit 890a1961c812 ("perf tools: Create source symlink in perf object dir") which added a 'source' symlink in the output dir pointing to the source dir. With in-tree builds, the added 'SOURCE = ...' line is executed multiple times (I observed 2 during the build plus 2 during installation). This is a minor inefficiency, in theory not harmful because symlink creation is assumed to be idempotent. But it is not. Considering with in-tree builds: srctree=/absolute/path/to/linux OUTPUT=/absolute/path/to/linux/tools/perf here's what happens: 1. ln -sf $(srctree)/tools/perf $(OUTPUT)/source -> creates /absolute/path/to/linux/tools/perf/source link to /absolute/path/to/linux/tools/perf => OK, that's what was intended 2. ln -sf $(srctree)/tools/perf $(OUTPUT)/source # same command as 1 -> creates /absolute/path/to/linux/tools/perf/perf link to /absolute/path/to/linux/tools/perf => Not what was intended, not idempotent 3. Now the build _should_ create the 'perf' executable, but it fails The reason is the tricky 'ln' command line. At the first invocation 'ln' uses the 1st form: ln [OPTION]... [-T] TARGET LINK_NAME and creates a link to TARGET *called LINK_NAME*. At the second invocation $(OUTPUT)/source exists, so 'ln' uses the 3rd form: ln [OPTION]... TARGET... DIRECTORY and creates a link to TARGET *called TARGET* inside DIRECTORY. Fix by adding -n/--no-dereference to "treat LINK_NAME as a normal file if it is a symbolic link to a directory", as the manpage says. Closes: https://lore.kernel.org/all/20241125182506.38af9907@booty/ Fixes: 890a1961c812 ("perf tools: Create source symlink in perf object dir") Signed-off-by: Luca Ceresoli Reviewed-by: Charlie Jenkins Tested-by: Charlie Jenkins Link: https://lore.kernel.org/r/20250124-perf-fix-intree-build-v1-1-485dd7a855e4@bootlin.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit c28bf1a33b4e98d070c1983d2c3e35a236f1ba2a Author: Ian Rogers Date: Tue Feb 25 11:36:00 2025 -0800 tools/x86: Fix linux/unaligned.h include path in lib/insn.c [ Upstream commit fad07a5c0f07ad0884e1cb4362fe28c083b5b811 ] tools/arch/x86/include/linux doesn't exist but building is working by virtue of a -I. Building using bazel this fails. Use angle brackets to include unaligned.h so there isn't an invalid relative include. Fixes: 5f60d5f6bbc1 ("move asm/unaligned.h to linux/unaligned.h") Signed-off-by: Ian Rogers Acked-by: Josh Poimboeuf Cc: Al Viro Link: https://lore.kernel.org/r/20250225193600.90037-1-irogers@google.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit e63dd4b348e724858dde7e4dc9ed1de52becdaf0 Author: James Clark Date: Wed Feb 26 10:41:01 2025 +0000 perf pmu: Don't double count common sysfs and json events [ Upstream commit c9d699e10fa6c0cdabcddcf991e7ff42af6b2503 ] After pmu_add_cpu_aliases() is called, perf_pmu__num_events() returns an incorrect value that double counts common events and doesn't match the actual count of events in the alias list. This is because after 'cpu_aliases_added == true', the number of events returned is 'sysfs_aliases + cpu_json_aliases'. But when adding 'case EVENT_SRC_SYSFS' events, 'sysfs_aliases' and 'cpu_json_aliases' are both incremented together, failing to account that these ones overlap and only add a single item to the list. Fix it by adding another counter for overlapping events which doesn't influence 'cpu_json_aliases'. There doesn't seem to be a current issue because it's used in perf list before pmu_add_cpu_aliases() so the correct value is returned. Other uses in tests may also miss it for other reasons like only looking at uncore events. However it's marked as a fixes commit in case any new fix with new uses of perf_pmu__num_events() is backported. Fixes: d9c5f5f94c2d ("perf pmu: Count sys and cpuid JSON events separately") Reviewed-by: Ian Rogers Signed-off-by: James Clark Link: https://lore.kernel.org/r/20250226104111.564443-3-james.clark@linaro.org Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 8365648de0eadd5b7115e5e1686342852d371869 Author: James Clark Date: Wed Feb 26 10:41:00 2025 +0000 perf pmu: Dynamically allocate tool PMU [ Upstream commit 72c6f57a4193f2eadceb52261315438719c4c1ad ] perf_pmus__destroy() treats all PMUs as allocated and free's them so we can't have any static PMUs that are added to the PMU lists. Fix it by allocating the tool PMU in the same way as the others. Current users of the tool PMU already use find_pmu() and not perf_pmus__tool_pmu(), so rename the function to add 'new' to avoid it being misused in the future. perf_pmus__fake_pmu() can remain as static as it's not added to the PMU lists. Fixes the following error: $ perf bench internals pmu-scan # Running 'internals/pmu-scan' benchmark: Computing performance of sysfs PMU event scan for 100 times munmap_chunk(): invalid pointer Aborted (core dumped) Fixes: 240505b2d0ad ("perf tool_pmu: Factor tool events into their own PMU") Reviewed-by: Ian Rogers Signed-off-by: James Clark Link: https://lore.kernel.org/r/20250226104111.564443-2-james.clark@linaro.org Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 9c8dc3b2c3b10d340199c50b144b5ff4eab60411 Author: Ian Rogers Date: Fri Jan 31 23:43:17 2025 -0800 perf pmus: Restructure pmu_read_sysfs to scan fewer PMUs [ Upstream commit 57e13264dcea670d5f42a067562f02aa923219e2 ] Rather than scanning core or all PMUs, allow pmu_read_sysfs to read some combination of core, other, hwmon and tool PMUs. The PMUs that should be read and are already read are held as bitmaps. It is known that a "hwmon_" prefix is necessary for a hwmon PMU's name, similarly with "tool", so only scan those PMUs in situations the PMU name or the PMU's type number make sense to. The number of openat system calls reduces from 276 to 98 for a hwmon event. The number of openats for regular perf events isn't changed. Signed-off-by: Ian Rogers Reviewed-by: Kan Liang Link: https://lore.kernel.org/r/20250201074320.746259-3-irogers@google.com Signed-off-by: Namhyung Kim Stable-dep-of: 72c6f57a4193 ("perf pmu: Dynamically allocate tool PMU") Signed-off-by: Sasha Levin commit c9b6124876a0608aa488ace5d3bfe92d59b55de4 Author: Yuanfang Zhang Date: Thu Jan 16 17:04:20 2025 +0800 coresight-etm4x: add isb() before reading the TRCSTATR [ Upstream commit 4ff6039ffb79a4a8a44b63810a8a2f2b43264856 ] As recommended by section 4.3.7 ("Synchronization when using system instructions to progrom the trace unit") of ARM IHI 0064H.b, the self-hosted trace analyzer must perform a Context synchronization event between writing to the TRCPRGCTLR and reading the TRCSTATR. Additionally, add an ISB between the each read of TRCSTATR on coresight_timeout() when using system instructions to program the trace unit. Fixes: 1ab3bb9df5e3 ("coresight: etm4x: Add necessary synchronization for sysreg access") Signed-off-by: Yuanfang Zhang Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20250116-etm_sync-v4-1-39f2b05e9514@quicinc.com Signed-off-by: Sasha Levin commit 63b449f73ab0dcc0ba11ceaa4c5c70bc86ccf03c Author: Mike Christie Date: Wed Jan 29 15:09:22 2025 -0600 vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint [ Upstream commit 5dd639a1646ef5fe8f4bf270fad47c5c3755b9b6 ] If vhost_scsi_set_endpoint is called multiple times without a vhost_scsi_clear_endpoint between them, we can hit multiple bugs found by Haoran Zhang: 1. Use-after-free when no tpgs are found: This fixes a use after free that occurs when vhost_scsi_set_endpoint is called more than once and calls after the first call do not find any tpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds tpgs to add to the vs_tpg array match=true, so we will do: vhost_vq_set_backend(vq, vs_tpg); ... kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg; If vhost_scsi_set_endpoint is called again and no tpgs are found match=false so we skip the vhost_vq_set_backend call leaving the pointer to the vs_tpg we then free via: kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg; If a scsi request is then sent we do: vhost_scsi_handle_vq -> vhost_scsi_get_req -> vhost_vq_get_backend which sees the vs_tpg we just did a kfree on. 2. Tpg dir removal hang: This patch fixes an issue where we cannot remove a LIO/target layer tpg (and structs above it like the target) dir due to the refcount dropping to -1. The problem is that if vhost_scsi_set_endpoint detects a tpg is already in the vs->vs_tpg array or if the tpg has been removed so target_depend_item fails, the undepend goto handler will do target_undepend_item on all tpgs in the vs_tpg array dropping their refcount to 0. At this time vs_tpg contains both the tpgs we have added in the current vhost_scsi_set_endpoint call as well as tpgs we added in previous calls which are also in vs->vs_tpg. Later, when vhost_scsi_clear_endpoint runs it will do target_undepend_item on all the tpgs in the vs->vs_tpg which will drop their refcount to -1. Userspace will then not be able to remove the tpg and will hang when it tries to do rmdir on the tpg dir. 3. Tpg leak: This fixes a bug where we can leak tpgs and cause them to be un-removable because the target name is overwritten when vhost_scsi_set_endpoint is called multiple times but with different target names. The bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setup a vhost-scsi device to target/tpg mapping, then calls VHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs we haven't seen before (target1 has tpg1 but target2 has tpg2). When this happens we don't teardown the old target tpg mapping and just overwrite the target name and the vs->vs_tpg array. Later when we do vhost_scsi_clear_endpoint, we are passed in either target1 or target2's name and we will only match that target's tpgs when we loop over the vs->vs_tpg. We will then return from the function without doing target_undepend_item on the tpgs. Because of all these bugs, it looks like being able to call vhost_scsi_set_endpoint multiple times was never supported. The major user, QEMU, already has checks to prevent this use case. So to fix the issues, this patch prevents vhost_scsi_set_endpoint from being called if it's already successfully added tpgs. To add, remove or change the tpg config or target name, you must do a vhost_scsi_clear_endpoint first. Fixes: 25b98b64e284 ("vhost scsi: alloc cmds per vq instead of session") Fixes: 4f7f46d32c98 ("tcm_vhost: Use vq->private_data to indicate if the endpoint is setup") Reported-by: Haoran Zhang Closes: https://lore.kernel.org/virtualization/e418a5ee-45ca-4d18-9b5d-6f8b6b1add8e@oracle.com/T/#me6c0041ce376677419b9b2563494172a01487ecb Signed-off-by: Mike Christie Reviewed-by: Stefan Hajnoczi Message-Id: <20250129210922.121533-1-michael.christie@oracle.com> Signed-off-by: Michael S. Tsirkin Acked-by: Stefano Garzarella Signed-off-by: Sasha Levin commit 92aab0768c928e0555e70825a7053590b980ad18 Author: Ilkka Koskinen Date: Thu Jan 9 21:53:48 2025 +0000 coresight: catu: Fix number of pages while using 64k pages [ Upstream commit 0e14e062f5ff98aa15264dfa87c5f5e924028561 ] Trying to record a trace on kernel with 64k pages resulted in -ENOMEM. This happens due to a bug in calculating the number of table pages, which returns zero. Fix the issue by rounding up. $ perf record --kcore -e cs_etm/@tmc_etr55,cycacc,branch_broadcast/k --per-thread taskset --cpu-list 1 dd if=/dev/zero of=/dev/null failed to mmap with 12 (Cannot allocate memory) Fixes: 8ed536b1e283 ("coresight: catu: Add support for scatter gather tables") Signed-off-by: Ilkka Koskinen Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20250109215348.5483-1-ilkka@os.amperecomputing.com Signed-off-by: Sasha Levin commit 60df29b7f83d53086153633c065ee329a38097b9 Author: Wentao Liang Date: Mon Jan 20 22:05:47 2025 +0800 greybus: gb-beagleplay: Add error handling for gb_greybus_init [ Upstream commit be382372d55d65b5c7e5a523793ca5e403f8c595 ] Add error handling for the gb_greybus_init(bg) function call during the firmware reflash process to maintain consistency in error handling throughout the codebase. If initialization fails, log an error and return FW_UPLOAD_ERR_RW_ERROR. Fixes: 0cf7befa3ea2 ("greybus: gb-beagleplay: Add firmware upload API") Signed-off-by: Wentao Liang Reviewed-by: Ayush Singh Link: https://lore.kernel.org/r/20250120140547.1460-1-vulab@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ef27051ba8c4f4f298d210c7d23fec1c295abbfd Author: Dmitry Vyukov Date: Wed Jan 8 07:36:23 2025 +0100 perf report: Fix input reload/switch with symbol sort key [ Upstream commit 6353255e7cfab568058580424fa0967bf4504fe5 ] Currently the code checks that there is no "ipc" in the sort order and add an ipc string. This will always error out on the second pass after input reload/switch, since the sort order already contains "ipc". Do the ipc check/fixup only on the first pass. Signed-off-by: Dmitry Vyukov Link: https://lore.kernel.org/r/20250108063628.215577-1-dvyukov@google.com Fixes: ec6ae74fe8f0 ("perf report: Display average IPC and IPC coverage per symbol") Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 5947290922450a33576fee7955be6420dbbad6b2 Author: Namhyung Kim Date: Mon Feb 10 22:07:44 2025 -0800 perf report: Switch data file correctly in TUI [ Upstream commit 43c2b6139b188d8a756130147f7efd5ddf99f88d ] The 's' key is to switch to a new data file and load the data in the same window. The switch_data_file() will show a popup menu to select which data file user wants and update the 'input_name' global variable. But in the cmd_report(), it didn't update the data.path using the new 'input_name' and keep usng the old file. This is fairly an old bug and I assume people don't use this feature much. :) Link: https://lore.kernel.org/r/20250211060745.294289-1-namhyung@kernel.org Closes: https://lore.kernel.org/linux-perf-users/89e678bc-f0af-4929-a8a6-a2666f1294a4@linaro.org Fixes: f5fc14124c5cefdd ("perf tools: Add data object to handle perf data file") Reported-by: James Clark Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit c82ae06f49e70d1c14ee9c76c392345856d050c9 Author: Dave Penkler Date: Thu Feb 13 11:31:12 2025 +0100 staging: gpib: Fix cb7210 pcmcia Oops [ Upstream commit c1baf6528bcfd6a86842093ff3f8ff8caf309c12 ] The pcmcia_driver struct was still only using the old .name initialization in the drv field. This led to a NULL pointer deref Oops in strcmp called from pcmcia_register_driver. Initialize the pcmcia_driver struct name field. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202502131453.cb6d2e4a-lkp@intel.com Fixes: e9dc69956d4d ("staging: gpib: Add Computer Boards GPIB driver") Signed-off-by: Dave Penkler Link: https://lore.kernel.org/r/20250213103112.4415-1-dpenkler@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ff91ca1bb03cd65beff75b8f2286a670403b94a9 Author: Joe Hattori Date: Thu Dec 5 12:48:44 2024 +0900 soundwire: slave: fix an OF node reference leak in soundwire slave device [ Upstream commit aac2f8363f773ae1f65aab140e06e2084ac6b787 ] When initializing a soundwire slave device, an OF node is stored to the device with refcount incremented. However, the refcount is not decremented in .release(), thus call of_node_put() in sdw_slave_release(). Fixes: a2e484585ad3 ("soundwire: core: add device tree support for slave devices") Signed-off-by: Joe Hattori Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20241205034844.2784964-1-joe@pf.is.s.u-tokyo.ac.jp Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 4945503dc03eab3449e1614778057c2ede4ce221 Author: James Clark Date: Wed Feb 12 16:38:56 2025 +0000 perf tests: Fix Tool PMU test segfault [ Upstream commit 615ec00b06f78912c370b372426190768402a5b9 ] tool_pmu__event_to_str() now handles skipped events by returning NULL, so it's wrong to re-check for a skip on the resulting string. Calling tool_pmu__skip_event() with a NULL string results in a segfault so remove the unnecessary skip to fix it: $ perf test -vv "parsing with PMU name" 12.2: Parsing with PMU name: ... ---- unexpected signal (11) ---- 12.2: Parsing with PMU name : FAILED! Fixes: ee8aef2d2321 ("perf tools: Add skip check in tool_pmu__event_to_str()") Signed-off-by: James Clark Reported-by: Athira Rajeev Acked-by: Kan Liang Tested-by: Ian Rogers Link: https://lore.kernel.org/r/20250212163859.1489916-1-james.clark@linaro.org Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 92cd117b8d1d3645768fb142cf64bd381bb5c1b1 Author: Qasim Ijaz Date: Tue Feb 11 19:59:00 2025 +0000 isofs: fix KMSAN uninit-value bug in do_isofs_readdir() [ Upstream commit 81a82e8f33880793029cd6f8a766fb13b737e6a7 ] In do_isofs_readdir() when assigning the variable "struct iso_directory_record *de" the b_data field of the buffer_head is accessed and an offset is added to it, the size of b_data is 2048 and the offset size is 2047, meaning "de = (struct iso_directory_record *) (bh->b_data + offset);" yields the final byte of the 2048 sized b_data block. The first byte of the directory record (de_len) is then read and found to be 31, meaning the directory record size is 31 bytes long. The directory record is defined by the structure: struct iso_directory_record { __u8 length; // 1 byte __u8 ext_attr_length; // 1 byte __u8 extent[8]; // 8 bytes __u8 size[8]; // 8 bytes __u8 date[7]; // 7 bytes __u8 flags; // 1 byte __u8 file_unit_size; // 1 byte __u8 interleave; // 1 byte __u8 volume_sequence_number[4]; // 4 bytes __u8 name_len; // 1 byte char name[]; // variable size } __attribute__((packed)); The fixed portion of this structure occupies 33 bytes. Therefore, a valid directory record must be at least 33 bytes long (even without considering the variable-length name field). Since de_len is only 31, it is insufficient to contain the complete fixed header. The code later hits the following sanity check that compares de_len against the sum of de->name_len and sizeof(struct iso_directory_record): if (de_len < de->name_len[0] + sizeof(struct iso_directory_record)) { ... } Since the fixed portion of the structure is 33 bytes (up to and including name_len member), a valid record should have de_len of at least 33 bytes; here, however, de_len is too short, and the field de->name_len (located at offset 32) is accessed even though it lies beyond the available 31 bytes. This access on the corrupted isofs data triggers a KASAN uninitialized memory warning. The fix would be to first verify that de_len is at least sizeof(struct iso_directory_record) before accessing any fields like de->name_len. Reported-by: syzbot Tested-by: syzbot Closes: https://syzkaller.appspot.com/bug?extid=812641c6c3d7586a1613 Fixes: 2deb1acc653c ("isofs: fix access to unallocated memory when reading corrupted filesystem") Signed-off-by: Qasim Ijaz Signed-off-by: Jan Kara Link: https://patch.msgid.link/20250211195900.42406-1-qasdev00@gmail.com Signed-off-by: Sasha Levin commit 36d7fd9a3d5c32b81eb06a75aafc6d22afe7d5a9 Author: Kan Liang Date: Fri Feb 7 07:28:44 2025 -0800 perf tools: Add skip check in tool_pmu__event_to_str() [ Upstream commit ee8aef2d232142e5fdfed9c16132815969a0bf81 ] Some topdown related metrics may fail on hybrid machines. $ perf stat -M tma_frontend_bound Cannot resolve IDs for tma_frontend_bound: cpu_atom@TOPDOWN_FE_BOUND.ALL@ / (8 * cpu_atom@CPU_CLK_UNHALTED.CORE@) In the find_tool_events(), the tool_pmu__event_to_str() is used to compare the tool_events. It only checks the event name, no PMU or arch. So the tool_events[TOOL_PMU__EVENT_SLOTS] is set to true, because the p-core Topdown metrics has "slots" event. The tool_events is shared. So when parsing the e-core metrics, the "slots" is automatically added. The "slots" event as a tool event should only be available on arm64. It has a different meaning on X86. The tool_pmu__skip_event() intends handle the case. Apply it for tool_pmu__event_to_str() as well. There is a lack of sanity check in the expr__get_id(). Add the check. Closes: https://lore.kernel.org/lkml/608077bc-4139-4a97-8dc4-7997177d95c4@linux.intel.com/ Fixes: 069057239a67 ("perf tool_pmu: Move expr literals to tool_pmu") Signed-off-by: Kan Liang Reviewed-by: Ian Rogers Cc: thomas.falcon@intel.com Link: https://lore.kernel.org/r/20250207152844.302167-1-kan.liang@linux.intel.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit df672134318cd7d34e872082833639e52a548f01 Author: Heiko Stuebner Date: Fri Dec 6 11:34:01 2024 +0100 phy: phy-rockchip-samsung-hdptx: Don't use dt aliases to determine phy-id [ Upstream commit f08d1c08563846f9be79a4859e912c8795d690fd ] The phy needs to know its identity in the system (phy0 or phy1 on rk3588) for some actions and the driver currently contains code abusing of_alias for that. Devicetree aliases are always optional and should not be used for core device functionality, so instead keep a list of phys on a soc in the of_device_data and find the phy-id by comparing against the mapped register-base. Fixes: c4b09c562086 ("phy: phy-rockchip-samsung-hdptx: Add clock provider support") Signed-off-by: Heiko Stuebner Reviewed-by: Cristian Ciocaltea Reviewed-by: Sebastian Reichel Link: https://lore.kernel.org/r/20241206103401.1780416-3-heiko@sntech.de Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 526c47d41bcb2a99d2d89282c2bf24873a76ed01 Author: Uwe Kleine-König Date: Tue Feb 4 12:50:23 2025 +0100 iio: adc: ad7124: Really disable all channels at probe time [ Upstream commit e903868b4ce73d1ba3663d5e0718424946cebd99 ] If one or more of the 16 channels are enabled and the driver is not aware of that, unexpected things happen because different channels are used than intended. To prevent that, all channels should be disabled at probe time. In Commit 4be339af334c ("iio: adc: ad7124: Disable all channels at probe time") I intended do that, however only the channels that are potentially used by the driver and not all channels are disabled since then. So disable all 16 channels and not only the used ones. Also fix the same issue in the .disable_all() callback. Fixes: 4be339af334c ("iio: adc: ad7124: Disable all channels at probe time") Signed-off-by: Uwe Kleine-König Link: https://patch.msgid.link/20250204115023.265813-2-u.kleine-koenig@baylibre.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit e25acb68a114d37b5bafc8f6394fdc69af56059b Author: Uwe Kleine-König Date: Mon Jan 20 15:07:09 2025 +0100 iio: adc: ad7124: Micro-optimize channel disabling [ Upstream commit cf67879bd4280f6243103e281595f9b523c61481 ] The key objective in ad7124_disable_one() is clearing the AD7124_CHANNEL_EN_MSK bit in the channel register. However there is no advantage to keep the other bits in that register because when the channel is used next time, all fields are rewritten anyhow. So instead of using ad7124_spi_write_mask() (which is a register read plus a register write) use a simple register write clearing the complete register. Also do the same in the .disable_all() callback by using the .disable_one() callback there. Signed-off-by: Uwe Kleine-König Reviewed-by: Nuno Sa Link: https://patch.msgid.link/20250120140708.1093655-2-u.kleine-koenig@baylibre.com Signed-off-by: Jonathan Cameron Stable-dep-of: e903868b4ce7 ("iio: adc: ad7124: Really disable all channels at probe time") Signed-off-by: Sasha Levin commit 7d0fb11cfca25f635bd686b955b5d204809dd7db Author: Javier Carrasco Date: Mon Jan 27 20:30:23 2025 +0100 iio: light: veml6030: fix scale to conform to ABI [ Upstream commit 22eaca4283b216f5e1f7721e4ad0ecb3d23c6774 ] The current scale is not ABI-compliant as it is just the sensor gain instead of the value that acts as a multiplier to be applied to the raw value (there is no offset). Use the iio-gts helpers to obtain the proper scale values according to the gain and integration time to match the resolution tables from the datasheet and drop dedicated variables to store the current values of the integration time, gain and resolution. When at it, use 'scale' instead of 'gain' consistently for the get/set functions to avoid misunderstandings. Fixes: 7b779f573c48 ("iio: light: add driver for veml6030 ambient light sensor") Acked-by: Matti Vaittinen Signed-off-by: Javier Carrasco Link: https://patch.msgid.link/20250127-veml6030-scale-v3-2-4f32ba03df94@gmail.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 1671241d3c00302ef14e891a8103363f929de58f Author: Javier Carrasco Date: Mon Jan 27 20:30:22 2025 +0100 iio: gts-helper: export iio_gts_get_total_gain() [ Upstream commit dbd2e08ff09fd6bd51215b44474899cc1b7b7a16 ] Export this function in preparation for the fix in veml6030.c, where the total gain can be used to ease the calculation of the processed value of the IIO_LIGHT channel compared to acquiring the scale in NANO. Suggested-by: Matti Vaittinen Signed-off-by: Javier Carrasco Reviewed-by: Matti Vaittinen Link: https://patch.msgid.link/20250127-veml6030-scale-v3-1-4f32ba03df94@gmail.com Signed-off-by: Jonathan Cameron Stable-dep-of: 22eaca4283b2 ("iio: light: veml6030: fix scale to conform to ABI") Signed-off-by: Sasha Levin commit 497dcc669860a296a76db92c0fd6b8b75a22e3c8 Author: Javier Carrasco Date: Sun Jan 19 18:31:58 2025 +0100 iio: light: veml6030: extend regmap to support regfields [ Upstream commit 9c7eb1ab2eec47ad9eaf6e11ce14d3d6fd54e677 ] Add support for regfields as well to simplify register operations, taking into account the different fields for the veml6030/veml7700 and veml6035. Signed-off-by: Javier Carrasco Link: https://patch.msgid.link/20250119-veml6030-scale-v2-1-6bfc4062a371@gmail.com Signed-off-by: Jonathan Cameron Stable-dep-of: 22eaca4283b2 ("iio: light: veml6030: fix scale to conform to ABI") Signed-off-by: Sasha Levin commit 737ee66564eed4714f9397fcbeafcec9e757f73a Author: Konstantin Komarov Date: Thu Jan 30 17:03:41 2025 +0300 fs/ntfs3: Update inode->i_mapping->a_ops on compression state [ Upstream commit b432163ebd15a0fb74051949cb61456d6c55ccbd ] Update inode->i_mapping->a_ops when the compression state changes to ensure correct address space operations. Clear ATTR_FLAG_SPARSED/FILE_ATTRIBUTE_SPARSE_FILE when enabling compression to prevent flag conflicts. v2: Additionally, ensure that all dirty pages are flushed and concurrent access to the page cache is blocked. Fixes: 6b39bfaeec44 ("fs/ntfs3: Add support for the compression attribute") Reported-by: Kun Hu , Jiaji Qin Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit a05fbcf8a5777fe773054faee5c8375a20d2fe75 Author: Ye Bin Date: Fri Oct 11 15:40:25 2024 +0800 fs/ntfs3: Fix 'proc_info_root' leak when init ntfs failed [ Upstream commit 1d1a7e2525491f56901f5f63370a0775768044b8 ] There's a issue as follows: proc_dir_entry 'fs/ntfs3' already registered WARNING: CPU: 3 PID: 9788 at fs/proc/generic.c:375 proc_register+0x418/0x590 Modules linked in: ntfs3(E+) Call Trace: _proc_mkdir+0x165/0x200 init_ntfs_fs+0x36/0xf90 [ntfs3] do_one_initcall+0x115/0x6c0 do_init_module+0x253/0x760 load_module+0x55f2/0x6c80 init_module_from_file+0xd2/0x130 __x64_sys_finit_module+0xbf/0x130 do_syscall_64+0x72/0x1c0 Above issue happens as missing destroy 'proc_info_root' when error happens after create 'proc_info_root' in init_ntfs_fs(). So destroy 'proc_info_root' in error path in init_ntfs_fs(). Fixes: 7832e123490a ("fs/ntfs3: Add support /proc/fs/ntfs3//volinfo and /proc/fs/ntfs3//label") Signed-off-by: Ye Bin Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 30edc5d8ef0c4b22ec0a0c30953cdd65c3a2b73b Author: Ye Bin Date: Fri Oct 11 15:40:24 2024 +0800 fs/ntfs3: Factor out ntfs_{create/remove}_proc_root() [ Upstream commit c5a396295370fa99ddc0c4c4d25f8a3ee4f013d8 ] Introduce ntfs_create_proc_root()/ntfs_remove_proc_root() for create/remove "/proc/fs/ntfs3". Signed-off-by: Ye Bin Signed-off-by: Konstantin Komarov Stable-dep-of: 1d1a7e252549 ("fs/ntfs3: Fix 'proc_info_root' leak when init ntfs failed") Signed-off-by: Sasha Levin commit c6b7adb1d2f54e7eb85abe31d637576ce0a12f7b Author: Ye Bin Date: Fri Oct 11 15:40:23 2024 +0800 fs/ntfs3: Factor out ntfs_{create/remove}_procdir() [ Upstream commit e2d74c47a3d3d84a5fa444f380c126328b44f4db ] Introduce ntfs_create_procdir() and ntfs_remove_procdir() to create/remove "/proc/fs/ntfs3/.." Signed-off-by: Ye Bin Signed-off-by: Konstantin Komarov Stable-dep-of: 1d1a7e252549 ("fs/ntfs3: Fix 'proc_info_root' leak when init ntfs failed") Signed-off-by: Sasha Levin commit eee800341e01a0fa05c20c6f53416d8294ee65d6 Author: Ian Rogers Date: Fri Jan 31 23:43:19 2025 -0800 perf stat: Don't merge counters purely on name [ Upstream commit 2d9961c690d299893735783a2077e866f2d46a56 ] Counter merging was added in commit 942c5593393d ("perf stat: Add perf_stat_merge_counters()"), however, it merges events with the same name on different PMUs regardless of whether the different PMUs are actually of the same type (ie they differ only in the suffix on the PMU). For hwmon events there may be a temp1 event on every PMU, but the PMU names are all unique and don't differ just by a suffix. The merging is over eager and will merge all the hwmon counters together meaning an aggregated and very large temp1 value is shown. The same would be true for say cache events and memory controller events where the PMUs differ but the event names are the same. Fix the problem by correctly saying two PMUs alias when they differ only by suffix. Note, there is an overlap with evsel's merged_stat with aggregation and the evsel's metric_leader where aggregation happens for metrics. Fixes: 942c5593393d ("perf stat: Add perf_stat_merge_counters()") Signed-off-by: Ian Rogers Reviewed-by: Kan Liang Link: https://lore.kernel.org/r/20250201074320.746259-5-irogers@google.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 4fb7ca93a50bfcde44eba5703c42b89e5c1f34c5 Author: Thomas Richter Date: Fri Jan 31 12:24:00 2025 +0100 perf test: Fix Hwmon PMU test endianess issue [ Upstream commit 888751e4d0e948d0364eee6fb47e21f090b2b5e4 ] perf test 11 hwmon fails on s390 with this error # ./perf test -Fv 11 --- start --- ---- end ---- 11.1: Basic parsing test : Ok --- start --- Testing 'temp_test_hwmon_event1' Using CPUID IBM,3931,704,A01,3.7,002f temp_test_hwmon_event1 -> hwmon_a_test_hwmon_pmu/temp_test_hwmon_event1/ FAILED tests/hwmon_pmu.c:189 Unexpected config for 'temp_test_hwmon_event1', 292470092988416 != 655361 ---- end ---- 11.2: Parsing without PMU name : FAILED! --- start --- Testing 'hwmon_a_test_hwmon_pmu/temp_test_hwmon_event1/' FAILED tests/hwmon_pmu.c:189 Unexpected config for 'hwmon_a_test_hwmon_pmu/temp_test_hwmon_event1/', 292470092988416 != 655361 ---- end ---- 11.3: Parsing with PMU name : FAILED! # The root cause is in member test_event::config which is initialized to 0xA0001 or 655361. During event parsing a long list event parsing functions are called and end up with this gdb call stack: #0 hwmon_pmu__config_term (hwm=0x168dfd0, attr=0x3ffffff5ee8, term=0x168db60, err=0x3ffffff81c8) at util/hwmon_pmu.c:623 #1 hwmon_pmu__config_terms (pmu=0x168dfd0, attr=0x3ffffff5ee8, terms=0x3ffffff5ea8, err=0x3ffffff81c8) at util/hwmon_pmu.c:662 #2 0x00000000012f870c in perf_pmu__config_terms (pmu=0x168dfd0, attr=0x3ffffff5ee8, terms=0x3ffffff5ea8, zero=false, apply_hardcoded=false, err=0x3ffffff81c8) at util/pmu.c:1519 #3 0x00000000012f88a4 in perf_pmu__config (pmu=0x168dfd0, attr=0x3ffffff5ee8, head_terms=0x3ffffff5ea8, apply_hardcoded=false, err=0x3ffffff81c8) at util/pmu.c:1545 #4 0x00000000012680c4 in parse_events_add_pmu (parse_state=0x3ffffff7fb8, list=0x168dc00, pmu=0x168dfd0, const_parsed_terms=0x3ffffff6090, auto_merge_stats=true, alternate_hw_config=10) at util/parse-events.c:1508 #5 0x00000000012684c6 in parse_events_multi_pmu_add (parse_state=0x3ffffff7fb8, event_name=0x168ec10 "temp_test_hwmon_event1", hw_config=10, const_parsed_terms=0x0, listp=0x3ffffff6230, loc_=0x3ffffff70e0) at util/parse-events.c:1592 #6 0x00000000012f0e4e in parse_events_parse (_parse_state=0x3ffffff7fb8, scanner=0x16878c0) at util/parse-events.y:293 #7 0x00000000012695a0 in parse_events__scanner (str=0x3ffffff81d8 "temp_test_hwmon_event1", input=0x0, parse_state=0x3ffffff7fb8) at util/parse-events.c:1867 #8 0x000000000126a1e8 in __parse_events (evlist=0x168b580, str=0x3ffffff81d8 "temp_test_hwmon_event1", pmu_filter=0x0, err=0x3ffffff81c8, fake_pmu=false, warn_if_reordered=true, fake_tp=false) at util/parse-events.c:2136 #9 0x00000000011e36aa in parse_events (evlist=0x168b580, str=0x3ffffff81d8 "temp_test_hwmon_event1", err=0x3ffffff81c8) at /root/linux/tools/perf/util/parse-events.h:41 #10 0x00000000011e3e64 in do_test (i=0, with_pmu=false, with_alias=false) at tests/hwmon_pmu.c:164 #11 0x00000000011e422c in test__hwmon_pmu (with_pmu=false) at tests/hwmon_pmu.c:219 #12 0x00000000011e431c in test__hwmon_pmu_without_pmu (test=0x1610368 , subtest=1) at tests/hwmon_pmu.c:23 where the attr::config is set to value 292470092988416 or 0x10a0000000000 in line 625 of file ./util/hwmon_pmu.c: attr->config = key.type_and_num; However member key::type_and_num is defined as union and bit field: union hwmon_pmu_event_key { long type_and_num; struct { int num :16; enum hwmon_type type :8; }; }; s390 is big endian and Intel is little endian architecture. The events for the hwmon dummy pmu have num = 1 or num = 2 and type is set to HWMON_TYPE_TEMP (which is 10). On s390 this assignes member key::type_and_num the value of 0x10a0000000000 (which is 292470092988416) as shown in above trace output. Fix this and export the structure/union hwmon_pmu_event_key so the test shares the same implementation as the event parsing functions for union and bit fields. This should avoid endianess issues on all platforms. Output after: # ./perf test -F 11 11.1: Basic parsing test : Ok 11.2: Parsing without PMU name : Ok 11.3: Parsing with PMU name : Ok # Fixes: 531ee0fd4836 ("perf test: Add hwmon "PMU" test") Signed-off-by: Thomas Richter Reviewed-by: Ian Rogers Link: https://lore.kernel.org/r/20250131112400.568975-1-tmricht@linux.ibm.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit fc49b1d5429d939ef9aae586fa0b77e6f8107bcc Author: Angelo Dureghello Date: Tue Jan 14 16:30:12 2025 +0100 iio: dac: adi-axi-dac: modify stream enable [ Upstream commit 6cc60bc38e8428544f8f4f12ddb6cc05fc83a7da ] Change suggested from the AXI HDL team, modify the function axi_dac_data_stream_enable() to check for interface busy, to avoid possible issues when starting the stream. Fixes: e61d7178429a ("iio: dac: adi-axi-dac: extend features") Reviewed-by: Nuno Sa Signed-off-by: Angelo Dureghello Link: https://patch.msgid.link/20250114-wip-bl-ad3552r-axi-v0-iio-testing-carlos-v4-3-979402e33545@baylibre.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 46efdf876d17c9b1adfc8e8c6202a9f83b9cdde3 Author: Benson Leung Date: Fri Jan 24 19:40:38 2025 +0000 usb: typec: thunderbolt: Remove IS_ERR check for plug [ Upstream commit 9682c35ff6ecd76d9462d4749b8b413d3e8e605e ] Fixes these Smatch static checker warnings: drivers/usb/typec/altmodes/thunderbolt.c:354 tbt_ready() warn: 'plug' is not an error pointer Fixes: 100e25738659 ("usb: typec: Add driver for Thunderbolt 3 Alternate Mode") Signed-off-by: Benson Leung Reported-by: Dan Carpenter Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/Z5PstnlA52Z1F2SU@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit dd67fdbec7cf338736bc53207c5cc2cd4572a26f Author: Benson Leung Date: Fri Jan 24 19:40:23 2025 +0000 usb: typec: thunderbolt: Fix loops that iterate TYPEC_PLUG_SOP_P and TYPEC_PLUG_SOP_PP [ Upstream commit b51c1e8d2f49342b2087338c72511326fdb7b172 ] Fixes these Smatch static checker warnings: drivers/usb/typec/altmodes/thunderbolt.c:116 tbt_altmode_work() warn: why is zero skipped 'i' drivers/usb/typec/altmodes/thunderbolt.c:147 tbt_enter_modes_ordered() warn: why is zero skipped 'i' drivers/usb/typec/altmodes/thunderbolt.c:328 tbt_altmode_remove() warn: why is zero skipped 'i' Fixes: 100e25738659 ("usb: typec: Add driver for Thunderbolt 3 Alternate Mode") Signed-off-by: Benson Leung Reported-by: Dan Carpenter Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/Z5Psp615abaaId6J@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 531077193896a1eb81e5a5cfb905ca59c153c9e9 Author: Dave Penkler Date: Fri Jan 24 11:58:58 2025 +0100 staging: gpib: Fix pr_err format warning [ Upstream commit 03ec050c437bb4e7c5d215bbeedaa93932f13b35 ] This patch fixes the following compile warning: drivers/staging/gpib/hp_82341/hp_82341.c: In function 'hp_82341_attach': ./include/linux/kern_levels.h:5:25: warning: format '%lx' expects argument of type 'long unsigned int', but argument 2 has type 'u32' {aka 'unsigned int'} [-Wformat=] It was introduced in commit baf8855c9160 ("staging: gpib: fix address space mixup") but was not detected as the build of the driver depended on BROKEN. Fixes: baf8855c9160 ("staging: gpib: fix address space mixup") Signed-off-by: Dave Penkler Link: https://lore.kernel.org/r/20250124105900.27592-2-dpenkler@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 85bf479b991392ff8919a53dc94cd4b8894e9f4b Author: Dave Penkler Date: Wed Jan 22 11:38:58 2025 +0100 staging: gpib: Add missing interface entry point [ Upstream commit 2f548210a5a5d4cb5f20af39b684a9f6de58cd0e ] Declaring the driver entry points as static caused a warning that the serial_poll_status function of the agilent_82350b driver was unused. Add the entry point to the corresponding interface structure initializations where it was missing. Fixes: 09a4655ee1eb ("staging: gpib: Add HP/Agilent/Keysight 8235xx PCI GPIB driver") Signed-off-by: Dave Penkler Reviewed-by: Dan Carpenter Link: https://lore.kernel.org/r/20250122103859.25499-2-dpenkler@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit cc6b0ec7cccbf66ef3621e9e93296b7bd1f52298 Author: Chenyuan Yang Date: Sat Jan 11 12:18:03 2025 -0600 w1: fix NULL pointer dereference in probe [ Upstream commit 0dd6770a72f138dabea9eae87f3da6ffa68f0d06 ] The w1_uart_probe() function calls w1_uart_serdev_open() (which includes devm_serdev_device_open()) before setting the client ops via serdev_device_set_client_ops(). This ordering can trigger a NULL pointer dereference in the serdev controller's receive_buf handler, as it assumes serdev->ops is valid when SERPORT_ACTIVE is set. This is similar to the issue fixed in commit 5e700b384ec1 ("platform/chrome: cros_ec_uart: properly fix race condition") where devm_serdev_device_open() was called before fully initializing the device. Fix the race by ensuring client ops are set before enabling the port via w1_uart_serdev_open(). Fixes: a3c08804364e ("w1: add UART w1 bus driver") Signed-off-by: Chenyuan Yang Acked-by: Christoph Winklhofer Link: https://lore.kernel.org/r/20250111181803.2283611-1-chenyuan0y@gmail.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 08034682550084202d2ba3c02f0e9bc4729eeb95 Author: James Clark Date: Wed Jan 29 15:44:05 2025 +0000 perf: Always feature test reallocarray [ Upstream commit 4c4c0724d6521a8092b7c16f8f210c5869d95b17 ] This is also used in util/comm.c now, so instead of selectively doing the feature test, always do it. If it's ever used anywhere else it's less likely to cause another build failure. This doesn't remove the need to manually include libc_compat.h, and missing that will still cause an error for glibc < 2.26. There isn't a way to fix that without poisoning reallocarray like libbpf did, but that has other downsides like making memory debugging tools less useful. So for Perf keep it like this and we'll have to fix up any missed includes. Fixes the following build error: util/comm.c:152:31: error: implicit declaration of function 'reallocarray' [-Wimplicit-function-declaration] 152 | tmp = reallocarray(comm_strs->strs, | ^~~~~~~~~~~~ Fixes: 13ca628716c6 ("perf comm: Add reference count checking to 'struct comm_str'") Reported-by: Ali Utku Selen Signed-off-by: James Clark Reviewed-by: Ian Rogers Link: https://lore.kernel.org/r/20250129154405.777533-1-james.clark@linaro.org Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 5854c6bd7a6aac74685698579912320549b84e2e Author: Ian Rogers Date: Thu Jan 9 14:21:07 2025 -0800 perf stat: Fix find_stat for mixed legacy/non-legacy events [ Upstream commit 8ce0d2da14d3fb62844dd0e95982c194326b1a5f ] Legacy events typically don't have a PMU when added leading to mismatched legacy/non-legacy cases in find_stat. Use evsel__find_pmu to make sure the evsel PMU is looked up. Update the evsel__find_pmu code to look for the PMU using the extended config type or, for legacy hardware/hw_cache events on non-hybrid systems, just use the core PMU. Before: ``` $ perf stat -e cycles,cpu/instructions/ -a sleep 1 Performance counter stats for 'system wide': 215,309,764 cycles 44,326,491 cpu/instructions/ 1.002555314 seconds time elapsed ``` After: ``` $ perf stat -e cycles,cpu/instructions/ -a sleep 1 Performance counter stats for 'system wide': 990,676,332 cycles 1,235,762,487 cpu/instructions/ # 1.25 insn per cycle 1.002667198 seconds time elapsed ``` Fixes: 3612ca8e2935 ("perf stat: Fix the hard-coded metrics calculation on the hybrid") Signed-off-by: Ian Rogers Tested-by: James Clark Tested-by: Leo Yan Tested-by: Atish Patra Link: https://lore.kernel.org/r/20250109222109.567031-3-irogers@google.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 3a67f60f0a8be10cea7a884a1a00e9feb6645657 Author: Tony Ambardar Date: Fri Jan 24 22:52:36 2025 -0800 libbpf: Fix accessing BTF.ext core_relo header [ Upstream commit 0a7c2a84359612e54328aa52030eb202093da6e2 ] Update btf_ext_parse_info() to ensure the core_relo header is present before reading its fields. This avoids a potential buffer read overflow reported by the OSS Fuzz project. Fixes: cf579164e9ea ("libbpf: Support BTF.ext loading and output in either endianness") Signed-off-by: Tony Ambardar Signed-off-by: Andrii Nakryiko Link: https://issues.oss-fuzz.com/issues/388905046 Link: https://lore.kernel.org/bpf/20250125065236.2603346-1-itugrok@yahoo.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 47c7a9e05674ddf851fdf95fd3365f28e7174960 Author: Barnabás Czémán Date: Sat Mar 15 16:26:17 2025 +0100 clk: qcom: mmcc-sdm660: fix stuck video_subcore0 clock [ Upstream commit 000cbe3896c56bf5c625e286ff096533a6b27657 ] This clock can't be enable with VENUS_CORE0 GDSC turned off. But that GDSC is under HW control so it can be turned off at any moment. Instead of checking the dependent clock we can just vote for it to enable later when GDSC gets turned on. Fixes: 5db3ae8b33de6 ("clk: qcom: Add SDM660 Multimedia Clock Controller (MMCC) driver") Signed-off-by: Barnabás Czémán Link: https://lore.kernel.org/r/20250315-clock-fix-v1-1-2efdc4920dda@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 46ad387358efdccecf1125201210cd5dbdfbc0a3 Author: Andy Shevchenko Date: Mon Feb 10 21:44:51 2025 +0200 pinctrl: intel: Fix wrong bypass assignment in intel_pinctrl_probe_pwm() [ Upstream commit 0eee258cdf172763502f142d85e967f27a573be0 ] When instantiating PWM, the bypass should be set to false. The field is used for the selected Intel SoCs that do not have PWM feature enabled in their pin control IPs. Fixes: eb78d3604d6b ("pinctrl: intel: Enumerate PWM device when community has a capability") Reported-by: Alexis GUILLEMET Signed-off-by: Andy Shevchenko Reviewed-by: Mika Westerberg Tested-by: Alexis GUILLEMET Signed-off-by: Sasha Levin commit 7452a878d5bdcaf4d1c0e13e099dda6644f51f3f Author: Wenkai Lin Date: Wed Feb 5 11:56:26 2025 +0800 crypto: hisilicon/sec2 - fix for aead auth key length [ Upstream commit 1b284ffc30b02808a0de698667cbcf5ce5f9144e ] According to the HMAC RFC, the authentication key can be 0 bytes, and the hardware can handle this scenario. Therefore, remove the incorrect validation for this case. Fixes: 2f072d75d1ab ("crypto: hisilicon - Add aead support on SEC2") Signed-off-by: Wenkai Lin Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit edf6b543e81ba68c6dbac2499ab362098a5a9716 Author: Wang Liang Date: Thu Mar 13 17:24:21 2025 +0800 RDMA/core: Fix use-after-free when rename device name [ Upstream commit 1d6a9e7449e2a0c1e2934eee7880ba8bd1e464cd ] Syzbot reported a slab-use-after-free with the following call trace: ================================================================== BUG: KASAN: slab-use-after-free in nla_put+0xd3/0x150 lib/nlattr.c:1099 Read of size 5 at addr ffff888140ea1c60 by task syz.0.988/10025 CPU: 0 UID: 0 PID: 10025 Comm: syz.0.988 Not tainted 6.14.0-rc4-syzkaller-00859-gf77f12010f67 #0 Hardware name: Google Compute Engine, BIOS Google 02/12/2025 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0x16e/0x5b0 mm/kasan/report.c:521 kasan_report+0x143/0x180 mm/kasan/report.c:634 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105 nla_put+0xd3/0x150 lib/nlattr.c:1099 nla_put_string include/net/netlink.h:1621 [inline] fill_nldev_handle+0x16e/0x200 drivers/infiniband/core/nldev.c:265 rdma_nl_notify_event+0x561/0xef0 drivers/infiniband/core/nldev.c:2857 ib_device_notify_register+0x22/0x230 drivers/infiniband/core/device.c:1344 ib_register_device+0x1292/0x1460 drivers/infiniband/core/device.c:1460 rxe_register_device+0x233/0x350 drivers/infiniband/sw/rxe/rxe_verbs.c:1540 rxe_net_add+0x74/0xf0 drivers/infiniband/sw/rxe/rxe_net.c:550 rxe_newlink+0xde/0x1a0 drivers/infiniband/sw/rxe/rxe.c:212 nldev_newlink+0x5ea/0x680 drivers/infiniband/core/nldev.c:1795 rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline] rdma_nl_rcv+0x6dd/0x9e0 drivers/infiniband/core/netlink.c:259 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8de/0xcb0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:709 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:724 ____sys_sendmsg+0x53a/0x860 net/socket.c:2564 ___sys_sendmsg net/socket.c:2618 [inline] __sys_sendmsg+0x269/0x350 net/socket.c:2650 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f42d1b8d169 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 ... RSP: 002b:00007f42d2960038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f42d1da6320 RCX: 00007f42d1b8d169 RDX: 0000000000000000 RSI: 00004000000002c0 RDI: 000000000000000c RBP: 00007f42d1c0e2a0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f42d1da6320 R15: 00007ffe399344a8 Allocated by task 10025: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4294 [inline] __kmalloc_node_track_caller_noprof+0x28b/0x4c0 mm/slub.c:4313 __kmemdup_nul mm/util.c:61 [inline] kstrdup+0x42/0x100 mm/util.c:81 kobject_set_name_vargs+0x61/0x120 lib/kobject.c:274 dev_set_name+0xd5/0x120 drivers/base/core.c:3468 assign_name drivers/infiniband/core/device.c:1202 [inline] ib_register_device+0x178/0x1460 drivers/infiniband/core/device.c:1384 rxe_register_device+0x233/0x350 drivers/infiniband/sw/rxe/rxe_verbs.c:1540 rxe_net_add+0x74/0xf0 drivers/infiniband/sw/rxe/rxe_net.c:550 rxe_newlink+0xde/0x1a0 drivers/infiniband/sw/rxe/rxe.c:212 nldev_newlink+0x5ea/0x680 drivers/infiniband/core/nldev.c:1795 rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline] rdma_nl_rcv+0x6dd/0x9e0 drivers/infiniband/core/netlink.c:259 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8de/0xcb0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:709 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:724 ____sys_sendmsg+0x53a/0x860 net/socket.c:2564 ___sys_sendmsg net/socket.c:2618 [inline] __sys_sendmsg+0x269/0x350 net/socket.c:2650 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 10035: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2353 [inline] slab_free mm/slub.c:4609 [inline] kfree+0x196/0x430 mm/slub.c:4757 kobject_rename+0x38f/0x410 lib/kobject.c:524 device_rename+0x16a/0x200 drivers/base/core.c:4525 ib_device_rename+0x270/0x710 drivers/infiniband/core/device.c:402 nldev_set_doit+0x30e/0x4c0 drivers/infiniband/core/nldev.c:1146 rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline] rdma_nl_rcv+0x6dd/0x9e0 drivers/infiniband/core/netlink.c:259 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8de/0xcb0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:709 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:724 ____sys_sendmsg+0x53a/0x860 net/socket.c:2564 ___sys_sendmsg net/socket.c:2618 [inline] __sys_sendmsg+0x269/0x350 net/socket.c:2650 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f This is because if rename device happens, the old name is freed in ib_device_rename() with lock, but ib_device_notify_register() may visit the dev name locklessly by event RDMA_REGISTER_EVENT or RDMA_NETDEV_ATTACH_EVENT. Fix this by hold devices_rwsem in ib_device_notify_register(). Reported-by: syzbot+f60349ba1f9f08df349f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=25bc6f0ed2b88b9eb9b8 Fixes: 9cbed5aab5ae ("RDMA/nldev: Add support for RDMA monitoring") Signed-off-by: Wang Liang Link: https://patch.msgid.link/20250313092421.944658-1-wangliang74@huawei.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 729762ed944ed65d18409a6deeffac8f9bed65ba Author: Jann Horn Date: Tue Mar 25 03:01:23 2025 +0100 x86/dumpstack: Fix inaccurate unwinding from exception stacks due to misplaced assignment [ Upstream commit 2c118f50d7fd4d9aefc4533a26f83338b2906b7a ] Commit: 2e4be0d011f2 ("x86/show_trace_log_lvl: Ensure stack pointer is aligned, again") was intended to ensure alignment of the stack pointer; but it also moved the initialization of the "stack" variable down into the loop header. This was likely intended as a no-op cleanup, since the commit message does not mention it; however, this caused a behavioral change because the value of "regs" is different between the two places. Originally, get_stack_pointer() used the regs provided by the caller; after that commit, get_stack_pointer() instead uses the regs at the top of the stack frame the unwinder is looking at. Often, there are no such regs at all, and "regs" is NULL, causing get_stack_pointer() to fall back to the task's current stack pointer, which is not what we want here, but probably happens to mostly work. Other times, the original regs will point to another regs frame - in that case, the linear guess unwind logic in show_trace_log_lvl() will start unwinding too far up the stack, causing the first frame found by the proper unwinder to never be visited, resulting in a stack trace consisting purely of guess lines. Fix it by moving the "stack = " assignment back where it belongs. Fixes: 2e4be0d011f2 ("x86/show_trace_log_lvl: Ensure stack pointer is aligned, again") Signed-off-by: Jann Horn Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20250325-2025-03-unwind-fixes-v1-2-acd774364768@google.com Signed-off-by: Sasha Levin commit d62503a08e00ec8b1e37069df661e3cb8bb55aca Author: Remi Pommarel Date: Thu Feb 20 12:23:17 2025 +0100 leds: Fix LED_OFF brightness race [ Upstream commit 2c70953b6f535f7698ccbf22c1f5ba26cb6c2816 ] While commit fa15d8c69238 ("leds: Fix set_brightness_delayed() race") successfully forces led_set_brightness() to be called with LED_OFF at least once when switching from blinking to LED on state so that hw-blinking can be disabled, another race remains. Indeed in led_set_brightness(LED_OFF) followed by led_set_brightness(any) scenario the following CPU scheduling can happen: CPU0 CPU1 ---- ---- set_brightness_delayed() { test_and_clear_bit(BRIGHTNESS_OFF) led_set_brightness(LED_OFF) { set_bit(BRIGHTNESS_OFF) queue_work() } led_set_brightness(any) { set_bit(BRIGHTNESS) queue_work() //already queued } test_and_clear_bit(BRIGHTNESS) /* LED set with brightness any */ } /* From previous CPU1 queue_work() */ set_brightness_delayed() { test_and_clear_bit(BRIGHTNESS_OFF) /* LED turned off */ test_and_clear_bit(BRIGHTNESS) /* Clear from previous run, LED remains off */ In that case the led_set_brightness(LED_OFF)/led_set_brightness(any) sequence will be effectively executed in reverse order and LED will remain off. With the introduction of commit 32360bf6a5d4 ("leds: Introduce ordered workqueue for LEDs events instead of system_wq") the race is easier to trigger as sysfs brightness configuration does not wait for set_brightness_delayed() work to finish (flush_work() removal). Use delayed_set_value to optionnally re-configure brightness after a LED_OFF. That way a LED state could be configured more that once but final state will always be as expected. Ensure that delayed_set_value modification is seen before set_bit() using smp_mb__before_atomic(). Fixes: fa15d8c69238 ("leds: Fix set_brightness_delayed() race") Signed-off-by: Remi Pommarel Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/19c81177059dab7b656c42063958011a8e4d1a66.1740050412.git.repk@triplefau.lt Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 413989a4941712047ebc54674d69639acf26df1a Author: Nikita Zhandarovich Date: Wed Jan 15 09:12:06 2025 -0800 mfd: sm501: Switch to BIT() to mitigate integer overflows [ Upstream commit 2d8cb9ffe18c2f1e5bd07a19cbce85b26c1d0cf0 ] If offset end up being high enough, right hand expression in functions like sm501_gpio_set() shifted left for that number of bits, may not fit in int type. Just in case, fix that by using BIT() both as an option safe from overflow issues and to make this step look similar to other gpio drivers. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. Fixes: f61be273d369 ("sm501: add gpiolib support") Signed-off-by: Nikita Zhandarovich Link: https://lore.kernel.org/r/20250115171206.20308-1-n.zhandarovich@fintech.ru Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit aff0257463d3a4b8b76d395daa9582e2f14fa0f3 Author: Manikanta Mylavarapu Date: Fri Jan 24 11:39:14 2025 +0530 clk: qcom: ipq5424: fix software and hardware flow control error of UART [ Upstream commit 4b28beb882a0a1af0ce47a8a87e7877a3ae6ad36 ] The UART’s software and hardware flow control are currently not functioning correctly. For software flow control, the following error is encountered: qcom_geni_serial 1a80000.serial: Couldn't find suitable clock rate for 56000000, 3500000, 2500000, 1152000, 921600, 19200 During hardware flow control testing, a “Retry 0: Got ZCAN error” is observed. To address these issues, update the UART frequency table to include all supported frequencies according to the frequency plan. Fixes: 21b5d5a4a311 ("clk: qcom: add Global Clock controller (GCC) driver for IPQ5424 SoC") Signed-off-by: Manikanta Mylavarapu Link: https://lore.kernel.org/r/20250124060914.1564681-1-quic_mmanikan@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c4b2cc27a0fab0c40eac9066a94921cd437ced7a Author: Fabrizio Castro Date: Wed Mar 5 16:37:52 2025 +0000 pinctrl: renesas: rzv2m: Fix missing of_node_put() call [ Upstream commit 5a550b00704d3a2cd9d766a9427b0f8166da37df ] of_parse_phandle_with_fixed_args() requires its caller to call into of_node_put() on the node pointer from the output structure, but such a call is currently missing. Call into of_node_put() to rectify that. Fixes: 92a9b8252576 ("pinctrl: renesas: Add RZ/V2M pin and gpio controller driver") Signed-off-by: Fabrizio Castro Reviewed-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/20250305163753.34913-4-fabrizio.castro.jz@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit d52636eb13ccba448a752964cc6fc49970912874 Author: Patrisious Haddad Date: Thu Mar 13 16:29:53 2025 +0200 RDMA/mlx5: Fix mlx5_poll_one() cur_qp update flow [ Upstream commit 5ed3b0cb3f827072e93b4c5b6e2b8106fd7cccbd ] When cur_qp isn't NULL, in order to avoid fetching the QP from the radix tree again we check if the next cqe QP is identical to the one we already have. The bug however is that we are checking if the QP is identical by checking the QP number inside the CQE against the QP number inside the mlx5_ib_qp, but that's wrong since the QP number from the CQE is from FW so it should be matched against mlx5_core_qp which is our FW QP number. Otherwise we could use the wrong QP when handling a CQE which could cause the kernel trace below. This issue is mainly noticeable over QPs 0 & 1, since for now they are the only QPs in our driver whereas the QP number inside mlx5_ib_qp doesn't match the QP number inside mlx5_core_qp. BUG: kernel NULL pointer dereference, address: 0000000000000012 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core] RIP: 0010:mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] Code: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 <0f> b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21 RSP: 0018:ffff88810511bd60 EFLAGS: 00010046 RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a RBP: 00000000000000b0 R08: 0000000000000000 R09: ffff88810511bc10 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88810d593000 R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0 FS: 0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0 Call Trace: ? __die+0x20/0x60 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x130 ? asm_exc_page_fault+0x22/0x30 ? mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] __ib_process_cq+0x5a/0x150 [ib_core] ib_cq_poll_work+0x31/0x90 [ib_core] process_one_work+0x169/0x320 worker_thread+0x288/0x3a0 ? work_busy+0xb0/0xb0 kthread+0xd7/0x1f0 ? kthreads_online_cpu+0x130/0x130 ? kthreads_online_cpu+0x130/0x130 ret_from_fork+0x2d/0x50 ? kthreads_online_cpu+0x130/0x130 ret_from_fork_asm+0x11/0x20 Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Signed-off-by: Patrisious Haddad Reviewed-by: Edward Srouji Link: https://patch.msgid.link/4ada09d41f1e36db62c44a9b25c209ea5f054316.1741875692.git.leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 1a86ae57b2600e5749f5f674e9d4296ac00c69a8 Author: Jiayuan Chen Date: Fri Feb 14 17:18:21 2025 +0800 bpf: Fix array bounds error with may_goto [ Upstream commit 6ebc5030e0c5a698f1dd9a6684cddf6ccaed64a0 ] may_goto uses an additional 8 bytes on the stack, which causes the interpreters[] array to go out of bounds when calculating index by stack_size. 1. If a BPF program is rewritten, re-evaluate the stack size. For non-JIT cases, reject loading directly. 2. For non-JIT cases, calculating interpreters[idx] may still cause out-of-bounds array access, and just warn about it. 3. For jit_requested cases, the execution of bpf_func also needs to be warned. So move the definition of function __bpf_prog_ret0_warn out of the macro definition CONFIG_BPF_JIT_ALWAYS_ON. Reported-by: syzbot+d2a2c639d03ac200a4f1@syzkaller.appspotmail.com Closes: https://lore.kernel.org/bpf/0000000000000f823606139faa5d@google.com/ Fixes: 011832b97b311 ("bpf: Introduce may_goto instruction") Signed-off-by: Jiayuan Chen Link: https://lore.kernel.org/r/20250214091823.46042-2-mrpre@163.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 409160e7dbc5f7649de4c1e1b8990341d872c239 Author: Neil Armstrong Date: Wed Mar 5 20:00:29 2025 +0100 clk: qcom: gcc-sm8650: Do not turn off USB GDSCs during gdsc_disable() [ Upstream commit 8b75c2973997e66fd897b7e87b5ba2f3d683e94b ] With PWRSTS_OFF_ON, USB GDSCs are turned off during gdsc_disable(). This can happen during scenarios such as system suspend and breaks the resume of USB controller from suspend. So use PWRSTS_RET_ON to indicate the GDSC driver to not turn off the GDSCs during gdsc_disable() and allow the hardware to transition the GDSCs to retention when the parent domain enters low power state during system suspend. Fixes: c58225b7e3d7 ("clk: qcom: add the SM8650 Global Clock Controller driver, part 1") Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20250305-topic-sm8650-upstream-fix-usb-suspend-v1-1-649036ab0557@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 5ca11c75d4500609b27f024878dd562e1f156cc2 Author: Herbert Xu Date: Sat Mar 15 16:50:42 2025 +0800 crypto: nx - Fix uninitialised hv_nxc on error [ Upstream commit 9b00eb923f3e60ca76cbc8b31123716f3a87ac6a ] The compiler correctly warns that hv_nxc may be used uninitialised as that will occur when NX-GZIP is unavailable. Fix it by rearranging the code and delay setting caps_feat until the final query succeeds. Fixes: b4ba22114c78 ("crypto/nx: Get NX capabilities for GZIP coprocessor type") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit c93d8d693a5ac357f085ce77c2ac4297bc6809d1 Author: Dario Binacchi Date: Fri Jan 24 12:16:54 2025 +0100 clk: stm32f4: fix an uninitialized variable [ Upstream commit 9c981c868f5f335e1b51e766b5d36799de163d43 ] The variable s, used by pr_debug() to print the mnemonic of the modulation depth in use, was not initialized. Fix the output by addressing the correct mnemonic. Fixes: 65b3516dbe50 ("clk: stm32f4: support spread spectrum clock generation") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/77355eb9-19b3-46e5-a003-c21c0fae5bcd@stanley.mountain Signed-off-by: Dario Binacchi Link: https://lore.kernel.org/r/20250124111711.1051436-1-dario.binacchi@amarulasolutions.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 944f3c3bf8fa897d3b17fc2f7574162d5f0451b5 Author: Herbert Xu Date: Sun Mar 16 17:50:24 2025 +0800 crypto: api - Call crypto_alg_put in crypto_unregister_alg [ Upstream commit 27b13425349e94ad77b174b032674097cab241c8 ] Instead of calling cra_destroy by hand, call it through crypto_alg_put so that the correct unwinding functions are called through crypto_destroy_alg. Fixes: 3d6979bf3bd5 ("crypto: api - Add cra_type->destroy hook") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit b96fc7fef3d3759bfd332661fe8fabab77db4398 Author: Artur Weber Date: Sun Mar 16 21:11:49 2025 +0100 power: supply: max77693: Fix wrong conversion of charge input threshold value [ Upstream commit 30cc7b0d0e9341d419eb7da15fb5c22406dbe499 ] The charge input threshold voltage register on the MAX77693 PMIC accepts four values: 0x0 for 4.3v, 0x1 for 4.7v, 0x2 for 4.8v and 0x3 for 4.9v. Due to an oversight, the driver calculated the values for 4.7v and above starting from 0x0, rather than from 0x1 ([(4700000 - 4700000) / 100000] gives 0). Add 1 to the calculation to ensure that 4.7v is converted to a register value of 0x1 and that the other two voltages are converted correctly as well. Fixes: 87c2d9067893 ("power: max77693: Add charger driver for Maxim 77693") Signed-off-by: Artur Weber Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20250316-max77693-charger-input-threshold-fix-v1-1-2b037d0ac722@gmail.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit c56a4d89a2d9f82a10a9cf18b8ee7a9b2b61d736 Author: Jann Horn Date: Tue Mar 25 03:01:22 2025 +0100 x86/entry: Fix ORC unwinder for PUSH_REGS with save_ret=1 [ Upstream commit 57e2428f8df8263275344566e02c277648a4b7f1 ] PUSH_REGS with save_ret=1 is used by interrupt entry helper functions that initially start with a UNWIND_HINT_FUNC ORC state. However, save_ret=1 means that we clobber the helper function's return address (and then later restore the return address further down on the stack); after that point, the only thing on the stack we can unwind through is the IRET frame, so use UNWIND_HINT_IRET_REGS until we have a full pt_regs frame. ( An alternate approach would be to move the pt_regs->di overwrite down such that it is the final step of pt_regs setup; but I don't want to rearrange entry code just to make unwinding a tiny bit more elegant. ) Fixes: 9e809d15d6b6 ("x86/entry: Reduce the code footprint of the 'idtentry' macro") Signed-off-by: Jann Horn Signed-off-by: Ingo Molnar Cc: Andy Lutomirski Cc: Brian Gerst Cc: Juergen Gross Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Kees Cook Cc: Peter Zijlstra Cc: Josh Poimboeuf Link: https://lore.kernel.org/r/20250325-2025-03-unwind-fixes-v1-1-acd774364768@google.com Signed-off-by: Sasha Levin commit b36fd5d8fdac20ac0f7746ae071e0aaf5a5ab35d Author: Bartosz Golaszewski Date: Wed Feb 19 11:27:50 2025 +0100 pinctrl: bcm2835: don't -EINVAL on alternate funcs from get_direction() [ Upstream commit 75f87f5d04f73645136d7a603c331d844fc5704a ] Since commit 9d846b1aebbe ("gpiolib: check the return value of gpio_chip::get_direction()") we check the return value of the get_direction() callback as per its API contract. This driver returns -EINVAL if the pin in question is set to one of the alternative (non-GPIO) functions. This isn't really an error that should be communicated to GPIOLIB so default to returning the "safe" value of INPUT in this case. The GPIO subsystem does not have the notion of "unknown" direction. Fixes: 9d846b1aebbe ("gpiolib: check the return value of gpio_chip::get_direction()") Reported-by: Mark Brown Closes: https://lore.kernel.org/all/Z7VFB1nST6lbmBIo@finisterre.sirena.org.uk/ Signed-off-by: Bartosz Golaszewski Tested-by: Marek Szyprowski Reviewed-by: Stefan Wahren Link: https://lore.kernel.org/20250219102750.38519-1-brgl@bgdev.pl Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit be19a32a00862fc58105afb5c774357b1c65ea12 Author: Jerome Brunet Date: Fri Dec 13 11:03:23 2024 +0100 clk: amlogic: g12a: fix mmc A peripheral clock [ Upstream commit 0079e77c08de692cb20b38e408365c830a44b1ef ] The bit index of the peripheral clock for mmc A is wrong This was probably not a problem for mmc A as the peripheral is likely left enabled by the bootloader. No issues has been reported so far but it could be a problem, most likely some form of conflict between the ethernet and mmc A clock, breaking ethernet on init. Use the value provided by the documentation for mmc A before this becomes an actual problem. Fixes: 085a4ea93d54 ("clk: meson: g12a: add peripheral clock controller") Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20241213-amlogic-clk-g12a-mmca-fix-v1-1-5af421f58b64@baylibre.com Signed-off-by: Jerome Brunet Signed-off-by: Sasha Levin commit 8ad1206dde46b4383a2e4cff28475d0c6eaf9d56 Author: Laurentiu Mihalcea Date: Wed Feb 26 11:45:11 2025 -0500 clk: clk-imx8mp-audiomix: fix dsp/ocram_a clock parents [ Upstream commit 91be7d27099dedf813b80702e4ca117d1fb38ce6 ] The DSP and OCRAM_A modules from AUDIOMIX are clocked by AUDIO_AXI_CLK_ROOT, not AUDIO_AHB_CLK_ROOT. Update the clock data accordingly. Fixes: 6cd95f7b151c ("clk: imx: imx8mp: Add audiomix block control") Signed-off-by: Laurentiu Mihalcea Reviewed-by: Iuliana Prodan Reviewed-by: Peng Fan Link: https://lore.kernel.org/r/20250226164513.33822-3-laurentiumihalcea111@gmail.com Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin commit 5a92a8d8ca688cb10513928ea8396d108ce7b641 Author: Bairavi Alagappan Date: Fri Mar 14 15:09:31 2025 +0000 crypto: qat - remove access to parity register for QAT GEN4 [ Upstream commit 92c6a707d82f0629debf1c21dd87717776d96af2 ] The firmware already handles parity errors reported by the accelerators by clearing them through the corresponding SSMSOFTERRORPARITY register. To ensure consistent behavior and prevent race conditions between the driver and firmware, remove the logic that checks the SSMSOFTERRORPARITY registers. Additionally, change the return type of the function adf_handle_rf_parr_err() to void, as it consistently returns false. Parity errors are recoverable and do not necessitate a device reset. Fixes: 895f7d532c84 ("crypto: qat - add handling of errors from ERRSOU2 for QAT GEN4") Signed-off-by: Bairavi Alagappan Reviewed-by: Andy Shevchenko Signed-off-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 6d36a388c555cc39ad145c77707a40c574a7adad Author: Jinghao Jia Date: Mon Feb 3 02:55:05 2025 -0600 samples/bpf: Fix broken vmlinux path for VMLINUX_BTF [ Upstream commit 94f53edc64e19640b5245721cd6d0c4a84f52587 ] Commit 13b25489b6f8 ("kbuild: change working directory to external module directory with M=") changed kbuild working directory of bpf sample programs to samples/bpf, which broke the vmlinux path for VMLINUX_BTF, as the Makefiles assume the current work directory to be the kernel output directory and use a relative path (i.e., ./vmlinux): Makefile:316: *** Cannot find a vmlinux for VMLINUX_BTF at any of " /path/to/linux/samples/bpf/vmlinux", build the kernel or set VMLINUX_BTF like "VMLINUX_BTF=/sys/kernel/btf/vmlinux" or VMLINUX_H variable. Stop. Correctly refer to the kernel output directory using $(objtree). Fixes: 13b25489b6f8 ("kbuild: change working directory to external module directory with M=") Signed-off-by: Jinghao Jia Signed-off-by: Andrii Nakryiko Tested-by: Ruowen Qin Link: https://lore.kernel.org/bpf/20250203085506.220297-3-jinghao7@illinois.edu Signed-off-by: Sasha Levin commit 6874ed89895c36c79e623bb8af62853cc56ec7dc Author: Andy Shevchenko Date: Tue Mar 18 12:57:14 2025 +0200 pinctrl: npcm8xx: Fix incorrect struct npcm8xx_pincfg assignment [ Upstream commit 113ec87b0f26a17b02c58aa2714a9b8f1020eed9 ] Sparse is not happy about implementation of the NPCM8XX_PINCFG() pinctrl-npcm8xx.c:1314:9: warning: obsolete array initializer, use C99 syntax pinctrl-npcm8xx.c:1315:9: warning: obsolete array initializer, use C99 syntax ... pinctrl-npcm8xx.c:1412:9: warning: obsolete array initializer, use C99 syntax pinctrl-npcm8xx.c:1413:9: warning: too many warnings which uses index-based assignment in a wrong way, i.e. it missed the equal sign and hence the index is simply ignored, while the entries are indexed naturally. This is not a problem as the pin numbering repeats the natural order, but it might be in case of shuffling the entries. Fix this by adding missed equal sign and reformat a bit for better readability. Fixes: acf4884a5717 ("pinctrl: nuvoton: add NPCM8XX pinctrl and GPIO driver") Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/20250318105932.2090926-2-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 83346501b43f8c014081257017b5c2394ec72699 Author: Charles Han Date: Fri Mar 7 14:47:07 2025 +0800 clk: mmp: Fix NULL vs IS_ERR() check [ Upstream commit 00153c64a72d336cc61f4141e5be53b49b7797e1 ] The devm_kzalloc() function returns NULL on error, not error pointers. Fix the check. Fixes: 03437e857b0a ("clk: mmp: Add Marvell PXA1908 APMU driver") Signed-off-by: Charles Han Link: https://lore.kernel.org/r/20250307064708.209511-1-hanchunchao@inspur.com Reviewed-by: Krzysztof Kozlowski Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit a6306110f54176c4bbc5ff6f04a4f4b4e8f47ad9 Author: Ian Rogers Date: Thu Mar 20 15:24:39 2025 -0700 libbpf: Add namespace for errstr making it libbpf_errstr [ Upstream commit 307ef667e94530c2f2f77797bfe9ea85c22bec7d ] When statically linking symbols can be replaced with those from other statically linked libraries depending on the link order and the hoped for "multiple definition" error may not appear. To avoid conflicts it is good practice to namespace symbols, this change renames errstr to libbpf_errstr. To avoid churn a #define is used to turn use of errstr(err) to libbpf_errstr(err). Fixes: 1633a83bf993 ("libbpf: Introduce errstr() for stringifying errno") Signed-off-by: Ian Rogers Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250320222439.1350187-1-irogers@google.com Signed-off-by: Sasha Levin commit 70ca29ae174cbaaca3a8c5829dc78fad675b016e Author: Nathan Chancellor Date: Thu Mar 13 16:29:31 2025 +0100 crypto: tegra - Fix format specifier in tegra_sha_prep_cmd() [ Upstream commit 795e5bdb0ada2c77ea28611d88f1d5d7ca9b2f4d ] When building for 32-bit targets, for which ssize_t is 'int' instead of 'long', there is a warning due to an incorrect format specifier: In file included from include/linux/printk.h:610, from include/linux/kernel.h:31, from include/linux/clk.h:13, from drivers/crypto/tegra/tegra-se-hash.c:7: drivers/crypto/tegra/tegra-se-hash.c: In function 'tegra_sha_prep_cmd': drivers/crypto/tegra/tegra-se-hash.c:343:26: error: format '%lu' expects argument of type 'long unsigned int', but argument 6 has type 'ssize_t' {aka 'int'} [-Werror=format=] 343 | dev_dbg(se->dev, "msg len %llu msg left %llu sz %lu cfg %#x", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... drivers/crypto/tegra/tegra-se-hash.c:343:59: note: format string is defined here 343 | dev_dbg(se->dev, "msg len %llu msg left %llu sz %lu cfg %#x", | ~~^ | | | long unsigned int | %u cc1: all warnings being treated as errors Use '%zd', the proper specifier for ssize_t, to resolve the warning. Fixes: ff4b7df0b511 ("crypto: tegra - Fix HASH intermediate result handling") Signed-off-by: Nathan Chancellor Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 3083459852c7f9794b8c156abd9bcd3019c7623d Author: Alice Ryhl Date: Mon Mar 3 08:45:12 2025 +0000 rust: fix signature of rust_fmt_argument [ Upstream commit 901b3290bd4dc35e613d13abd03c129e754dd3dd ] Without this change, the rest of this series will emit the following error message: error[E0308]: `if` and `else` have incompatible types --> /rust/kernel/print.rs:22:22 | 21 | #[export] | --------- expected because of this 22 | unsafe extern "C" fn rust_fmt_argument( | ^^^^^^^^^^^^^^^^^ expected `u8`, found `i8` | = note: expected fn item `unsafe extern "C" fn(*mut u8, *mut u8, *mut c_void) -> *mut u8 {bindings::rust_fmt_argument}` found fn item `unsafe extern "C" fn(*mut i8, *mut i8, *const c_void) -> *mut i8 {print::rust_fmt_argument}` The error may be different depending on the architecture. To fix this, change the void pointer argument to use a const pointer, and change the imports to use crate::ffi instead of core::ffi for integer types. Fixes: 787983da7718 ("vsprintf: add new `%pA` format specifier") Reviewed-by: Tamir Duberstein Acked-by: Greg Kroah-Hartman Signed-off-by: Alice Ryhl Acked-by: Petr Mladek Link: https://lore.kernel.org/r/20250303-export-macro-v3-1-41fbad85a27f@google.com Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit 0129fd53624b4b52420846ad9204bbf29399bfdf Author: Saket Kumar Bhaskar Date: Fri Jan 31 12:35:22 2025 +0530 selftests/bpf: Select NUMA_NO_NODE to create map [ Upstream commit 4107a1aeb20ed4cdad6a0d49de92ea0f933c71b7 ] On powerpc, a CPU does not necessarily originate from NUMA node 0. This contrasts with architectures like x86, where CPU 0 is not hot-pluggable, making NUMA node 0 a consistently valid node. This discrepancy can lead to failures when creating a map on NUMA node 0, which is initialized by default, if no CPUs are allocated from NUMA node 0. This patch fixes the issue by setting NUMA_NO_NODE (-1) for map creation for this selftest. Fixes: 96eabe7a40aa ("bpf: Allow selecting numa node during map creation") Signed-off-by: Saket Kumar Bhaskar Signed-off-by: Andrii Nakryiko Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/cf1f61468b47425ecf3728689bc9636ddd1d910e.1738302337.git.skb99@linux.ibm.com Signed-off-by: Sasha Levin commit 1eb7a2f3e25075b2dc9b10c94616b066f80e79ee Author: Jerome Brunet Date: Fri Dec 20 11:25:37 2024 +0100 clk: amlogic: gxbb: drop non existing 32k clock parent [ Upstream commit 7915d7d5407c026fa9343befb4d3343f7a345f97 ] The 32k clock reference a parent 'cts_slow_oscin' with a fixme note saying that this clock should be provided by AO controller. The HW probably has this clock but it does not exist at the moment in any controller implementation. Furthermore, referencing clock by the global name should be avoided whenever possible. There is no reason to keep this hack around, at least for now. Fixes: 14c735c8e308 ("clk: meson-gxbb: Add EE 32K Clock for CEC") Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20241220-amlogic-clk-gxbb-32k-fixes-v1-2-baca56ecf2db@baylibre.com Signed-off-by: Jerome Brunet Signed-off-by: Sasha Levin commit 4f2546e626519ccda4b9b9e5cebb58666b695e6e Author: Jerome Brunet Date: Fri Dec 13 15:30:17 2024 +0100 clk: amlogic: g12b: fix cluster A parent data [ Upstream commit 8995f8f108c3ac5ad52b12a6cfbbc7b3b32e9a58 ] Several clocks used by both g12a and g12b use the g12a cpu A clock hw pointer as clock parent. This is incorrect on g12b since the parents of cluster A cpu clock are different. Also the hw clock provided as parent to these children is not even registered clock on g12b. Fix the problem by reverting to the global namespace and let CCF pick the appropriate, as it is already done for other clocks, such as cpu_clk_trace_div. Fixes: 25e682a02d91 ("clk: meson: g12a: migrate to the new parent description method") Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20241213-amlogic-clk-g12a-cpua-parent-fix-v1-1-d8c0f41865fe@baylibre.com Signed-off-by: Jerome Brunet Signed-off-by: Sasha Levin commit 5405e05a428b51027496664275c8ee890725e8b8 Author: Prathamesh Shete Date: Thu Mar 6 10:35:42 2025 +0530 pinctrl: tegra: Set SFIO mode to Mux Register [ Upstream commit 17013f0acb322e5052ff9b9d0fab0ab5a4bfd828 ] Tegra devices have an 'sfsel' bit field that determines whether a pin operates in SFIO (Special Function I/O) or GPIO mode. Currently, tegra_pinctrl_gpio_disable_free() sets this bit when releasing a GPIO. However, tegra_pinctrl_set_mux() can be called independently in certain code paths where gpio_disable_free() is not invoked. In such cases, failing to set the SFIO mode could lead to incorrect pin configurations, resulting in functional issues for peripherals relying on SFIO. This patch ensures that whenever set_mux() is called, the SFIO mode is correctly set in the Mux Register if the 'sfsel' bit is present. This prevents situations where the pin remains in GPIO mode despite being configured for SFIO use. Fixes: 971dac7123c7 ("pinctrl: add a driver for NVIDIA Tegra") Signed-off-by: Prathamesh Shete Link: https://lore.kernel.org/20250306050542.16335-1-pshete@nvidia.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 204e555972a0878eab1449f906ae215a58787acd Author: Maher Sanalla Date: Thu Mar 13 16:20:17 2025 +0200 IB/mad: Check available slots before posting receive WRs [ Upstream commit 37826f0a8c2f6b6add5179003b8597e32a445362 ] The ib_post_receive_mads() function handles posting receive work requests (WRs) to MAD QPs and is called in two cases: 1) When a MAD port is opened. 2) When a receive WQE is consumed upon receiving a new MAD. Whereas, if MADs arrive during the port open phase, a race condition might cause an extra WR to be posted, exceeding the QP’s capacity. This leads to failures such as: infiniband mlx5_0: ib_post_recv failed: -12 infiniband mlx5_0: Couldn't post receive WRs infiniband mlx5_0: Couldn't start port infiniband mlx5_0: Couldn't open port 1 Fix this by checking the current receive count before posting a new WR. If the QP’s receive queue is full, do not post additional WRs. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Maher Sanalla Link: https://patch.msgid.link/c4984ba3c3a98a5711a558bccefcad789587ecf1.1741875592.git.leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit af8ee85ef099e392f2b499ff3a2d4d916073457f Author: Herbert Xu Date: Fri Feb 14 10:31:25 2025 +0800 crypto: api - Fix larval relookup type and mask [ Upstream commit 7505436e2925d89a13706a295a6734d6cabb4b43 ] When the lookup is retried after instance construction, it uses the type and mask from the larval, which may not match the values used by the caller. For example, if the caller is requesting for a !NEEDS_FALLBACK algorithm, it may end up getting an algorithm that needs fallbacks. Fix this by making the caller supply the type/mask and using that for the lookup. Reported-by: Coiby Xu Fixes: 96ad59552059 ("crypto: api - Remove instance larval fulfilment") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 398168477aed1ffc92165b5c0a6a58a043341173 Author: Thomas Weißschuh Date: Tue Feb 4 07:52:50 2025 +0100 leds: st1202: Check for error code from devm_mutex_init() call [ Upstream commit 8168906bbb3ba678583422de29e6349407a94bb5 ] Even if it's not critical, the avoidance of checking the error code from devm_mutex_init() call today diminishes the point of using devm variant of it. Tomorrow it may even leak something. Add the missed check. Fixes: 259230378c65 ("leds: Add LED1202 I2C driver") Signed-off-by: Thomas Weißschuh Link: https://lore.kernel.org/r/20250204-must_check-devm_mutex_init-v2-1-7b6271c4b7e6@weissschuh.net Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 421ef42b0e67f3a4f128aa867294f3d3be336c0a Author: Sicelo A. Mhlongo Date: Mon Nov 25 17:29:30 2024 +0200 power: supply: bq27xxx_battery: do not update cached flags prematurely [ Upstream commit 45291874a762dbb12a619dc2efaf84598859007a ] Commit 243f8ffc883a1 ("power: supply: bq27xxx_battery: Notify also about status changes") intended to notify userspace when the status changes, based on the flags register. However, the cached state is updated too early, before the flags are tested for any changes. Remove the premature update. Fixes: 243f8ffc883a1 ("power: supply: bq27xxx_battery: Notify also about status changes") Signed-off-by: Sicelo A. Mhlongo Link: https://lore.kernel.org/r/20241125152945.47937-1-absicsz@gmail.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit f26ccf859483f3edcc3e65d0281aacae3bbd3d3f Author: Luca Weiss Date: Mon Feb 17 23:05:18 2025 +0100 remoteproc: qcom_q6v5_mss: Handle platforms with one power domain [ Upstream commit 4641840341f37dc8231e0840ec1514b4061b4322 ] For example MSM8974 has mx voltage rail exposed as regulator and only cx voltage rail is exposed as power domain. This power domain (cx) is attached internally in power domain and cannot be attached in this driver. Fixes: 8750cf392394 ("remoteproc: qcom_q6v5_mss: Allow replacing regulators with power domains") Co-developed-by: Matti Lehtimäki Signed-off-by: Matti Lehtimäki Reviewed-by: Stephan Gerhold Signed-off-by: Luca Weiss Link: https://lore.kernel.org/r/20250217-msm8226-modem-v5-4-2bc74b80e0ae@lucaweiss.eu Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 7aa6bb5276d9fec98deb05615a086eeb893854ad Author: Cheng Xu Date: Thu Mar 6 20:04:40 2025 +0800 RDMA/erdma: Prevent use-after-free in erdma_accept_newconn() [ Upstream commit 83437689249e6a17b25e27712fbee292e42e7855 ] After the erdma_cep_put(new_cep) being called, new_cep will be freed, and the following dereference will cause a UAF problem. Fix this issue. Fixes: 920d93eac8b9 ("RDMA/erdma: Add connection management (CM) support") Signed-off-by: Markus Elfring Signed-off-by: Cheng Xu Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 4c23ef91027f0eba44233d312c016d6a33ebe1e8 Author: Chiara Meiohas Date: Thu Mar 13 16:29:54 2025 +0200 RDMA/mlx5: Fix calculation of total invalidated pages [ Upstream commit 79195147644653ebffadece31a42181e4c48c07d ] When invalidating an address range in mlx5, there is an optimization to do UMR operations in chunks. Previously, the invalidation counter was incorrectly updated for the same indexes within a chunk. Now, the invalidation counter is updated only when a chunk is complete and mlx5r_umr_update_xlt() is called. This ensures that the counter accurately represents the number of pages invalidated using UMR. Fixes: a3de94e3d61e ("IB/mlx5: Introduce ODP diagnostic counters") Signed-off-by: Chiara Meiohas Reviewed-by: Michael Guralnik Link: https://patch.msgid.link/560deb2433318e5947282b070c915f3c81fef77f.1741875692.git.leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 6682da5d8fd578a5068531d01633c9d2e4c8f12b Author: Roman Gushchin Date: Thu Feb 27 16:54:20 2025 +0000 RDMA/core: Don't expose hw_counters outside of init net namespace [ Upstream commit a1ecb30f90856b0be4168ad51b8875148e285c1f ] Commit 467f432a521a ("RDMA/core: Split port and device counter sysfs attributes") accidentally almost exposed hw counters to non-init net namespaces. It didn't expose them fully, as an attempt to read any of those counters leads to a crash like this one: [42021.807566] BUG: kernel NULL pointer dereference, address: 0000000000000028 [42021.814463] #PF: supervisor read access in kernel mode [42021.819549] #PF: error_code(0x0000) - not-present page [42021.824636] PGD 0 P4D 0 [42021.827145] Oops: 0000 [#1] SMP PTI [42021.830598] CPU: 82 PID: 2843922 Comm: switchto-defaul Kdump: loaded Tainted: G S W I XXX [42021.841697] Hardware name: XXX [42021.849619] RIP: 0010:hw_stat_device_show+0x1e/0x40 [ib_core] [42021.855362] Code: 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 49 89 d0 4c 8b 5e 20 48 8b 8f b8 04 00 00 48 81 c7 f0 fa ff ff <48> 8b 41 28 48 29 ce 48 83 c6 d0 48 c1 ee 04 69 d6 ab aa aa aa 48 [42021.873931] RSP: 0018:ffff97fe90f03da0 EFLAGS: 00010287 [42021.879108] RAX: ffff9406988a8c60 RBX: ffff940e1072d438 RCX: 0000000000000000 [42021.886169] RDX: ffff94085f1aa000 RSI: ffff93c6cbbdbcb0 RDI: ffff940c7517aef0 [42021.893230] RBP: ffff97fe90f03e70 R08: ffff94085f1aa000 R09: 0000000000000000 [42021.900294] R10: ffff94085f1aa000 R11: ffffffffc0775680 R12: ffffffff87ca2530 [42021.907355] R13: ffff940651602840 R14: ffff93c6cbbdbcb0 R15: ffff94085f1aa000 [42021.914418] FS: 00007fda1a3b9700(0000) GS:ffff94453fb80000(0000) knlGS:0000000000000000 [42021.922423] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [42021.928130] CR2: 0000000000000028 CR3: 00000042dcfb8003 CR4: 00000000003726f0 [42021.935194] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [42021.942257] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [42021.949324] Call Trace: [42021.951756] [42021.953842] [] ? show_regs+0x64/0x70 [42021.959030] [] ? __die+0x78/0xc0 [42021.963874] [] ? page_fault_oops+0x2b5/0x3b0 [42021.969749] [] ? exc_page_fault+0x1a2/0x3c0 [42021.975549] [] ? asm_exc_page_fault+0x26/0x30 [42021.981517] [] ? __pfx_show_hw_stats+0x10/0x10 [ib_core] [42021.988482] [] ? hw_stat_device_show+0x1e/0x40 [ib_core] [42021.995438] [] dev_attr_show+0x1e/0x50 [42022.000803] [] sysfs_kf_seq_show+0x81/0xe0 [42022.006508] [] seq_read_iter+0xf4/0x410 [42022.011954] [] vfs_read+0x16e/0x2f0 [42022.017058] [] ksys_read+0x6e/0xe0 [42022.022073] [] do_syscall_64+0x6a/0xa0 [42022.027441] [] entry_SYSCALL_64_after_hwframe+0x78/0xe2 The problem can be reproduced using the following steps: ip netns add foo ip netns exec foo bash cat /sys/class/infiniband/mlx4_0/hw_counters/* The panic occurs because of casting the device pointer into an ib_device pointer using container_of() in hw_stat_device_show() is wrong and leads to a memory corruption. However the real problem is that hw counters should never been exposed outside of the non-init net namespace. Fix this by saving the index of the corresponding attribute group (it might be 1 or 2 depending on the presence of driver-specific attributes) and zeroing the pointer to hw_counters group for compat devices during the initialization. With this fix applied hw_counters are not available in a non-init net namespace: find /sys/class/infiniband/mlx4_0/ -name hw_counters /sys/class/infiniband/mlx4_0/ports/1/hw_counters /sys/class/infiniband/mlx4_0/ports/2/hw_counters /sys/class/infiniband/mlx4_0/hw_counters ip netns add foo ip netns exec foo bash find /sys/class/infiniband/mlx4_0/ -name hw_counters Fixes: 467f432a521a ("RDMA/core: Split port and device counter sysfs attributes") Signed-off-by: Roman Gushchin Cc: Jason Gunthorpe Cc: Leon Romanovsky Cc: Maher Sanalla Cc: linux-rdma@vger.kernel.org Cc: linux-kernel@vger.kernel.org Link: https://patch.msgid.link/20250227165420.3430301-1-roman.gushchin@linux.dev Reviewed-by: Parav Pandit Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 4bcb85b4f58aa68d13ac8ac539b9d6deb26001e9 Author: Peter Geis Date: Wed Jan 15 01:26:22 2025 +0000 clk: rockchip: rk3328: fix wrong clk_ref_usb3otg parent [ Upstream commit a9e60f1ffe1ca57d6af6a2573e2f950e76efbf5b ] Correct the clk_ref_usb3otg parent to fix clock control for the usb3 controller on rk3328. Verified against the rk3328 trm, the rk3228h trm, and the rk3328 usb3 phy clock map. Fixes: fe3511ad8a1c ("clk: rockchip: add clock controller for rk3328") Signed-off-by: Peter Geis Reviewed-by: Dragan Simic Link: https://lore.kernel.org/r/20250115012628.1035928-2-pgwipeout@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 49fd736fd6bc7ed75404ec4555cefdee26695e3a Author: Tengda Wu Date: Wed Jan 22 10:28:38 2025 +0800 selftests/bpf: Fix freplace_link segfault in tailcalls prog test [ Upstream commit a63a631c9b5cb25a1c17dd2cb18c63df91e978b1 ] There are two bpf_link__destroy(freplace_link) calls in test_tailcall_bpf2bpf_freplace(). After the first bpf_link__destroy() is called, if the following bpf_map_{update,delete}_elem() throws an exception, it will jump to the "out" label and call bpf_link__destroy() again, causing double free and eventually leading to a segfault. Fix it by directly resetting freplace_link to NULL after the first bpf_link__destroy() call. Fixes: 021611d33e78 ("selftests/bpf: Add test to verify tailcall and freplace restrictions") Signed-off-by: Tengda Wu Signed-off-by: Andrii Nakryiko Reviewed-by: Leon Hwang Link: https://lore.kernel.org/bpf/20250122022838.1079157-1-wutengda@huaweicloud.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 6a49f8d41d75adbf474f00ff605ca1d9209c5ae9 Author: Michael Guralnik Date: Thu Mar 13 16:29:48 2025 +0200 RDMA/mlx5: Fix MR cache initialization error flow [ Upstream commit a0130ef84b00c68ba0b79ee974a0f01459741421 ] Destroy all previously created cache entries and work queue when rolling back the MR cache initialization upon an error. Fixes: 73d09b2fe833 ("RDMA/mlx5: Introduce mlx5r_cache_rb_key") Signed-off-by: Michael Guralnik Reviewed-by: Yishai Hadas Link: https://patch.msgid.link/c41d525fb3c72e28dd38511bf3aaccb5d584063e.1741875692.git.leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 9c7a8a6174b2d4e0e461c698630183a1e3584f6b Author: Fabrizio Castro Date: Wed Mar 5 16:37:51 2025 +0000 pinctrl: renesas: rzg2l: Fix missing of_node_put() call [ Upstream commit a5779e625e2b377f16a6675c432aaf299ce5028c ] of_parse_phandle_with_fixed_args() requires its caller to call into of_node_put() on the node pointer from the output structure, but such a call is currently missing. Call into of_node_put() to rectify that. Fixes: c4c4637eb57f ("pinctrl: renesas: Add RZ/G2L pin and gpio controller driver") Signed-off-by: Fabrizio Castro Reviewed-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/20250305163753.34913-3-fabrizio.castro.jz@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit a03d08d8764597e8013feb690485bece33ac55d0 Author: Fabrizio Castro Date: Wed Mar 5 16:37:53 2025 +0000 pinctrl: renesas: rza2: Fix missing of_node_put() call [ Upstream commit abcdeb4e299a11ecb5a3ea0cce00e68e8f540375 ] of_parse_phandle_with_fixed_args() requires its caller to call into of_node_put() on the node pointer from the output structure, but such a call is currently missing. Call into of_node_put() to rectify that. Fixes: b59d0e782706 ("pinctrl: Add RZ/A2 pin and gpio controller") Signed-off-by: Fabrizio Castro Reviewed-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/20250305163753.34913-5-fabrizio.castro.jz@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 78ba74b9aa19d26c6424bf556f1c908423accab6 Author: Tanya Agarwal Date: Tue Jan 14 19:42:04 2025 +0530 lib: 842: Improve error handling in sw842_compress() [ Upstream commit af324dc0e2b558678aec42260cce38be16cc77ca ] The static code analysis tool "Coverity Scan" pointed the following implementation details out for further development considerations: CID 1309755: Unused value In sw842_compress: A value assigned to a variable is never used. (CWE-563) returned_value: Assigning value from add_repeat_template(p, repeat_count) to ret here, but that stored value is overwritten before it can be used. Conclusion: Add error handling for the return value from an add_repeat_template() call. Fixes: 2da572c959dd ("lib: add software 842 compression/decompression") Signed-off-by: Tanya Agarwal Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 3b650bf7026fac5a6cf4948c62a59851a328bb63 Author: Hou Tao Date: Thu Feb 20 12:22:59 2025 +0800 bpf: Use preempt_count() directly in bpf_send_signal_common() [ Upstream commit b4a8b5bba712a711d8ca1f7d04646db63f9c88f5 ] bpf_send_signal_common() uses preemptible() to check whether or not the current context is preemptible. If it is preemptible, it will use irq_work to send the signal asynchronously instead of trying to hold a spin-lock, because spin-lock is sleepable under PREEMPT_RT. However, preemptible() depends on CONFIG_PREEMPT_COUNT. When CONFIG_PREEMPT_COUNT is turned off (e.g., CONFIG_PREEMPT_VOLUNTARY=y), !preemptible() will be evaluated as 1 and bpf_send_signal_common() will use irq_work unconditionally. Fix it by unfolding "!preemptible()" and using "preempt_count() != 0 || irqs_disabled()" instead. Fixes: 87c544108b61 ("bpf: Send signals asynchronously if !preemptible") Signed-off-by: Hou Tao Link: https://lore.kernel.org/r/20250220042259.1583319-1-houtao@huaweicloud.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 1460ff6790af45a36e8900c71f2fbebaf1de925c Author: Akhil R Date: Mon Feb 24 14:46:09 2025 +0530 crypto: tegra - Reserve keyslots to allocate dynamically [ Upstream commit b157e7a228aee9b48c2de05129476b822aa7956d ] The HW supports only storing 15 keys at a time. This limits the number of tfms that can work without failutes. Reserve keyslots to solve this and use the reserved ones during the encryption/decryption operation. This allow users to have the capability of hardware protected keys and faster operations if there are limited number of tfms while not halting the operation if there are more tfms. Fixes: 0880bb3b00c8 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Akhil R Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 3ba914ad4991be67a4ff88ecaa388bafb55de298 Author: Akhil R Date: Mon Feb 24 14:46:03 2025 +0530 crypto: tegra - finalize crypto req on error [ Upstream commit 1e245948ca0c252f561792fabb45de5518301d97 ] Call the crypto finalize function before exiting *do_one_req() functions. This allows the driver to take up further requests even if the previous one fails. Fixes: 0880bb3b00c8 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Akhil R Signed-off-by: Herbert Xu Stable-dep-of: b157e7a228ae ("crypto: tegra - Reserve keyslots to allocate dynamically") Signed-off-by: Sasha Levin commit e157436980de04a60b52e2623f268d3ea43dd8fe Author: Konrad Dybcio Date: Sat Jan 11 17:54:18 2025 +0100 clk: qcom: gcc-x1e80100: Unregister GCC_GPU_CFG_AHB_CLK/GCC_DISP_XO_CLK [ Upstream commit b60521eff227ef459e03879cbea2b2bd85a8d7af ] The GPU clock is required for CPU access to GPUSS registers. It was previously decided (on this and many more platforms) that the added overhead/hassle introduced by keeping track of it would not bring much measurable improvement in the power department. The display clock is basically the same story over again. Now, we're past that discussion and this commit is not trying to change that. Instead, the clocks are both force-enabled in .probe *and* registered with the common clock framework, resulting in them being toggled off after ignore_unused. Unregister said clocks to fix breakage when clk_ignore_unused is absent (as it should be). Fixes: 161b7c401f4b ("clk: qcom: Add Global Clock controller (GCC) driver for X1E80100") Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20250111-topic-x1e_fixups-v1-1-77dc39237c12@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit eff3272783ba3d2e490214c0a824f0f8f86e0c7c Author: Luca Weiss Date: Tue Jan 28 22:53:59 2025 +0100 remoteproc: qcom_q6v5_pas: Use resource with CX PD for MSM8226 [ Upstream commit ba785ff4162a65f18ed501019637a998b752b5ad ] MSM8226 requires the CX power domain, so use the msm8996_adsp_resource which has cx under proxy_pd_names and is otherwise equivalent. Suggested-by: Stephan Gerhold Fixes: fb4f07cc9399 ("remoteproc: qcom: pas: Add MSM8226 ADSP support") Signed-off-by: Luca Weiss Reviewed-by: Stephan Gerhold Link: https://lore.kernel.org/r/20250128-pas-singlepd-v1-1-85d9ae4b0093@lucaweiss.eu Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 479cb7954522ea7391c1d31af421dbffce7b5793 Author: Akhil R Date: Mon Feb 24 14:46:08 2025 +0530 crypto: tegra - Set IV to NULL explicitly for AES ECB [ Upstream commit bde558220866e74f19450e16d9a2472b488dfedf ] It may happen that the variable req->iv may have stale values or zero sized buffer by default and may end up getting used during encryption/decryption. This inturn may corrupt the results or break the operation. Set the req->iv variable to NULL explicitly for algorithms like AES-ECB where IV is not used. Fixes: 0880bb3b00c8 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Akhil R Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 2979b2265caf770ac3d8cb13cbe6eddd5f62173b Author: Kees Bakker Date: Fri Feb 21 20:39:03 2025 +0100 RDMA/mana_ib: Ensure variable err is initialized [ Upstream commit be35a3127d60964b338da95c7bfaaf4a01b330d4 ] In the function mana_ib_gd_create_dma_region if there are no dma blocks to process the variable `err` remains uninitialized. Fixes: 0266a177631d ("RDMA/mana_ib: Add a driver for Microsoft Azure Network Adapter") Signed-off-by: Kees Bakker Link: https://patch.msgid.link/20250221195833.7516C16290A@bout3.ijzerbout.nl Reviewed-by: Long Li Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 9c31bd7358379355cbd7d8a4968d1464b05f2861 Author: Niklas Schnelle Date: Fri Feb 21 12:51:48 2025 +0100 s390: Remove ioremap_wt() and pgprot_writethrough() [ Upstream commit c94bff63e49302d4ce36502a85a2710a67332a4f ] It turns out that while s390 architecture calls its memory-I/O mapping variants write-through and write-back the implementation of ioremap_wt() and pgprot_writethrough() does not match Linux notion of ioremap_wt(). In particular Linux expects ioremap_wt() to be weaker still than ioremap_wc(), allowing not just gathering and re-ordering but also reads to be served from cache. Instead s390's implementation is equivalent to normal ioremap() while its ioremap_wc() allows re-ordering. Note that there are no known users of ioremap_wt() on s390 and the resulting behavior is in line with asm-generic defining ioremap_wt() as ioremap(), if undefined, so no breakage is expected. As s390 does not have a mapping type matching the Linux notion of ioremap_wt() and pgprot_writethrough(), simply drop them and rely on the asm-generic fallbacks instead. Fixes: b02002cc4c0f ("s390/pci: Implement ioremap_wc/prot() with MIO") Fixes: b43b3fff042d ("s390: mm: convert to GENERIC_IOREMAP") Acked-by: Heiko Carstens Signed-off-by: Niklas Schnelle Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 8b89a136171b39fa9adb64cb7a50967b24f92503 Author: Tony Ambardar Date: Fri Jan 24 23:14:23 2025 -0800 selftests/bpf: Fix runqslower cross-endian build [ Upstream commit cb3ade567816a03d1ac1c33bf86073574efcfcaf ] The runqslower binary from a cross-endian build currently fails to run because the included skeleton has host endianness. Fix this by passing the target BPF endianness to the runqslower sub-make. Fixes: 5a63c33d6f00 ("selftests/bpf: Support cross-endian building") Signed-off-by: Tony Ambardar Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250125071423.2603588-1-itugrok@yahoo.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 3652935a92cc95903c6a6ccda98672f5139da783 Author: Vladimir Lypak Date: Sat Mar 15 16:26:18 2025 +0100 clk: qcom: gcc-msm8953: fix stuck venus0_core0 clock [ Upstream commit cdc59600bccf2cb4c483645438a97d4ec55f326b ] This clock can't be enable with VENUS_CORE0 GDSC turned off. But that GDSC is under HW control so it can be turned off at any moment. Instead of checking the dependent clock we can just vote for it to enable later when GDSC gets turned on. Fixes: 9bb6cfc3c77e6 ("clk: qcom: Add Global Clock Controller driver for MSM8953") Signed-off-by: Vladimir Lypak Signed-off-by: Barnabás Czémán Link: https://lore.kernel.org/r/20250315-clock-fix-v1-2-2efdc4920dda@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit e4327d54bcca938f9411394081d1ec87f9e26933 Author: Akhil R Date: Mon Feb 24 14:46:07 2025 +0530 crypto: tegra - Fix CMAC intermediate result handling [ Upstream commit ce390d6c2675d2e24d798169a1a0e3cdbc076907 ] Saving and restoring of the intermediate results are needed if there is context switch caused by another ongoing request on the same engine. This is therefore not only to support import/export functionality. Hence, save and restore the intermediate result for every non-first task. Fixes: 0880bb3b00c8 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Akhil R Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit b56a17ed1e6a8ce4d2d87523979146b7bccb4cc8 Author: Yue Haibing Date: Sat Jan 18 11:13:34 2025 +0800 pinctrl: nuvoton: npcm8xx: Fix error handling in npcm8xx_gpio_fw() [ Upstream commit d6c6fd77e5816e3f6689a2767cdd777797506f24 ] fwnode_irq_get() was changed to not return 0, fix this by checking for negative error, also update the error log. Fixes: acf4884a5717 ("pinctrl: nuvoton: add NPCM8XX pinctrl and GPIO driver") Signed-off-by: Yue Haibing Link: https://lore.kernel.org/20250118031334.243324-1-yuehaibing@huawei.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 157de9e48007a20c65d02fc0229a16f38134a72d Author: Will McVicker Date: Wed Feb 12 10:32:52 2025 -0800 clk: samsung: Fix UBSAN panic in samsung_clk_init() [ Upstream commit d19d7345a7bcdb083b65568a11b11adffe0687af ] With UBSAN_ARRAY_BOUNDS=y, I'm hitting the below panic due to dereferencing `ctx->clk_data.hws` before setting `ctx->clk_data.num = nr_clks`. Move that up to fix the crash. UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP Call trace: samsung_clk_init+0x110/0x124 (P) samsung_clk_init+0x48/0x124 (L) samsung_cmu_register_one+0x3c/0xa0 exynos_arm64_register_cmu+0x54/0x64 __gs101_cmu_top_of_clk_init_declare+0x28/0x60 ... Fixes: e620a1e061c4 ("drivers/clk: convert VL struct to struct_size") Signed-off-by: Will McVicker Link: https://lore.kernel.org/r/20250212183253.509771-1-willmcvicker@google.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit a34b551cc631d0ed0fe16ca05444827e7add4bfd Author: Luca Weiss Date: Fri Mar 14 09:24:31 2025 +0100 remoteproc: qcom: pas: add minidump_id to SC7280 WPSS [ Upstream commit d2909538bff0189d4d038f4e903c70be5f5c2bfc ] Add the minidump ID to the wpss resources, based on msm-5.4 devicetree. Fixes: 300ed425dfa9 ("remoteproc: qcom_q6v5_pas: Add SC7280 ADSP, CDSP & WPSS") Signed-off-by: Luca Weiss Link: https://lore.kernel.org/r/20250314-sc7280-wpss-minidump-v1-1-d869d53fd432@fairphone.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d5824fa1954d2094d185b625c203edfeec5ae530 Author: Claudiu Beznea Date: Wed Jan 15 16:20:58 2025 +0200 clk: renesas: r8a08g045: Check the source of the CPU PLL settings [ Upstream commit dc0f16c1b76293ac942a783e960abfd19e95fdf5 ] On the RZ/G3S SoC, the CPU PLL settings can be set and retrieved through the CPG_PLL1_CLK1 and CPG_PLL1_CLK2 registers. However, these settings are applied only when CPG_PLL1_SETTING.SEL_PLL1 is set to 0. Otherwise, the CPU PLL operates at the default frequency of 1.1 GHz. Hence add support to the PLL driver for returning the 1.1 GHz frequency when the CPU PLL is configured with the default frequency. Fixes: 01eabef547e6 ("clk: renesas: rzg2l: Add support for RZ/G3S PLL") Fixes: de60a3ebe410 ("clk: renesas: Add minimal boot support for RZ/G3S SoC") Signed-off-by: Claudiu Beznea Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/20250115142059.1833063-1-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit de6185b8892d88142ef69768fe4077cbf40109c0 Author: David Hildenbrand Date: Fri Mar 21 12:23:23 2025 +0100 x86/mm/pat: Fix VM_PAT handling when fork() fails in copy_page_range() [ Upstream commit dc84bc2aba85a1508f04a936f9f9a15f64ebfb31 ] If track_pfn_copy() fails, we already added the dst VMA to the maple tree. As fork() fails, we'll cleanup the maple tree, and stumble over the dst VMA for which we neither performed any reservation nor copied any page tables. Consequently untrack_pfn() will see VM_PAT and try obtaining the PAT information from the page table -- which fails because the page table was not copied. The easiest fix would be to simply clear the VM_PAT flag of the dst VMA if track_pfn_copy() fails. However, the whole thing is about "simply" clearing the VM_PAT flag is shaky as well: if we passed track_pfn_copy() and performed a reservation, but copying the page tables fails, we'll simply clear the VM_PAT flag, not properly undoing the reservation ... which is also wrong. So let's fix it properly: set the VM_PAT flag only if the reservation succeeded (leaving it clear initially), and undo the reservation if anything goes wrong while copying the page tables: clearing the VM_PAT flag after undoing the reservation. Note that any copied page table entries will get zapped when the VMA will get removed later, after copy_page_range() succeeded; as VM_PAT is not set then, we won't try cleaning VM_PAT up once more and untrack_pfn() will be happy. Note that leaving these page tables in place without a reservation is not a problem, as we are aborting fork(); this process will never run. A reproducer can trigger this usually at the first try: https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/reproducers/pat_fork.c WARNING: CPU: 26 PID: 11650 at arch/x86/mm/pat/memtype.c:983 get_pat_info+0xf6/0x110 Modules linked in: ... CPU: 26 UID: 0 PID: 11650 Comm: repro3 Not tainted 6.12.0-rc5+ #92 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:get_pat_info+0xf6/0x110 ... Call Trace: ... untrack_pfn+0x52/0x110 unmap_single_vma+0xa6/0xe0 unmap_vmas+0x105/0x1f0 exit_mmap+0xf6/0x460 __mmput+0x4b/0x120 copy_process+0x1bf6/0x2aa0 kernel_clone+0xab/0x440 __do_sys_clone+0x66/0x90 do_syscall_64+0x95/0x180 Likely this case was missed in: d155df53f310 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed") ... and instead of undoing the reservation we simply cleared the VM_PAT flag. Keep the documentation of these functions in include/linux/pgtable.h, one place is more than sufficient -- we should clean that up for the other functions like track_pfn_remap/untrack_pfn separately. Fixes: d155df53f310 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed") Fixes: 2ab640379a0a ("x86: PAT: hooks in generic vm code to help archs to track pfnmap regions - v3") Reported-by: xingwei lee Reported-by: yuxin wang Reported-by: Marius Fleischer Signed-off-by: David Hildenbrand Signed-off-by: Ingo Molnar Cc: Andy Lutomirski Cc: Peter Zijlstra Cc: Rik van Riel Cc: "H. Peter Anvin" Cc: Linus Torvalds Cc: Andrew Morton Cc: linux-mm@kvack.org Link: https://lore.kernel.org/r/20250321112323.153741-1-david@redhat.com Closes: https://lore.kernel.org/lkml/CABOYnLx_dnqzpCW99G81DmOr+2UzdmZMk=T3uxwNxwz+R1RAwg@mail.gmail.com/ Closes: https://lore.kernel.org/lkml/CAJg=8jwijTP5fre8woS4JVJQ8iUA6v+iNcsOgtj9Zfpc3obDOQ@mail.gmail.com/ Signed-off-by: Sasha Levin commit 10da42f089ecda6515bd46d572982fed729aac79 Author: Viktor Malik Date: Thu Mar 13 13:28:52 2025 +0100 selftests/bpf: Fix string read in strncmp benchmark [ Upstream commit de07b182899227d5fd1ca7a1a7d495ecd453d49c ] The strncmp benchmark uses the bpf_strncmp helper and a hand-written loop to compare two strings. The values of the strings are filled from userspace. One of the strings is non-const (in .bss) while the other is const (in .rodata) since that is the requirement of bpf_strncmp. The problem is that in the hand-written loop, Clang optimizes the reads from the const string to always return 0 which breaks the benchmark. Use barrier_var to prevent the optimization. The effect can be seen on the strncmp-no-helper variant. Before this change: # ./bench strncmp-no-helper Setting up benchmark 'strncmp-no-helper'... Benchmark 'strncmp-no-helper' started. Iter 0 (112.309us): hits 0.000M/s ( 0.000M/prod), drops 0.000M/s, total operations 0.000M/s Iter 1 (-23.238us): hits 0.000M/s ( 0.000M/prod), drops 0.000M/s, total operations 0.000M/s Iter 2 ( 58.994us): hits 0.000M/s ( 0.000M/prod), drops 0.000M/s, total operations 0.000M/s Iter 3 (-30.466us): hits 0.000M/s ( 0.000M/prod), drops 0.000M/s, total operations 0.000M/s Iter 4 ( 29.996us): hits 0.000M/s ( 0.000M/prod), drops 0.000M/s, total operations 0.000M/s Iter 5 ( 16.949us): hits 0.000M/s ( 0.000M/prod), drops 0.000M/s, total operations 0.000M/s Iter 6 (-60.035us): hits 0.000M/s ( 0.000M/prod), drops 0.000M/s, total operations 0.000M/s Summary: hits 0.000 ± 0.000M/s ( 0.000M/prod), drops 0.000 ± 0.000M/s, total operations 0.000 ± 0.000M/s After this change: # ./bench strncmp-no-helper Setting up benchmark 'strncmp-no-helper'... Benchmark 'strncmp-no-helper' started. Iter 0 ( 77.711us): hits 5.534M/s ( 5.534M/prod), drops 0.000M/s, total operations 5.534M/s Iter 1 ( 11.215us): hits 6.006M/s ( 6.006M/prod), drops 0.000M/s, total operations 6.006M/s Iter 2 (-14.253us): hits 5.931M/s ( 5.931M/prod), drops 0.000M/s, total operations 5.931M/s Iter 3 ( 59.087us): hits 6.005M/s ( 6.005M/prod), drops 0.000M/s, total operations 6.005M/s Iter 4 (-21.379us): hits 6.010M/s ( 6.010M/prod), drops 0.000M/s, total operations 6.010M/s Iter 5 (-20.310us): hits 5.861M/s ( 5.861M/prod), drops 0.000M/s, total operations 5.861M/s Iter 6 ( 53.937us): hits 6.004M/s ( 6.004M/prod), drops 0.000M/s, total operations 6.004M/s Summary: hits 5.969 ± 0.061M/s ( 5.969M/prod), drops 0.000 ± 0.000M/s, total operations 5.969 ± 0.061M/s Fixes: 9c42652f8be3 ("selftests/bpf: Add benchmark for bpf_strncmp() helper") Suggested-by: Andrii Nakryiko Signed-off-by: Viktor Malik Signed-off-by: Andrii Nakryiko Acked-by: Hou Tao Link: https://lore.kernel.org/bpf/20250313122852.1365202-1-vmalik@redhat.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 42d8b4570ffaa2284778087681629590a5bd5d6b Author: Manikanta Mylavarapu Date: Thu Mar 6 16:59:00 2025 +0530 drivers: clk: qcom: ipq5424: fix the freq table of sdcc1_apps clock [ Upstream commit e9ed0ac3ccba65c17ed0d59c77a340a75abc317b ] The divider values in the sdcc1_apps frequency table were incorrectly updated, assuming the frequency of gpll2_out_main to be 1152MHz. However, the frequency of the gpll2_out_main clock is actually 576MHz (gpll2/2). Due to these incorrect divider values, the sdcc1_apps clock is running at half of the expected frequency. Fixing the frequency table of sdcc1_apps allows the sdcc1_apps clock to run according to the frequency plan. Fixes: 21b5d5a4a311 ("clk: qcom: add Global Clock controller (GCC) driver for IPQ5424 SoC") Signed-off-by: Manikanta Mylavarapu Reviewed-by: Kathiravan Thirumoorthy Link: https://lore.kernel.org/r/20250306112900.3319330-1-quic_mmanikan@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit b010834b0657f9852bb171ebb5b5e82100afdf02 Author: Andrii Nakryiko Date: Wed Feb 19 16:28:21 2025 -0800 libbpf: Fix hypothetical STT_SECTION extern NULL deref case [ Upstream commit e0525cd72b5979d8089fe524a071ea93fd011dc9 ] Fix theoretical NULL dereference in linker when resolving *extern* STT_SECTION symbol against not-yet-existing ELF section. Not sure if it's possible in practice for valid ELF object files (this would require embedded assembly manipulations, at which point BTF will be missing), but fix the s/dst_sym/dst_sec/ typo guarding this condition anyways. Fixes: faf6ed321cf6 ("libbpf: Add BPF static linker APIs") Fixes: a46349227cd8 ("libbpf: Add linker extern resolution support for functions and global variables") Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/r/20250220002821.834400-1-andrii@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 33424002a24237357b5eb6db4596877b57e925fd Author: Luca Weiss Date: Tue Jan 28 22:54:00 2025 +0100 remoteproc: qcom_q6v5_pas: Make single-PD handling more robust [ Upstream commit e917b73234b02aa4966325e7380d2559bf127ba9 ] Only go into the if condition for single-PD handling when there's actually just one power domain specified there. Otherwise it'll be an issue in the dts and we should fail in the regular code path. This also mirrors the latest changes in the qcom_q6v5_mss driver. Suggested-by: Stephan Gerhold Fixes: 17ee2fb4e856 ("remoteproc: qcom: pas: Vote for active/proxy power domains") Signed-off-by: Luca Weiss Reviewed-by: Stephan Gerhold Link: https://lore.kernel.org/r/20250128-pas-singlepd-v1-2-85d9ae4b0093@lucaweiss.eu Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 11c9561cf20248596ac06dd77f277503c8e1931a Author: Claudiu Beznea Date: Sat Feb 15 15:12:35 2025 +0200 pinctrl: renesas: rzg2l: Suppress binding attributes [ Upstream commit ea4065345643f3163e812e58ed8add2c75c3ee46 ] Suppress binding attributes for the rzg2l pinctrl driver, as it is an essential block for Renesas SoCs. Unbinding the driver leads to warnings from __device_links_no_driver() and can eventually render the system inaccessible. Fixes: c4c4637eb57f ("pinctrl: renesas: Add RZ/G2L pin and gpio controller driver") Signed-off-by: Claudiu Beznea Reviewed-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/20250215131235.228274-1-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 2b96752ab380d91966792913d62fb4c3af01941e Author: Zijun Hu Date: Tue Feb 25 21:58:06 2025 +0800 of: property: Increase NR_FWNODE_REFERENCE_ARGS [ Upstream commit eb50844d728f11e87491f7c7af15a4a737f1159d ] Currently, the following two macros have different values: // The maximal argument count for firmware node reference #define NR_FWNODE_REFERENCE_ARGS 8 // The maximal argument count for DT node reference #define MAX_PHANDLE_ARGS 16 It may cause firmware node reference's argument count out of range if directly assign DT node reference's argument count to firmware's. drivers/of/property.c:of_fwnode_get_reference_args() is doing the direct assignment, so may cause firmware's argument count @args->nargs got out of range, namely, in [9, 16]. Fix by increasing NR_FWNODE_REFERENCE_ARGS to 16 to meet DT requirement. Will align both macros later to avoid such inconsistency. Fixes: 3e3119d3088f ("device property: Introduce fwnode_property_get_reference_args") Signed-off-by: Zijun Hu Acked-by: Sakari Ailus Link: https://lore.kernel.org/r/20250225-fix_arg_count-v4-1-13cdc519eb31@quicinc.com Signed-off-by: Rob Herring (Arm) Signed-off-by: Sasha Levin commit 068f6648ff5b0c7adeb6c363fae7fb188aa178fa Author: Peng Fan Date: Wed Mar 19 18:01:05 2025 +0800 remoteproc: core: Clear table_sz when rproc_shutdown [ Upstream commit efdde3d73ab25cef4ff2d06783b0aad8b093c0e4 ] There is case as below could trigger kernel dump: Use U-Boot to start remote processor(rproc) with resource table published to a fixed address by rproc. After Kernel boots up, stop the rproc, load a new firmware which doesn't have resource table ,and start rproc. When starting rproc with a firmware not have resource table, `memcpy(loaded_table, rproc->cached_table, rproc->table_sz)` will trigger dump, because rproc->cache_table is set to NULL during the last stop operation, but rproc->table_sz is still valid. This issue is found on i.MX8MP and i.MX9. Dump as below: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 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=000000010af63000 [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP Modules linked in: CPU: 2 UID: 0 PID: 1060 Comm: sh Not tainted 6.14.0-rc7-next-20250317-dirty #38 Hardware name: NXP i.MX8MPlus EVK board (DT) pstate: a0000005 (NzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __pi_memcpy_generic+0x110/0x22c lr : rproc_start+0x88/0x1e0 Call trace: __pi_memcpy_generic+0x110/0x22c (P) rproc_boot+0x198/0x57c state_store+0x40/0x104 dev_attr_store+0x18/0x2c sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x120/0x1cc vfs_write+0x240/0x378 ksys_write+0x70/0x108 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xcc el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19c Clear rproc->table_sz to address the issue. Fixes: 9dc9507f1880 ("remoteproc: Properly deal with the resource table when detaching") Signed-off-by: Peng Fan Link: https://lore.kernel.org/r/20250319100106.3622619-1-peng.fan@oss.nxp.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 05b215d5e219c0228b9c7082ba9bcf176c576646 Author: Michael Guralnik Date: Thu Mar 13 16:29:51 2025 +0200 RDMA/mlx5: Fix page_size variable overflow [ Upstream commit f0c2427412b43cdf1b7b0944749ea17ddb97d5a5 ] Change all variables storing mlx5_umem_mkc_find_best_pgsz() result to unsigned long to support values larger than 31 and avoid overflow. For example: If we try to register 4GB of memory that is contiguous in physical memory, the driver will optimize the page_size and try to use an mkey with 4GB entity size. The 'unsigned int' page_size variable will overflow to '0' and we'll hit the WARN_ON() in alloc_cacheable_mr(). WARNING: CPU: 2 PID: 1203 at drivers/infiniband/hw/mlx5/mr.c:1124 alloc_cacheable_mr+0x22/0x580 [mlx5_ib] Modules linked in: mlx5_ib mlx5_core bonding ip6_gre ip6_tunnel tunnel6 ip_gre gre rdma_rxe rdma_ucm ib_uverbs ib_ipoib ib_umad rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm fuse ib_core [last unloaded: mlx5_core] CPU: 2 UID: 70878 PID: 1203 Comm: rdma_resource_l Tainted: G W 6.14.0-rc4-dirty #43 Tainted: [W]=WARN Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:alloc_cacheable_mr+0x22/0x580 [mlx5_ib] Code: 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 41 52 53 48 83 ec 30 f6 46 28 04 4c 8b 77 08 75 21 <0f> 0b 49 c7 c2 ea ff ff ff 48 8d 65 d0 4c 89 d0 5b 41 5a 41 5c 41 RSP: 0018:ffffc900006ffac8 EFLAGS: 00010246 RAX: 0000000004c0d0d0 RBX: ffff888217a22000 RCX: 0000000000100001 RDX: 00007fb7ac480000 RSI: ffff8882037b1240 RDI: ffff8882046f0600 RBP: ffffc900006ffb28 R08: 0000000000000001 R09: 0000000000000000 R10: 00000000000007e0 R11: ffffea0008011d40 R12: ffff8882037b1240 R13: ffff8882046f0600 R14: ffff888217a22000 R15: ffffc900006ffe00 FS: 00007fb7ed013340(0000) GS:ffff88885fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb7ed1d8000 CR3: 00000001fd8f6006 CR4: 0000000000772eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? __warn+0x81/0x130 ? alloc_cacheable_mr+0x22/0x580 [mlx5_ib] ? report_bug+0xfc/0x1e0 ? handle_bug+0x55/0x90 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? alloc_cacheable_mr+0x22/0x580 [mlx5_ib] create_real_mr+0x54/0x150 [mlx5_ib] ib_uverbs_reg_mr+0x17f/0x2a0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xca/0x140 [ib_uverbs] ib_uverbs_run_method+0x6d0/0x780 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x19b/0x360 [ib_uverbs] ? walk_system_ram_range+0x79/0xd0 ? ___pte_offset_map+0x1b/0x110 ? __pte_offset_map_lock+0x80/0x100 ib_uverbs_ioctl+0xac/0x110 [ib_uverbs] __x64_sys_ioctl+0x94/0xb0 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fb7ecf0737b Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 7d 2a 0f 00 f7 d8 64 89 01 48 RSP: 002b:00007ffdbe03ecc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffdbe03edb8 RCX: 00007fb7ecf0737b RDX: 00007ffdbe03eda0 RSI: 00000000c0181b01 RDI: 0000000000000003 RBP: 00007ffdbe03ed80 R08: 00007fb7ecc84010 R09: 00007ffdbe03eed4 R10: 0000000000000009 R11: 0000000000000246 R12: 00007ffdbe03eed4 R13: 000000000000000c R14: 000000000000000c R15: 00007fb7ecc84150 Fixes: cef7dde8836a ("net/mlx5: Expand mkey page size to support 6 bits") Signed-off-by: Michael Guralnik Reviewed-by: Yishai Hadas Link: https://patch.msgid.link/2479a4a3f6fd9bd032e1b6d396274a89c4c5e22f.1741875692.git.leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 5dad0063224e0fb34d40862a9fb7c3a918a5642b Author: Wenkai Lin Date: Wed Feb 5 11:56:28 2025 +0800 crypto: hisilicon/sec2 - fix for sec spec check [ Upstream commit f4f353cb7ae9bb43e34943edb693532a39118eca ] During encryption and decryption, user requests must be checked first, if the specifications that are not supported by the hardware are used, the software computing is used for processing. Fixes: 2f072d75d1ab ("crypto: hisilicon - Add aead support on SEC2") Signed-off-by: Wenkai Lin Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 7408c0e04c55f87edcef3a92c1e9f5d3284a7b8a Author: Wenkai Lin Date: Wed Feb 5 11:56:27 2025 +0800 crypto: hisilicon/sec2 - fix for aead authsize alignment [ Upstream commit a49cc71e219040d771a8c1254879984f98192811 ] The hardware only supports authentication sizes that are 4-byte aligned. Therefore, the driver switches to software computation in this case. Fixes: 2f072d75d1ab ("crypto: hisilicon - Add aead support on SEC2") Signed-off-by: Wenkai Lin Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Stable-dep-of: f4f353cb7ae9 ("crypto: hisilicon/sec2 - fix for sec spec check") Signed-off-by: Sasha Levin commit 2361b9e4f914f990d0781b0c6b281044cb65f463 Author: Jerome Brunet Date: Fri Dec 20 11:25:36 2024 +0100 clk: amlogic: gxbb: drop incorrect flag on 32k clock [ Upstream commit f38f7fe4830c5cb4eac138249225f119e7939965 ] gxbb_32k_clk_div sets CLK_DIVIDER_ROUND_CLOSEST in the init_data flag which is incorrect. This is field is not where the divider flags belong. Thankfully, CLK_DIVIDER_ROUND_CLOSEST maps to bit 4 which is an unused clock flag, so there is no unintended consequence to this error. Effectively, the clock has been used without CLK_DIVIDER_ROUND_CLOSEST so far, so just drop it. Fixes: 14c735c8e308 ("clk: meson-gxbb: Add EE 32K Clock for CEC") Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20241220-amlogic-clk-gxbb-32k-fixes-v1-1-baca56ecf2db@baylibre.com Signed-off-by: Jerome Brunet Signed-off-by: Sasha Levin commit d82d2119bec14366923733119518111e4bfafa90 Author: Akhil R Date: Mon Feb 24 14:46:10 2025 +0530 crypto: tegra - Use HMAC fallback when keyslots are full [ Upstream commit f80a2e2e77bedd0aa645a60f89b4f581c70accda ] The intermediate results for HMAC is stored in the allocated keyslot by the hardware. Dynamic allocation of keyslot during an operation is hence not possible. As the number of keyslots are limited in the hardware, fallback to the HMAC software implementation if keyslots are not available Fixes: 0880bb3b00c8 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Akhil R Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 68b1616bbb0fc79db76ff35f1a0e151002aeaca0 Author: Arnd Bergmann Date: Mon Feb 17 13:55:55 2025 +0100 crypto: bpf - Add MODULE_DESCRIPTION for skcipher [ Upstream commit f307c87ea06c64b87fcd3221a682cd713cde51e9 ] All modules should have a description, building with extra warnings enabled prints this outfor the for bpf_crypto_skcipher module: WARNING: modpost: missing MODULE_DESCRIPTION() in crypto/bpf_crypto_skcipher.o Add a description line. Fixes: fda4f71282b2 ("bpf: crypto: add skcipher to bpf crypto") Signed-off-by: Arnd Bergmann Reviewed-by: Vadim Fedorenko Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 7c9df75c51da1bcb991a2fcb260352d27967793a Author: Akhil R Date: Mon Feb 24 14:46:06 2025 +0530 crypto: tegra - Fix HASH intermediate result handling [ Upstream commit ff4b7df0b511b6121f3386607f02c16fb5d41192 ] The intermediate hash values generated during an update task were handled incorrectly in the driver. The values have a defined format for each algorithm. Copying and pasting from the HASH_RESULT register balantly would not work for all the supported algorithms. This incorrect handling causes failures when there is a context switch between multiple operations. To handle the expected format correctly, add a separate buffer for storing the intermediate results for each request. Remove the previous copy/paste functions which read/wrote to the registers directly. Instead configure the hardware to get the intermediate result copied to the buffer and use host1x path to restore the intermediate hash results. Fixes: 0880bb3b00c8 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Akhil R Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 7497c9a509cf33a9f64c7e39b7f0b73e895a3cbd Author: Akhil R Date: Mon Feb 24 14:46:05 2025 +0530 crypto: tegra - Transfer HASH init function to crypto engine [ Upstream commit 97ee15ea101629d2ffe21d3c5dc03b8d8be43603 ] Ahash init() function was called asynchronous to the crypto engine queue. This could corrupt the request context if there is any ongoing operation for the same request. Queue the init function as well to the crypto engine queue so that this scenario can be avoided. Fixes: 0880bb3b00c8 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Akhil R Signed-off-by: Herbert Xu Stable-dep-of: ff4b7df0b511 ("crypto: tegra - Fix HASH intermediate result handling") Signed-off-by: Sasha Levin commit 6c01a1457ae200ed80fcb2578257b7fa7da79c82 Author: Akhil R Date: Mon Feb 24 14:46:04 2025 +0530 crypto: tegra - check return value for hash do_one_req [ Upstream commit dcf8b7e49b86738296c77fb58c123dd2d74a22a7 ] Initialize and check the return value in hash *do_one_req() functions and exit the function if there is an error. This fixes the 'uninitialized variable' warnings reported by testbots. Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202412071747.flPux4oB-lkp@intel.com/ Fixes: 0880bb3b00c8 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Akhil R Signed-off-by: Herbert Xu Stable-dep-of: ff4b7df0b511 ("crypto: tegra - Fix HASH intermediate result handling") Signed-off-by: Sasha Levin commit bf8bba61b836b65ecc255760041a39fca57be44b Author: Akhil R Date: Mon Feb 24 14:46:02 2025 +0530 crypto: tegra - Do not use fixed size buffers [ Upstream commit 1cb328da4e8f34350c61a2b6548766c79b4bb64c ] Allocate the buffer based on the request instead of a fixed buffer length. In operations which may require larger buffer size, a fixed buffer may fail. Fixes: 0880bb3b00c8 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Akhil R Signed-off-by: Herbert Xu Stable-dep-of: ff4b7df0b511 ("crypto: tegra - Fix HASH intermediate result handling") Signed-off-by: Sasha Levin commit 5b5c97f44a7208c1297a2f53bd6cc022deee5bad Author: Akhil R Date: Mon Feb 24 14:46:01 2025 +0530 crypto: tegra - Use separate buffer for setkey [ Upstream commit bcfc8fc53f3acb3213fb9d28675244aa4ce208e0 ] The buffer which sends the commands to host1x was shared for all tasks in the engine. This causes a problem with the setkey() function as it gets called asynchronous to the crypto engine queue. Modifying the same cmdbuf in setkey() will corrupt the ongoing host1x task and in turn break the encryption/decryption operation. Hence use a separate cmdbuf for setkey(). Fixes: 0880bb3b00c8 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Akhil R Signed-off-by: Herbert Xu Stable-dep-of: ff4b7df0b511 ("crypto: tegra - Fix HASH intermediate result handling") Signed-off-by: Sasha Levin commit 8da632077003a74d79f63412001b057d8b5fd766 Author: Bairavi Alagappan Date: Fri Mar 14 13:14:29 2025 +0000 crypto: qat - set parity error mask for qat_420xx [ Upstream commit f9555d18084985c80a91baa4fdb7d205b401a754 ] The field parerr_wat_wcp_mask in the structure adf_dev_err_mask enables the detection and reporting of parity errors for the wireless cipher and wireless authentication accelerators. Set the parerr_wat_wcp_mask field, which was inadvertently omitted during the initial enablement of the qat_420xx driver, to ensure that parity errors are enabled for those accelerators. In addition, fix the string used to report such errors that was inadvertently set to "ath_cph" (authentication and cipher). Fixes: fcf60f4bcf54 ("crypto: qat - add support for 420xx devices") Signed-off-by: Bairavi Alagappan Signed-off-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 0310c91832337b15e5b6d6bbe594b0a4895e7996 Author: Herbert Xu Date: Thu Feb 27 18:14:55 2025 +0800 crypto: iaa - Test the correct request flag [ Upstream commit fc4bd01d9ff592f620c499686245c093440db0e8 ] Test the correct flags for the MAY_SLEEP bit. Fixes: 2ec6761df889 ("crypto: iaa - Add support for deflate-iaa compression algorithm") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 4281ecebd0ffc25bca6654ab1e8c1c25836fe9b7 Author: Danila Chernetsov Date: Wed Mar 19 01:30:11 2025 +0000 fbdev: sm501fb: Add some geometry checks. [ Upstream commit aee50bd88ea5fde1ff4cc021385598f81a65830c ] Added checks for xoffset, yoffset settings. Incorrect settings of these parameters can lead to errors in sm501fb_pan_ functions. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 5fc404e47bdf ("[PATCH] fb: SM501 framebuffer driver") Signed-off-by: Danila Chernetsov Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 19ac7dd520b1915f38eba771d950bc2bf8480177 Author: Arnd Bergmann Date: Tue Feb 25 17:44:23 2025 +0100 mdacon: rework dependency list [ Upstream commit 5bbcc7645f4b244ffb5ac6563fbe9d3d42194447 ] mdacon has roughly the same dependencies as vgacon but expresses them as a negative list instead of a positive list, with the only practical difference being PowerPC/CHRP, which uses vga16fb instead of vgacon. The CONFIG_MDA_CONSOLE description advises to only turn it on when vgacon is also used because MDA/Hercules-only systems should be using vgacon instead, so just change the list to enforce that directly for simplicity. The probing was broken from 2002 to 2008, this improves on the fix that was added then: If vgacon is a loadable module, then mdacon cannot be built-in now, and the list of systems that support vgacon is carried over. Fixes: 0b9cf3aa6b1e ("mdacon messing up default vc's - set default to vc13-16 again") Signed-off-by: Arnd Bergmann Reviewed-by: Thomas Zimmermann Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 6cfe709a2bcae8134364497acfc1314230c985f7 Author: Arnd Bergmann Date: Tue Feb 25 17:44:22 2025 +0100 dummycon: fix default rows/cols [ Upstream commit beefaba1978c04ea2950d34236f58fe6cf6a7f58 ] dummycon fails to build on ARM/footbridge when the VGA console is disabled, since I got the dependencies slightly wrong in a previous patch: drivers/video/console/dummycon.c: In function 'dummycon_init': drivers/video/console/dummycon.c:27:25: error: 'CONFIG_DUMMY_CONSOLE_COLUMNS' undeclared (first use in this function); did you mean 'CONFIG_DUMMY_CONSOLE'? 27 | #define DUMMY_COLUMNS CONFIG_DUMMY_CONSOLE_COLUMNS drivers/video/console/dummycon.c:28:25: error: 'CONFIG_DUMMY_CONSOLE_ROWS' undeclared (first use in this function); did you mean 'CONFIG_DUMMY_CONSOLE'? 28 | #define DUMMY_ROWS CONFIG_DUMMY_CONSOLE_ROWS This only showed up after many thousand randconfig builds on Arm, and doesn't matter in practice, but should still be fixed. Address it by using the default row/columns on footbridge after all in that corner case. Fixes: 4293b0925149 ("dummycon: limit Arm console size hack to footbridge") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202409151512.LML1slol-lkp@intel.com/ Signed-off-by: Arnd Bergmann Reviewed-by: Thomas Zimmermann Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit dc14bafc8854136112b2c411b65cd7b86d411f13 Author: Markus Elfring Date: Thu Apr 13 21:35:36 2023 +0200 fbdev: au1100fb: Move a variable assignment behind a null pointer check [ Upstream commit 2df2c0caaecfd869b49e14f2b8df822397c5dd7f ] The address of a data structure member was determined before a corresponding null pointer check in the implementation of the function “au1100fb_setmode”. This issue was detected by using the Coccinelle software. Fixes: 3b495f2bb749 ("Au1100 FB driver uplift for 2.6.") Signed-off-by: Markus Elfring Acked-by: Uwe Kleine-König Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit e558ae50ab8fc9871bbc9ed844ea9c46e475b770 Author: Pavel Begunkov Date: Mon Mar 24 15:32:32 2025 +0000 io_uring: fix retry handling off iowq [ Upstream commit 3f0cb8de56b9a5c052a9e43fa548856926059810 ] io_req_complete_post() doesn't handle reissue and if called with a REQ_F_REISSUE request it might post extra unexpected completions. Fix it by pushing into flush_completion via task work. Fixes: d803d123948fe ("io_uring/rw: handle -EAGAIN retry at IO completion time") Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/badb3d7e462881e7edbfcc2be6301090b07dbe53.1742829388.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit aeb5f9accf41dc6fba2e05f26a09e85914f644d0 Author: Caleb Sander Mateos Date: Tue Feb 11 17:51:18 2025 -0700 io_uring: use lockless_cq flag in io_req_complete_post() [ Upstream commit 62aa9805d123165102273eb277f776aaca908e0e ] io_uring_create() computes ctx->lockless_cq as: ctx->task_complete || (ctx->flags & IORING_SETUP_IOPOLL) So use it to simplify that expression in io_req_complete_post(). Signed-off-by: Caleb Sander Mateos Reviewed-by: Li Zetao Link: https://lore.kernel.org/r/20250212005119.3433005-1-csander@purestorage.com Signed-off-by: Jens Axboe Stable-dep-of: 3f0cb8de56b9 ("io_uring: fix retry handling off iowq") Signed-off-by: Sasha Levin commit c67a233834b778b8c78f8b62c072ccf87a9eb6d0 Author: Shay Drory Date: Mon Mar 10 10:45:24 2025 +0200 PCI: Fix NULL dereference in SR-IOV VF creation error path [ Upstream commit 04d50d953ab46d96b0b32d5ad955fceaa28622db ] Clean up when virtfn setup fails to prevent NULL pointer dereference during device removal. The kernel oops below occurred due to incorrect error handling flow when pci_setup_device() fails. Add pci_iov_scan_device(), which handles virtfn allocation and setup and cleans up if pci_setup_device() fails, so pci_iov_add_virtfn() doesn't need to call pci_stop_and_remove_bus_device(). This prevents accessing partially initialized virtfn devices during removal. BUG: kernel NULL pointer dereference, address: 00000000000000d0 RIP: 0010:device_del+0x3d/0x3d0 Call Trace: pci_remove_bus_device+0x7c/0x100 pci_iov_add_virtfn+0xfa/0x200 sriov_enable+0x208/0x420 mlx5_core_sriov_configure+0x6a/0x160 [mlx5_core] sriov_numvfs_store+0xae/0x1a0 Link: https://lore.kernel.org/r/20250310084524.599225-1-shayd@nvidia.com Fixes: e3f30d563a38 ("PCI: Make pci_destroy_dev() concurrent safe") Signed-off-by: Shay Drory [bhelgaas: commit log, return ERR_PTR(-ENOMEM) directly] Signed-off-by: Bjorn Helgaas Cc: Keith Busch Signed-off-by: Sasha Levin commit c0ddd8f7fdb7dd5879c1a5f05ab0f0241aa64b41 Author: Caleb Sander Mateos Date: Fri Mar 21 12:48:17 2025 -0600 io_uring/net: only import send_zc buffer once [ Upstream commit 8e3100fcc5cbba03518b8b5c059624aba5c29d50 ] io_send_zc() guards its call to io_send_zc_import() with if (!done_io) in an attempt to avoid calling it redundantly on the same req. However, if the initial non-blocking issue returns -EAGAIN, done_io will stay 0. This causes the subsequent issue to unnecessarily re-import the buffer. Add an explicit flag "imported" to io_sr_msg to track if its buffer has already been imported. Clear the flag in io_send_zc_prep(). Call io_send_zc_import() and set the flag in io_send_zc() if it is unset. Signed-off-by: Caleb Sander Mateos Fixes: 54cdcca05abd ("io_uring/net: switch io_send() and io_send_zc() to using io_async_msghdr") Link: https://lore.kernel.org/r/20250321184819.3847386-2-csander@purestorage.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c2655c70409cceb4e6ea361304e7a973f0bea74c Author: Ilpo Järvinen Date: Fri Mar 21 18:31:03 2025 +0200 PCI/bwctrl: Fix pcie_bwctrl_select_speed() return type [ Upstream commit 026e4bffb0af9632f5a0bbf8d594f2aace44cf07 ] pcie_bwctrl_select_speed() should take __fls() of the speed bit, not return it as a raw value. Instead of directly returning 2.5GT/s speed bit, simply assign the fallback speed (2.5GT/s) into supported_speeds variable to share the normal return path that calls pcie_supported_speeds2target_speed() to calculate __fls(). This code path is not very likely to execute because pcie_get_supported_speeds() should provide valid ->supported_speeds but a spec violating device could fail to synthesize any speed in pcie_get_supported_speeds(). It could also happen in case the supported_speeds intersection is empty (also a violation of the current PCIe specs). Link: https://lore.kernel.org/r/20250321163103.5145-1-ilpo.jarvinen@linux.intel.com Fixes: de9a6c8d5dbf ("PCI/bwctrl: Add pcie_set_target_speed() to set PCIe Link Speed") Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit f6029c0a5098c4ad71d8021a62b30695e2542ad4 Author: Ilpo Järvinen Date: Fri Mar 21 18:21:14 2025 +0200 PCI: pciehp: Don't enable HPIE when resuming in poll mode [ Upstream commit 527664f738afb6f2c58022cd35e63801e5dc7aec ] PCIe hotplug can operate in poll mode without interrupt handlers using a polling kthread only. eb34da60edee ("PCI: pciehp: Disable hotplug interrupt during suspend") failed to consider that and enables HPIE (Hot-Plug Interrupt Enable) unconditionally when resuming the Port. Only set HPIE if non-poll mode is in use. This makes pcie_enable_interrupt() match how pcie_enable_notification() already handles HPIE. Link: https://lore.kernel.org/r/20250321162114.3939-1-ilpo.jarvinen@linux.intel.com Fixes: eb34da60edee ("PCI: pciehp: Disable hotplug interrupt during suspend") Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Reviewed-by: Lukas Wunner Signed-off-by: Sasha Levin commit 4bf8a9dec472e0701e92e1d086c34a6de1bf7b44 Author: Alex Deucher Date: Wed Mar 19 10:42:45 2025 -0400 drm/amdgpu/mes: enable compute pipes across all MEC [ Upstream commit a52077b6b6f7d1553d2dc89666f111f89d7418e0 ] Enable pipes on both MECs for MES. Fixes: 745f46b6a99f ("drm/amdgpu: enable mes v12 self test") Acked-by: Lijo Lazar Reviewed-by: Prike Liang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 8e1ba812c83a6114c4d964f6ca2e04ae87f00d1c Author: Alex Deucher Date: Wed Mar 19 09:56:00 2025 -0400 drm/amdgpu/mes: optimize compute loop handling [ Upstream commit 5608ddf6e94c41a673170b2a7e3aad485fd8b88a ] Break when we get to the end of the supported pipes rather than continuing the loop. Reviewed-by: Shaoyun.liu Signed-off-by: Alex Deucher Stable-dep-of: a52077b6b6f7 ("drm/amdgpu/mes: enable compute pipes across all MEC") Signed-off-by: Sasha Levin commit 6dc8ab13f934688357655f35e516f70ba6bd8532 Author: Ilpo Järvinen Date: Thu Mar 20 16:28:37 2025 +0200 PCI: Fix BAR resizing when VF BARs are assigned [ Upstream commit 9ec19bfa78bd788945e2445b09de7b4482dee432 ] __resource_resize_store() attempts to release all resources of the device before attempting the resize. The loop, however, only covers standard BARs (< PCI_STD_NUM_BARS). If a device has VF BARs that are assigned, pci_reassign_bridge_resources() finds the bridge window still has some assigned child resources and returns -NOENT which makes pci_resize_resource() to detect an error and abort the resize. Change the release loop to cover all resources up to VF BARs which allows the resize operation to release the bridge windows and attempt to assigned them again with the different size. If SR-IOV is enabled, disallow resize as it requires releasing also IOV resources. Link: https://lore.kernel.org/r/20250320142837.8027-1-ilpo.jarvinen@linux.intel.com Fixes: 91fa127794ac ("PCI: Expose PCIe Resizable BAR support via sysfs") Reported-by: Michał Winiarski Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Reviewed-by: Alex Williamson Signed-off-by: Sasha Levin commit 5bb2356626cf6899f1c625e97792f79460fa515f Author: Christophe JAILLET Date: Sat Mar 1 19:42:54 2025 +0100 PCI: histb: Fix an error handling path in histb_pcie_probe() [ Upstream commit b36fb50701619efca5f5450b355d42575cf532ed ] If an error occurs after a successful phy_init() call, then phy_exit() should be called. Add the missing call, as already done in the remove function. Fixes: bbd11bddb398 ("PCI: hisi: Add HiSilicon STB SoC PCIe controller driver") Signed-off-by: Christophe JAILLET [kwilczynski: remove unnecessary hipcie->phy NULL check from histb_pcie_probe() and squash a patch that removes similar NULL check for hipcie-phy from histb_pcie_remove() from https://lore.kernel.org/linux-pci/c369b5d25e17a44984ae5a889ccc28a59a0737f7.1742058005.git.christophe.jaillet@wanadoo.fr] Signed-off-by: Krzysztof Wilczyński Link: https://lore.kernel.org/r/8301fc15cdea5d2dac21f57613e8e6922fb1ad95.1740854531.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin commit 6c82eeadccccee53bc7f9b1314fea38b4d1bdc19 Author: Dan Carpenter Date: Wed Mar 5 18:00:07 2025 +0300 PCI: dwc: ep: Return -ENOMEM for allocation failures [ Upstream commit 8189aa56dbed0bfb46b7b30d4d231f57ab17b3f4 ] If the bitmap or memory allocations fail, then dw_pcie_ep_init_registers() will incorrectly return a success. Return -ENOMEM instead. Fixes: 869bc5253406 ("PCI: dwc: ep: Fix DBI access failure for drivers requiring refclk from host") Signed-off-by: Dan Carpenter [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński Reviewed-by: Krzysztof Wilczyński Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/36dcb6fc-f292-4dd5-bd45-a8c6f9dc3df7@stanley.mountain Signed-off-by: Sasha Levin commit 35ad39afd007eddf34b3307bebb715c26891cc96 Author: Thadeu Lima de Souza Cascardo Date: Wed Feb 5 10:06:38 2025 -0300 drm/amd/display: avoid NPD when ASIC does not support DMUB [ Upstream commit 42d9d7bed270247f134190ba0cb05bbd072f58c2 ] ctx->dmub_srv will de NULL if the ASIC does not support DMUB, which is tested in dm_dmub_sw_init. However, it will be dereferenced in dmub_hw_lock_mgr_cmd if should_use_dmub_lock returns true. This has been the case since dmub support has been added for PSR1. Fix this by checking for dmub_srv in should_use_dmub_lock. [ 37.440832] BUG: kernel NULL pointer dereference, address: 0000000000000058 [ 37.447808] #PF: supervisor read access in kernel mode [ 37.452959] #PF: error_code(0x0000) - not-present page [ 37.458112] PGD 0 P4D 0 [ 37.460662] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI [ 37.465553] CPU: 2 UID: 1000 PID: 1745 Comm: DrmThread Not tainted 6.14.0-rc1-00003-gd62e938120f0 #23 99720e1cb1e0fc4773b8513150932a07de3c6e88 [ 37.478324] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023 [ 37.487103] RIP: 0010:dmub_hw_lock_mgr_cmd+0x77/0xb0 [ 37.492074] Code: 44 24 0e 00 00 00 00 48 c7 04 24 45 00 00 0c 40 88 74 24 0d 0f b6 02 88 44 24 0c 8b 01 89 44 24 08 85 f6 75 05 c6 44 24 0e 01 <48> 8b 7f 58 48 89 e6 ba 01 00 00 00 e8 08 3c 2a 00 65 48 8b 04 5 [ 37.510822] RSP: 0018:ffff969442853300 EFLAGS: 00010202 [ 37.516052] RAX: 0000000000000000 RBX: ffff92db03000000 RCX: ffff969442853358 [ 37.523185] RDX: ffff969442853368 RSI: 0000000000000001 RDI: 0000000000000000 [ 37.530322] RBP: 0000000000000001 R08: 00000000000004a7 R09: 00000000000004a5 [ 37.537453] R10: 0000000000000476 R11: 0000000000000062 R12: ffff92db0ade8000 [ 37.544589] R13: ffff92da01180ae0 R14: ffff92da011802a8 R15: ffff92db03000000 [ 37.551725] FS: 0000784a9cdfc6c0(0000) GS:ffff92db2af00000(0000) knlGS:0000000000000000 [ 37.559814] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 37.565562] CR2: 0000000000000058 CR3: 0000000112b1c000 CR4: 00000000003506f0 [ 37.572697] Call Trace: [ 37.575152] [ 37.577258] ? __die_body+0x66/0xb0 [ 37.580756] ? page_fault_oops+0x3e7/0x4a0 [ 37.584861] ? exc_page_fault+0x3e/0xe0 [ 37.588706] ? exc_page_fault+0x5c/0xe0 [ 37.592550] ? asm_exc_page_fault+0x22/0x30 [ 37.596742] ? dmub_hw_lock_mgr_cmd+0x77/0xb0 [ 37.601107] dcn10_cursor_lock+0x1e1/0x240 [ 37.605211] program_cursor_attributes+0x81/0x190 [ 37.609923] commit_planes_for_stream+0x998/0x1ef0 [ 37.614722] update_planes_and_stream_v2+0x41e/0x5c0 [ 37.619703] dc_update_planes_and_stream+0x78/0x140 [ 37.624588] amdgpu_dm_atomic_commit_tail+0x4362/0x49f0 [ 37.629832] ? srso_return_thunk+0x5/0x5f [ 37.633847] ? mark_held_locks+0x6d/0xd0 [ 37.637774] ? _raw_spin_unlock_irq+0x24/0x50 [ 37.642135] ? srso_return_thunk+0x5/0x5f [ 37.646148] ? lockdep_hardirqs_on+0x95/0x150 [ 37.650510] ? srso_return_thunk+0x5/0x5f [ 37.654522] ? _raw_spin_unlock_irq+0x2f/0x50 [ 37.658883] ? srso_return_thunk+0x5/0x5f [ 37.662897] ? wait_for_common+0x186/0x1c0 [ 37.666998] ? srso_return_thunk+0x5/0x5f [ 37.671009] ? drm_crtc_next_vblank_start+0xc3/0x170 [ 37.675983] commit_tail+0xf5/0x1c0 [ 37.679478] drm_atomic_helper_commit+0x2a2/0x2b0 [ 37.684186] drm_atomic_commit+0xd6/0x100 [ 37.688199] ? __cfi___drm_printfn_info+0x10/0x10 [ 37.692911] drm_atomic_helper_update_plane+0xe5/0x130 [ 37.698054] drm_mode_cursor_common+0x501/0x670 [ 37.702600] ? __cfi_drm_mode_cursor_ioctl+0x10/0x10 [ 37.707572] drm_mode_cursor_ioctl+0x48/0x70 [ 37.711851] drm_ioctl_kernel+0xf2/0x150 [ 37.715781] drm_ioctl+0x363/0x590 [ 37.719189] ? __cfi_drm_mode_cursor_ioctl+0x10/0x10 [ 37.724165] amdgpu_drm_ioctl+0x41/0x80 [ 37.728013] __se_sys_ioctl+0x7f/0xd0 [ 37.731685] do_syscall_64+0x87/0x100 [ 37.735355] ? vma_end_read+0x12/0xe0 [ 37.739024] ? srso_return_thunk+0x5/0x5f [ 37.743041] ? find_held_lock+0x47/0xf0 [ 37.746884] ? vma_end_read+0x12/0xe0 [ 37.750552] ? srso_return_thunk+0x5/0x5f [ 37.754565] ? lock_release+0x1c4/0x2e0 [ 37.758406] ? vma_end_read+0x12/0xe0 [ 37.762079] ? exc_page_fault+0x84/0xe0 [ 37.765921] ? srso_return_thunk+0x5/0x5f [ 37.769938] ? lockdep_hardirqs_on+0x95/0x150 [ 37.774303] ? srso_return_thunk+0x5/0x5f [ 37.778317] ? exc_page_fault+0x84/0xe0 [ 37.782163] entry_SYSCALL_64_after_hwframe+0x55/0x5d [ 37.787218] RIP: 0033:0x784aa5ec3059 [ 37.790803] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 77 1d 48 8b 45 c8 64 48 2b 04 25 28 00 0 [ 37.809553] RSP: 002b:0000784a9cdf90e0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 37.817121] RAX: ffffffffffffffda RBX: 0000784a9cdf917c RCX: 0000784aa5ec3059 [ 37.824256] RDX: 0000784a9cdf917c RSI: 00000000c01c64a3 RDI: 0000000000000020 [ 37.831391] RBP: 0000784a9cdf9130 R08: 0000000000000100 R09: 0000000000ff0000 [ 37.838525] R10: 0000000000000000 R11: 0000000000000246 R12: 0000025c01606ed0 [ 37.845657] R13: 0000025c00030200 R14: 00000000c01c64a3 R15: 0000000000000020 [ 37.852799] [ 37.854992] Modules linked in: [ 37.864546] gsmi: Log Shutdown Reason 0x03 [ 37.868656] CR2: 0000000000000058 [ 37.871979] ---[ end trace 0000000000000000 ]--- [ 37.880976] RIP: 0010:dmub_hw_lock_mgr_cmd+0x77/0xb0 [ 37.885954] Code: 44 24 0e 00 00 00 00 48 c7 04 24 45 00 00 0c 40 88 74 24 0d 0f b6 02 88 44 24 0c 8b 01 89 44 24 08 85 f6 75 05 c6 44 24 0e 01 <48> 8b 7f 58 48 89 e6 ba 01 00 00 00 e8 08 3c 2a 00 65 48 8b 04 5 [ 37.904703] RSP: 0018:ffff969442853300 EFLAGS: 00010202 [ 37.909933] RAX: 0000000000000000 RBX: ffff92db03000000 RCX: ffff969442853358 [ 37.917068] RDX: ffff969442853368 RSI: 0000000000000001 RDI: 0000000000000000 [ 37.924201] RBP: 0000000000000001 R08: 00000000000004a7 R09: 00000000000004a5 [ 37.931336] R10: 0000000000000476 R11: 0000000000000062 R12: ffff92db0ade8000 [ 37.938469] R13: ffff92da01180ae0 R14: ffff92da011802a8 R15: ffff92db03000000 [ 37.945602] FS: 0000784a9cdfc6c0(0000) GS:ffff92db2af00000(0000) knlGS:0000000000000000 [ 37.953689] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 37.959435] CR2: 0000000000000058 CR3: 0000000112b1c000 CR4: 00000000003506f0 [ 37.966570] Kernel panic - not syncing: Fatal exception [ 37.971901] Kernel Offset: 0x30200000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) [ 37.982840] gsmi: Log Shutdown Reason 0x02 Fixes: b5c764d6ed55 ("drm/amd/display: Use HW lock mgr for PSR1") Signed-off-by: Thadeu Lima de Souza Cascardo Cc: Sun peng Li Cc: Tom Chung Cc: Daniel Wheeler Cc: Alex Deucher Reviewed-by: Rodrigo Siqueira Reviewed-by: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 93d0d21af17b24e49516395726428a4ff68e1452 Author: Dan Carpenter Date: Wed Jan 8 12:35:57 2025 +0300 drm/mediatek: dsi: fix error codes in mtk_dsi_host_transfer() [ Upstream commit dcb166ee43c3d594e7b73a24f6e8cf5663eeff2c ] There is a type bug because the return statement: return ret < 0 ? ret : recv_cnt; The issue is that ret is an int, recv_cnt is a u32 and the function returns ssize_t, which is a signed long. The way that the type promotion works is that the negative error codes are first cast to u32 and then to signed long. The error codes end up being positive instead of negative and the callers treat them as success. Fixes: 81cc7e51c4f1 ("drm/mediatek: Allow commands to be sent during video mode") Reported-by: kernel test robot Closes: https://lore.kernel.org/r/202412210801.iADw0oIH-lkp@intel.com/ Signed-off-by: Dan Carpenter Reviewed-by: Mattijs Korpershoek Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/dri-devel/patch/b754a408-4f39-4e37-b52d-7706c132e27f@stanley.mountain/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 149a5c38436c229950cf1020992ce65c9549bc19 Author: Douglas Anderson Date: Thu Jan 16 09:42:50 2025 -0800 drm/mediatek: dp: drm_err => dev_err in HPD path to avoid NULL ptr [ Upstream commit 106a6de46cf4887d535018185ec528ce822d6d84 ] The function mtk_dp_wait_hpd_asserted() may be called before the `mtk_dp->drm_dev` pointer is assigned in mtk_dp_bridge_attach(). Specifically it can be called via this callpath: - mtk_edp_wait_hpd_asserted - [panel probe] - dp_aux_ep_probe Using "drm" level prints anywhere in this callpath causes a NULL pointer dereference. Change the error message directly in mtk_dp_wait_hpd_asserted() to dev_err() to avoid this. Also change the error messages in mtk_dp_parse_capabilities(), which is called by mtk_dp_wait_hpd_asserted(). While touching these prints, also add the error code to them to make future debugging easier. Fixes: 7eacba9a083b ("drm/mediatek: dp: Add .wait_hpd_asserted() for AUX bus") Signed-off-by: Douglas Anderson Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/dri-devel/patch/20250116094249.1.I29b0b621abb613ddc70ab4996426a3909e1aa75f@changeid/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 3e08fdf59ecc23467f457b9354c982559508b787 Author: Jason-JH Lin Date: Mon Feb 24 13:12:21 2025 +0800 drm/mediatek: Fix config_updating flag never false when no mbox channel [ Upstream commit 4ba973c8bad04d59fd4efa62512f4d9cee131714 ] When CONFIG_MTK_CMDQ is enabled, if the display is controlled by the CPU while other hardware is controlled by the GCE, the display will encounter a mbox request channel failure. However, it will still enter the CONFIG_MTK_CMDQ statement, causing the config_updating flag to never be set to false. As a result, no page flip event is sent back to user space, and the screen does not update. Fixes: da03801ad08f ("drm/mediatek: Move mtk_crtc_finish_page_flip() to ddp_cmdq_cb()") Signed-off-by: Jason-JH Lin Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/dri-devel/patch/20250224051301.3538484-1-jason-jh.lin@mediatek.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit a974cf2a6963bf7b5385653dee9648780d2f95b1 Author: Thippeswamy Havalige Date: Mon Feb 24 21:20:22 2025 +0530 PCI: xilinx-cpm: Fix IRQ domain leak in error path of probe [ Upstream commit 57b0302240741e73fe51f88404b3866e0d2933ad ] The IRQ domain allocated for the PCIe controller is not freed if resource_list_first_type() returns NULL, leading to a resource leak. This fix ensures properly cleaning up the allocated IRQ domain in the error path. Fixes: 49e427e6bdd1 ("Merge branch 'pci/host-probe-refactor'") Signed-off-by: Thippeswamy Havalige [kwilczynski: added missing Fixes: tag, refactored to use one of the goto labels] Signed-off-by: Krzysztof Wilczyński Link: https://lore.kernel.org/r/20250224155025.782179-2-thippeswamy.havalige@amd.com Signed-off-by: Sasha Levin commit 272fc4454b09e57ad2d2aea50956b83ccf38e057 Author: Dan Carpenter Date: Fri Mar 7 11:46:34 2025 +0300 PCI: Remove stray put_device() in pci_register_host_bridge() [ Upstream commit 6e8d06e5096c80cbf41313b4a204f43071ca42be ] This put_device() was accidentally left over from when we changed the code from using device_register() to calling device_add(). Delete it. Link: https://lore.kernel.org/r/55b24870-89fb-4c91-b85d-744e35db53c2@stanley.mountain Fixes: 9885440b16b8 ("PCI: Fix pci_host_bridge struct device release/free handling") Signed-off-by: Dan Carpenter Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 8dc888990de9ac098e1156ce70648344f6d4ecc3 Author: Christophe Leroy Date: Thu Mar 6 11:24:28 2025 +0100 powerpc/kexec: fix physical address calculation in clear_utlb_entry() [ Upstream commit 861efb8a48ee8b73ae4e8817509cd4e82fd52bc4 ] In relocate_32.S, function clear_utlb_entry() goes into real mode. To do so, it has to calculate the physical address based on the virtual address. To get the virtual address it uses 'bl' which is problematic (see commit c974809a26a1 ("powerpc/vdso: Avoid link stack corruption in __get_datapage()")). In addition, the calculation is done on a wrong address because 'bl' loads LR with the address of the following instruction, not the address of the target. So when the target is not the instruction following the 'bl' instruction, it may lead to unexpected behaviour. Fix it by re-writing the code so that is goes via another path which is based 'bcl 20,31,.+4' which is the right instruction to use for that. Fixes: 683430200315 ("powerpc/47x: Kernel support for KEXEC") Signed-off-by: Christophe Leroy Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/dc4f9616fba9c05c5dbf9b4b5480eb1c362adc17.1741256651.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit a9f7fff3933c48f45b284b5e0ae6f88f2b7899bd Author: Christophe Leroy Date: Wed Mar 5 00:02:39 2025 +0100 crypto: powerpc: Mark ghashp8-ppc.o as an OBJECT_FILES_NON_STANDARD [ Upstream commit 1e4d73d06c98f5a1af4f7591cf7c2c4eee5b94fa ] The following build warning has been reported: arch/powerpc/crypto/ghashp8-ppc.o: warning: objtool: .text+0x22c: unannotated intra-function call This happens due to commit bb7f054f4de2 ("objtool/powerpc: Add support for decoding all types of uncond branches") Disassembly of arch/powerpc/crypto/ghashp8-ppc.o shows: arch/powerpc/crypto/ghashp8-ppc.o: file format elf64-powerpcle Disassembly of section .text: 0000000000000140 : 140: f8 ff 00 3c lis r0,-8 ... 20c: 20 00 80 4e blr 210: 00 00 00 00 .long 0x0 214: 00 0c 14 00 .long 0x140c00 218: 00 00 04 00 .long 0x40000 21c: 00 00 00 00 .long 0x0 220: 47 48 41 53 rlwimi. r1,r26,9,1,3 224: 48 20 66 6f xoris r6,r27,8264 228: 72 20 50 6f xoris r16,r26,8306 22c: 77 65 72 49 bla 1726574 <== ... It corresponds to the following code in ghashp8-ppc.o : _GLOBAL(gcm_ghash_p8) lis 0,0xfff8 ... blr .long 0 .byte 0,12,0x14,0,0,0,4,0 .long 0 .size gcm_ghash_p8,.-gcm_ghash_p8 .byte 71,72,65,83,72,32,102,111,114,32,80,111,119,101,114,73,83,65,32,50,46,48,55,44,32,67,82,89,80,84,79,71,65,77,83,32,98,121,32,60,97,112,112,114,111,64,111,112,101,110,115,115,108,46,111,114,103,62,0 .align 2 .align 2 In fact this is raw data that is after the function end and that is not text so shouldn't be disassembled as text. But ghashp8-ppc.S is generated by a perl script and should have been marked as OBJECT_FILES_NON_STANDARD. Now that 'bla' is understood as a call instruction, that raw data is mis-interpreted as an infra-function call. Mark ghashp8-ppc.o as a OBJECT_FILES_NON_STANDARD to avoid this warning. Reported-by: Venkat Rao Bagalkote Closes: https://lore.kernel.org/all/8c4c3fc2-2bd7-4148-af68-2f504d6119e0@linux.ibm.com Fixes: 109303336a0c ("crypto: vmx - Move to arch/powerpc/crypto") Signed-off-by: Christophe Leroy Tested-By: Venkat Rao Bagalkote Reviewed-by: Sathvika Vasireddy Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/7aa7eb73fe6bc95ac210510e22394ca0ae227b69.1741128786.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit 1a5add27dc16d5ee2b95655023c89a3d9fa04c08 Author: Niklas Cassel Date: Mon Jan 27 17:12:42 2025 +0100 PCI: endpoint: pci-epf-test: Handle endianness properly [ Upstream commit 3c936e0ec0e412a3ce6072883da8682fb723d573 ] The struct pci_epf_test_reg is the actual data in pci-epf-test's test_reg BAR (usually BAR0), which the host uses to send commands (etc.), and which pci-epf-test uses to send back status codes. pci-epf-test currently reads and writes this data without any endianness conversion functions, which means that pci-epf-test is completely broken on big-endian endpoint systems. PCI devices are inherently little-endian, and the data stored in the PCI BARs should be in little-endian. Use endianness conversion functions when reading and writing data to struct pci_epf_test_reg so that pci-epf-test will behave correctly on big-endian endpoint systems. Fixes: 349e7a85b25f ("PCI: endpoint: functions: Add an EP function to test PCI") Reviewed-by: Frank Li Reviewed-by: Manivannan Sadhasivam Signed-off-by: Niklas Cassel Link: https://lore.kernel.org/r/20250127161242.104651-2-cassel@kernel.org Signed-off-by: Manivannan Sadhasivam Signed-off-by: Krzysztof Wilczyński Signed-off-by: Sasha Levin commit ad59a93b8e35dce1c9f0af6ef011d066c3f1709d Author: Niklas Cassel Date: Fri Jan 24 10:33:01 2025 +0100 misc: pci_endpoint_test: Handle BAR sizes larger than INT_MAX [ Upstream commit 7962c82a6e648d07bf0067796e4a0e69ba1fc702 ] Running 'pcitest -b 0' fails with "TEST FAILED" when the BAR0 size is e.g. 8 GB. The return value of the pci_resource_len() macro can be larger than that of a signed integer type. Thus, when using 'pcitest' with an 8 GB BAR, the bar_size of the integer type will overflow. Change bar_size from integer to resource_size_t to prevent integer overflow for large BAR sizes with 32-bit compilers. In order to handle 64-bit resource_type_t on 32-bit platforms, we would have needed to use a function like div_u64() or similar. Instead, change the code to use addition instead of division. This avoids the need for div_u64() or similar, while also simplifying the code. Fixes: cda370ec6d1f ("misc: pci_endpoint_test: Avoid using hard-coded BAR sizes") Co-developed-by: Hans Zhang <18255117159@163.com> Signed-off-by: Hans Zhang <18255117159@163.com> Signed-off-by: Niklas Cassel Reviewed-by: Manivannan Sadhasivam Tested-by: Jon Hunter Reviewed-by: Frank Li Link: https://lore.kernel.org/r/20250124093300.3629624-2-cassel@kernel.org [mani: added fixes tag] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Krzysztof Wilczyński Signed-off-by: Sasha Levin commit fbe8d734818a57a83d1f22e9eaeb4351d872c9e6 Author: Niklas Cassel Date: Tue Feb 4 12:06:41 2025 +0100 misc: pci_endpoint_test: Fix pci_endpoint_test_bars_read_bar() error handling [ Upstream commit 2a93192d2058507b2e39b590fc1efa0e03344136 ] Commit f26d37ee9bda ("misc: pci_endpoint_test: Fix IOCTL return value") changed the return value of pci_endpoint_test_bars_read_bar() from false to -EINVAL on error, however, it failed to update the error handling. Fixes: f26d37ee9bda ("misc: pci_endpoint_test: Fix IOCTL return value") Signed-off-by: Niklas Cassel Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20250204110640.570823-2-cassel@kernel.org Signed-off-by: Manivannan Sadhasivam Signed-off-by: Krzysztof Wilczyński Signed-off-by: Sasha Levin commit 6cf045b51e2c5721db7e55305f09ee32741e00f9 Author: Vaibhav Jain Date: Tue Feb 4 21:05:26 2025 +0530 powerpc/perf: Fix ref-counting on the PMU 'vpa_pmu' [ Upstream commit ff99d5b6a246715f2257123cdf6c4a29cb33aa78 ] Commit 176cda0619b6 ("powerpc/perf: Add perf interface to expose vpa counters") introduced 'vpa_pmu' to expose Book3s-HV nested APIv2 provided L1<->L2 context switch latency counters to L1 user-space via perf-events. However the newly introduced PMU named 'vpa_pmu' doesn't assign ownership of the PMU to the module 'vpa_pmu'. Consequently the module 'vpa_pmu' can be unloaded while one of the perf-events are still active, which can lead to kernel oops and panic of the form below on a Pseries-LPAR: BUG: Kernel NULL pointer dereference on read at 0x00000058 NIP [c000000000506cb8] event_sched_out+0x40/0x258 LR [c00000000050e8a4] __perf_remove_from_context+0x7c/0x2b0 Call Trace: [c00000025fc3fc30] [c00000025f8457a8] 0xc00000025f8457a8 (unreliable) [c00000025fc3fc80] [fffffffffffffee0] 0xfffffffffffffee0 [c00000025fc3fcd0] [c000000000501e70] event_function+0xa8/0x120 Kernel panic - not syncing: Aiee, killing interrupt handler! Fix this by adding the module ownership to 'vpa_pmu' so that the module 'vpa_pmu' is ref-counted and prevented from being unloaded when perf-events are initialized. Fixes: 176cda0619b6 ("powerpc/perf: Add perf interface to expose vpa counters") Signed-off-by: Vaibhav Jain Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20250204153527.125491-1-vaibhav@linux.ibm.com Signed-off-by: Sasha Levin commit 7e674a6d60ce45e8f5faf7dd0a44416a2635d2a4 Author: Rob Clark Date: Fri Feb 28 13:31:24 2025 -0800 drm/msm/a6xx: Fix a6xx indexed-regs in devcoreduump [ Upstream commit 06dd5d86c6aef1c7609ca3a5ffa4097e475e2213 ] Somehow, possibly as a result of rebase gone badly, setting nr_indexed_regs for pre-a650 a6xx devices lost the setting of nr_indexed_regs, resulting in values getting snapshot, but omitted from the devcoredump. Fixes: e997ae5f45ca ("drm/msm/a6xx: Mostly implement A7xx gpu_state") Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/640289/ Signed-off-by: Sasha Levin commit 19eabfdf5facba8098d2d39b705d13e9750e7ec3 Author: Vitaliy Shevtsov Date: Thu Feb 27 01:28:51 2025 +0500 drm/amd/display: fix type mismatch in CalculateDynamicMetadataParameters() [ Upstream commit c3c584c18c90a024a54716229809ba36424f9660 ] There is a type mismatch between what CalculateDynamicMetadataParameters() takes and what is passed to it. Currently this function accepts several args as signed long but it's called with unsigned integers and integer. On some systems where long is 32 bits and one of these unsigned int params is greater than INT_MAX it may cause passing input params as negative values. Fix this by changing these argument types from long to unsigned int and to int respectively. Also this will align the function's definition with similar functions in other dcn* drivers. Found by Linux Verification Center (linuxtesting.org) with Svace. Fixes: 6725a88f88a7 ("drm/amd/display: Add DCN3 DML") Signed-off-by: Vitaliy Shevtsov Reviewed-by: Alex Hung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 8f6c920ca38609360c3fea5c51d84063463fb343 Author: Steven Price Date: Thu Feb 13 16:12:48 2025 +0000 drm/panthor: Clean up FW version information display [ Upstream commit 3b87886bfb038de2c62e627079472ba612e89410 ] Assigning a string to an array which is too small to include the NUL byte at the end causes a warning on some compilers. But this function also has some other oddities like the 'header' array which is only ever used within sizeof(). Tidy up the function by removing the 'header' array, allow the NUL byte to be present in git_sha_header, and calculate the length directly from git_sha_header. Reported-by: Will Deacon Closes: https://lore.kernel.org/all/20250213154237.GA11897@willie-the-truck/ Fixes: 9d443deb0441 ("drm/panthor: Display FW version information") Signed-off-by: Steven Price Acked-by: Will Deacon Reviewed-by: Boris Brezillon Link: https://patchwork.freedesktop.org/patch/msgid/20250213161248.1642392-1-steven.price@arm.com Signed-off-by: Sasha Levin commit ab9cb310823ed0f3df7e6f86d514f391a3007544 Author: Adrián Larumbe Date: Mon Mar 3 19:08:46 2025 +0000 drm/panthor: Avoid sleep locking in the internal BO size path [ Upstream commit c63c3bfdde2656a3ead50ac3ce4a51a634e22dab ] Commit 434e5ca5b5d7 ("drm/panthor: Expose size of driver internal BO's over fdinfo") locks the VMS xarray, to avoid UAF errors when the same VM is being concurrently destroyed by another thread. However, that puts the current thread in atomic context, which means taking the VMS' heap locks will trigger a warning as the thread is no longer allowed to sleep. Because in this case replacing the heap mutex with a spinlock isn't feasible, the fdinfo handler no longer traverses the list of heaps for every single VM associated with an open DRM file. Instead, when a new heap chunk is allocated, its size is accumulated into a pool-wide tally, which also makes the atomic context code path somewhat faster. Signed-off-by: Adrián Larumbe Fixes: 434e5ca5b5d7 ("drm/panthor: Expose size of driver internal BO's over fdinfo") Reviewed-by: Boris Brezillon Reviewed-by: Steven Price Signed-off-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20250303190923.1639985-2-adrian.larumbe@collabora.com Signed-off-by: Sasha Levin commit 446311aa801cbf21a9c22f7174fd1716ea6aefe9 Author: Adrián Larumbe Date: Mon Mar 3 19:08:45 2025 +0000 drm/panthor: Replace sleep locks with spinlocks in fdinfo path [ Upstream commit e379856b428acafb8ed689f31d65814da6447b2e ] Commit 0590c94c3596 ("drm/panthor: Fix race condition when gathering fdinfo group samples") introduced an xarray lock to deal with potential use-after-free errors when accessing groups fdinfo figures. However, this toggles the kernel's atomic context status, so the next nested mutex lock will raise a warning when the kernel is compiled with mutex debug options: CONFIG_DEBUG_RT_MUTEXES=y CONFIG_DEBUG_MUTEXES=y Replace Panthor's group fdinfo data mutex with a guarded spinlock. Signed-off-by: Adrián Larumbe Fixes: 0590c94c3596 ("drm/panthor: Fix race condition when gathering fdinfo group samples") Reviewed-by: Liviu Dudau Reviewed-by: Boris Brezillon Reviewed-by: Steven Price Signed-off-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20250303190923.1639985-1-adrian.larumbe@collabora.com Signed-off-by: Sasha Levin commit 097a87319ef1bd0d227406e2d686bfcada826ac0 Author: Adrián Larumbe Date: Thu Jan 30 17:28:11 2025 +0000 drm/panthor: Expose size of driver internal BO's over fdinfo [ Upstream commit 434e5ca5b5d7ea415670d4fcb399d90d355a1e38 ] This will display the sizes of kenrel BO's bound to an open file, which are otherwise not exposed to UM through a handle. The sizes recorded are as follows: - Per group: suspend buffer, protm-suspend buffer, syncobjcs - Per queue: ringbuffer, profiling slots, firmware interface - For all heaps in all heap pools across all VM's bound to an open file, record size of all heap chuks, and for each pool the gpu_context BO too. This does not record the size of FW regions, as these aren't bound to a specific open file and remain active through the whole life of the driver. Reviewed-by: Liviu Dudau Reviewed-by: Mihail Atanassov Reviewed-by: Steven Price Reviewed-by: Boris Brezillon Signed-off-by: Adrián Larumbe Signed-off-by: Boris Brezillon Link: https://patchwork.freedesktop.org/patch/msgid/20250130172851.941597-4-adrian.larumbe@collabora.com Stable-dep-of: e379856b428a ("drm/panthor: Replace sleep locks with spinlocks in fdinfo path") Signed-off-by: Sasha Levin commit c31e5e720aa627eadb2075cd53c3e6ba995b4ed8 Author: Adrián Larumbe Date: Thu Jan 30 17:28:10 2025 +0000 drm/file: Add fdinfo helper for printing regions with prefix [ Upstream commit af6c2b7c46e16701fba44a21326cb634786e3e71 ] This is motivated by the desire of some drivers (eg. Panthor) to print the size of internal memory regions with a prefix that reflects the driver name, as suggested in the previous documentation commit. That means adding a new argument to print_size and making it available for DRM users. Cc: Tvrtko Ursulin Reviewed-by: Tvrtko Ursulin Signed-off-by: Adrián Larumbe Signed-off-by: Boris Brezillon Link: https://patchwork.freedesktop.org/patch/msgid/20250130172851.941597-3-adrian.larumbe@collabora.com Stable-dep-of: e379856b428a ("drm/panthor: Replace sleep locks with spinlocks in fdinfo path") Signed-off-by: Sasha Levin commit 3d659dc2f9a02f0e140a3d5287709f2263e5e863 Author: Ashley Smith Date: Mon Mar 3 18:04:32 2025 +0000 drm/panthor: Update CS_STATUS_ defines to correct values [ Upstream commit c82734fbdc50dc9e568e8686622eaa4498acb81e ] Values for SC_STATUS_BLOCKED_REASON_ are documented in the G610 "Odin" GPU specification (CS_STATUS_BLOCKED_REASON register). This change updates the defines to the correct values. Fixes: 2718d91816ee ("drm/panthor: Add the FW logical block") Signed-off-by: Ashley Smith Reviewed-by: Liviu Dudau Reviewed-by: Adrián Larumbe Reviewed-by: Boris Brezillon Reviewed-by: Steven Price Signed-off-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20250303180444.3768993-1-ashley.smith@collabora.com Signed-off-by: Sasha Levin commit 07c05d6c6fa36eedf601fdeeafd5b14439ed6fa2 Author: Dmitry Baryshkov Date: Thu Jan 23 14:43:36 2025 +0200 drm/msm/dpu: don't set crtc_state->mode_changed from atomic_check() [ Upstream commit 2dde2aadaed113feb724c19063ac61e2f6ba61a4 ] The MSM driver uses drm_atomic_helper_check() which mandates that none of the atomic_check() callbacks toggles crtc_state->mode_changed. Perform corresponding check before calling the drm_atomic_helper_check() function. Fixes: 8b45a26f2ba9 ("drm/msm/dpu: reserve cdm blocks for writeback in case of YUV output") Reported-by: Simona Vetter Closes: https://lore.kernel.org/dri-devel/ZtW_S0j5AEr4g0QW@phenom.ffwll.local/ Reviewed-by: Abhinav Kumar [DB: dropped the WARN_ON] Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/633400/ Link: https://lore.kernel.org/r/20250123-drm-dirty-modeset-v2-4-bbfd3a6cd1a4@linaro.org Signed-off-by: Sasha Levin commit 83b74af219bef6c3e04db35c20d4ad0fbf91c451 Author: Dmitry Baryshkov Date: Thu Jan 23 14:43:35 2025 +0200 drm/msm/dpu: simplify dpu_encoder_get_topology() interface [ Upstream commit 41921f231abf9a3a95550b2b565df8e4329319cb ] As a preparation for calling dpu_encoder_get_topology() from different code paths, simplify its calling interface, obtaining some data pointers internally instead passing them via arguments. Reviewed-by: Abhinav Kumar Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/633396/ Link: https://lore.kernel.org/r/20250123-drm-dirty-modeset-v2-3-bbfd3a6cd1a4@linaro.org Stable-dep-of: 2dde2aadaed1 ("drm/msm/dpu: don't set crtc_state->mode_changed from atomic_check()") Signed-off-by: Sasha Levin commit 567e54ae4ec1675f4b09771406b3b10292c432ef Author: Dmitry Baryshkov Date: Thu Jan 23 14:43:34 2025 +0200 drm/msm/dpu: move needs_cdm setting to dpu_encoder_get_topology() [ Upstream commit 7d39f5bb82c0d7155037982dd0ff583a68db1c34 ] As a preparation for calling dpu_encoder_get_topology() from different places, move the code setting topology->needs_cdm to that function (instead of patching topology separately). Reviewed-by: Abhinav Kumar Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/633395/ Link: https://lore.kernel.org/r/20250123-drm-dirty-modeset-v2-2-bbfd3a6cd1a4@linaro.org Stable-dep-of: 2dde2aadaed1 ("drm/msm/dpu: don't set crtc_state->mode_changed from atomic_check()") Signed-off-by: Sasha Levin commit 792bd08a41bdc309e08ff4d429f670cbb30f2b63 Author: Nishanth Aravamudan Date: Fri Feb 7 14:56:00 2025 -0600 PCI: Avoid reset when disabled via sysfs [ Upstream commit 479380efe1625e251008d24b2810283db60d6fcd ] After d88f521da3ef ("PCI: Allow userspace to query and set device reset mechanism"), userspace can disable reset of specific PCI devices by writing an empty string to the sysfs reset_method file. However, pci_slot_resettable() does not check pci_reset_supported(), which means that pci_reset_function() will still reset the device even if userspace has disabled all the reset methods. I was able to reproduce this issue with a vfio device passed to a qemu guest, where I had disabled PCI reset via sysfs. Add an explicit check of pci_reset_supported() in both pci_slot_resettable() and pci_bus_resettable() to ensure both the reset status and reset execution are bypassed if an administrator disables it for a device. Link: https://lore.kernel.org/r/20250207205600.1846178-1-naravamudan@nvidia.com Fixes: d88f521da3ef ("PCI: Allow userspace to query and set device reset mechanism") Signed-off-by: Nishanth Aravamudan [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Cc: Alex Williamson Cc: Raphael Norwitz Cc: Amey Narkhede Cc: Jason Gunthorpe Cc: Yishai Hadas Cc: Shameer Kolothum Cc: Kevin Tian Signed-off-by: Sasha Levin commit ffaff1d98bde263fa921b8a20ca2364eb6e33585 Author: Feng Tang Date: Mon Mar 3 10:36:30 2025 +0800 PCI/portdrv: Only disable pciehp interrupts early when needed [ Upstream commit 9d7db4db19827380e225914618c0c1bf435ed2f5 ] Firmware developers reported that Linux issues two PCIe hotplug commands in very short intervals on an ARM server, which doesn't comply with the PCIe spec. According to PCIe r6.1, sec 6.7.3.2, if the Command Completed event is supported, software must wait for a command to complete or wait at least 1 second before sending a new command. In the failure case, the first PCIe hotplug command is from get_port_device_capability(), which sends a command to disable PCIe hotplug interrupts without waiting for its completion, and the second command comes from pcie_enable_notification() of pciehp driver, which enables hotplug interrupts again. Fix this by only disabling the hotplug interrupts when the pciehp driver is not enabled. Link: https://lore.kernel.org/r/20250303023630.78397-1-feng.tang@linux.alibaba.com Fixes: 2bd50dd800b5 ("PCI: PCIe: Disable PCIe port services during port initialization") Suggested-by: Lukas Wunner Signed-off-by: Feng Tang [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Reviewed-by: Lukas Wunner Reviewed-by: Kuppuswamy Sathyanarayanan Signed-off-by: Sasha Levin commit 5fd8f8750930f106f5df0e0fb27ab07d97279472 Author: Yi Lai Date: Fri Feb 28 15:00:59 2025 +0800 selftests/pcie_bwctrl: Add 'set_pcie_speed.sh' to TEST_PROGS [ Upstream commit df6f8c4d72aebaf66aaa8658c723fd360c272e59 ] The test shell script "set_pcie_speed.sh" is not installed in INSTALL_PATH. Attempting to execute set_pcie_cooling_state.sh shows warning: ./set_pcie_cooling_state.sh: line 119: ./set_pcie_speed.sh: No such file or directory Add "set_pcie_speed.sh" to TEST_PROGS. Link: https://lore.kernel.org/r/Z8FfK8rN30lKzvVV@ly-workstation Fixes: 838f12c3d551 ("selftests/pcie_bwctrl: Create selftests") Signed-off-by: Yi Lai Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 9bb8d77669648c7df7066caa68492a5e913f38a5 Author: Jim Quinlan Date: Fri Feb 14 12:39:33 2025 -0500 PCI: brcmstb: Fix potential premature regulator disabling [ Upstream commit b7de1b60ecab2f7b6f05d8116e93228a0bbb8563 ] The platform supports enabling and disabling regulators only on ports below the Root Complex. Thus, we need to verify this both when adding and removing the bus, otherwise regulators may be disabled prematurely when a bus further down the topology is removed. Fixes: 9e6be018b263 ("PCI: brcmstb: Enable child bus device regulators from DT") Signed-off-by: Jim Quinlan Reviewed-by: Florian Fainelli Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20250214173944.47506-6-james.quinlan@broadcom.com [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński Signed-off-by: Sasha Levin commit 6f44e1fdb006db61394aa4d4c25728ada00842e7 Author: Jim Quinlan Date: Fri Feb 14 12:39:32 2025 -0500 PCI: brcmstb: Fix error path after a call to regulator_bulk_get() [ Upstream commit 3651ad5249c51cf7eee078e12612557040a6bdb4 ] If the regulator_bulk_get() returns an error and no regulators are created, we need to set their number to zero. If we don't do this and the PCIe link up fails, a call to the regulator_bulk_free() will result in a kernel panic. While at it, print the error value, as we cannot return an error upwards as the kernel will WARN() on an error from add_bus(). Fixes: 9e6be018b263 ("PCI: brcmstb: Enable child bus device regulators from DT") Signed-off-by: Jim Quinlan Reviewed-by: Florian Fainelli Link: https://lore.kernel.org/r/20250214173944.47506-5-james.quinlan@broadcom.com [kwilczynski: commit log, use comma in the message to match style with other similar messages] Signed-off-by: Krzysztof Wilczyński Signed-off-by: Sasha Levin commit 6918a1b77b5f60b76dd347426686790ab8887b12 Author: Jim Quinlan Date: Fri Feb 14 12:39:30 2025 -0500 PCI: brcmstb: Use internal register to change link capability [ Upstream commit 0c97321e11e0e9e18546f828492758f6aaecec59 ] The driver has been mistakenly writing to a read-only (RO) configuration space register (PCI_EXP_LNKCAP) to change the PCIe link capability. Although harmless in this case, the proper write destination is an internal register that is reflected by PCI_EXP_LNKCAP. Thus, fix the brcm_pcie_set_gen() function to correctly update the link capability. Fixes: c0452137034b ("PCI: brcmstb: Add Broadcom STB PCIe host controller driver") Signed-off-by: Jim Quinlan Reviewed-by: Florian Fainelli Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20250214173944.47506-3-james.quinlan@broadcom.com [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński Signed-off-by: Sasha Levin commit b3949f7edf92b5f8191be820124f6cb956faa95d Author: Jim Quinlan Date: Fri Feb 14 12:39:29 2025 -0500 PCI: brcmstb: Set generation limit before PCIe link up [ Upstream commit 72d36589c6b7bef6b30eb99fcb7082f72faca37f ] When the user elects to limit the PCIe generation via the appropriate devicetree property, apply the settings before the PCIe link up, not after. Fixes: c0452137034b ("PCI: brcmstb: Add Broadcom STB PCIe host controller driver") Signed-off-by: Jim Quinlan Reviewed-by: Florian Fainelli Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20250214173944.47506-2-james.quinlan@broadcom.com [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński Signed-off-by: Sasha Levin commit faf043ed96941d7810e09e2f20dccf64fc897b11 Author: Hans Zhang <18255117159@163.com> Date: Sat Feb 15 00:57:24 2025 +0800 PCI: cadence-ep: Fix the driver to send MSG TLP for INTx without data payload [ Upstream commit 3ac47fbf4f6e8c3a7c3855fac68cc3246f90f850 ] Per the Cadence's "PCIe Controller IP for AX14" user guide, Version 1.04, Section 9.1.7.1, "AXI Subordinate to PCIe Address Translation Registers", Table 9.4, the bit 16 of the AXI Subordinate Address (axi_s_awaddr) when set corresponds to MSG with data, and when not set, to MSG without data. However, the driver is currently doing the opposite and due to this, the INTx is never received on the host. So, fix the driver to reflect the documentation and also make INTx work. Fixes: 37dddf14f1ae ("PCI: cadence: Add EndPoint Controller driver for Cadence PCIe controller") Signed-off-by: Hans Zhang <18255117159@163.com> Signed-off-by: Hans Zhang Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20250214165724.184599-1-18255117159@163.com [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński Signed-off-by: Sasha Levin commit c7ca14aa446f074fb717af6a1bc81e2fef824a28 Author: Lorenzo Bianconi Date: Tue Feb 25 09:04:07 2025 +0100 PCI: mediatek-gen3: Configure PBUS_CSR registers for EN7581 SoC [ Upstream commit 249b78298078448a699c39356d27d8183af4b281 ] Configure PBus base address and address mask to allow the hw to detect if a given address is accessible on PCIe controller. Fixes: f6ab898356dd ("PCI: mediatek-gen3: Add Airoha EN7581 support") Reviewed-by: Manivannan Sadhasivam Signed-off-by: Lorenzo Bianconi Link: https://lore.kernel.org/r/20250225-en7581-pcie-pbus-csr-v4-2-24324382424a@kernel.org Signed-off-by: Krzysztof Wilczyński Signed-off-by: Sasha Levin commit d86ba913bbfd1afafacbfb750001ffc6bfe29da0 Author: Srinivasan Shanmugam Date: Mon Feb 24 13:46:32 2025 +0530 drm/amdkfd: Fix Circular Locking Dependency in 'svm_range_cpu_invalidate_pagetables' [ Upstream commit fddc45026311c05a5355fd34b9dc0a1d7eaef4a2 ] This commit addresses a circular locking dependency in the svm_range_cpu_invalidate_pagetables function. The function previously held a lock while determining whether to perform an unmap or eviction operation, which could lead to deadlocks. Fixes the below: [ 223.418794] ====================================================== [ 223.418820] WARNING: possible circular locking dependency detected [ 223.418845] 6.12.0-amdstaging-drm-next-lol-050225 #14 Tainted: G U OE [ 223.418869] ------------------------------------------------------ [ 223.418889] kfdtest/3939 is trying to acquire lock: [ 223.418906] ffff8957552eae38 (&dqm->lock_hidden){+.+.}-{3:3}, at: evict_process_queues_cpsch+0x43/0x210 [amdgpu] [ 223.419302] but task is already holding lock: [ 223.419303] ffff8957556b83b0 (&prange->lock){+.+.}-{3:3}, at: svm_range_cpu_invalidate_pagetables+0x9d/0x850 [amdgpu] [ 223.419447] Console: switching to colour dummy device 80x25 [ 223.419477] [IGT] amd_basic: executing [ 223.419599] which lock already depends on the new lock. [ 223.419611] the existing dependency chain (in reverse order) is: [ 223.419621] -> #2 (&prange->lock){+.+.}-{3:3}: [ 223.419636] __mutex_lock+0x85/0xe20 [ 223.419647] mutex_lock_nested+0x1b/0x30 [ 223.419656] svm_range_validate_and_map+0x2f1/0x15b0 [amdgpu] [ 223.419954] svm_range_set_attr+0xe8c/0x1710 [amdgpu] [ 223.420236] svm_ioctl+0x46/0x50 [amdgpu] [ 223.420503] kfd_ioctl_svm+0x50/0x90 [amdgpu] [ 223.420763] kfd_ioctl+0x409/0x6d0 [amdgpu] [ 223.421024] __x64_sys_ioctl+0x95/0xd0 [ 223.421036] x64_sys_call+0x1205/0x20d0 [ 223.421047] do_syscall_64+0x87/0x140 [ 223.421056] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 223.421068] -> #1 (reservation_ww_class_mutex){+.+.}-{3:3}: [ 223.421084] __ww_mutex_lock.constprop.0+0xab/0x1560 [ 223.421095] ww_mutex_lock+0x2b/0x90 [ 223.421103] amdgpu_amdkfd_alloc_gtt_mem+0xcc/0x2b0 [amdgpu] [ 223.421361] add_queue_mes+0x3bc/0x440 [amdgpu] [ 223.421623] unhalt_cpsch+0x1ae/0x240 [amdgpu] [ 223.421888] kgd2kfd_start_sched+0x5e/0xd0 [amdgpu] [ 223.422148] amdgpu_amdkfd_start_sched+0x3d/0x50 [amdgpu] [ 223.422414] amdgpu_gfx_enforce_isolation_handler+0x132/0x270 [amdgpu] [ 223.422662] process_one_work+0x21e/0x680 [ 223.422673] worker_thread+0x190/0x330 [ 223.422682] kthread+0xe7/0x120 [ 223.422690] ret_from_fork+0x3c/0x60 [ 223.422699] ret_from_fork_asm+0x1a/0x30 [ 223.422708] -> #0 (&dqm->lock_hidden){+.+.}-{3:3}: [ 223.422723] __lock_acquire+0x16f4/0x2810 [ 223.422734] lock_acquire+0xd1/0x300 [ 223.422742] __mutex_lock+0x85/0xe20 [ 223.422751] mutex_lock_nested+0x1b/0x30 [ 223.422760] evict_process_queues_cpsch+0x43/0x210 [amdgpu] [ 223.423025] kfd_process_evict_queues+0x8a/0x1d0 [amdgpu] [ 223.423285] kgd2kfd_quiesce_mm+0x43/0x90 [amdgpu] [ 223.423540] svm_range_cpu_invalidate_pagetables+0x4a7/0x850 [amdgpu] [ 223.423807] __mmu_notifier_invalidate_range_start+0x1f5/0x250 [ 223.423819] copy_page_range+0x1e94/0x1ea0 [ 223.423829] copy_process+0x172f/0x2ad0 [ 223.423839] kernel_clone+0x9c/0x3f0 [ 223.423847] __do_sys_clone+0x66/0x90 [ 223.423856] __x64_sys_clone+0x25/0x30 [ 223.423864] x64_sys_call+0x1d7c/0x20d0 [ 223.423872] do_syscall_64+0x87/0x140 [ 223.423880] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 223.423891] other info that might help us debug this: [ 223.423903] Chain exists of: &dqm->lock_hidden --> reservation_ww_class_mutex --> &prange->lock [ 223.423926] Possible unsafe locking scenario: [ 223.423935] CPU0 CPU1 [ 223.423942] ---- ---- [ 223.423949] lock(&prange->lock); [ 223.423958] lock(reservation_ww_class_mutex); [ 223.423970] lock(&prange->lock); [ 223.423981] lock(&dqm->lock_hidden); [ 223.423990] *** DEADLOCK *** [ 223.423999] 5 locks held by kfdtest/3939: [ 223.424006] #0: ffffffffb82b4fc0 (dup_mmap_sem){.+.+}-{0:0}, at: copy_process+0x1387/0x2ad0 [ 223.424026] #1: ffff89575eda81b0 (&mm->mmap_lock){++++}-{3:3}, at: copy_process+0x13a8/0x2ad0 [ 223.424046] #2: ffff89575edaf3b0 (&mm->mmap_lock/1){+.+.}-{3:3}, at: copy_process+0x13e4/0x2ad0 [ 223.424066] #3: ffffffffb82e76e0 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}, at: copy_page_range+0x1cea/0x1ea0 [ 223.424088] #4: ffff8957556b83b0 (&prange->lock){+.+.}-{3:3}, at: svm_range_cpu_invalidate_pagetables+0x9d/0x850 [amdgpu] [ 223.424365] stack backtrace: [ 223.424374] CPU: 0 UID: 0 PID: 3939 Comm: kfdtest Tainted: G U OE 6.12.0-amdstaging-drm-next-lol-050225 #14 [ 223.424392] Tainted: [U]=USER, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE [ 223.424401] Hardware name: Gigabyte Technology Co., Ltd. X570 AORUS PRO WIFI/X570 AORUS PRO WIFI, BIOS F36a 02/16/2022 [ 223.424416] Call Trace: [ 223.424423] [ 223.424430] dump_stack_lvl+0x9b/0xf0 [ 223.424441] dump_stack+0x10/0x20 [ 223.424449] print_circular_bug+0x275/0x350 [ 223.424460] check_noncircular+0x157/0x170 [ 223.424469] ? __bfs+0xfd/0x2c0 [ 223.424481] __lock_acquire+0x16f4/0x2810 [ 223.424490] ? srso_return_thunk+0x5/0x5f [ 223.424505] lock_acquire+0xd1/0x300 [ 223.424514] ? evict_process_queues_cpsch+0x43/0x210 [amdgpu] [ 223.424783] __mutex_lock+0x85/0xe20 [ 223.424792] ? evict_process_queues_cpsch+0x43/0x210 [amdgpu] [ 223.425058] ? srso_return_thunk+0x5/0x5f [ 223.425067] ? mark_held_locks+0x54/0x90 [ 223.425076] ? evict_process_queues_cpsch+0x43/0x210 [amdgpu] [ 223.425339] ? srso_return_thunk+0x5/0x5f [ 223.425350] mutex_lock_nested+0x1b/0x30 [ 223.425358] ? mutex_lock_nested+0x1b/0x30 [ 223.425367] evict_process_queues_cpsch+0x43/0x210 [amdgpu] [ 223.425631] kfd_process_evict_queues+0x8a/0x1d0 [amdgpu] [ 223.425893] kgd2kfd_quiesce_mm+0x43/0x90 [amdgpu] [ 223.426156] svm_range_cpu_invalidate_pagetables+0x4a7/0x850 [amdgpu] [ 223.426423] ? srso_return_thunk+0x5/0x5f [ 223.426436] __mmu_notifier_invalidate_range_start+0x1f5/0x250 [ 223.426450] copy_page_range+0x1e94/0x1ea0 [ 223.426461] ? srso_return_thunk+0x5/0x5f [ 223.426474] ? srso_return_thunk+0x5/0x5f [ 223.426484] ? lock_acquire+0xd1/0x300 [ 223.426494] ? copy_process+0x1718/0x2ad0 [ 223.426502] ? srso_return_thunk+0x5/0x5f [ 223.426510] ? sched_clock_noinstr+0x9/0x10 [ 223.426519] ? local_clock_noinstr+0xe/0xc0 [ 223.426528] ? copy_process+0x1718/0x2ad0 [ 223.426537] ? srso_return_thunk+0x5/0x5f [ 223.426550] copy_process+0x172f/0x2ad0 [ 223.426569] kernel_clone+0x9c/0x3f0 [ 223.426577] ? __schedule+0x4c9/0x1b00 [ 223.426586] ? srso_return_thunk+0x5/0x5f [ 223.426594] ? sched_clock_noinstr+0x9/0x10 [ 223.426602] ? srso_return_thunk+0x5/0x5f [ 223.426610] ? local_clock_noinstr+0xe/0xc0 [ 223.426619] ? schedule+0x107/0x1a0 [ 223.426629] __do_sys_clone+0x66/0x90 [ 223.426643] __x64_sys_clone+0x25/0x30 [ 223.426652] x64_sys_call+0x1d7c/0x20d0 [ 223.426661] do_syscall_64+0x87/0x140 [ 223.426671] ? srso_return_thunk+0x5/0x5f [ 223.426679] ? common_nsleep+0x44/0x50 [ 223.426690] ? srso_return_thunk+0x5/0x5f [ 223.426698] ? trace_hardirqs_off+0x52/0xd0 [ 223.426709] ? srso_return_thunk+0x5/0x5f [ 223.426717] ? syscall_exit_to_user_mode+0xcc/0x200 [ 223.426727] ? srso_return_thunk+0x5/0x5f [ 223.426736] ? do_syscall_64+0x93/0x140 [ 223.426748] ? srso_return_thunk+0x5/0x5f [ 223.426756] ? up_write+0x1c/0x1e0 [ 223.426765] ? srso_return_thunk+0x5/0x5f [ 223.426775] ? srso_return_thunk+0x5/0x5f [ 223.426783] ? trace_hardirqs_off+0x52/0xd0 [ 223.426792] ? srso_return_thunk+0x5/0x5f [ 223.426800] ? syscall_exit_to_user_mode+0xcc/0x200 [ 223.426810] ? srso_return_thunk+0x5/0x5f [ 223.426818] ? do_syscall_64+0x93/0x140 [ 223.426826] ? syscall_exit_to_user_mode+0xcc/0x200 [ 223.426836] ? srso_return_thunk+0x5/0x5f [ 223.426844] ? do_syscall_64+0x93/0x140 [ 223.426853] ? srso_return_thunk+0x5/0x5f [ 223.426861] ? irqentry_exit+0x6b/0x90 [ 223.426869] ? srso_return_thunk+0x5/0x5f [ 223.426877] ? exc_page_fault+0xa7/0x2c0 [ 223.426888] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 223.426898] RIP: 0033:0x7f46758eab57 [ 223.426906] Code: ba 04 00 f3 0f 1e fa 64 48 8b 04 25 10 00 00 00 45 31 c0 31 d2 31 f6 bf 11 00 20 01 4c 8d 90 d0 02 00 00 b8 38 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 41 41 89 c0 85 c0 75 2c 64 48 8b 04 25 10 00 [ 223.426930] RSP: 002b:00007fff5c3e5188 EFLAGS: 00000246 ORIG_RAX: 0000000000000038 [ 223.426943] RAX: ffffffffffffffda RBX: 00007f4675f8c040 RCX: 00007f46758eab57 [ 223.426954] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000001200011 [ 223.426965] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 223.426975] R10: 00007f4675e81a50 R11: 0000000000000246 R12: 0000000000000001 [ 223.426986] R13: 00007fff5c3e5470 R14: 00007fff5c3e53e0 R15: 00007fff5c3e5410 [ 223.427004] v2: To resolve this issue, the allocation of the process context buffer (`proc_ctx_bo`) has been moved from the `add_queue_mes` function to the `pqm_create_queue` function. This change ensures that the buffer is allocated only when the first queue for a process is created and only if the Micro Engine Scheduler (MES) is enabled. (Felix) v3: Fix typo s/Memory Execution Scheduler (MES)/Micro Engine Scheduler in commit message. (Lijo) Fixes: 438b39ac74e2 ("drm/amdkfd: pause autosuspend when creating pdd") Cc: Jesse Zhang Cc: Yunxiang Li Cc: Philip Yang Cc: Alex Sierra Cc: Felix Kuehling Cc: Christian König Cc: Alex Deucher Signed-off-by: Srinivasan Shanmugam Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit efe759dcf3352d8379a1adad7b4d14044a4c41a7 Author: Dan Carpenter Date: Mon Feb 17 10:32:11 2025 +0300 drm/msm/gem: Fix error code msm_parse_deps() [ Upstream commit 0b305b7cadce835505bd93183a599acb1f800a05 ] The SUBMIT_ERROR() macro turns the error code negative. This extra '-' operation turns it back to positive EINVAL again. The error code is passed to ERR_PTR() and since positive values are not an IS_ERR() it eventually will lead to an oops. Delete the '-'. Fixes: 866e43b945bf ("drm/msm: UAPI error reporting") Signed-off-by: Dan Carpenter Patchwork: https://patchwork.freedesktop.org/patch/637625/ Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 98adf63c16131a4a3476adc8dea89308c5300d32 Author: Marijn Suijten Date: Mon Feb 17 12:17:43 2025 +0100 drm/msm/dpu: Remove arbitrary limit of 1 interface in DSC topology [ Upstream commit d245ce568929e30f650e260631f7ad14970d7c2c ] When DSC is enabled the number of interfaces is forced to be 1, and documented that it is a "power-optimal" layout to use two DSC encoders together with two Layer Mixers. However, the same layout (two DSC hard-slice encoders with two LMs) is also used when the display is fed with data over two instead of one interface (common on 4k@120Hz smartphone panels with Dual-DSI). Solve this by simply removing the num_intf = 1 assignment as the count is already calculated by computing the number of physical encoders within the virtual encoder. Fixes: 7e9cc175b159 ("drm/msm/disp/dpu1: Add support for DSC in topology") Reviewed-by: Dmitry Baryshkov Reviewed-by: Jessica Zhang Signed-off-by: Marijn Suijten Patchwork: https://patchwork.freedesktop.org/patch/637649/ Link: https://lore.kernel.org/r/20250217-drm-msm-initial-dualpipe-dsc-fixes-v3-3-913100d6103f@somainline.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 74a4f3559cf316eef21bd26f683d96bbfc15500c Author: Marijn Suijten Date: Wed Jan 22 17:23:44 2025 +0100 drm/msm/dpu: Fall back to a single DSC encoder (1:1:1) on small SoCs [ Upstream commit b6090ffb30f3301d3831774f9c3e2f1b1141a399 ] Some SoCs such as SC7280 (used in the Fairphone 5) have only a single DSC "hard slice" encoder. The current hardcoded use of 2:2:1 topology (2 LM and 2 DSC for a single interface) make it impossible to use Display Stream Compression panels with mainline, which is exactly what's installed on the Fairphone 5. By loosening the hardcoded `num_dsc = 2` to fall back to `num_dsc = 1` when the catalog only contains one entry, we can trivially support this phone and unblock further panel enablement on mainline. A few more supporting changes in this patch ensure hardcoded constants of 2 DSC encoders are replaced to count or read back the actual number of DSC hardware blocks that are enabled for the given virtual encoder. Likewise DSC_MODE_SPLIT_PANEL can no longer be unconditionally enabled. Cc: Luca Weiss Signed-off-by: Marijn Suijten Reviewed-by: Dmitry Baryshkov Tested-by: Luca Weiss Reviewed-by: Jessica Zhang Tested-by: Danila Tikhonov Patchwork: https://patchwork.freedesktop.org/patch/633318/ Link: https://lore.kernel.org/r/20250122-dpu-111-topology-v2-1-505e95964af9@somainline.org Signed-off-by: Dmitry Baryshkov Stable-dep-of: d245ce568929 ("drm/msm/dpu: Remove arbitrary limit of 1 interface in DSC topology") Signed-off-by: Sasha Levin commit 18e470662387668e7572e0d3c058d3aaee034a46 Author: Marijn Suijten Date: Mon Feb 17 12:17:42 2025 +0100 drm/msm/dsi: Set PHY usescase (and mode) before registering DSI host [ Upstream commit 660c396c98c061f9696bebacc178b74072e80054 ] Ordering issues here cause an uninitialized (default STANDALONE) usecase to be programmed (which appears to be a MUX) in some cases when msm_dsi_host_register() is called, leading to the slave PLL in bonded-DSI mode to source from a clock parent (dsi1vco) that is off. This should seemingly not be a problem as the actual dispcc clocks from DSI1 that are muxed in the clock tree of DSI0 are way further down, this bit still seems to have an effect on them somehow and causes the right side of the panel controlled by DSI1 to not function. In an ideal world this code is refactored to no longer have such error-prone calls "across subsystems", and instead model the "PLL src" register field as a regular mux so that changing the clock parents programmatically or in DTS via `assigned-clock-parents` has the desired effect. But for the avid reader, the clocks that we *are* muxing into DSI0's tree are way further down, so if this bit turns out to be a simple mux between dsiXvco and out_div, that shouldn't have any effect as this whole tree is off anyway. Fixes: 57bf43389337 ("drm/msm/dsi: Pass down use case to PHY") Reviewed-by: Abhinav Kumar Reviewed-by: Dmitry Baryshkov Signed-off-by: Marijn Suijten Patchwork: https://patchwork.freedesktop.org/patch/637650/ Link: https://lore.kernel.org/r/20250217-drm-msm-initial-dualpipe-dsc-fixes-v3-2-913100d6103f@somainline.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 75b440bf3baf0aee8183735ab5d914c624b1e6da Author: Marijn Suijten Date: Mon Feb 17 12:17:41 2025 +0100 drm/msm/dsi: Use existing per-interface slice count in DSC timing [ Upstream commit 14ad809ceb66d0874cbe4bd5ca9edf0de8d9ad96 ] When configuring the timing of DSI hosts (interfaces) in dsi_timing_setup() all values written to registers are taking bonded-mode into account by dividing the original mode width by 2 (half the data is sent over each of the two DSI hosts), but the full width instead of the interface width is passed as hdisplay parameter to dsi_update_dsc_timing(). Currently only msm_dsc_get_slices_per_intf() is called within dsi_update_dsc_timing() with the `hdisplay` argument which clearly documents that it wants the width of a single interface (which, again, in bonded DSI mode is half the total width of the mode) resulting in all subsequent values to be completely off. However, as soon as we start to pass the halved hdisplay into dsi_update_dsc_timing() we might as well discard msm_dsc_get_slices_per_intf() since the value it calculates is already available in dsc->slice_count which is per-interface by the current design of MSM DPU/DSI implementations and their use of the DRM DSC helpers. Fixes: 08802f515c3c ("drm/msm/dsi: Add support for DSC configuration") Reviewed-by: Dmitry Baryshkov Reviewed-by: Jessica Zhang Signed-off-by: Marijn Suijten Patchwork: https://patchwork.freedesktop.org/patch/637648/ Link: https://lore.kernel.org/r/20250217-drm-msm-initial-dualpipe-dsc-fixes-v3-1-913100d6103f@somainline.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 0a729dbbdceee2ea48cb9dca358ee3f0c72ae159 Author: Krzysztof Kozlowski Date: Wed Jan 29 12:55:04 2025 +0100 drm/msm/dsi/phy: Program clock inverters in correct register [ Upstream commit baf49072877726616c7f5943a6b45eb86bfeca0a ] Since SM8250 all downstream sources program clock inverters in PLL_CLOCK_INVERTERS_1 register and leave the PLL_CLOCK_INVERTERS as reset value (0x0). The most recent Hardware Programming Guide for 3 nm, 4 nm, 5 nm and 7 nm PHYs also mention PLL_CLOCK_INVERTERS_1. Signed-off-by: Krzysztof Kozlowski Fixes: 1ef7c99d145c ("drm/msm/dsi: add support for 7nm DSI PHY/PLL") Reviewed-by: Dmitry Baryshkov Reported-by: Abhinav Kumar Patchwork: https://patchwork.freedesktop.org/patch/634489/ Link: https://lore.kernel.org/r/20250129115504.40080-1-krzysztof.kozlowski@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit eaf8913e338d9a792c3c37bbb1173152b60d1242 Author: Dmitry Baryshkov Date: Thu Jan 23 14:43:33 2025 +0200 drm/msm/dpu: don't use active in atomic_check() [ Upstream commit 25b4614843bcc56ba150f7c99905125a019e656c ] The driver isn't supposed to consult crtc_state->active/active_check for resource allocation. Instead all resources should be allocated if crtc_state->enabled is set. Stop consulting active / active_changed in order to determine whether the hardware resources should be (re)allocated. Fixes: ccc862b957c6 ("drm/msm/dpu: Fix reservation failures in modeset") Reported-by: Simona Vetter Closes: https://lore.kernel.org/dri-devel/ZtW_S0j5AEr4g0QW@phenom.ffwll.local/ Reviewed-by: Simona Vetter Reviewed-by: Abhinav Kumar Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/633393/ Link: https://lore.kernel.org/r/20250123-drm-dirty-modeset-v2-1-bbfd3a6cd1a4@linaro.org Signed-off-by: Sasha Levin commit 93d48e6543ab771532167444963214dbee60576a Author: Aurabindo Pillai Date: Fri Feb 21 09:45:12 2025 -0500 drm/amd/display: fix an indent issue in DML21 [ Upstream commit a1addcf8499a566496847f1e36e1cf0b4ad72a26 ] Remove extraneous tab and newline in dml2_core_dcn4.c that was reported by the bot Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202502211920.txUfwtSj-lkp@intel.com/ Fixes: 70839da6360 ("drm/amd/display: Add new DCN401 sources") Signed-off-by: Aurabindo Pillai Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2091794cdb4460fd7d7eb1101098bf1e40db5ce7 Author: Tushar Dave Date: Thu Feb 6 19:03:38 2025 -0800 PCI/ACS: Fix 'pci=config_acs=' parameter [ Upstream commit 9cf8a952d57b422d3ff8a9a0163f8adf694f4b2b ] Commit 47c8846a49ba ("PCI: Extend ACS configurability") introduced bugs that fail to configure ACS ctrl to the value specified by the kernel parameter. Essentially there are two bugs: 1) When ACS is configured for multiple PCI devices using 'config_acs' kernel parameter, it results into error "PCI: Can't parse ACS command line parameter". This is due to a bug that doesn't preserve the ACS mask, but instead overwrites the mask with value 0. For example, using 'config_acs' to configure ACS ctrl for multiple BDFs fails: Kernel command line: pci=config_acs=1111011@0020:02:00.0;101xxxx@0039:00:00.0 "dyndbg=file drivers/pci/pci.c +p" PCI: Can't parse ACS command line parameter pci 0020:02:00.0: ACS mask = 0x007f pci 0020:02:00.0: ACS flags = 0x007b pci 0020:02:00.0: Configured ACS to 0x007b After this fix: Kernel command line: pci=config_acs=1111011@0020:02:00.0;101xxxx@0039:00:00.0 "dyndbg=file drivers/pci/pci.c +p" pci 0020:02:00.0: ACS mask = 0x007f pci 0020:02:00.0: ACS flags = 0x007b pci 0020:02:00.0: ACS control = 0x005f pci 0020:02:00.0: ACS fw_ctrl = 0x0053 pci 0020:02:00.0: Configured ACS to 0x007b pci 0039:00:00.0: ACS mask = 0x0070 pci 0039:00:00.0: ACS flags = 0x0050 pci 0039:00:00.0: ACS control = 0x001d pci 0039:00:00.0: ACS fw_ctrl = 0x0000 pci 0039:00:00.0: Configured ACS to 0x0050 2) In the bit manipulation logic, we copy the bit from the firmware settings when mask bit 0. For example, 'disable_acs_redir' fails to clear all three ACS P2P redir bits due to the wrong bit fiddling: Kernel command line: pci=disable_acs_redir=0020:02:00.0;0030:02:00.0;0039:00:00.0 "dyndbg=file drivers/pci/pci.c +p" pci 0020:02:00.0: ACS mask = 0x002c pci 0020:02:00.0: ACS flags = 0xffd3 pci 0020:02:00.0: Configured ACS to 0xfffb pci 0030:02:00.0: ACS mask = 0x002c pci 0030:02:00.0: ACS flags = 0xffd3 pci 0030:02:00.0: Configured ACS to 0xffdf pci 0039:00:00.0: ACS mask = 0x002c pci 0039:00:00.0: ACS flags = 0xffd3 pci 0039:00:00.0: Configured ACS to 0xffd3 After this fix: Kernel command line: pci=disable_acs_redir=0020:02:00.0;0030:02:00.0;0039:00:00.0 "dyndbg=file drivers/pci/pci.c +p" pci 0020:02:00.0: ACS mask = 0x002c pci 0020:02:00.0: ACS flags = 0xffd3 pci 0020:02:00.0: ACS control = 0x007f pci 0020:02:00.0: ACS fw_ctrl = 0x007b pci 0020:02:00.0: Configured ACS to 0x0053 pci 0030:02:00.0: ACS mask = 0x002c pci 0030:02:00.0: ACS flags = 0xffd3 pci 0030:02:00.0: ACS control = 0x005f pci 0030:02:00.0: ACS fw_ctrl = 0x005f pci 0030:02:00.0: Configured ACS to 0x0053 pci 0039:00:00.0: ACS mask = 0x002c pci 0039:00:00.0: ACS flags = 0xffd3 pci 0039:00:00.0: ACS control = 0x001d pci 0039:00:00.0: ACS fw_ctrl = 0x0000 pci 0039:00:00.0: Configured ACS to 0x0000 Link: https://lore.kernel.org/r/20250207030338.456887-1-tdave@nvidia.com Fixes: 47c8846a49ba ("PCI: Extend ACS configurability") Signed-off-by: Tushar Dave Signed-off-by: Bjorn Helgaas Reviewed-by: Jason Gunthorpe Reviewed-by: Kuppuswamy Sathyanarayanan Signed-off-by: Sasha Levin commit ab882ad4c9ab390a152cb221ae2240aa54d6a195 Author: John Keeping Date: Mon Feb 17 12:04:28 2025 +0000 drm/panel: ilitek-ili9882t: fix GPIO name in error message [ Upstream commit 4ce2c7e201c265df1c62a9190a98a98803208b8f ] This driver uses the enable-gpios property and it is confusing that the error message refers to reset-gpios. Use the correct name when the enable GPIO is not found. Fixes: e2450d32e5fb5 ("drm/panel: ili9882t: Break out as separate driver") Signed-off-by: John Keeping Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20250217120428.3779197-1-jkeeping@inmusicbrands.com Signed-off-by: Sasha Levin commit 4d96930239981f312821a4065db8cc0f8240a173 Author: Daniel Stodden Date: Sun Dec 22 19:39:08 2024 -0800 PCI/ASPM: Fix link state exit during switch upstream function removal [ Upstream commit cbf937dcadfd571a434f8074d057b32cd14fbea5 ] Before 456d8aa37d0f ("PCI/ASPM: Disable ASPM on MFD function removal to avoid use-after-free"), we would free the ASPM link only after the last function on the bus pertaining to the given link was removed. That was too late. If function 0 is removed before sibling function, link->downstream would point to free'd memory after. After above change, we freed the ASPM parent link state upon any function removal on the bus pertaining to a given link. That is too early. If the link is to a PCIe switch with MFD on the upstream port, then removing functions other than 0 first would free a link which still remains parent_link to the remaining downstream ports. The resulting GPFs are especially frequent during hot-unplug, because pciehp removes devices on the link bus in reverse order. On that switch, function 0 is the virtual P2P bridge to the internal bus. Free exactly when function 0 is removed -- before the parent link is obsolete, but after all subordinate links are gone. Link: https://lore.kernel.org/r/e12898835f25234561c9d7de4435590d957b85d9.1734924854.git.dns@arista.com Fixes: 456d8aa37d0f ("PCI/ASPM: Disable ASPM on MFD function removal to avoid use-after-free") Signed-off-by: Daniel Stodden Signed-off-by: Bjorn Helgaas [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński Signed-off-by: Sasha Levin commit 5c1741a0c176ae11675a64cb7f2dd21d72db6b91 Author: Srinivasan Shanmugam Date: Fri Feb 14 14:22:17 2025 +0530 drm/amdgpu: Replace Mutex with Spinlock for RLCG register access to avoid Priority Inversion in SRIOV [ Upstream commit dc0297f3198bd60108ccbd167ee5d9fa4af31ed0 ] RLCG Register Access is a way for virtual functions to safely access GPU registers in a virtualized environment., including TLB flushes and register reads. When multiple threads or VFs try to access the same registers simultaneously, it can lead to race conditions. By using the RLCG interface, the driver can serialize access to the registers. This means that only one thread can access the registers at a time, preventing conflicts and ensuring that operations are performed correctly. Additionally, when a low-priority task holds a mutex that a high-priority task needs, ie., If a thread holding a spinlock tries to acquire a mutex, it can lead to priority inversion. register access in amdgpu_virt_rlcg_reg_rw especially in a fast code path is critical. The call stack shows that the function amdgpu_virt_rlcg_reg_rw is being called, which attempts to acquire the mutex. This function is invoked from amdgpu_sriov_wreg, which in turn is called from gmc_v11_0_flush_gpu_tlb. The [ BUG: Invalid wait context ] indicates that a thread is trying to acquire a mutex while it is in a context that does not allow it to sleep (like holding a spinlock). Fixes the below: [ 253.013423] ============================= [ 253.013434] [ BUG: Invalid wait context ] [ 253.013446] 6.12.0-amdstaging-drm-next-lol-050225 #14 Tainted: G U OE [ 253.013464] ----------------------------- [ 253.013475] kworker/0:1/10 is trying to lock: [ 253.013487] ffff9f30542e3cf8 (&adev->virt.rlcg_reg_lock){+.+.}-{3:3}, at: amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.013815] other info that might help us debug this: [ 253.013827] context-{4:4} [ 253.013835] 3 locks held by kworker/0:1/10: [ 253.013847] #0: ffff9f3040050f58 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x3f5/0x680 [ 253.013877] #1: ffffb789c008be40 ((work_completion)(&wfc.work)){+.+.}-{0:0}, at: process_one_work+0x1d6/0x680 [ 253.013905] #2: ffff9f3054281838 (&adev->gmc.invalidate_lock){+.+.}-{2:2}, at: gmc_v11_0_flush_gpu_tlb+0x198/0x4f0 [amdgpu] [ 253.014154] stack backtrace: [ 253.014164] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Tainted: G U OE 6.12.0-amdstaging-drm-next-lol-050225 #14 [ 253.014189] Tainted: [U]=USER, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE [ 253.014203] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/18/2024 [ 253.014224] Workqueue: events work_for_cpu_fn [ 253.014241] Call Trace: [ 253.014250] [ 253.014260] dump_stack_lvl+0x9b/0xf0 [ 253.014275] dump_stack+0x10/0x20 [ 253.014287] __lock_acquire+0xa47/0x2810 [ 253.014303] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.014321] lock_acquire+0xd1/0x300 [ 253.014333] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.014562] ? __lock_acquire+0xa6b/0x2810 [ 253.014578] __mutex_lock+0x85/0xe20 [ 253.014591] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.014782] ? sched_clock_noinstr+0x9/0x10 [ 253.014795] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.014808] ? local_clock_noinstr+0xe/0xc0 [ 253.014822] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.015012] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.015029] mutex_lock_nested+0x1b/0x30 [ 253.015044] ? mutex_lock_nested+0x1b/0x30 [ 253.015057] amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.015249] amdgpu_sriov_wreg+0xc5/0xd0 [amdgpu] [ 253.015435] gmc_v11_0_flush_gpu_tlb+0x44b/0x4f0 [amdgpu] [ 253.015667] gfx_v11_0_hw_init+0x499/0x29c0 [amdgpu] [ 253.015901] ? __pfx_smu_v13_0_update_pcie_parameters+0x10/0x10 [amdgpu] [ 253.016159] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.016173] ? smu_hw_init+0x18d/0x300 [amdgpu] [ 253.016403] amdgpu_device_init+0x29ad/0x36a0 [amdgpu] [ 253.016614] amdgpu_driver_load_kms+0x1a/0xc0 [amdgpu] [ 253.017057] amdgpu_pci_probe+0x1c2/0x660 [amdgpu] [ 253.017493] local_pci_probe+0x4b/0xb0 [ 253.017746] work_for_cpu_fn+0x1a/0x30 [ 253.017995] process_one_work+0x21e/0x680 [ 253.018248] worker_thread+0x190/0x330 [ 253.018500] ? __pfx_worker_thread+0x10/0x10 [ 253.018746] kthread+0xe7/0x120 [ 253.018988] ? __pfx_kthread+0x10/0x10 [ 253.019231] ret_from_fork+0x3c/0x60 [ 253.019468] ? __pfx_kthread+0x10/0x10 [ 253.019701] ret_from_fork_asm+0x1a/0x30 [ 253.019939] v2: s/spin_trylock/spin_lock_irqsave to be safe (Christian). Fixes: e864180ee49b ("drm/amdgpu: Add lock around VF RLCG interface") Cc: lin cao Cc: Jingwen Chen Cc: Victor Skvortsov Cc: Zhigang Luo Cc: Christian König Cc: Alex Deucher Signed-off-by: Srinivasan Shanmugam Suggested-by: Alex Deucher Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ea350e107e82630251a7ad160f94c53b469b5e19 Author: AngeloGioacchino Del Regno Date: Mon Feb 17 16:48:12 2025 +0100 drm/mediatek: mtk_hdmi: Fix typo for aud_sampe_size member [ Upstream commit 72fcb88e7bbc053ed4fc74cebb0315b98a0f20c3 ] Rename member aud_sampe_size of struct hdmi_audio_param to aud_sample_size to fix a typo and enhance readability. This commit brings no functional changes. Fixes: 8f83f26891e1 ("drm/mediatek: Add HDMI support") Reviewed-by: CK Hu Signed-off-by: AngeloGioacchino Del Regno Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20250217154836.108895-20-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit a7ab72b5eec9eb5381b431e3959e89aec39fe61e Author: AngeloGioacchino Del Regno Date: Mon Feb 17 16:48:10 2025 +0100 drm/mediatek: mtk_hdmi: Unregister audio platform device on failure [ Upstream commit 0be123cafc06eed0fd1227166a66e786434b0c50 ] The probe function of this driver may fail after registering the audio platform device: in that case, the state is not getting cleaned up, leaving this device registered. Adding up to the mix, should the probe function of this driver return a probe deferral for N times, we're registering up to N audio platform devices and, again, never freeing them up. To fix this, add a pointer to the audio platform device in the mtk_hdmi structure, and add a devm action to unregister it upon driver removal or probe failure. Fixes: 8f83f26891e1 ("drm/mediatek: Add HDMI support") Reviewed-by: CK Hu Signed-off-by: AngeloGioacchino Del Regno Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20250217154836.108895-18-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 22df32c984be9e9145978acf011642da042a2af3 Author: Ilpo Järvinen Date: Mon Dec 16 19:56:11 2024 +0200 PCI: Allow relaxed bridge window tail sizing for optional resources [ Upstream commit 67f9085596ee55dd27b540ca6088ba0717ee511c ] Commit 566f1dd52816 ("PCI: Relax bridge window tail sizing rules") relaxed the bridge window requirements for non-optional size (size0) but pbus_size_mem() also handles optional sizes (IOV resources) using size1. This can manifest, e.g., as a failure to resize a BAR back to its original size after it was first shrunk when device has a VF BAR resource because the bridge window (size1) is enlarged beyond what is strictly required to fit the downstream resources. Allow using relaxed bridge window tail sizing rules also with the optional resources (size1) so that the remove/realloc cycle during BAR resize (smaller and back to the original size) does not fail unexpectedly due to increase in bridge window size demand. Also move add_align calculation to more logical place next to size1 assignment as they are strongly related to each other. Link: https://lore.kernel.org/r/20241216175632.4175-5-ilpo.jarvinen@linux.intel.com Fixes: 566f1dd52816 ("PCI: Relax bridge window tail sizing rules") Reported-by: Michał Winiarski Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Tested-by: Xiaochun Lee Signed-off-by: Sasha Levin commit c00f6328c92eba812a456eb5fea0e84213ffa2b7 Author: Ilpo Järvinen Date: Mon Dec 16 19:56:10 2024 +0200 PCI: Simplify size1 assignment logic [ Upstream commit a55bf64b30e4ee04c8f690e2c3d0924beb7fbd62 ] In pbus_size_io() and pbus_size_mem(), a complex ?: operation is performed to set size1. Decompose this so it's easier to read. In the case of pbus_size_mem(), simply initializing size1 to zero ensures the size1 checks work as expected. Link: https://lore.kernel.org/r/20241216175632.4175-4-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Tested-by: Xiaochun Lee Stable-dep-of: 67f9085596ee ("PCI: Allow relaxed bridge window tail sizing for optional resources") Signed-off-by: Sasha Levin commit 6a9bed7d0ac464f3add13324d3105b9bca080871 Author: Ilpo Järvinen Date: Mon Dec 16 19:56:08 2024 +0200 PCI: Remove add_align overwrite unrelated to size0 [ Upstream commit d06cc1e3809040e8250f69a4c656e3717e6b963c ] Commit 566f1dd52816 ("PCI: Relax bridge window tail sizing rules") relaxed bridge window tail alignment rule for the non-optional part (size0, no add_size/add_align). The change, however, also overwrote add_align, which is only related to case where optional size1 related entry is added into realloc head. Correct this by removing the add_align overwrite. Link: https://lore.kernel.org/r/20241216175632.4175-2-ilpo.jarvinen@linux.intel.com Fixes: 566f1dd52816 ("PCI: Relax bridge window tail sizing rules") Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Tested-by: Xiaochun Lee Signed-off-by: Sasha Levin commit c798a1343428ee0cbdc02ef280ecab85065cb7f8 Author: Kai-Heng Feng Date: Wed Dec 4 10:24:57 2024 +0800 PCI: Use downstream bridges for distributing resources [ Upstream commit 1a596ad00ffe9b37fc60a93cbdd4daead3bf95f3 ] 7180c1d08639 ("PCI: Distribute available resources for root buses, too") breaks BAR assignment on some devices: pci 0006:03:00.0: BAR 0 [mem 0x6300c0000000-0x6300c1ffffff 64bit pref]: assigned pci 0006:03:00.1: BAR 0 [mem 0x6300c2000000-0x6300c3ffffff 64bit pref]: assigned pci 0006:03:00.2: BAR 0 [mem size 0x00800000 64bit pref]: can't assign; no space pci 0006:03:00.0: VF BAR 0 [mem size 0x02000000 64bit pref]: can't assign; no space pci 0006:03:00.1: VF BAR 0 [mem size 0x02000000 64bit pref]: can't assign; no space The apertures of domain 0006 before 7180c1d08639: 6300c0000000-63ffffffffff : PCI Bus 0006:00 6300c0000000-6300c9ffffff : PCI Bus 0006:01 6300c0000000-6300c9ffffff : PCI Bus 0006:02 # 160MB 6300c0000000-6300c8ffffff : PCI Bus 0006:03 # 144MB 6300c0000000-6300c1ffffff : 0006:03:00.0 # 32MB 6300c2000000-6300c3ffffff : 0006:03:00.1 # 32MB 6300c4000000-6300c47fffff : 0006:03:00.2 # 8MB 6300c4800000-6300c67fffff : 0006:03:00.0 # 32MB 6300c6800000-6300c87fffff : 0006:03:00.1 # 32MB 6300c9000000-6300c9bfffff : PCI Bus 0006:04 # 12MB 6300c9000000-6300c9bfffff : PCI Bus 0006:05 # 12MB 6300c9000000-6300c91fffff : PCI Bus 0006:06 # 2MB 6300c9200000-6300c93fffff : PCI Bus 0006:07 # 2MB 6300c9400000-6300c95fffff : PCI Bus 0006:08 # 2MB 6300c9600000-6300c97fffff : PCI Bus 0006:09 # 2MB After 7180c1d08639: 6300c0000000-63ffffffffff : PCI Bus 0006:00 6300c0000000-6300c9ffffff : PCI Bus 0006:01 6300c0000000-6300c9ffffff : PCI Bus 0006:02 # 160MB 6300c0000000-6300c43fffff : PCI Bus 0006:03 # 68MB 6300c0000000-6300c1ffffff : 0006:03:00.0 # 32MB 6300c2000000-6300c3ffffff : 0006:03:00.1 # 32MB --- no space --- : 0006:03:00.2 # 8MB --- no space --- : 0006:03:00.0 # 32MB --- no space --- : 0006:03:00.1 # 32MB 6300c4400000-6300c4dfffff : PCI Bus 0006:04 # 10MB 6300c4400000-6300c4dfffff : PCI Bus 0006:05 # 10MB 6300c4400000-6300c45fffff : PCI Bus 0006:06 # 2MB 6300c4600000-6300c47fffff : PCI Bus 0006:07 # 2MB 6300c4800000-6300c49fffff : PCI Bus 0006:08 # 2MB 6300c4a00000-6300c4bfffff : PCI Bus 0006:09 # 2MB We can see that the window to 0006:03 gets shrunken too much and 0006:04 eats away the window for 0006:03:00.2. The offending commit distributes the upstream bridge's resources multiple times to every downstream bridge, hence makes the aperture smaller than desired because calculation of io_per_b, mmio_per_b and mmio_pref_per_b becomes incorrect. Instead, distribute downstream bridges' own resources to resolve the issue. Link: https://lore.kernel.org/r/20241204022457.51322-1-kaihengf@nvidia.com Fixes: 7180c1d08639 ("PCI: Distribute available resources for root buses, too") Link: https://bugzilla.kernel.org/show_bug.cgi?id=219540 Signed-off-by: Kai-Heng Feng Signed-off-by: Bjorn Helgaas Tested-by: Chia-Lin Kao (AceLan) Reviewed-by: Mika Westerberg Cc: Carol Soto Cc: Jonathan Cameron Cc: Chris Chiu Signed-off-by: Sasha Levin commit e31f4b4501fe6124127296961e4ea81bbb45f401 Author: Alex Deucher Date: Mon Feb 10 17:45:14 2025 -0500 drm/amdgpu/vcn5.0.1: use correct dpm helper [ Upstream commit 0487f50310cfeec1bb4480a67294fc7081c5ed22 ] The VCN and UVD helpers were split in commit ff69bba05f08 ("drm/amd/pm: add inst to dpm_set_powergating_by_smu") However, this happened in parallel to the vcn 5.0.1 development so it was missed there. Fixes: 346492f30ce3 ("drm/amdgpu: Add VCN_5_0_1 support") Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Cc: Sonny Jiang Cc: Boyuan Zhang Signed-off-by: Sasha Levin commit 5f7d1675105c1cbc526069c1a1b6aaef3013c71a Author: Alex Deucher Date: Wed Feb 12 16:31:43 2025 -0500 drm/amdgpu/umsch: fix ucode check [ Upstream commit c917e39cbdcd9fff421184db6cc461cc58d52c17 ] Return an error if the IP version doesn't match otherwise we end up passing a NULL string to amdgpu_ucode_request. We should never hit this in practice today since we only enable the umsch code on the supported IP versions, but add a check to be safe. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202502130406.iWQ0eBug-lkp@intel.com/ Fixes: 020620424b27 ("drm/amd: Use a constant format string for amdgpu_ucode_request") Reviewed-by: Saleemkhan Jamadar Signed-off-by: Alex Deucher Cc: Arnd Bergmann Cc: Lang Yu Signed-off-by: Sasha Levin commit 24aa94c88063f7b18746468e5508b3d14ddd750a Author: Alex Deucher Date: Wed Feb 12 16:20:15 2025 -0500 drm/amdgpu/umsch: declare umsch firmware [ Upstream commit fe652becdbfccf265f4cea0eb379418d08c6596a ] Needed to be properly picked up for the initrd, etc. Fixes: 3488c79beafa ("drm/amdgpu: add initial support for UMSCH") Reviewed-by: Saleemkhan Jamadar Signed-off-by: Alex Deucher Cc: Lang Yu Signed-off-by: Sasha Levin commit e023e3328cc7033b366c294b3305529d9c92a47d Author: Saleemkhan Jamadar Date: Tue Dec 3 17:27:44 2024 +0530 drm/amdgpu/umsch: remove vpe test from umsch [ Upstream commit b0bebbe4ea2a25937d341fa1f2ab2cd8ce339cad ] current test is more intrusive for user queue test Signed-off-by: Saleemkhan Jamadar Suggested-by: Christian Koenig Reviewed-by: Christian König Signed-off-by: Alex Deucher Stable-dep-of: fe652becdbfc ("drm/amdgpu/umsch: declare umsch firmware") Signed-off-by: Sasha Levin commit e8f8fb36c03b97c97c5891801e59afaec0129c1d Author: Yang Wang Date: Wed Feb 5 15:46:42 2025 +0800 drm/amdgpu: refine smu send msg debug log format [ Upstream commit 8c6631234557515a7567c6251505a98e9793c8a6 ] remove unnecessary line breaks. [ 51.280860] amdgpu 0000:24:00.0: amdgpu: smu send message: GetEnabledSmuFeaturesHigh(13) param: 0x00000000, resp: 0x00000001, readval: 0x00003763 Fixes: 0cd2bc06de72 ("drm/amd/pm: enable amdgpu smu send message log") Signed-off-by: Yang Wang Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 37da1ec9047661dd17ecfa04a0336ebfed25a0c6 Author: Vitalii Mordan Date: Fri Feb 14 18:46:32 2025 +0300 gpu: cdns-mhdp8546: fix call balance of mhdp->clk handling routines [ Upstream commit f65727be3fa5f252c8d982d15023aab8255ded19 ] If the clock mhdp->clk was not enabled in cdns_mhdp_probe(), it should not be disabled in any path. The return value of clk_prepare_enable() is not checked. If mhdp->clk was not enabled, it may be disabled in the error path of cdns_mhdp_probe() (e.g., if cdns_mhdp_load_firmware() fails) or in cdns_mhdp_remove() after a successful cdns_mhdp_probe() call. Use the devm_clk_get_enabled() helper function to ensure proper call balance for mhdp->clk. Found by Linux Verification Center (linuxtesting.org) with Klever. Fixes: fb43aa0acdfd ("drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge") Signed-off-by: Vitalii Mordan Reviewed-by: Dmitry Baryshkov Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20250214154632.1907425-1-mordan@ispras.ru Signed-off-by: Sasha Levin commit 1f68f1cf09d06061eb549726ff8339e064eddebd Author: José Expósito Date: Wed Feb 12 09:49:12 2025 +0100 drm/vkms: Fix use after free and double free on init error [ Upstream commit ed15511a773df86205bda66c37193569575ae828 ] If the driver initialization fails, the vkms_exit() function might access an uninitialized or freed default_config pointer and it might double free it. Fix both possible errors by initializing default_config only when the driver initialization succeeded. Reported-by: Louis Chauvet Closes: https://lore.kernel.org/all/Z5uDHcCmAwiTsGte@louis-chauvet-laptop/ Fixes: 2df7af93fdad ("drm/vkms: Add vkms_config type") Signed-off-by: José Expósito Reviewed-by: Thomas Zimmermann Reviewed-by: Louis Chauvet Link: https://patchwork.freedesktop.org/patch/msgid/20250212084912.3196-1-jose.exposito89@gmail.com Signed-off-by: Louis Chauvet Signed-off-by: Sasha Levin commit 7a8d53aa5b7d2a89cda598239d08423bd66920f1 Author: Bart Van Assche Date: Fri Feb 7 11:25:27 2025 -0500 drm: zynqmp_dp: Fix a deadlock in zynqmp_dp_ignore_hpd_set() [ Upstream commit f887685ee0eb4ef716391355568181230338f6eb ] Instead of attempting the same mutex twice, lock and unlock it. This bug has been detected by the Clang thread-safety analyzer. Cc: Sean Anderson Cc: Tomi Valkeinen Fixes: 28edaacb821c ("drm: zynqmp_dp: Add debugfs interface for compliance testing") Signed-off-by: Bart Van Assche Reviewed-by: Sean Anderson Signed-off-by: Sean Anderson Reviewed-by: Laurent Pinchart Reviewed-by: Sean Anderson Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20250207162528.1651426-2-sean.anderson@linux.dev Signed-off-by: Sasha Levin commit 066d6f22e7d84953db6bbf2dae507401157660c6 Author: Charles Han Date: Tue Feb 11 18:20:49 2025 +0800 drm: xlnx: zynqmp_dpsub: Add NULL check in zynqmp_audio_init [ Upstream commit d0660f9c588a1246a1a543c91a1e3cad910237da ] devm_kasprintf() calls can return null pointers on failure. But some return values were not checked in zynqmp_audio_init(). Add NULL check in zynqmp_audio_init(), avoid referencing null pointers in the subsequent code. Fixes: 3ec5c1579305 ("drm: xlnx: zynqmp_dpsub: Add DP audio support") Reviewed-by: Laurent Pinchart Signed-off-by: Charles Han Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20250211102049.6468-1-hanchunchao@inspur.com Signed-off-by: Sasha Levin commit 4631b91c684ecd34bbef706919d7d3ce650321a2 Author: Tomi Valkeinen Date: Wed Jan 15 11:03:39 2025 +0200 drm: xlnx: zynqmp: Fix max dma segment size [ Upstream commit 28b529a98525123acd37372a04d21e87ec2edcf7 ] Fix "mapping sg segment longer than device claims to support" warning by setting the max segment size. Fixes: d76271d22694 ("drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort Subsystem") Reviewed-by: Sean Anderson Tested-by: Sean Anderson Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20250115-xilinx-formats-v2-10-160327ca652a@ideasonboard.com Signed-off-by: Sasha Levin commit e9d45f42a64a400adba59ee83d03e6db662530b4 Author: Adrián Larumbe Date: Thu Jan 30 17:28:13 2025 +0000 drm/panthor: Fix race condition when gathering fdinfo group samples [ Upstream commit 0590c94c3596d6c1a3d549ae611366f2ad4e1d8d ] Commit e16635d88fa0 ("drm/panthor: add DRM fdinfo support") failed to protect access to groups with an xarray lock, which could lead to use-after-free errors. Fixes: e16635d88fa0 ("drm/panthor: add DRM fdinfo support") Reviewed-by: Boris Brezillon Reviewed-by: Steven Price Signed-off-by: Adrián Larumbe Signed-off-by: Boris Brezillon Link: https://patchwork.freedesktop.org/patch/msgid/20250130172851.941597-6-adrian.larumbe@collabora.com Link: https://patchwork.freedesktop.org/patch/msgid/20250107173310.88329-1-florent.tomasin@arm.com Signed-off-by: Sasha Levin commit 246959b597d10599947eff57b25672e4e2162f78 Author: Hermes Wu Date: Tue Jan 21 15:01:51 2025 +0800 drm/bridge: it6505: fix HDCP V match check is not performed correctly [ Upstream commit a5072fc77fb9e38fa9fd883642c83c3720049159 ] Fix a typo where V compare incorrectly compares av[] with av[] itself, which can result in HDCP failure. The loop of V compare is expected to iterate for 5 times which compare V array form av[0][] to av[4][]. It should check loop counter reach the last statement "i == 5" before return true Fixes: 0989c02c7a5c ("drm/bridge: it6505: fix HDCP CTS compare V matching") Signed-off-by: Hermes Wu Reviewed-by: Dmitry Baryshkov Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20250121-fix-hdcp-v-comp-v4-1-185f45c728dc@ite.com.tw Signed-off-by: Sasha Levin commit 75700533ada9b02e4b1a45937c9a8943e2e58928 Author: Wayne Lin Date: Mon Jan 13 17:10:59 2025 +0800 drm/dp_mst: Fix drm RAD print [ Upstream commit 6bbce873a9c97cb12f5455c497be279ac58e707f ] [Why] The RAD of sideband message printed today is incorrect. For RAD stored within MST branch - If MST branch LCT is 1, it's RAD array is untouched and remained as 0. - If MST branch LCT is larger than 1, use nibble to store the up facing port number in cascaded sequence as illustrated below: u8 RAD[0] = (LCT_2_UFP << 4) | LCT_3_UFP RAD[1] = (LCT_4_UFP << 4) | LCT_5_UFP ... In drm_dp_mst_rad_to_str(), it wrongly to use BIT_MASK(4) to fetch the port number of one nibble. [How] Adjust the code by: - RAD array items are valuable only for LCT >= 1. - Use 0xF as the mask to replace BIT_MASK(4) V2: - Document how RAD is constructed (Imre) V3: - Adjust the comment for rad[] so kdoc formats it properly (Lyude) Fixes: 2f015ec6eab6 ("drm/dp_mst: Add sideband down request tracing + selftests") Cc: Imre Deak Cc: Ville Syrjälä Cc: Harry Wentland Cc: Lyude Paul Reviewed-by: Lyude Paul Signed-off-by: Wayne Lin Signed-off-by: Lyude Paul Link: https://patchwork.freedesktop.org/patch/msgid/20250113091100.3314533-2-Wayne.Lin@amd.com Signed-off-by: Sasha Levin commit a7a48d392fb3be5364691f0e02b5c8e64c2efba9 Author: John Keeping Date: Wed Jan 15 11:01:38 2025 +0000 drm/ssd130x: ensure ssd132x pitch is correct [ Upstream commit 229adcffdb54b13332d2afd2dc5d203418d50908 ] The bounding rectangle is adjusted to ensure it aligns to SSD132X_SEGMENT_WIDTH, which may adjust the pitch. Calculate the pitch after aligning the left and right edge. Fixes: fdd591e00a9c ("drm/ssd130x: Add support for the SSD132x OLED controller family") Signed-off-by: John Keeping Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20250115110139.1672488-3-jkeeping@inmusicbrands.com Signed-off-by: Javier Martinez Canillas Signed-off-by: Sasha Levin commit ae74b6ae3634d8096314cad9d770b3b7d5e7f6db Author: John Keeping Date: Wed Jan 15 11:01:37 2025 +0000 drm/ssd130x: fix ssd132x encoding [ Upstream commit 1e14484677c8e87548f5f0d4eb8800e408004404 ] The ssd132x buffer is encoded one pixel per nibble, with two pixels in each byte. When encoding an 8-bit greyscale input, take the top 4-bits as the value and ensure the two pixels are distinct and do not overwrite each other. Fixes: fdd591e00a9c ("drm/ssd130x: Add support for the SSD132x OLED controller family") Signed-off-by: John Keeping Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20250115110139.1672488-2-jkeeping@inmusicbrands.com Signed-off-by: Javier Martinez Canillas Signed-off-by: Sasha Levin commit 8d70fa5d83c7aaa787edd8f3d23110dbed4f683c Author: Boris Brezillon Date: Tue Dec 17 10:24:57 2024 +0100 drm/panthor: Fix a race between the reset and suspend path [ Upstream commit 57e233c3bd63f32d2c7e937db2e16b98f723ce2f ] If a reset is scheduled when the suspend happens, we drop the reset-pending info on the floor assuming the resume will fix things, but the resume logic might try a fast reset. If we're lucky, the fast reset fails and we fallback to a slow reset, but if the FW was corrupted in a way that makes it partially functional (it boots but doesn't quite do what it's expected to do), we won't notice immediately that things are not working correctly, leading to a new reset further down the road. Fixes: 5fe909cae118 ("drm/panthor: Add the device logical block") Signed-off-by: Boris Brezillon Reviewed-by: Liviu Dudau Reviewed-by: Steven Price Signed-off-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20241217092457.1582053-1-boris.brezillon@collabora.com Signed-off-by: Sasha Levin commit ed1b59582a5949167d5606528511142e85b68c7d Author: Lizhi Hou Date: Thu Jan 9 11:48:11 2025 -0800 accel/amdxdna: Return error when setting clock failed for npu1 [ Upstream commit 0c2768bf818904db705ff18674f771c3c4d8bbca ] Due to miss returning error when setting clock, the smatch static checker reports warning: drivers/accel/amdxdna/aie2_smu.c:68 npu1_set_dpm() error: uninitialized symbol 'freq'. Fixes: f4d7b8a6bc8c ("accel/amdxdna: Enhance power management settings") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/dri-devel/202267d0-882e-4593-b58d-be9274592f9b@stanley.mountain/ Signed-off-by: Lizhi Hou Reviewed-by: Mario Limonciello Signed-off-by: Mario Limonciello Link: https://patchwork.freedesktop.org/patch/msgid/20250109194811.499505-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit 848666df4456557866e3e925ade58c8778fd1894 Author: Javier Martinez Canillas Date: Tue Dec 31 12:44:58 2024 +0100 drm/ssd130x: Set SPI .id_table to prevent an SPI core warning [ Upstream commit 5d40d4fae6f2fb789f48207a9d4772bbee970b5c ] The only reason for the ssd130x-spi driver to have an spi_device_id table is that the SPI core always reports an "spi:" MODALIAS, even when the SPI device has been registered via a Device Tree Blob. Without spi_device_id table information in the module's metadata, module autoloading would not work because there won't be an alias that matches the MODALIAS reported by the SPI core. This spi_device_id table is not needed for device matching though, since the of_device_id table is always used in this case. For this reason, the struct spi_driver .id_table member is currently not set in the SPI driver. Because the spi_device_id table is always required for module autoloading, the SPI core checks during driver registration that both an of_device_id table and a spi_device_id table are present and that they contain the same entries for all the SPI devices. Not setting the .id_table member in the driver then confuses the core and leads to the following warning when the ssd130x-spi driver is registered: [ 41.091198] SPI driver ssd130x-spi has no spi_device_id for sinowealth,sh1106 [ 41.098614] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1305 [ 41.105862] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1306 [ 41.113062] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1307 [ 41.120247] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1309 [ 41.127449] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1322 [ 41.134627] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1325 [ 41.141784] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1327 [ 41.149021] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1331 To prevent the warning, set the .id_table even though it's not necessary. Since the check is done even for built-in drivers, drop the condition to only define the ID table when the driver is built as a module. Finally, rename the variable to use the "_spi_id" convention used for ID tables. Fixes: 74373977d2ca ("drm/solomon: Add SSD130x OLED displays SPI support") Reviewed-by: Dmitry Baryshkov Link: https://patchwork.freedesktop.org/patch/msgid/20241231114516.2063201-1-javierm@redhat.com Signed-off-by: Javier Martinez Canillas Signed-off-by: Sasha Levin commit ecf953efd3b68a06103cddb85539c2bdd4d81c3e Author: Geert Uytterhoeven Date: Tue Dec 10 15:18:46 2024 +0100 drm/bridge: ti-sn65dsi86: Fix multiple instances [ Upstream commit 574f5ee2c85a00a579549d50e9fc9c6c072ee4c4 ] Each bridge instance creates up to four auxiliary devices with different names. However, their IDs are always zero, causing duplicate filename errors when a system has multiple bridges: sysfs: cannot create duplicate filename '/bus/auxiliary/devices/ti_sn65dsi86.gpio.0' Fix this by using a unique instance ID per bridge instance. The instance ID is derived from the I2C adapter number and the bridge's I2C address, to support multiple instances on the same bus. Fixes: bf73537f411b ("drm/bridge: ti-sn65dsi86: Break GPIO and MIPI-to-eDP bridge into sub-drivers") Signed-off-by: Geert Uytterhoeven Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patchwork.freedesktop.org/patch/msgid/7a68a0e3f927e26edca6040067fb653eb06efb79.1733840089.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit 638fe5cb6e1c5ade4855f8a4cda9b8334f5c056c Author: Jann Horn Date: Wed Mar 26 22:04:36 2025 +0100 rwonce: fix crash by removing READ_ONCE() for unaligned read [ Upstream commit 47a60391ae0ed04ffbb9bd8dcd94ad9d08b41288 ] When arm64 is built with LTO, it upgrades READ_ONCE() to ldar / ldapr (load-acquire) to avoid issues that can be caused by the compiler optimizing away implicit address dependencies. Unlike plain loads, these load-acquire instructions actually require an aligned address. For now, fix it by removing the READ_ONCE() that the buggy commit introduced. Fixes: ece69af2ede1 ("rwonce: handle KCSAN like KASAN in read_word_at_a_time()") Reported-by: Nathan Chancellor Closes: https://lore.kernel.org/r/20250326203926.GA10484@ax162 Signed-off-by: Jann Horn Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 5f583e059eced1857f41e221ef5951e029e632bd Author: Jiawen Wu Date: Mon Mar 24 18:32:35 2025 +0800 net: libwx: fix Tx L4 checksum [ Upstream commit c7d82913d5f9e97860772ee4051eaa66b56a6273 ] The hardware only supports L4 checksum offload for TCP/UDP/SCTP protocol. There was a bug to set Tx checksum flag for the other protocol that results in Tx ring hang. Fix to compute software checksum for these packets. Fixes: 3403960cdf86 ("net: wangxun: libwx add tx offload functions") Signed-off-by: Jiawen Wu Link: https://patch.msgid.link/20250324103235.823096-2-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6016a59d8baa0e36d54b21b83547f4d9b9d83322 Author: Jiawen Wu Date: Mon Mar 24 18:32:34 2025 +0800 net: libwx: fix Tx descriptor content for some tunnel packets [ Upstream commit a44940d094afa2e04b5b164b1e136fc18bcb4a2d ] The length of skb header was incorrectly calculated when transmit a tunnel packet with outer IPv6 extension header, or a IP over IP packet which has inner IPv6 header. Thus the correct Tx context descriptor cannot be composed, resulting in Tx ring hang. Fixes: 3403960cdf86 ("net: wangxun: libwx add tx offload functions") Signed-off-by: Jiawen Wu Link: https://patch.msgid.link/20250324103235.823096-1-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b8b0c9e9f2d27ff74e6e5c8b77560bd0d76a6ebd Author: Pranjal Shrivastava Date: Mon Mar 24 07:42:27 2025 +0000 net: Fix the devmem sock opts and msgs for parisc [ Upstream commit fd87b7783802b45cdd261b273e6b2b792823064d ] The devmem socket options and socket control message definitions introduced in the TCP devmem series[1] incorrectly continued the socket definitions for arch/parisc. The UAPI change seems safe as there are currently no drivers that declare support for devmem TCP RX via PP_FLAG_ALLOW_UNREADABLE_NETMEM. Hence, fixing this UAPI should be safe. Fix the devmem socket options and socket control message definitions to reflect the series followed by arch/parisc. [1] https://lore.kernel.org/lkml/20240910171458.219195-10-almasrymina@google.com/ Fixes: 8f0b3cc9a4c10 ("tcp: RX path for devmem TCP") Signed-off-by: Pranjal Shrivastava Reviewed-by: Willem de Bruijn Reviewed-by: Jason Xing Reviewed-by: Mina Almasry Link: https://patch.msgid.link/20250324074228.3139088-1-praan@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d6eb0a505e3bc12415e6e550656a0fcf16f7b7b2 Author: Luiz Augusto von Dentz Date: Thu Mar 20 11:22:23 2025 -0400 Bluetooth: hci_event: Fix handling of HCI_EV_LE_DIRECT_ADV_REPORT [ Upstream commit 3a7fdfb7d876910cfe734488f553dbbc938f8f16 ] Some controllers seems to generate HCI_EV_LE_DIRECT_ADV_REPORT even when scan_filter is not set to 0x02 or 0x03, which indicates that local privacy is enabled, causing them to be ignored thus breaking auto-connect logic: < HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7 Type: Passive (0x00) Interval: 60.000 msec (0x0060) Window: 30.000 msec (0x0030) Own address type: Public (0x00) Filter policy: Ignore not in accept list (0x01) ... > HCI Event: LE Meta Event (0x3e) plen 18 LE Direct Advertising Report (0x0b) Num reports: 1 Event type: Connectable directed - ADV_DIRECT_IND (0x01) Address type: Random (0x01) Address: XX:XX:XX:XX:XX:XX (Static) Direct address type: Random (0x01) Direct address: XX:XX:XX:XX:XX:XX (Non-Resolvable) RSSI: -54 dBm (0xca) So this attempts to mitigate the above problem by skipping checking of direct_addr if local privacy is not enabled. Link: https://github.com/bluez/bluez/issues/1138 Fixes: e209e5ccc5ac ("Bluetooth: MGMT: Mark LL Privacy as stable") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 6749cf49eff7ce6dadcb603c5c8db70b28079a5d Author: Neeraj Sanjay Kale Date: Mon Mar 10 17:32:31 2025 +0530 Bluetooth: btnxpuart: Fix kernel panic during FW release [ Upstream commit 1f77c05408c96bc0b58ae476a9cadc9e5b9cfd0f ] This fixes a kernel panic seen during release FW in a stress test scenario where WLAN and BT FW download occurs simultaneously, and due to a HW bug, chip sends out only 1 bootloader signatures. When driver receives the bootloader signature, it enters FW download mode, but since no consequtive bootloader signatures seen, FW file is not requested. After 60 seconds, when FW download times out, release_firmware causes a kernel panic. [ 2601.949184] Unable to handle kernel paging request at virtual address 0000312e6f006573 [ 2601.992076] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000111802000 [ 2601.992080] [0000312e6f006573] pgd=0000000000000000, p4d=0000000000000000 [ 2601.992087] Internal error: Oops: 0000000096000021 [#1] PREEMPT SMP [ 2601.992091] Modules linked in: algif_hash algif_skcipher af_alg btnxpuart(O) pciexxx(O) mlan(O) overlay fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine authenc libdes crct10dif_ce polyval_ce snd_soc_fsl_easrc snd_soc_fsl_asoc_card imx8_media_dev(C) snd_soc_fsl_micfil polyval_generic snd_soc_fsl_xcvr snd_soc_fsl_sai snd_soc_imx_audmux snd_soc_fsl_asrc snd_soc_imx_card snd_soc_imx_hdmi snd_soc_fsl_aud2htx snd_soc_fsl_utils imx_pcm_dma dw_hdmi_cec flexcan can_dev [ 2602.001825] CPU: 2 PID: 20060 Comm: hciconfig Tainted: G C O 6.6.23-lts-next-06236-gb586a521770e #1 [ 2602.010182] Hardware name: NXP i.MX8MPlus EVK board (DT) [ 2602.010185] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2602.010191] pc : _raw_spin_lock+0x34/0x68 [ 2602.010201] lr : free_fw_priv+0x20/0xfc [ 2602.020561] sp : ffff800089363b30 [ 2602.020563] x29: ffff800089363b30 x28: ffff0000d0eb5880 x27: 0000000000000000 [ 2602.020570] x26: 0000000000000000 x25: ffff0000d728b330 x24: 0000000000000000 [ 2602.020577] x23: ffff0000dc856f38 [ 2602.033797] x22: ffff800089363b70 x21: ffff0000dc856000 [ 2602.033802] x20: ff00312e6f006573 x19: ffff0000d0d9ea80 x18: 0000000000000000 [ 2602.033809] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaad80dd480 [ 2602.083320] x14: 0000000000000000 x13: 00000000000001b9 x12: 0000000000000002 [ 2602.083326] x11: 0000000000000000 x10: 0000000000000a60 x9 : ffff800089363a30 [ 2602.083333] x8 : ffff0001793d75c0 x7 : ffff0000d6dbc400 x6 : 0000000000000000 [ 2602.083339] x5 : 00000000410fd030 x4 : 0000000000000000 x3 : 0000000000000001 [ 2602.083346] x2 : 0000000000000000 x1 : 0000000000000001 x0 : ff00312e6f006573 [ 2602.083354] Call trace: [ 2602.083356] _raw_spin_lock+0x34/0x68 [ 2602.083364] release_firmware+0x48/0x6c [ 2602.083370] nxp_setup+0x3c4/0x540 [btnxpuart] [ 2602.083383] hci_dev_open_sync+0xf0/0xa34 [ 2602.083391] hci_dev_open+0xd8/0x178 [ 2602.083399] hci_sock_ioctl+0x3b0/0x590 [ 2602.083405] sock_do_ioctl+0x60/0x118 [ 2602.083413] sock_ioctl+0x2f4/0x374 [ 2602.091430] __arm64_sys_ioctl+0xac/0xf0 [ 2602.091437] invoke_syscall+0x48/0x110 [ 2602.091445] el0_svc_common.constprop.0+0xc0/0xe0 [ 2602.091452] do_el0_svc+0x1c/0x28 [ 2602.091457] el0_svc+0x40/0xe4 [ 2602.091465] el0t_64_sync_handler+0x120/0x12c [ 2602.091470] el0t_64_sync+0x190/0x194 Fixes: e3c4891098c8 ("Bluetooth: btnxpuart: Handle FW Download Abort scenario") Fixes: 689ca16e5232 ("Bluetooth: NXP: Add protocol support for NXP Bluetooth chipsets") Signed-off-by: Neeraj Sanjay Kale Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 7cf34f5a0480e50566514bb24d0d7ae11b28e058 Author: Oleksij Rempel Date: Fri Mar 21 15:10:44 2025 +0100 net: dsa: microchip: fix DCB apptrust configuration on KSZ88x3 [ Upstream commit 1ae1d705a1120e8e0ca41698c5a0fff6f5290bc1 ] Remove KSZ88x3-specific priority and apptrust configuration logic that was based on incorrect register access assumptions. Also fix the register offset for KSZ8_REG_PORT_1_CTRL_0 to align with get_port_addr() logic. The KSZ88x3 switch family uses a different register layout compared to KSZ9477-compatible variants. Specifically, port control registers need offset adjustment through get_port_addr(), and do not match the datasheet values directly. Commit a1ea57710c9d ("net: dsa: microchip: dcb: add special handling for KSZ88X3 family") introduced quirks based on datasheet offsets, which do not work with the driver's internal addressing model. As a result, these quirks addressed the wrong ports and caused unstable behavior. This patch removes all KSZ88x3-specific DCB quirks and corrects the port control register offset, effectively restoring working and predictable apptrust configuration. Fixes: a1ea57710c9d ("net: dsa: microchip: dcb: add special handling for KSZ88X3 family") Signed-off-by: Oleksij Rempel Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250321141044.2128973-1-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 00dfe220e85517dfed663a386a6066fd4dd9bf40 Author: Jann Horn Date: Tue Mar 25 17:01:34 2025 +0100 rwonce: handle KCSAN like KASAN in read_word_at_a_time() [ Upstream commit ece69af2ede103e190ffdfccd9f9ec850606ab5e ] read_word_at_a_time() is allowed to read out of bounds by straddling the end of an allocation (and the caller is expected to then mask off out-of-bounds data). This works as long as the caller guarantees that the access won't hit a pagefault (either by ensuring that addr is aligned or by explicitly checking where the next page boundary is). Such out-of-bounds data could include things like KASAN redzones, adjacent allocations that are concurrently written to, or simply an adjacent struct field that is concurrently updated. KCSAN should ignore racy reads of OOB data that is not actually used, just like KASAN, so (similar to the code above) change read_word_at_a_time() to use __no_sanitize_or_inline instead of __no_kasan_or_inline, and explicitly inform KCSAN that we're reading the first byte. We do have an instrument_read() helper that calls into both KASAN and KCSAN, but I'm instead open-coding that here to avoid having to pull the entire instrumented.h header into rwonce.h. Also, since this read can be racy by design, we should technically do READ_ONCE(), so add that. Fixes: dfd402a4c4ba ("kcsan: Add Kernel Concurrency Sanitizer infrastructure") Signed-off-by: Jann Horn Acked-by: Arnd Bergmann Acked-by: Marco Elver Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 44073ccc09e6b64951ce2347234bd89a0059f0f3 Author: Wentao Guan Date: Tue Mar 18 02:50:34 2025 +0800 Bluetooth: HCI: Add definition of hci_rp_remote_name_req_cancel [ Upstream commit e8c00f5433d020a2230226abe7e43f43dc686920 ] Return Parameters is not only status, also bdaddr: BLUETOOTH CORE SPECIFICATION Version 5.4 | Vol 4, Part E page 1870: BLUETOOTH CORE SPECIFICATION Version 5.0 | Vol 2, Part E page 802: Return parameters: Status: Size: 1 octet BD_ADDR: Size: 6 octets Note that it also fixes the warning: "Bluetooth: hci0: unexpected cc 0x041a length: 7 > 1" Fixes: c8992cffbe741 ("Bluetooth: hci_event: Use of a function table to handle Command Complete") Signed-off-by: Wentao Guan Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 2c778debf67ed7572fc6eca208015501ea6f6678 Author: Luiz Augusto von Dentz Date: Wed Mar 12 11:14:20 2025 -0400 Bluetooth: hci_core: Enable buffer flow control for SCO/eSCO [ Upstream commit 13218453521d75916dfed55efb8e809bfc03cb4b ] This enables buffer flow control for SCO/eSCO (see: Bluetooth Core 6.0 spec: 6.22. Synchronous Flow Control Enable), recently this has caused the following problem and is actually a nice addition for the likes of Socket TX complete: < HCI Command: Read Buffer Size (0x04|0x0005) plen 0 > HCI Event: Command Complete (0x0e) plen 11 Read Buffer Size (0x04|0x0005) ncmd 1 Status: Success (0x00) ACL MTU: 1021 ACL max packet: 5 SCO MTU: 240 SCO max packet: 8 ... < SCO Data TX: Handle 257 flags 0x00 dlen 120 < SCO Data TX: Handle 257 flags 0x00 dlen 120 < SCO Data TX: Handle 257 flags 0x00 dlen 120 < SCO Data TX: Handle 257 flags 0x00 dlen 120 < SCO Data TX: Handle 257 flags 0x00 dlen 120 < SCO Data TX: Handle 257 flags 0x00 dlen 120 < SCO Data TX: Handle 257 flags 0x00 dlen 120 < SCO Data TX: Handle 257 flags 0x00 dlen 120 < SCO Data TX: Handle 257 flags 0x00 dlen 120 > HCI Event: Hardware Error (0x10) plen 1 Code: 0x0a To fix the code will now attempt to enable buffer flow control when HCI_QUIRK_SYNC_FLOWCTL_SUPPORTED is set by the driver: < HCI Command: Write Sync Fl.. (0x03|0x002f) plen 1 Flow control: Enabled (0x01) > HCI Event: Command Complete (0x0e) plen 4 Write Sync Flow Control Enable (0x03|0x002f) ncmd 1 Status: Success (0x00) On success then HCI_SCO_FLOWCTL would be set which indicates sco_cnt shall be used for flow contro. Fixes: 7fedd3bb6b77 ("Bluetooth: Prioritize SCO traffic") Signed-off-by: Luiz Augusto von Dentz Tested-by: Pauli Virtanen Signed-off-by: Sasha Levin commit 1c49d4d7c94b3e7183e9755263decd8368fc41f2 Author: Pedro Nishiyama Date: Sat Mar 1 03:23:01 2025 -0300 Bluetooth: btusb: Fix regression in the initialization of fake Bluetooth controllers [ Upstream commit 1f04b0e5e3b90b30f3ae7bee7e3d42a55fa91d5f ] Set HCI_READ_VOICE_SETTING and HCI_READ_PAGE_SCAN_TYPE as broken. Once the min/max length of the commands began to be asserted, these fake controllers can no longer be initialized because they return a smaller report for these commands. This affects various fake controllers reusing the 0A12:0001 VID/PID. Fixes: c8992cffbe74 ("Bluetooth: hci_event: Use of a function table to handle Command Complete") Signed-off-by: Pedro Nishiyama Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 05dc261b600266d202ea9cb6d1e230c2990d7493 Author: Pedro Nishiyama Date: Sat Mar 1 03:22:59 2025 -0300 Bluetooth: Add quirk for broken READ_PAGE_SCAN_TYPE [ Upstream commit 127881334eaad639e0a19a399ee8c91d6c9dc982 ] Some fake controllers cannot be initialized because they return a smaller report than expected for READ_PAGE_SCAN_TYPE. Signed-off-by: Pedro Nishiyama Signed-off-by: Luiz Augusto von Dentz Stable-dep-of: 1f04b0e5e3b9 ("Bluetooth: btusb: Fix regression in the initialization of fake Bluetooth controllers") Signed-off-by: Sasha Levin commit a256de0d34e5937da8e9e0b23a8fa17ec32afa7d Author: Pedro Nishiyama Date: Sat Mar 1 03:22:58 2025 -0300 Bluetooth: Add quirk for broken READ_VOICE_SETTING [ Upstream commit ff26b2dd6568392f60fa67a4e58279938025c3af ] Some fake controllers cannot be initialized because they return a smaller report than expected for READ_VOICE_SETTING. Signed-off-by: Pedro Nishiyama Signed-off-by: Luiz Augusto von Dentz Stable-dep-of: 1f04b0e5e3b9 ("Bluetooth: btusb: Fix regression in the initialization of fake Bluetooth controllers") Signed-off-by: Sasha Levin commit 3d8daa3c9fe8ddf228a7d11c689b41a5c6f4e6e9 Author: Akihiko Odaki Date: Fri Mar 21 15:48:33 2025 +0900 virtio_net: Fix endian with virtio_net_ctrl_rss [ Upstream commit 97841341e302eac13d54eb5e968570b5626196a7 ] Mark the fields of struct virtio_net_ctrl_rss as little endian as they are in struct virtio_net_rss_config, which it follows. Fixes: c7114b1249fa ("drivers/net/virtio_net: Added basic RSS support.") Signed-off-by: Akihiko Odaki Acked-by: Jason Wang Reviewed-by: Xuan Zhuo Acked-by: Michael S. Tsirkin Tested-by: Lei Yang Link: https://patch.msgid.link/20250321-virtio-v2-2-33afb8f4640b@daynix.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f9dff65140efc289f01bcf39c3ca66a8806b6132 Author: Wang Liang Date: Fri Mar 21 17:03:53 2025 +0800 net: fix NULL pointer dereference in l3mdev_l3_rcv [ Upstream commit 0032c99e83b9ce6d5995d65900aa4b6ffb501cce ] When delete l3s ipvlan: ip link del link eth0 ipvlan1 type ipvlan mode l3s This may cause a null pointer dereference: Call trace: ip_rcv_finish+0x48/0xd0 ip_rcv+0x5c/0x100 __netif_receive_skb_one_core+0x64/0xb0 __netif_receive_skb+0x20/0x80 process_backlog+0xb4/0x204 napi_poll+0xe8/0x294 net_rx_action+0xd8/0x22c __do_softirq+0x12c/0x354 This is because l3mdev_l3_rcv() visit dev->l3mdev_ops after ipvlan_l3s_unregister() assign the dev->l3mdev_ops to NULL. The process like this: (CPU1) | (CPU2) l3mdev_l3_rcv() | check dev->priv_flags: | master = skb->dev; | | | ipvlan_l3s_unregister() | set dev->priv_flags | dev->l3mdev_ops = NULL; | visit master->l3mdev_ops | To avoid this by do not set dev->l3mdev_ops when unregister l3s ipvlan. Suggested-by: David Ahern Fixes: c675e06a98a4 ("ipvlan: decouple l3s mode dependencies from other modes") Signed-off-by: Wang Liang Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250321090353.1170545-1-wangliang74@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ae6b1d6c1acee3a2000394d83ec9f1028321e207 Author: Nick Child Date: Thu Mar 20 16:29:51 2025 -0500 ibmvnic: Use kernel helpers for hex dumps [ Upstream commit d93a6caab5d7d9b5ce034d75b1e1e993338e3852 ] Previously, when the driver was printing hex dumps, the buffer was cast to an 8 byte long and printed using string formatters. If the buffer size was not a multiple of 8 then a read buffer overflow was possible. Therefore, create a new ibmvnic function that loops over a buffer and calls hex_dump_to_buffer instead. This patch address KASAN reports like the one below: ibmvnic 30000003 env3: Login Buffer: ibmvnic 30000003 env3: 01000000af000000 <...> ibmvnic 30000003 env3: 2e6d62692e736261 ibmvnic 30000003 env3: 65050003006d6f63 ================================================================== BUG: KASAN: slab-out-of-bounds in ibmvnic_login+0xacc/0xffc [ibmvnic] Read of size 8 at addr c0000001331a9aa8 by task ip/17681 <...> Allocated by task 17681: <...> ibmvnic_login+0x2f0/0xffc [ibmvnic] ibmvnic_open+0x148/0x308 [ibmvnic] __dev_open+0x1ac/0x304 <...> The buggy address is located 168 bytes inside of allocated 175-byte region [c0000001331a9a00, c0000001331a9aaf) <...> ================================================================= ibmvnic 30000003 env3: 000000000033766e Fixes: 032c5e82847a ("Driver for IBM System i/p VNIC protocol") Signed-off-by: Nick Child Reviewed-by: Dave Marquardt Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250320212951.11142-1-nnac123@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0dd4fac43bdea23cfe4bb2a3eabb76d752ac32fb Author: Wang Liang Date: Fri Mar 21 12:48:52 2025 +0800 bonding: check xdp prog when set bond mode [ Upstream commit 094ee6017ea09c11d6af187935a949df32803ce0 ] Following operations can trigger a warning[1]: ip netns add ns1 ip netns exec ns1 ip link add bond0 type bond mode balance-rr ip netns exec ns1 ip link set dev bond0 xdp obj af_xdp_kern.o sec xdp ip netns exec ns1 ip link set bond0 type bond mode broadcast ip netns del ns1 When delete the namespace, dev_xdp_uninstall() is called to remove xdp program on bond dev, and bond_xdp_set() will check the bond mode. If bond mode is changed after attaching xdp program, the warning may occur. Some bond modes (broadcast, etc.) do not support native xdp. Set bond mode with xdp program attached is not good. Add check for xdp program when set bond mode. [1] ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at net/core/dev.c:9912 unregister_netdevice_many_notify+0x8d9/0x930 Modules linked in: CPU: 0 UID: 0 PID: 11 Comm: kworker/u4:0 Not tainted 6.14.0-rc4 #107 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Workqueue: netns cleanup_net RIP: 0010:unregister_netdevice_many_notify+0x8d9/0x930 Code: 00 00 48 c7 c6 6f e3 a2 82 48 c7 c7 d0 b3 96 82 e8 9c 10 3e ... RSP: 0018:ffffc90000063d80 EFLAGS: 00000282 RAX: 00000000ffffffa1 RBX: ffff888004959000 RCX: 00000000ffffdfff RDX: 0000000000000000 RSI: 00000000ffffffea RDI: ffffc90000063b48 RBP: ffffc90000063e28 R08: ffffffff82d39b28 R09: 0000000000009ffb R10: 0000000000000175 R11: ffffffff82d09b40 R12: ffff8880049598e8 R13: 0000000000000001 R14: dead000000000100 R15: ffffc90000045000 FS: 0000000000000000(0000) GS:ffff888007a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000d406b60 CR3: 000000000483e000 CR4: 00000000000006f0 Call Trace: ? __warn+0x83/0x130 ? unregister_netdevice_many_notify+0x8d9/0x930 ? report_bug+0x18e/0x1a0 ? handle_bug+0x54/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? unregister_netdevice_many_notify+0x8d9/0x930 ? bond_net_exit_batch_rtnl+0x5c/0x90 cleanup_net+0x237/0x3d0 process_one_work+0x163/0x390 worker_thread+0x293/0x3b0 ? __pfx_worker_thread+0x10/0x10 kthread+0xec/0x1e0 ? __pfx_kthread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]--- Fixes: 9e2ee5c7e7c3 ("net, bonding: Add XDP support to the bonding driver") Signed-off-by: Wang Liang Acked-by: Jussi Maki Reviewed-by: Nikolay Aleksandrov Reviewed-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20250321044852.1086551-1-wangliang74@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9908541a9e235b7c5e2fbdd59910eaf9c32c3075 Author: Sankararaman Jayaraman Date: Thu Mar 20 10:25:22 2025 +0530 vmxnet3: unregister xdp rxq info in the reset path [ Upstream commit 0dd765fae295832934bf28e45dd5a355e0891ed4 ] vmxnet3 does not unregister xdp rxq info in the vmxnet3_reset_work() code path as vmxnet3_rq_destroy() is not invoked in this code path. So, we get below message with a backtrace. Missing unregister, handled but fix driver WARNING: CPU:48 PID: 500 at net/core/xdp.c:182 __xdp_rxq_info_reg+0x93/0xf0 This patch fixes the problem by moving the unregister code of XDP from vmxnet3_rq_destroy() to vmxnet3_rq_cleanup(). Fixes: 54f00cce1178 ("vmxnet3: Add XDP support.") Signed-off-by: Sankararaman Jayaraman Signed-off-by: Ronak Doshi Link: https://patch.msgid.link/20250320045522.57892-1-sankararaman.jayaraman@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 08fce4f85963fe81b785466dfbb4060943547107 Author: Moshe Shemesh Date: Tue Mar 18 22:51:17 2025 +0200 net/mlx5: Start health poll after enable hca [ Upstream commit 1726ad035cb0c93cc5c3f2227ec71322ccd7c2f8 ] The health poll mechanism performs periodic checks to detect firmware errors. One of the checks verifies the function is still enabled on firmware side, but the function is enabled only after enable_hca command completed. Start health poll after enable_hca command to avoid a race between function enabled and first health polling. Fixes: 9b98d395b85d ("net/mlx5: Start health poll at earlier stage of driver load") Signed-off-by: Moshe Shemesh Reviewed-by: Shay Drori Signed-off-by: Tariq Toukan Reviewed-by: Michal Swiatkowski Reviewed-by: Kalesh AP Link: https://patch.msgid.link/1742331077-102038-3-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9cb3d07c6d63c6611a7fdf35a4f00e92ee893a25 Author: Mark Bloch Date: Tue Mar 18 22:51:16 2025 +0200 net/mlx5: LAG, reload representors on LAG creation failure [ Upstream commit bdf549a7a4d738838d50833168881a0b6247446a ] When LAG creation fails, the driver reloads the RDMA devices. If RDMA representors are present, they should also be reloaded. This step was missed in the cited commit. Fixes: 598fe77df855 ("net/mlx5: Lag, Create shared FDB when in switchdev mode") Signed-off-by: Mark Bloch Reviewed-by: Shay Drori Signed-off-by: Tariq Toukan Reviewed-by: Michal Swiatkowski Reviewed-by: Kalesh AP Link: https://patch.msgid.link/1742331077-102038-2-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 59b97641de03c081f26b3a8876628c765b5faa25 Author: Vladimir Oltean Date: Tue Mar 18 13:57:16 2025 +0200 net: dsa: sja1105: fix kasan out-of-bounds warning in sja1105_table_delete_entry() [ Upstream commit 5f2b28b79d2d1946ee36ad8b3dc0066f73c90481 ] There are actually 2 problems: - deleting the last element doesn't require the memmove of elements [i + 1, end) over it. Actually, element i+1 is out of bounds. - The memmove itself should move size - i - 1 elements, because the last element is out of bounds. The out-of-bounds element still remains out of bounds after being accessed, so the problem is only that we touch it, not that it becomes in active use. But I suppose it can lead to issues if the out-of-bounds element is part of an unmapped page. Fixes: 6666cebc5e30 ("net: dsa: sja1105: Add support for VLAN operations") Signed-off-by: Vladimir Oltean Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250318115716.2124395-4-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a7d4d9f0c9bd870ca171a04f45a4a52f0d221579 Author: Vladimir Oltean Date: Tue Mar 18 13:57:15 2025 +0200 net: dsa: sja1105: reject other RX filters than HWTSTAMP_FILTER_PTP_V2_L2_EVENT [ Upstream commit b6a177b559717b707087114e08537fd47a4d1aca ] This is all that we can support timestamping, so we shouldn't accept anything else. Also see sja1105_hwtstamp_get(). To avoid erroring out in an inconsistent state, operate on copies of priv->hwts_rx_en and priv->hwts_tx_en, and write them back when nothing else can fail anymore. Fixes: a602afd200f5 ("net: dsa: sja1105: Expose PTP timestamping ioctls to userspace") Signed-off-by: Vladimir Oltean Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250318115716.2124395-3-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 15bfd522c24a294a3eaed8859bc27f658862da89 Author: Vladimir Oltean Date: Tue Mar 18 13:57:14 2025 +0200 net: dsa: sja1105: fix displaced ethtool statistics counters [ Upstream commit 00eb88752f48615ae7b4c1df6f9271cdd62c1d95 ] Port counters with no name (aka sja1105_port_counters[__SJA1105_COUNTER_UNUSED]) are skipped when reporting sja1105_get_sset_count(), but are not skipped during sja1105_get_strings() and sja1105_get_ethtool_stats(). As a consequence, the first reported counter has an empty name and a bogus value (reads from area 0, aka MAC, from offset 0, bits start:end 0:0). Also, the last counter (N_NOT_REACH on E/T, N_RX_BCAST on P/Q/R/S) gets pushed out of the statistics counters that get shown. Skip __SJA1105_COUNTER_UNUSED consistently, so that the bogus counter with an empty name disappears, and in its place appears a valid counter. Fixes: 039b167d68a3 ("net: dsa: sja1105: don't use burst SPI reads for port statistics") Signed-off-by: Vladimir Oltean Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250318115716.2124395-2-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ef0b7d7cacf1c877cc1c8d2ace74b576bb4210d0 Author: WangYuli Date: Tue Mar 18 18:36:54 2025 +0800 mlxsw: spectrum_acl_bloom_filter: Workaround for some LLVM versions [ Upstream commit 4af9939a4977e05ccaaa645848f6208e82e06c61 ] This is a workaround to mitigate a compiler anomaly. During LLVM toolchain compilation of this driver on s390x architecture, an unreasonable __write_overflow_field warning occurs. Contextually, chunk_index is restricted to 0, 1 or 2. By expanding these possibilities, the compile warning is suppressed. Fix follow error with clang-19 when -Werror: In file included from drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_bloom_filter.c:5: In file included from ./include/linux/gfp.h:7: In file included from ./include/linux/mmzone.h:8: In file included from ./include/linux/spinlock.h:63: In file included from ./include/linux/lockdep.h:14: In file included from ./include/linux/smp.h:13: In file included from ./include/linux/cpumask.h:12: In file included from ./include/linux/bitmap.h:13: In file included from ./include/linux/string.h:392: ./include/linux/fortify-string.h:571:4: error: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror,-Wattribute-warning] 571 | __write_overflow_field(p_size_field, size); | ^ 1 error generated. According to the testing, we can be fairly certain that this is a clang compiler bug, impacting only clang-19 and below. Clang versions 20 and 21 do not exhibit this behavior. Link: https://lore.kernel.org/all/484364B641C901CD+20250311141025.1624528-1-wangyuli@uniontech.com/ Fixes: 7585cacdb978 ("mlxsw: spectrum_acl: Add Bloom filter handling") Co-developed-by: Zijian Chen Signed-off-by: Zijian Chen Co-developed-by: Wentao Guan Signed-off-by: Wentao Guan Suggested-by: Paolo Abeni Co-developed-by: Ido Schimmel Signed-off-by: Ido Schimmel Tested-by: Ido Schimmel Tested-by: WangYuli Signed-off-by: WangYuli Link: https://patch.msgid.link/A1858F1D36E653E0+20250318103654.708077-1-wangyuli@uniontech.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1864c8b85c764055e894acb07ba2710423c75caa Author: Marek Behún Date: Mon Mar 17 18:32:48 2025 +0100 net: dsa: mv88e6xxx: enable STU methods for 6320 family [ Upstream commit 1428a6109b20e356188c3fb027bdb7998cc2fb98 ] Commit c050f5e91b47 ("net: dsa: mv88e6xxx: Fill in STU support for all supported chips") introduced STU methods, but did not add them to the 6320 family. Fix it. Fixes: c050f5e91b47 ("net: dsa: mv88e6xxx: Fill in STU support for all supported chips") Signed-off-by: Marek Behún Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250317173250.28780-6-kabel@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4d7c550a55785cfa2b6083d3e0a3f6deab3d903e Author: Marek Behún Date: Mon Mar 17 18:32:44 2025 +0100 net: dsa: mv88e6xxx: fix VTU methods for 6320 family [ Upstream commit f9a457722cf5e3534be5ffab549d6b49737fca72 ] The VTU registers of the 6320 family use the 6352 semantics, not 6185. Fix it. Fixes: b8fee9571063 ("net: dsa: mv88e6xxx: add VLAN Get Next support") Signed-off-by: Marek Behún Cc: # 5.15.x Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250317173250.28780-2-kabel@kernel.org Signed-off-by: Jakub Kicinski Stable-dep-of: 1428a6109b20 ("net: dsa: mv88e6xxx: enable STU methods for 6320 family") Signed-off-by: Sasha Levin commit a0898cf9a38dc53ecf314a7c2d0e539c88759045 Author: Marek Behún Date: Mon Mar 17 18:32:47 2025 +0100 net: dsa: mv88e6xxx: enable .port_set_policy() for 6320 family [ Upstream commit a2ef58e2c4aea4de166fc9832eb2b621e88c98d5 ] Commit f3a2cd326e44 ("net: dsa: mv88e6xxx: introduce .port_set_policy") did not add the .port_set_policy() method for the 6320 family. Fix it. Fixes: f3a2cd326e44 ("net: dsa: mv88e6xxx: introduce .port_set_policy") Signed-off-by: Marek Behún Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250317173250.28780-5-kabel@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7eb13e5b461590e7d02f5439bab081ab4baec9d1 Author: Marek Behún Date: Mon Mar 17 18:32:46 2025 +0100 net: dsa: mv88e6xxx: enable PVT for 6321 switch [ Upstream commit f85c69369854a43af2c5d3b3896da0908d713133 ] Commit f36456522168 ("net: dsa: mv88e6xxx: move PVT description in info") did not enable PVT for 6321 switch. Fix it. Fixes: f36456522168 ("net: dsa: mv88e6xxx: move PVT description in info") Signed-off-by: Marek Behún Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250317173250.28780-4-kabel@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 74c9ffccc3c8becddcc6a6f5c38142ae1bf21bcd Author: Marek Behún Date: Mon Mar 17 18:32:45 2025 +0100 net: dsa: mv88e6xxx: fix atu_move_port_mask for 6341 family [ Upstream commit 4ae01ec007716986e1a20f1285eb013cbf188830 ] The atu_move_port_mask for 6341 family (Topaz) is 0xf, not 0x1f. The PortVec field is 8 bits wide, not 11 as in 6390 family. Fix this. Fixes: e606ca36bbf2 ("net: dsa: mv88e6xxx: rework ATU Remove") Signed-off-by: Marek Behún Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250317173250.28780-3-kabel@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fb813eb60e54ea952d2785eeb62003045918c898 Author: Michael Chan Date: Fri Mar 21 14:16:39 2025 -0700 bnxt_en: Linearize TX SKB if the fragments exceed the max [ Upstream commit b91e82129400bdc40ee1232aa7e32ae6027f9b4f ] If skb_shinfo(skb)->nr_frags excceds what the chip can support, linearize the SKB and warn once to let the user know. net.core.max_skb_frags can be lowered, for example, to avoid the issue. Fixes: 3948b05950fd ("net: introduce a config option to tweak MAX_SKB_FRAGS") Reviewed-by: Somnath Kotur Reviewed-by: Kalesh AP Reviewed-by: Andy Gospodarek Signed-off-by: Michael Chan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250321211639.3812992-3-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f60b41b815826f15c4d0323f923f398c423178d0 Author: Michael Chan Date: Fri Mar 21 14:16:38 2025 -0700 bnxt_en: Mask the bd_cnt field in the TX BD properly [ Upstream commit 107b25db61122d8f990987895c2912927b8b6e3f ] The bd_cnt field in the TX BD specifies the total number of BDs for the TX packet. The bd_cnt field has 5 bits and the maximum number supported is 32 with the value 0. CONFIG_MAX_SKB_FRAGS can be modified and the total number of SKB fragments can approach or exceed the maximum supported by the chip. Add a macro to properly mask the bd_cnt field so that the value 32 will be properly masked and set to 0 in the bd_cnd field. Without this patch, the out-of-range bd_cnt value will corrupt the TX BD and may cause TX timeout. The next patch will check for values exceeding 32. Fixes: 3948b05950fd ("net: introduce a config option to tweak MAX_SKB_FRAGS") Reviewed-by: Kalesh AP Reviewed-by: Somnath Kotur Reviewed-by: Andy Gospodarek Signed-off-by: Michael Chan Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250321211639.3812992-2-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ce86174422cee61241b84454d7788422db9fefcf Author: Maxim Mikityanskiy Date: Wed Mar 19 14:45:08 2025 +0200 net/mlx5e: Fix ethtool -N flow-type ip4 to RSS context [ Upstream commit 3865bec60683b86d39a5d8d6c34a1d269adaa84c ] There commands can be used to add an RSS context and steer some traffic into it: # ethtool -X eth0 context new New RSS context is 1 # ethtool -N eth0 flow-type ip4 dst-ip 1.1.1.1 context 1 Added rule with ID 1023 However, the second command fails with EINVAL on mlx5e: # ethtool -N eth0 flow-type ip4 dst-ip 1.1.1.1 context 1 rmgr: Cannot insert RX class rule: Invalid argument Cannot insert classification rule It happens when flow_get_tirn calls flow_type_to_traffic_type with flow_type = IP_USER_FLOW or IPV6_USER_FLOW. That function only handles IPV4_FLOW and IPV6_FLOW cases, but unlike all other cases which are common for hash and spec, IPv4 and IPv6 defines different contants for hash and for spec: #define TCP_V4_FLOW 0x01 /* hash or spec (tcp_ip4_spec) */ #define UDP_V4_FLOW 0x02 /* hash or spec (udp_ip4_spec) */ ... #define IPV4_USER_FLOW 0x0d /* spec only (usr_ip4_spec) */ #define IP_USER_FLOW IPV4_USER_FLOW #define IPV6_USER_FLOW 0x0e /* spec only (usr_ip6_spec; nfc only) */ #define IPV4_FLOW 0x10 /* hash only */ #define IPV6_FLOW 0x11 /* hash only */ Extend the switch in flow_type_to_traffic_type to support both, which fixes the failing ethtool -N command with flow-type ip4 or ip6. Fixes: 248d3b4c9a39 ("net/mlx5e: Support flow classification into RSS contexts") Signed-off-by: Maxim Mikityanskiy Tested-by: Daniel Borkmann Reviewed-by: Joe Damato Reviewed-by: Tariq Toukan Link: https://patch.msgid.link/20250319124508.3979818-1-maxim@isovalent.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 61203fdd3e35519db9a98b6ff8983c620ffc4696 Author: Murad Masimov Date: Mon Mar 17 13:53:52 2025 +0300 ax25: Remove broken autobind [ Upstream commit 2f6efbabceb6b2914ee9bafb86d9a51feae9cce8 ] Binding AX25 socket by using the autobind feature leads to memory leaks in ax25_connect() and also refcount leaks in ax25_release(). Memory leak was detected with kmemleak: ================================================================ unreferenced object 0xffff8880253cd680 (size 96): backtrace: __kmalloc_node_track_caller_noprof (./include/linux/kmemleak.h:43) kmemdup_noprof (mm/util.c:136) ax25_rt_autobind (net/ax25/ax25_route.c:428) ax25_connect (net/ax25/af_ax25.c:1282) __sys_connect_file (net/socket.c:2045) __sys_connect (net/socket.c:2064) __x64_sys_connect (net/socket.c:2067) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) ================================================================ When socket is bound, refcounts must be incremented the way it is done in ax25_bind() and ax25_setsockopt() (SO_BINDTODEVICE). In case of autobind, the refcounts are not incremented. This bug leads to the following issue reported by Syzkaller: ================================================================ ax25_connect(): syz-executor318 uses autobind, please contact jreuter@yaina.de ------------[ cut here ]------------ refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 0 PID: 5317 at lib/refcount.c:31 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:31 Modules linked in: CPU: 0 UID: 0 PID: 5317 Comm: syz-executor318 Not tainted 6.14.0-rc4-syzkaller-00278-gece144f151ac #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:31 ... Call Trace: __refcount_dec include/linux/refcount.h:336 [inline] refcount_dec include/linux/refcount.h:351 [inline] ref_tracker_free+0x6af/0x7e0 lib/ref_tracker.c:236 netdev_tracker_free include/linux/netdevice.h:4302 [inline] netdev_put include/linux/netdevice.h:4319 [inline] ax25_release+0x368/0x960 net/ax25/af_ax25.c:1080 __sock_release net/socket.c:647 [inline] sock_close+0xbc/0x240 net/socket.c:1398 __fput+0x3e9/0x9f0 fs/file_table.c:464 __do_sys_close fs/open.c:1580 [inline] __se_sys_close fs/open.c:1565 [inline] __x64_sys_close+0x7f/0x110 fs/open.c:1565 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... ================================================================ Considering the issues above and the comments left in the code that say: "check if we can remove this feature. It is broken."; "autobinding in this may or may not work"; - it is better to completely remove this feature than to fix it because it is broken and leads to various kinds of memory bugs. Now calling connect() without first binding socket will result in an error (-EINVAL). Userspace software that relies on the autobind feature might get broken. However, this feature does not seem widely used with this specific driver as it was not reliable at any point of time, and it is already broken anyway. E.g. ax25-tools and ax25-apps packages for popular distributions do not use the autobind feature for AF_AX25. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+33841dc6aa3e1d86b78a@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=33841dc6aa3e1d86b78a Signed-off-by: Murad Masimov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4d19714355bc16151ebd6bf08627a3f0f6453c5c Author: WangYuli Date: Wed Mar 19 22:01:47 2025 +0800 netfilter: nf_tables: Only use nf_skip_indirect_calls() when MITIGATION_RETPOLINE [ Upstream commit e3a4182edd1ae60e7e3539ff3b3784af9830d223 ] 1. MITIGATION_RETPOLINE is x86-only (defined in arch/x86/Kconfig), so no need to AND with CONFIG_X86 when checking if enabled. 2. Remove unused declaration of nf_skip_indirect_calls() when MITIGATION_RETPOLINE is disabled to avoid warnings. 3. Declare nf_skip_indirect_calls() and nf_skip_indirect_calls_enable() as inline when MITIGATION_RETPOLINE is enabled, as they are called only once and have simple logic. Fix follow error with clang-21 when W=1e: net/netfilter/nf_tables_core.c:39:20: error: unused function 'nf_skip_indirect_calls' [-Werror,-Wunused-function] 39 | static inline bool nf_skip_indirect_calls(void) { return false; } | ^~~~~~~~~~~~~~~~~~~~~~ 1 error generated. make[4]: *** [scripts/Makefile.build:207: net/netfilter/nf_tables_core.o] Error 1 make[3]: *** [scripts/Makefile.build:465: net/netfilter] Error 2 make[3]: *** Waiting for unfinished jobs.... Fixes: d8d760627855 ("netfilter: nf_tables: add static key to skip retpoline workarounds") Co-developed-by: Wentao Guan Signed-off-by: Wentao Guan Signed-off-by: WangYuli Acked-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit ddbf7e1d82a1d0c1d3425931a6cb1b83f8454759 Author: Chenyuan Yang Date: Thu Mar 13 14:54:41 2025 -0500 netfilter: nfnetlink_queue: Initialize ctx to avoid memory allocation error [ Upstream commit 778b09d91baafb13408470c721d034d6515cfa5a ] It is possible that ctx in nfqnl_build_packet_message() could be used before it is properly initialize, which is only initialized by nfqnl_get_sk_secctx(). This patch corrects this problem by initializing the lsmctx to a safe value when it is declared. This is similar to the commit 35fcac7a7c25 ("audit: Initialize lsmctx to avoid memory allocation error"). Fixes: 2d470c778120 ("lsm: replace context+len with lsm_context") Signed-off-by: Chenyuan Yang Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 00fe0ac64efd1f5373b3dd9f1f84b19235371e39 Author: Kuniyuki Iwashima Date: Sun Mar 16 12:28:37 2025 -0700 net: Remove RTNL dance for SIOCBRADDIF and SIOCBRDELIF. [ Upstream commit ed3ba9b6e280e14cc3148c1b226ba453f02fa76c ] SIOCBRDELIF is passed to dev_ioctl() first and later forwarded to br_ioctl_call(), which causes unnecessary RTNL dance and the splat below [0] under RTNL pressure. Let's say Thread A is trying to detach a device from a bridge and Thread B is trying to remove the bridge. In dev_ioctl(), Thread A bumps the bridge device's refcnt by netdev_hold() and releases RTNL because the following br_ioctl_call() also re-acquires RTNL. In the race window, Thread B could acquire RTNL and try to remove the bridge device. Then, rtnl_unlock() by Thread B will release RTNL and wait for netdev_put() by Thread A. Thread A, however, must hold RTNL after the unlock in dev_ifsioc(), which may take long under RTNL pressure, resulting in the splat by Thread B. Thread A (SIOCBRDELIF) Thread B (SIOCBRDELBR) ---------------------- ---------------------- sock_ioctl sock_ioctl `- sock_do_ioctl `- br_ioctl_call `- dev_ioctl `- br_ioctl_stub |- rtnl_lock | |- dev_ifsioc ' ' |- dev = __dev_get_by_name(...) |- netdev_hold(dev, ...) . / |- rtnl_unlock ------. | | |- br_ioctl_call `---> |- rtnl_lock Race | | `- br_ioctl_stub |- br_del_bridge Window | | | |- dev = __dev_get_by_name(...) | | | May take long | `- br_dev_delete(dev, ...) | | | under RTNL pressure | `- unregister_netdevice_queue(dev, ...) | | | | `- rtnl_unlock \ | |- rtnl_lock <-' `- netdev_run_todo | |- ... `- netdev_run_todo | `- rtnl_unlock |- __rtnl_unlock | |- netdev_wait_allrefs_any |- netdev_put(dev, ...) <----------------' Wait refcnt decrement and log splat below To avoid blocking SIOCBRDELBR unnecessarily, let's not call dev_ioctl() for SIOCBRADDIF and SIOCBRDELIF. In the dev_ioctl() path, we do the following: 1. Copy struct ifreq by get_user_ifreq in sock_do_ioctl() 2. Check CAP_NET_ADMIN in dev_ioctl() 3. Call dev_load() in dev_ioctl() 4. Fetch the master dev from ifr.ifr_name in dev_ifsioc() 3. can be done by request_module() in br_ioctl_call(), so we move 1., 2., and 4. to br_ioctl_stub(). Note that 2. is also checked later in add_del_if(), but it's better performed before RTNL. SIOCBRADDIF and SIOCBRDELIF have been processed in dev_ioctl() since the pre-git era, and there seems to be no specific reason to process them there. [0]: unregister_netdevice: waiting for wpan3 to become free. Usage count = 2 ref_tracker: wpan3@ffff8880662d8608 has 1/1 users at __netdev_tracker_alloc include/linux/netdevice.h:4282 [inline] netdev_hold include/linux/netdevice.h:4311 [inline] dev_ifsioc+0xc6a/0x1160 net/core/dev_ioctl.c:624 dev_ioctl+0x255/0x10c0 net/core/dev_ioctl.c:826 sock_do_ioctl+0x1ca/0x260 net/socket.c:1213 sock_ioctl+0x23a/0x6c0 net/socket.c:1318 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl fs/ioctl.c:892 [inline] __x64_sys_ioctl+0x1a4/0x210 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcb/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 893b19587534 ("net: bridge: fix ioctl locking") Reported-by: syzkaller Reported-by: yan kang Reported-by: yue sun Closes: https://lore.kernel.org/netdev/SY8P300MB0421225D54EB92762AE8F0F2A1D32@SY8P300MB0421.AUSP300.PROD.OUTLOOK.COM/ Signed-off-by: Kuniyuki Iwashima Acked-by: Stanislav Fomichev Reviewed-by: Ido Schimmel Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20250316192851.19781-1-kuniyu@amazon.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit b1e081d331ab3a0dea25425f2b6ddeb365fc9d22 Author: Taehee Yoo Date: Sun Mar 16 02:58:37 2025 +0000 eth: bnxt: fix out-of-range access of vnic_info array [ Upstream commit 919f9f497dbcee75d487400e8f9815b74a6a37df ] The bnxt_queue_{start | stop}() access vnic_info as much as allocated, which indicates bp->nr_vnics. So, it should not reach bp->vnic_info[bp->nr_vnics]. Fixes: 661958552eda ("eth: bnxt: do not use BNXT_VNIC_NTUPLE unconditionally in queue restart logic") Signed-off-by: Taehee Yoo Reviewed-by: Michael Chan Link: https://patch.msgid.link/20250316025837.939527-1-ap420073@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit db05767b5bc307143d99fe2afd8c43af58d2ebef Author: Ojaswin Mujoo Date: Tue Mar 18 13:22:56 2025 +0530 ext4: avoid journaling sb update on error if journal is destroying [ Upstream commit ce2f26e73783b4a7c46a86e3af5b5c8de0971790 ] Presently we always BUG_ON if trying to start a transaction on a journal marked with JBD2_UNMOUNT, since this should never happen. However, while ltp running stress tests, it was observed that in case of some error handling paths, it is possible for update_super_work to start a transaction after the journal is destroyed eg: (umount) ext4_kill_sb kill_block_super generic_shutdown_super sync_filesystem /* commits all txns */ evict_inodes /* might start a new txn */ ext4_put_super flush_work(&sbi->s_sb_upd_work) /* flush the workqueue */ jbd2_journal_destroy journal_kill_thread journal->j_flags |= JBD2_UNMOUNT; jbd2_journal_commit_transaction jbd2_journal_get_descriptor_buffer jbd2_journal_bmap ext4_journal_bmap ext4_map_blocks ... ext4_inode_error ext4_handle_error schedule_work(&sbi->s_sb_upd_work) /* work queue kicks in */ update_super_work jbd2_journal_start start_this_handle BUG_ON(journal->j_flags & JBD2_UNMOUNT) Hence, introduce a new mount flag to indicate journal is destroying and only do a journaled (and deferred) update of sb if this flag is not set. Otherwise, just fallback to an un-journaled commit. Further, in the journal destroy path, we have the following sequence: 1. Set mount flag indicating journal is destroying 2. force a commit and wait for it 3. flush pending sb updates This sequence is important as it ensures that, after this point, there is no sb update that might be journaled so it is safe to update the sb outside the journal. (To avoid race discussed in 2d01ddc86606) Also, we don't need a similar check in ext4_grp_locked_error since it is only called from mballoc and AFAICT it would be always valid to schedule work here. Fixes: 2d01ddc86606 ("ext4: save error info to sb through journal if available") Reported-by: Mahesh Kumar Signed-off-by: Ojaswin Mujoo Reviewed-by: Jan Kara Link: https://patch.msgid.link/9613c465d6ff00cd315602f99283d5f24018c3f7.1742279837.git.ojaswin@linux.ibm.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit e62d8f20c4e3e912e4325bf2f7a650678e81b446 Author: Ojaswin Mujoo Date: Tue Mar 18 13:22:55 2025 +0530 ext4: define ext4_journal_destroy wrapper [ Upstream commit 5a02a6204ca37e7c22fbb55a789c503f05e8e89a ] Define an ext4 wrapper over jbd2_journal_destroy to make sure we have consistent behavior during journal destruction. This will also come useful in the next patch where we add some ext4 specific logic in the destroy path. Reviewed-by: Jan Kara Reviewed-by: Baokun Li Signed-off-by: Ojaswin Mujoo Link: https://patch.msgid.link/c3ba78c5c419757e6d5f2d8ebb4a8ce9d21da86a.1742279837.git.ojaswin@linux.ibm.com Signed-off-by: Theodore Ts'o Stable-dep-of: ce2f26e73783 ("ext4: avoid journaling sb update on error if journal is destroying") Signed-off-by: Sasha Levin commit a785db2dc2bc5e274e030ee313a580fe7a631cd5 Author: Zhang Yi Date: Fri Dec 6 19:13:27 2024 +0800 jbd2: add a missing data flush during file and fs synchronization [ Upstream commit aac45075f6d79a63ac8dff93b3e1d7053a6ba628 ] When the filesystem performs file or filesystem synchronization (e.g., ext4_sync_file()), it queries the journal to determine whether to flush the file device through jbd2_trans_will_send_data_barrier(). If the target transaction has not started committing, it assumes that the journal will submit the flush command, allowing the filesystem to bypass a redundant flush command. However, this assumption is not always valid. If the journal is not located on the filesystem device, the journal commit thread will not submit the flush command unless the variable ->t_need_data_flush is set to 1. Consequently, the flush may be missed, and data may be lost following a power failure or system crash, even if the synchronization appears to succeed. Unfortunately, we cannot determine with certainty whether the target transaction will flush to the filesystem device before it commits. However, if it has not started committing, it must be the running transaction. Therefore, fix it by always set its t_need_data_flush to 1, ensuring that the committing thread will flush the filesystem device. Fixes: bbd2be369107 ("jbd2: Add function jbd2_trans_will_send_data_barrier()") Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Link: https://patch.msgid.link/20241206111327.4171337-1-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 38ed34138370dd231c0a2a96077930391bbb3324 Author: Niklas Cassel Date: Mon Mar 17 10:57:04 2025 +0100 nvmet: pci-epf: Always configure BAR0 as 64-bit [ Upstream commit 1cf0184c0ac4f1e936bb3b089894bbeb0a9eb2bc ] NVMe PCIe Transport Specification 1.1, section 2.1.10, claims that the BAR0 type is Implementation Specific. However, in NVMe 1.1, the type is required to be 64-bit. Thus, to make our PCI EPF work on as many host systems as possible, always configure the BAR0 type to be 64-bit. In the rare case that the underlying PCI EPC does not support configuring BAR0 as 64-bit, the call to pci_epc_set_bar() will fail, and we will return a failure back to the user. This should not be a problem, as most PCI EPCs support configuring a BAR as 64-bit (and those EPCs with .only_64bit set to true in epc_features only support configuring the BAR as 64-bit). Tested-by: Damien Le Moal Fixes: 0faa0fe6f90e ("nvmet: New NVMe PCI endpoint function target driver") Signed-off-by: Niklas Cassel Reviewed-by: Christoph Hellwig Reviewed-by: Chaitanya Kulkarni Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 2d656806a309ee0af19964a5d6947cbf2226ac21 Author: Jacob Keller Date: Wed Mar 12 15:15:54 2025 -0700 ptp: ocp: reject unsupported periodic output flags [ Upstream commit 8dcfc910a81d8b53f59f8b23211e81f2a91f84f9 ] The ptp_ocp_signal_from_perout() function supports PTP_PEROUT_DUTY_CYCLE and PTP_PEROUT_PHASE. It does not support PTP_PEROUT_ONE_SHOT, but does not reject a request with such an unsupported flag. Add the appropriate check to ensure that unsupported requests are rejected both for PTP_PEROUT_ONE_SHOT as well as any future flags. Fixes: 1aa66a3a135a ("ptp: ocp: Program the signal generators via PTP_CLK_REQ_PEROUT") Reviewed-by: Vadim Fedorenko Signed-off-by: Jacob Keller Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250312-jk-net-fixes-supported-extts-flags-v2-5-ea930ba82459@intel.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c873372d5c8f3da1de67e4a37c0a87c0928001b9 Author: Jacob Keller Date: Wed Mar 12 15:15:53 2025 -0700 broadcom: fix supported flag check in periodic output function [ Upstream commit af2b428f7992c07b0767c9a3c341b54d9069542e ] In bcm_ptp_perout_locked, the driver rejects requests which have PTP_PEROUT_PHASE set. This appears to be an attempt to reject any unsupported flags. Unfortunately, this only checks one flag, but does not protect against PTP_PEROUT_ONE_SHOT, or any future flags which may be added. Fix the check to ensure that no flag other than the supported PTP_PEROUT_DUTY_CYCLE is set. Fixes: 7bfe91efd525 ("net: phy: Add support for 1PPS out and external timestamps") Signed-off-by: Jacob Keller Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250312-jk-net-fixes-supported-extts-flags-v2-4-ea930ba82459@intel.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 288f027030ff4845a322007efeea2a8715d241ea Author: Jacob Keller Date: Wed Mar 12 15:15:52 2025 -0700 net: lan743x: reject unsupported external timestamp requests [ Upstream commit c0b4ddd30871c59043ed3592e6abeee55c3bf045 ] The lan743x_ptp_io_event_cap_en() function checks that the given request sets only one of PTP_RISING_EDGE or PTP_FALLING_EDGE, but not both. However, this driver does not check whether other flags (such as PTP_EXT_OFF) are set, nor whether any future unrecognized flags are set. Fix this by adding the appropriate check to the lan743x_ptp_io_extts() function. Fixes: 60942c397af6 ("net: lan743x: Add support for PTP-IO Event Input External Timestamp (extts)") Signed-off-by: Jacob Keller Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250312-jk-net-fixes-supported-extts-flags-v2-3-ea930ba82459@intel.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit f04e5ebcc704736c1962e5be2cecd36748fc0799 Author: Jacob Keller Date: Wed Mar 12 15:15:51 2025 -0700 renesas: reject PTP_STRICT_FLAGS as unsupported [ Upstream commit 51d58c0c7921d3c93c44099b90dc46720d095bde ] The ravb_ptp_extts() function checks the flags coming from the PTP_EXTTS_REQUEST ioctl, to ensure that future flags are not accepted on accident. This was updated to 'honor' the PTP_STRICT_FLAGS in commit 6138e687c7b6 ("ptp: Introduce strict checking of external time stamp options."). However, the driver does not *actually* validate the flags. I originally fixed this driver to reject future flags in commit 592025a03b34 ("renesas: reject unsupported external timestamp flags"). It is still unclear whether this hardware timestamps the rising, falling, or both edges of the input signal. Accepting requests with PTP_STRICT_FLAGS is a bug, as this could lead to users mistakenly assuming a request with PTP_RISING_EDGE actually timestamps the rising edge only. Reject requests with PTP_STRICT_FLAGS (and hence all PTP_EXTTS_REQUEST2 requests) until someone with access to the datasheet or hardware knowledge can confirm the timestamping behavior and update this driver. Fixes: 6138e687c7b6 ("ptp: Introduce strict checking of external time stamp options.") Signed-off-by: Jacob Keller Reviewed-by: Niklas Söderlund Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250312-jk-net-fixes-supported-extts-flags-v2-2-ea930ba82459@intel.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit bf8207af7c384315b46dd7e029fe84697eea5367 Author: Jacob Keller Date: Wed Mar 12 15:15:50 2025 -0700 igb: reject invalid external timestamp requests for 82580-based HW [ Upstream commit 5eada2aabf13dcc4574b0a281b963b8cc55a52cc ] The igb_ptp_feature_enable_82580 function correctly checks that unknown flags are not passed to the function. However, it does not actually check PTP_RISING_EDGE or PTP_FALLING_EDGE when configuring the external timestamp function. The data sheet for the 82580 product says: Upon a change in the input level of one of the SDP pins that was configured to detect Time stamp events using the TSSDP register, a time stamp of the system time is captured into one of the two auxiliary time stamp registers (AUXSTMPL/H0 or AUXSTMPL/H1). For example to define timestamping of events in the AUXSTMPL0 and AUXSTMPH0 registers, Software should: 1. Set the TSSDP.AUX0_SDP_SEL field to select the SDP pin that detects the level change and set the TSSDP.AUX0_TS_SDP_EN bit to 1. 2. Set the TSAUXC.EN_TS0 bit to 1 to enable timestamping The same paragraph is in the i350 and i354 data sheets. The wording implies that the time stamps are captured at any level change. There does not appear to be any way to only timestamp one edge of the signal. Reject requests which do not set both PTP_RISING_EDGE and PTP_FALLING_EDGE when operating under PTP_STRICT_FLAGS mode via PTP_EXTTS_REQUEST2. Fixes: 38970eac41db ("igb: support EXTTS on 82580/i354/i350") Reviewed-by: Michal Swiatkowski Signed-off-by: Jacob Keller Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250312-jk-net-fixes-supported-extts-flags-v2-1-ea930ba82459@intel.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit f2d9a07dc73b6c2235284825e6be4bf37e87f9be Author: Nikita Zhandarovich Date: Tue Jan 14 07:44:41 2025 -0800 wifi: mt76: mt7915: fix possible integer overflows in mt7915_muru_stats_show() [ Upstream commit 77b749520cac06d000d9923f79ffa632cdea6113 ] Assuming sums of values stored in variables such as sub_total_cnt and total_ppdu_cnt are big enough to warrant their u64 type, it makes sense to ensure that their calculation takes into account possible integer overflow issues. Play it safe and fix the problem by casting right hand expressions to u64 as well. Also, slightly adjust tabulation. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. Fixes: 1966a5078f2d ("mt76: mt7915: add mu-mimo and ofdma debugfs knobs") Signed-off-by: Nikita Zhandarovich Link: https://patch.msgid.link/20250114154441.16920-1-n.zhandarovich@fintech.ru Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit ef6800a2015e706e9852a5ec15263fec9990d012 Author: Mark Harmstone Date: Tue Mar 11 16:39:25 2025 +0000 btrfs: don't clobber ret in btrfs_validate_super() [ Upstream commit 9db9c7dd5b4e1d3205137a094805980082c37716 ] Commit 2a9bb78cfd36 ("btrfs: validate system chunk array at btrfs_validate_super()") introduces a call to validate_sys_chunk_array() in btrfs_validate_super(), which clobbers the value of ret set earlier. This has the effect of negating the validity checks done earlier, making it so btrfs could potentially try to mount invalid filesystems. Fixes: 2a9bb78cfd36 ("btrfs: validate system chunk array at btrfs_validate_super()") Reviewed-by: Qu Wenruo Signed-off-by: Mark Harmstone Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 9d383a6fc59271aaaf07a33b23b2eac5b9268b7a Author: Boris Burkov Date: Wed Mar 5 15:03:13 2025 -0800 btrfs: fix block group refcount race in btrfs_create_pending_block_groups() [ Upstream commit 2d8e5168d48a91e7a802d3003e72afb4304bebfa ] Block group creation is done in two phases, which results in a slightly unintuitive property: a block group can be allocated/deallocated from after btrfs_make_block_group() adds it to the space_info with btrfs_add_bg_to_space_info(), but before creation is completely completed in btrfs_create_pending_block_groups(). As a result, it is possible for a block group to go unused and have 'btrfs_mark_bg_unused' called on it concurrently with 'btrfs_create_pending_block_groups'. This causes a number of issues, which were fixed with the block group flag 'BLOCK_GROUP_FLAG_NEW'. However, this fix is not quite complete. Since it does not use the unused_bg_lock, it is possible for the following race to occur: btrfs_create_pending_block_groups btrfs_mark_bg_unused if list_empty // false list_del_init clear_bit else if (test_bit) // true list_move_tail And we get into the exact same broken ref count and invalid new_bgs state for transaction cleanup that BLOCK_GROUP_FLAG_NEW was designed to prevent. The broken refcount aspect will result in a warning like: [1272.943527] refcount_t: underflow; use-after-free. [1272.943967] WARNING: CPU: 1 PID: 61 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110 [1272.944731] Modules linked in: btrfs virtio_net xor zstd_compress raid6_pq null_blk [last unloaded: btrfs] [1272.945550] CPU: 1 UID: 0 PID: 61 Comm: kworker/u32:1 Kdump: loaded Tainted: G W 6.14.0-rc5+ #108 [1272.946368] Tainted: [W]=WARN [1272.946585] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 [1272.947273] Workqueue: btrfs_discard btrfs_discard_workfn [btrfs] [1272.947788] RIP: 0010:refcount_warn_saturate+0xba/0x110 [1272.949532] RSP: 0018:ffffbf1200247df0 EFLAGS: 00010282 [1272.949901] RAX: 0000000000000000 RBX: ffffa14b00e3f800 RCX: 0000000000000000 [1272.950437] RDX: 0000000000000000 RSI: ffffbf1200247c78 RDI: 00000000ffffdfff [1272.950986] RBP: ffffa14b00dc2860 R08: 00000000ffffdfff R09: ffffffff90526268 [1272.951512] R10: ffffffff904762c0 R11: 0000000063666572 R12: ffffa14b00dc28c0 [1272.952024] R13: 0000000000000000 R14: ffffa14b00dc2868 R15: 000001285dcd12c0 [1272.952850] FS: 0000000000000000(0000) GS:ffffa14d33c40000(0000) knlGS:0000000000000000 [1272.953458] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1272.953931] CR2: 00007f838cbda000 CR3: 000000010104e000 CR4: 00000000000006f0 [1272.954474] Call Trace: [1272.954655] [1272.954812] ? refcount_warn_saturate+0xba/0x110 [1272.955173] ? __warn.cold+0x93/0xd7 [1272.955487] ? refcount_warn_saturate+0xba/0x110 [1272.955816] ? report_bug+0xe7/0x120 [1272.956103] ? handle_bug+0x53/0x90 [1272.956424] ? exc_invalid_op+0x13/0x60 [1272.956700] ? asm_exc_invalid_op+0x16/0x20 [1272.957011] ? refcount_warn_saturate+0xba/0x110 [1272.957399] btrfs_discard_cancel_work.cold+0x26/0x2b [btrfs] [1272.957853] btrfs_put_block_group.cold+0x5d/0x8e [btrfs] [1272.958289] btrfs_discard_workfn+0x194/0x380 [btrfs] [1272.958729] process_one_work+0x130/0x290 [1272.959026] worker_thread+0x2ea/0x420 [1272.959335] ? __pfx_worker_thread+0x10/0x10 [1272.959644] kthread+0xd7/0x1c0 [1272.959872] ? __pfx_kthread+0x10/0x10 [1272.960172] ret_from_fork+0x30/0x50 [1272.960474] ? __pfx_kthread+0x10/0x10 [1272.960745] ret_from_fork_asm+0x1a/0x30 [1272.961035] [1272.961238] ---[ end trace 0000000000000000 ]--- Though we have seen them in the async discard workfn as well. It is most likely to happen after a relocation finishes which cancels discard, tears down the block group, etc. Fix this fully by taking the lock around the list_del_init + clear_bit so that the two are done atomically. Fixes: 0657b20c5a76 ("btrfs: fix use-after-free of new block group that became unused") Reviewed-by: Qu Wenruo Reviewed-by: Filipe Manana Signed-off-by: Boris Burkov Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit efb5895c8ff8ea3d85c643beb5a072144a29bb81 Author: Filipe Manana Date: Mon Feb 24 16:22:22 2025 +0000 btrfs: fix reclaimed bytes accounting after automatic block group reclaim [ Upstream commit 620768704326c9a71ea9c8324ffda8748d8d4f10 ] We are considering the used bytes counter of a block group as the amount to update the space info's reclaim bytes counter after relocating the block group, but this value alone is often not enough. This is because we may have a reserved extent (or more) and in that case its size is reflected in the reserved counter of the block group - the size of the extent is only transferred from the reserved counter to the used counter of the block group when the delayed ref for the extent is run - typically when committing the transaction (or when flushing delayed refs due to ENOSPC on space reservation). Such call chain for data extents is: btrfs_run_delayed_refs_for_head() run_one_delayed_ref() run_delayed_data_ref() alloc_reserved_file_extent() alloc_reserved_extent() btrfs_update_block_group() -> transfers the extent size from the reserved counter to the used counter For metadata extents: btrfs_run_delayed_refs_for_head() run_one_delayed_ref() run_delayed_tree_ref() alloc_reserved_tree_block() alloc_reserved_extent() btrfs_update_block_group() -> transfers the extent size from the reserved counter to the used counter Since relocation flushes delalloc, waits for ordered extent completion and commits the current transaction before doing the actual relocation work, the correct amount of reclaimed space is therefore the sum of the "used" and "reserved" counters of the block group before we call btrfs_relocate_chunk() at btrfs_reclaim_bgs_work(). So fix this by taking the "reserved" counter into consideration. Fixes: 243192b67649 ("btrfs: report reclaim stats in sysfs") Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 80c790c73c8a4f9c1825bcc8c0c174b63e64f269 Author: Filipe Manana Date: Mon Feb 24 15:40:26 2025 +0000 btrfs: get used bytes while holding lock at btrfs_reclaim_bgs_work() [ Upstream commit ba5d06440cae63edc4f49465baf78f1f43e55c77 ] At btrfs_reclaim_bgs_work(), we are grabbing twice the used bytes counter of the block group while not holding the block group's spinlock. This can result in races, reported by KCSAN and similar tools, since a concurrent task can be updating that counter while at btrfs_update_block_group(). So avoid these races by grabbing the counter in a critical section delimited by the block group's spinlock after setting the block group to RO mode. This also avoids using two different values of the counter in case it changes in between each read. This silences KCSAN and is required for the next patch in the series too. Fixes: 243192b67649 ("btrfs: report reclaim stats in sysfs") Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 89768e33752211b2240ec4c34138170c95f11f97 Author: Emil Tantilov Date: Fri Feb 14 09:18:16 2025 -0800 idpf: check error for register_netdev() on init [ Upstream commit 680811c67906191b237bbafe7dabbbad64649b39 ] Current init logic ignores the error code from register_netdev(), which will cause WARN_ON() on attempt to unregister it, if there was one, and there is no info for the user that the creation of the netdev failed. WARNING: CPU: 89 PID: 6902 at net/core/dev.c:11512 unregister_netdevice_many_notify+0x211/0x1a10 ... [ 3707.563641] unregister_netdev+0x1c/0x30 [ 3707.563656] idpf_vport_dealloc+0x5cf/0xce0 [idpf] [ 3707.563684] idpf_deinit_task+0xef/0x160 [idpf] [ 3707.563712] idpf_vc_core_deinit+0x84/0x320 [idpf] [ 3707.563739] idpf_remove+0xbf/0x780 [idpf] [ 3707.563769] pci_device_remove+0xab/0x1e0 [ 3707.563786] device_release_driver_internal+0x371/0x530 [ 3707.563803] driver_detach+0xbf/0x180 [ 3707.563816] bus_remove_driver+0x11b/0x2a0 [ 3707.563829] pci_unregister_driver+0x2a/0x250 Introduce an error check and log the vport number and error code. On removal make sure to check VPORT_REG_NETDEV flag prior to calling unregister and free on the netdev. Add local variables for idx, vport_config and netdev for readability. Fixes: 0fe45467a104 ("idpf: add create vport and netdev configuration") Suggested-by: Tony Nguyen Signed-off-by: Emil Tantilov Reviewed-by: Simon Horman Tested-by: Samuel Salin Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 362f704ba73a359db9cded567e891d9a8f081875 Author: Mateusz Polchlopek Date: Tue Mar 4 12:08:36 2025 +0100 ice: fix using untrusted value of pkt_len in ice_vc_fdir_parse_raw() [ Upstream commit 1388dd564183a5a18ec4a966748037736b5653c5 ] Fix using the untrusted value of proto->raw.pkt_len in function ice_vc_fdir_parse_raw() by verifying if it does not exceed the VIRTCHNL_MAX_SIZE_RAW_PACKET value. Fixes: 99f419df8a5c ("ice: enable FDIR filters from raw binary patterns for VFs") Reviewed-by: Przemek Kitszel Signed-off-by: Mateusz Polchlopek Signed-off-by: Martyna Szapar-Mudlaw Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit de28850676d0d245c6adaabf7697630287d0c9d5 Author: Lukasz Czapnik Date: Tue Mar 4 12:08:34 2025 +0100 ice: fix input validation for virtchnl BW [ Upstream commit c5be6562de5a19c44605b1c1edba8e339f2022c8 ] Add missing validation of tc and queue id values sent by a VF in ice_vc_cfg_q_bw(). Additionally fixed logged value in the warning message, where max_tx_rate was incorrectly referenced instead of min_tx_rate. Also correct error handling in this function by properly exiting when invalid configuration is detected. Fixes: 015307754a19 ("ice: Support VF queue rate limit and quanta size configuration") Reviewed-by: Jedrzej Jagielski Reviewed-by: Simon Horman Signed-off-by: Lukasz Czapnik Co-developed-by: Martyna Szapar-Mudlaw Signed-off-by: Martyna Szapar-Mudlaw Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 4161cf3f4c11006507f4e02bedc048a215a4b81a Author: Jan Glaza Date: Tue Mar 4 12:08:33 2025 +0100 ice: validate queue quanta parameters to prevent OOB access [ Upstream commit e2f7d3f7331b92cb820da23e8c45133305da1e63 ] Add queue wraparound prevention in quanta configuration. Ensure end_qid does not overflow by validating start_qid and num_queues. Fixes: 015307754a19 ("ice: Support VF queue rate limit and quanta size configuration") Reviewed-by: Jedrzej Jagielski Reviewed-by: Simon Horman Signed-off-by: Jan Glaza Signed-off-by: Martyna Szapar-Mudlaw Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit d99c2b438c1a06182fd6fc5b684c195dd0df1425 Author: Jan Glaza Date: Tue Mar 4 12:08:32 2025 +0100 ice: stop truncating queue ids when checking [ Upstream commit f91d0efcc3dd7b341bb370499b99dc02d4fb792f ] Queue IDs can be up to 4096, fix invalid check to stop truncating IDs to 8 bits. Fixes: bf93bf791cec8 ("ice: introduce ice_virtchnl.c and ice_virtchnl.h") Reviewed-by: Aleksandr Loktionov Reviewed-by: Jedrzej Jagielski Reviewed-by: Simon Horman Signed-off-by: Jan Glaza Signed-off-by: Martyna Szapar-Mudlaw Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit aa6ba212f499e16470f7f5f16e3152d6edcca3ec Author: Jan Glaza Date: Tue Mar 4 12:08:31 2025 +0100 virtchnl: make proto and filter action count unsigned [ Upstream commit db5e8ea155fc1d89c87cb81f0e4a681a77b9b03f ] The count field in virtchnl_proto_hdrs and virtchnl_filter_action_set should never be negative while still being valid. Changing it from int to u32 ensures proper handling of values in virtchnl messages in driverrs and prevents unintended behavior. In its current signed form, a negative count does not trigger an error in ice driver but instead results in it being treated as 0. This can lead to unexpected outcomes when processing messages. By using u32, any invalid values will correctly trigger -EINVAL, making error detection more robust. Fixes: 1f7ea1cd6a374 ("ice: Enable FDIR Configure for AVF") Reviewed-by: Jedrzej Jagielski Reviewed-by: Simon Horman Signed-off-by: Jan Glaza Signed-off-by: Martyna Szapar-Mudlaw Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 40119f20452329e42b782e198a9f1e6330fe0985 Author: Jesse Brandeburg Date: Thu Mar 6 09:56:34 2025 -0800 ice: fix reservation of resources for RDMA when disabled [ Upstream commit 7fd71f317288d5150d353ce9d65b1e2abf99a8e2 ] If the CONFIG_INFINIBAND_IRDMA symbol is not enabled as a module or a built-in, then don't let the driver reserve resources for RDMA. The result of this change is a large savings in resources for older kernels, and a cleaner driver configuration for the IRDMA=n case for old and new kernels. Implement this by avoiding enabling the RDMA capability when scanning hardware capabilities. Note: Loading the out-of-tree irdma driver in connection to the in-kernel ice driver, is not supported, and should not be attempted, especially when disabling IRDMA in the kernel config. Fixes: d25a0fc41c1f ("ice: Initialize RDMA support") Signed-off-by: Jesse Brandeburg Acked-by: Dave Ertman Reviewed-by: Aleksandr Loktionov Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit d7a799e7068f56a3e134f1d147ddb4ed9716ca03 Author: Karol Kolacinski Date: Wed Feb 19 14:13:27 2025 -0800 ice: ensure periodic output start time is in the future [ Upstream commit 53ce7166cbffd2b8f3bd821fd3918be665afd4c6 ] On E800 series hardware, if the start time for a periodic output signal is programmed into GLTSYN_TGT_H and GLTSYN_TGT_L registers, the hardware logic locks up and the periodic output signal never starts. Any future attempt to reprogram the clock function is futile as the hardware will not reset until a power on. The ice_ptp_cfg_perout function has logic to prevent this, as it checks if the requested start time is in the past. If so, a new start time is calculated by rounding up. Since commit d755a7e129a5 ("ice: Cache perout/extts requests and check flags"), the rounding is done to the nearest multiple of the clock period, rather than to a full second. This is more accurate, since it ensures the signal matches the user request precisely. Unfortunately, there is a race condition with this rounding logic. If the current time is close to the multiple of the period, we could calculate a target time that is extremely soon. It takes time for the software to program the registers, during which time this requested start time could become a start time in the past. If that happens, the periodic output signal will lock up. For large enough periods, or for the logic prior to the mentioned commit, this is unlikely. However, with the new logic rounding to the period and with a small enough period, this becomes inevitable. For example, attempting to enable a 10MHz signal requires a period of 100 nanoseconds. This means in the *best* case, we have 99 nanoseconds to program the clock output. This is essentially impossible, and thus such a small period practically guarantees that the clock output function will lock up. To fix this, add some slop to the clock time used to check if the start time is in the past. Because it is not critical that output signals start immediately, but it *is* critical that we do not brick the function, 0.5 seconds is selected. This does mean that any requested output will be delayed by at least 0.5 seconds. This slop is applied before rounding, so that we always round up to the nearest multiple of the period that is at least 0.5 seconds in the future, ensuring a minimum of 0.5 seconds to program the clock output registers. Finally, to ensure that the hardware registers programming the clock output complete in a timely manner, add a write flush to the end of ice_ptp_write_perout. This ensures we don't risk any issue with PCIe transaction batching. Strictly speaking, this fixes a race condition all the way back at the initial implementation of periodic output programming, as it is theoretically possible to trigger this bug even on the old logic when always rounding to a full second. However, the window is narrow, and the code has been refactored heavily since then, making a direct backport not apply cleanly. Fixes: d755a7e129a5 ("ice: Cache perout/extts requests and check flags") Signed-off-by: Karol Kolacinski Signed-off-by: Jacob Keller Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit eb0a7d45beb653d05b6ed4dc70f20a176989fee5 Author: Przemek Kitszel Date: Thu Feb 6 23:30:23 2025 +0100 ice: health.c: fix compilation on gcc 7.5 [ Upstream commit fa8eda19015ca9ae625f46d4ecb13df651bb54cc ] GCC 7 is not as good as GCC 8+ in telling what is a compile-time const, and thus could be used for static storage. Fortunately keeping strings as const arrays is enough to make old gcc happy. Excerpt from the report: My GCC is: gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0. CC [M] drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.o drivers/net/ethernet/intel/ice/devlink/health.c:35:3: error: initializer element is not constant ice_common_port_solutions, {ice_port_number_label}}, ^~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/intel/ice/devlink/health.c:35:3: note: (near initialization for 'ice_health_status_lookup[0].solution') drivers/net/ethernet/intel/ice/devlink/health.c:35:31: error: initializer element is not constant ice_common_port_solutions, {ice_port_number_label}}, ^~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/intel/ice/devlink/health.c:35:31: note: (near initialization for 'ice_health_status_lookup[0].data_label[0]') drivers/net/ethernet/intel/ice/devlink/health.c:37:46: error: initializer element is not constant "Change or replace the module or cable.", {ice_port_number_label}}, ^~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/intel/ice/devlink/health.c:37:46: note: (near initialization for 'ice_health_status_lookup[1].data_label[0]') drivers/net/ethernet/intel/ice/devlink/health.c:39:3: error: initializer element is not constant ice_common_port_solutions, {ice_port_number_label}}, ^~~~~~~~~~~~~~~~~~~~~~~~~ Fixes: 85d6164ec56d ("ice: add fw and port health reporters") Reported-by: Qiuxu Zhuo Closes: https://lore.kernel.org/netdev/CY8PR11MB7134BF7A46D71E50D25FA7A989F72@CY8PR11MB7134.namprd11.prod.outlook.com Reviewed-by: Michal Swiatkowski Suggested-by: Simon Horman Signed-off-by: Przemek Kitszel Reviewed-by: Simon Horman Tested-by: Sunitha Mekala (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit acfbb63b1d1dcbef86b3a20100a645464d1192c5 Author: Jeff Chen Date: Tue Mar 18 13:07:39 2025 +0800 wifi: mwifiex: Fix RF calibration data download from file [ Upstream commit 9868c4ce9481043d6c11f7421fe2b9637aa0feee ] This patch resolves an issue where RF calibration data from a file could not be downloaded to the firmware. The feature to download calibration data from a file was broken by the commit: d39fbc88956e. The issue arose because the function `mwifiex_cmd_cfg_data()` was modified in a way that prevented proper handling of file-based calibration data. While this patch restores the ability to download RF calibration data from a file, it may inadvertently break the feature to download calibration data from the device tree. This is because the function `mwifiex_dnld_dt_cfgdata()`, which also relies on `mwifiex_cmd_cfg_data()`, is still used for device tree-based calibration data downloads. Fixes: d39fbc88956e ("mwifiex: remove cfg_data construction") Signed-off-by: Jeff Chen Link: https://patch.msgid.link/20250318050739.2239376-3-jeff.chen_1@nxp.com [add newline for shorter lines] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit bd00eb05b15705428aaf9d6a5997a0f8d406f339 Author: Jeff Chen Date: Tue Mar 18 13:07:38 2025 +0800 wifi: mwifiex: Fix premature release of RF calibration data. [ Upstream commit 69ae7e1f73abae20f26e3536ca4a980b90eafeb7 ] This patch resolves an issue where RF calibration data was being released before the download process. Without this fix, the external calibration data file would not be downloaded at all. Fixes: d39fbc88956e ("mwifiex: remove cfg_data construction") Signed-off-by: Jeff Chen Link: https://patch.msgid.link/20250318050739.2239376-2-jeff.chen_1@nxp.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 2617f60c3613ef105b8db2d514d2cac2a1836f7d Author: Edward Adam Davis Date: Tue Mar 18 11:13:45 2025 +0800 wifi: cfg80211: init wiphy_work before allocating rfkill fails [ Upstream commit fc88dee89d7b63eeb17699393eb659aadf9d9b7c ] syzbort reported a uninitialize wiphy_work_lock in cfg80211_dev_free. [1] After rfkill allocation fails, the wiphy release process will be performed, which will cause cfg80211_dev_free to access the uninitialized wiphy_work related data. Move the initialization of wiphy_work to before rfkill initialization to avoid this issue. [1] INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 UID: 0 PID: 5935 Comm: syz-executor550 Not tainted 6.14.0-rc6-syzkaller-00103-g4003c9e78778 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 assign_lock_key kernel/locking/lockdep.c:983 [inline] register_lock_class+0xc39/0x1240 kernel/locking/lockdep.c:1297 __lock_acquire+0x135/0x3c40 kernel/locking/lockdep.c:5103 lock_acquire.part.0+0x11b/0x380 kernel/locking/lockdep.c:5851 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x3a/0x60 kernel/locking/spinlock.c:162 cfg80211_dev_free+0x30/0x3d0 net/wireless/core.c:1196 device_release+0xa1/0x240 drivers/base/core.c:2568 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1e4/0x5a0 lib/kobject.c:737 put_device+0x1f/0x30 drivers/base/core.c:3774 wiphy_free net/wireless/core.c:1224 [inline] wiphy_new_nm+0x1c1f/0x2160 net/wireless/core.c:562 ieee80211_alloc_hw_nm+0x1b7a/0x2260 net/mac80211/main.c:835 mac80211_hwsim_new_radio+0x1d6/0x54e0 drivers/net/wireless/virtual/mac80211_hwsim.c:5185 hwsim_new_radio_nl+0xb42/0x12b0 drivers/net/wireless/virtual/mac80211_hwsim.c:6242 genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2533 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1882 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg net/socket.c:733 [inline] ____sys_sendmsg+0xaaf/0xc90 net/socket.c:2573 ___sys_sendmsg+0x135/0x1e0 net/socket.c:2627 __sys_sendmsg+0x16e/0x220 net/socket.c:2659 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 Fixes: 72d520476a2f ("wifi: cfg80211: cancel wiphy_work before freeing wiphy") Reported-by: syzbot+aaf0488c83d1d5f4f029@syzkaller.appspotmail.com Close: https://syzkaller.appspot.com/bug?extid=aaf0488c83d1d5f4f029 Tested-by: syzbot+aaf0488c83d1d5f4f029@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis Link: https://patch.msgid.link/tencent_258DD9121DDDB9DD9A1939CFAA0D8625B107@qq.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 872220be96f2fb113faaa65cd923ac87089fc78d Author: Mikhail Lobanov Date: Mon Mar 17 13:31:37 2025 +0300 wifi: mac80211: check basic rates validity in sta_link_apply_parameters [ Upstream commit 16ee3ea8faef8ff042acc15867a6c458c573de61 ] When userspace sets supported rates for a new station via NL80211_CMD_NEW_STATION, it might send a list that's empty or contains only invalid values. Currently, we process these values in sta_link_apply_parameters() without checking the result of ieee80211_parse_bitrates(), which can lead to an empty rates bitmap. A similar issue was addressed for NL80211_CMD_SET_BSS in commit ce04abc3fcc6 ("wifi: mac80211: check basic rates validity"). This patch applies the same approach in sta_link_apply_parameters() for NL80211_CMD_NEW_STATION, ensuring there is at least one valid rate by inspecting the result of ieee80211_parse_bitrates(). Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: b95eb7f0eee4 ("wifi: cfg80211/mac80211: separate link params from station params") Signed-off-by: Mikhail Lobanov Link: https://patch.msgid.link/20250317103139.17625-1-m.lobanov@rosa.ru Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 815e1b1547c15cdb00a4f59ff5985e687a971670 Author: Aditya Kumar Singh Date: Fri Mar 14 09:38:53 2025 +0530 wifi: nl80211: store chandef on the correct link when starting CAC [ Upstream commit ea841520c50f5f7c72c8070e3b79e1927b94fabf ] Link ID to store chandef is still being used as 0 even in case of MLO which is incorrect. This leads to issue during CAC completion where link 0 as well gets stopped. Fixes: 0b7798232eee ("wifi: cfg80211/mac80211: use proper link ID for DFS") Signed-off-by: Aditya Kumar Singh Link: https://patch.msgid.link/20250314-fix_starting_cac_during_mlo-v1-1-3b51617d7ea5@oss.qualcomm.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 6c5c31889778be5d61334283dda55c599924d765 Author: Niklas Cassel Date: Mon Mar 17 12:17:55 2025 +0100 ata: libata: Fix NCQ Non-Data log not supported print [ Upstream commit b500ee5fde1bd0c85026dfcdadbc175548fb5216 ] Currently, both ata_dev_config_ncq_send_recv() - which checks for NCQ Send/Recv Log (Log Address 13h) and ata_dev_config_ncq_non_data() - which checks for NCQ Non-Data Log (Log Address 12h), uses the same print when the log is not supported: "NCQ Send/Recv Log not supported" This seems like a copy paste error, since NCQ Non-Data Log is actually a separate log. Fix the print to reference the correct log. Fixes: 284b3b77ea88 ("libata: NCQ encapsulation for ZAC MANAGEMENT OUT") Reviewed-by: Damien Le Moal Reviewed-by: Hannes Reinecke Link: https://lore.kernel.org/r/20250317111754.1666084-2-cassel@kernel.org Signed-off-by: Niklas Cassel Signed-off-by: Sasha Levin commit f64c24be1ffb163937c567174d3ecc3db914af1d Author: Zhang Yi Date: Mon Feb 17 14:59:55 2025 +0800 jbd2: fix off-by-one while erasing journal [ Upstream commit 18aba2adb3e2a676fff0d81e51f5045f3c636666 ] In __jbd2_journal_erase(), the block_stop parameter includes the last block of a contiguous region; however, the calculation of byte_stop is incorrect, as it does not account for the bytes in that last block. Consequently, the page cache is not cleared properly, which occasionally causes the ext4/050 test to fail. Since block_stop operates on inclusion semantics, it involves repeated increments and decrements by 1, significantly increasing the complexity of the calculations. Optimize the calculation and fix the incorrect byte_stop by make both block_stop and byte_stop to use exclusion semantics. This fixes a failure in fstests ext4/050. Fixes: 01d5d96542fd ("ext4: add discard/zeroout flags to journal flush") Signed-off-by: Zhang Yi Reviewed-by: Baokun Li Reviewed-by: Jan Kara Link: https://patch.msgid.link/20250217065955.3829229-1-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 32d872e3905746ff1048078256cb00f946b97d8a Author: Baokun Li Date: Thu Feb 13 19:22:47 2025 +0800 ext4: goto right label 'out_mmap_sem' in ext4_setattr() [ Upstream commit 7e91ae31e2d264155dfd102101afc2de7bd74a64 ] Otherwise, if ext4_inode_attach_jinode() fails, a hung task will happen because filemap_invalidate_unlock() isn't called to unlock mapping->invalidate_lock. Like this: EXT4-fs error (device sda) in ext4_setattr:5557: Out of memory INFO: task fsstress:374 blocked for more than 122 seconds. Not tainted 6.14.0-rc1-next-20250206-xfstests-dirty #726 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:fsstress state:D stack:0 pid:374 tgid:374 ppid:373 task_flags:0x440140 flags:0x00000000 Call Trace: __schedule+0x2c9/0x7f0 schedule+0x27/0xa0 schedule_preempt_disabled+0x15/0x30 rwsem_down_read_slowpath+0x278/0x4c0 down_read+0x59/0xb0 page_cache_ra_unbounded+0x65/0x1b0 filemap_get_pages+0x124/0x3e0 filemap_read+0x114/0x3d0 vfs_read+0x297/0x360 ksys_read+0x6c/0xe0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: c7fc0366c656 ("ext4: partial zero eof block on unaligned inode size extension") Signed-off-by: Baokun Li Reviewed-by: Jan Kara Reviewed-by: Brian Foster Link: https://patch.msgid.link/20250213112247.3168709-1-libaokun@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 0c8fbb6ffb3c8f5164572ca88e4ccb6cd6a41ca8 Author: Ye Bin Date: Sat Feb 8 14:31:41 2025 +0800 ext4: fix out-of-bound read in ext4_xattr_inode_dec_ref_all() [ Upstream commit 5701875f9609b000d91351eaa6bfd97fe2f157f4 ] There's issue as follows: BUG: KASAN: use-after-free in ext4_xattr_inode_dec_ref_all+0x6ff/0x790 Read of size 4 at addr ffff88807b003000 by task syz-executor.0/15172 CPU: 3 PID: 15172 Comm: syz-executor.0 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0xbe/0xfd lib/dump_stack.c:123 print_address_description.constprop.0+0x1e/0x280 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 ext4_xattr_inode_dec_ref_all+0x6ff/0x790 fs/ext4/xattr.c:1137 ext4_xattr_delete_inode+0x4c7/0xda0 fs/ext4/xattr.c:2896 ext4_evict_inode+0xb3b/0x1670 fs/ext4/inode.c:323 evict+0x39f/0x880 fs/inode.c:622 iput_final fs/inode.c:1746 [inline] iput fs/inode.c:1772 [inline] iput+0x525/0x6c0 fs/inode.c:1758 ext4_orphan_cleanup fs/ext4/super.c:3298 [inline] ext4_fill_super+0x8c57/0xba40 fs/ext4/super.c:5300 mount_bdev+0x355/0x410 fs/super.c:1446 legacy_get_tree+0xfe/0x220 fs/fs_context.c:611 vfs_get_tree+0x8d/0x2f0 fs/super.c:1576 do_new_mount fs/namespace.c:2983 [inline] path_mount+0x119a/0x1ad0 fs/namespace.c:3316 do_mount+0xfc/0x110 fs/namespace.c:3329 __do_sys_mount fs/namespace.c:3540 [inline] __se_sys_mount+0x219/0x2e0 fs/namespace.c:3514 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Memory state around the buggy address: ffff88807b002f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88807b002f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff88807b003000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88807b003080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88807b003100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Above issue happens as ext4_xattr_delete_inode() isn't check xattr is valid if xattr is in inode. To solve above issue call xattr_check_inode() check if xattr if valid in inode. In fact, we can directly verify in ext4_iget_extra_inode(), so that there is no divergent verification. Fixes: e50e5129f384 ("ext4: xattr-in-inode support") Signed-off-by: Ye Bin Reviewed-by: Jan Kara Link: https://patch.msgid.link/20250208063141.1539283-3-yebin@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 4ac427905ae9adfff2c038c83e5277543149d5ed Author: Ye Bin Date: Sat Feb 8 14:31:40 2025 +0800 ext4: introduce ITAIL helper [ Upstream commit 69f3a3039b0d0003de008659cafd5a1eaaa0a7a4 ] Introduce ITAIL helper to get the bound of xattr in inode. Signed-off-by: Ye Bin Reviewed-by: Jan Kara Link: https://patch.msgid.link/20250208063141.1539283-2-yebin@huaweicloud.com Signed-off-by: Theodore Ts'o Stable-dep-of: 5701875f9609 ("ext4: fix out-of-bound read in ext4_xattr_inode_dec_ref_all()") Signed-off-by: Sasha Levin commit 8ed94320ba9e88f418f6d4ca3a52add65df5f51e Author: Guixin Liu Date: Thu Mar 13 09:47:27 2025 +0800 scsi: target: tcm_loop: Fix wrong abort tag [ Upstream commit 1909b643034ef741af9f24a57ab735440c4b5d1a ] When the tcm_loop_nr_hw_queues is set to a value greater than 1, the tags of requests in the block layer are no longer unique. This may lead to erroneous aborting of commands with the same tag. The issue can be resolved by using blk_mq_unique_tag to generate globally unique identifiers by combining the hardware queue index and per-queue tags. Fixes: 6375f8908255 ("tcm_loop: Fixup tag handling") Signed-off-by: Guixin Liu Link: https://lore.kernel.org/r/20250313014728.105849-1-kanie@linux.alibaba.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 059592207c1695a2cb344fd522927b884f5fb2de Author: Xingui Yang Date: Thu Feb 20 17:00:11 2025 +0800 scsi: hisi_sas: Fixed failure to issue vendor specific commands [ Upstream commit 750d4fbe2c20e65d764c70afe2c9e6cfa874b044 ] At present, we determine the protocol through the cmd type, but other cmd types, such as vendor-specific commands, default to the PIO protocol. This strategy often causes the execution of different vendor-specific commands to fail. In fact, for these commands, a better way is to use the protocol configured by the command's tf to determine its protocol. Fixes: 6f2ff1a1311e ("hisi_sas: add v2 path to send ATA command") Signed-off-by: Xingui Yang Link: https://lore.kernel.org/r/20250220090011.313848-1-liyihang9@huawei.com Reviewed-by: Yihang Li Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 6adc7592eef5404da40919771c70ac86d024fdaa Author: Chunhai Guo Date: Mon Mar 17 04:16:24 2025 -0600 f2fs: fix missing discard for active segments [ Upstream commit 21263d035ff21fa0ccf79adba20bab9cd8cca0f2 ] During a checkpoint, the current active segment X may not be handled properly. This occurs when segment X has 0 valid blocks and a non-zero number of discard blocks, for the following reasons: locate_dirty_segment() does not mark any active segment as a prefree segment. As a result, segment X is not included in dirty_segmap[PRE], and f2fs_clear_prefree_segments() skips it when handling prefree segments. add_discard_addrs() skips any segment with 0 valid blocks, so segment X is also skipped. Consequently, no `struct discard_cmd` is actually created for segment X. However, the ckpt_valid_map and cur_valid_map of segment X are synced by seg_info_to_raw_sit() during the current checkpoint process. As a result, it cannot find the missing discard bits even in subsequent checkpoints. Consequently, the value of sbi->discard_blks remains non-zero. Thus, when f2fs is umounted, CP_TRIMMED_FLAG will not be set due to the non-zero sbi->discard_blks. Relevant code process: f2fs_write_checkpoint() f2fs_flush_sit_entries() list_for_each_entry_safe(ses, tmp, head, set_list) { for_each_set_bit_from(segno, bitmap, end) { ... add_discard_addrs(sbi, cpc, false); // skip segment X due to its 0 valid blocks ... seg_info_to_raw_sit(); // sync ckpt_valid_map with cur_valid_map for segment X ... } } f2fs_clear_prefree_segments(); // segment X is not included in dirty_segmap[PRE] and is skipped This issue is easy to reproduce with the following operations: root # mkfs.f2fs -f /dev/f2fs_dev root # mount -t f2fs /dev/f2fs_dev /mnt_point root # dd if=/dev/blk_dev of=/mnt_point/1.bin bs=4k count=256 root # sync root # rm /mnt_point/1.bin root # umount /mnt_point root # dump.f2fs /dev/f2fs_dev | grep "checkpoint state" Info: checkpoint state = 45 : crc compacted_summary unmount ---- 'trimmed' flag is missing Since add_discard_addrs() can handle active segments with non-zero valid blocks, it is reasonable to fix this issue by allowing it to also handle active segments with 0 valid blocks. Fixes: b29555505d81 ("f2fs: add key functions for small discards") Signed-off-by: Chunhai Guo Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit bc2b365577ba6c9900a75b3dc06f20094ddd517d Author: Jan Kara Date: Thu Feb 6 10:44:55 2025 +0100 ext4: verify fast symlink length [ Upstream commit 5f920d5d60839f7cbbb1ed50eac68d8bc0a73a7c ] Verify fast symlink length stored in inode->i_size matches the string stored in the inode to avoid surprises from corrupted filesystems. Reported-by: syzbot+48a99e426f29859818c0@syzkaller.appspotmail.com Tested-by: syzbot+48a99e426f29859818c0@syzkaller.appspotmail.com Fixes: bae80473f7b0 ("ext4: use inode_set_cached_link()") Suggested-by: Darrick J. Wong Signed-off-by: Jan Kara Reviewed-by: Baokun Li Reviewed-by: Darrick J. Wong Link: https://patch.msgid.link/20250206094454.20522-2-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit a13016573de9311d017e95eb2c84ac48a54551e4 Author: Kemeng Shi Date: Fri Jan 24 00:20:48 2025 +0800 ext4: add missing brelse() for bh2 in ext4_dx_add_entry() [ Upstream commit eb640af64db6d4702a85ab001b9cc7f4c5dd6abb ] Add missing brelse() for bh2 in ext4_dx_add_entry(). Fixes: ac27a0ec112a ("[PATCH] ext4: initial copy of files from ext3") Signed-off-by: Kemeng Shi Reviewed-by: Ojaswin Mujoo Reviewed-by: Zhang Yi Link: https://patch.msgid.link/20250123162050.2114499-2-shikemeng@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 484ccd48564b057b21f48e1a830fd635205cc1d9 Author: Gao Xiang Date: Tue Feb 25 11:39:34 2025 +0800 erofs: allow 16-byte volume name again [ Upstream commit 579450277780159b8ba94a08b2f1d1da2002aec5 ] Actually, volume name doesn't need to include the NIL terminator if the string length matches the on-disk field size as mentioned in [1]. I tend to relax it together with the upcoming 48-bit block addressing (or stable kernels which backport this fix) so that we could have a chance to record a 16-byte volume name like ext4. Since in-memory `volume_name` has no user, just get rid of the unneeded check for now. `sbi->uuid` is useless and avoid it too. [1] https://lore.kernel.org/r/96efe46b-dcce-4490-bba1-a0b00932d1cc@linux.alibaba.com Fixes: a64d9493f587 ("staging: erofs: refuse to mount images with malformed volume name") Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Link: https://lore.kernel.org/r/20250225033934.2542635-1-hsiangkao@linux.alibaba.com Signed-off-by: Sasha Levin commit 274817805e64374fc8efc8577c88fb1a81e5b515 Author: Nicolas Frattaroli Date: Fri Mar 14 16:35:50 2025 +0100 arm64: dts: rockchip: remove ethm0_clk0_25m_out from Sige5 gmac0 [ Upstream commit 73d246b4402c3356f6b3d13665de3a51eea7b555 ] The GPIO3 A4 pin on the ArmSoM Sige5 is routed to the 40-pin GPIO header. This pin can serve a variety of functions, including ones of questionable use to us on a GPIO header such as the 25MHz clock of the ethernet controller. Unfortunately, this is the precise function that it is being claimed for by the gmac0 node in the Sige5 board dts, meaning it can't be used for anything else despite serving no useful function in this role. Since it goes through a RS0108 bidirectional voltage level translator with a maximum data rate of 24Mbit/s in push-pull mode and 2Mbit/s data rate in open-drain mode, it's doubtful as to whether the 25MHz clock signal would even survive to the actual user-accessible pin it terminates in. Remove it to leave the pin for users to play with. It's infinitely more useful as a GPIO or even as a PWM. Fixes: 40f742b07ab2 ("arm64: dts: rockchip: Add rk3576-armsom-sige5 board") Signed-off-by: Nicolas Frattaroli Link: https://lore.kernel.org/r/20250314-rk3576-sige5-eth-clk-begone-v1-1-2858338fc555@collabora.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit dfb3cbd165505dca157225d40af1e953e751f661 Author: Yao Zi Date: Mon Mar 10 14:09:17 2025 +0000 arm64: dts: rockchip: Fix PWM pinctrl names [ Upstream commit 09b0a7b63a6cda138e2e47c6acb2aee80338624c ] These Rockchip boards assign "active" as the pinctrl name for PWM controllers, which has never been supported in mainline Rockchip PWM driver. It seems the name used by downstream kernel is accidentally brought into maineline. Let's fix them. Fixes: 4403e1237be3 ("arm64: dts: rockchip: Add devicetree for board roc-rk3308-cc") Fixes: 964ed0807b5f ("arm64: dts: rockchip: add rk3318 A95X Z2 board") Fixes: e7a095908227 ("arm64: dts: rockchip: Add devicetree for NanoPC-T4") Fixes: 3f5d336d64d6 ("arm64: dts: rockchip: Add support for rk3588s based board Cool Pi 4B") Signed-off-by: Yao Zi Link: https://lore.kernel.org/r/20250310140916.14384-2-ziyao@disroot.org Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 7373782fd940f258642d3e622ab7d8bb2e692650 Author: Jianfeng Liu Date: Tue Mar 11 22:12:39 2025 +0800 arm64: dts: rockchip: Fix pcie reset gpio on Orange Pi 5 Max [ Upstream commit e0945a08fc7f7ed26c8dae286a3d30a68ad37d50 ] According to the schematic, pcie reset gpio is GPIO3_D4, not GPIO4_D4. Fixes: c600d252dc52 ("arm64: dts: rockchip: Add Orange Pi 5 Max board") Signed-off-by: Jianfeng Liu Reviewed-by: Jimmy Hon Link: https://lore.kernel.org/r/20250311141245.2719796-1-liujianfeng1994@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit e069437f70c3e9c1b865270c71b53a66251c23f6 Author: Christophe JAILLET Date: Sun Mar 2 17:21:35 2025 +0100 bus: qcom-ssc-block-bus: Fix the error handling path of qcom_ssc_block_bus_probe() [ Upstream commit f41658cd081ad7697796b3dacd9a717a57919268 ] If qcom_ssc_block_bus_pds_enable() fails, the previous call to qcom_ssc_block_bus_pds_attach() must be undone, as already done in the remove function. In order to do that, move the code related to the power domains management to the end of the function, in order to avoid many changes in all the error handling path that would need to go through the new error handling path. Fixes: 97d485edc1d9 ("bus: add driver for initializing the SSC bus on (some) qcom SoCs") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/1b89ec7438c9a893c09083e8591772c8ad3cb599.1740932040.git.christophe.jaillet@wanadoo.fr Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 071fef5e6c5b181c3d0b99c5f12b633662527e0a Author: Christophe JAILLET Date: Sun Mar 2 17:21:34 2025 +0100 bus: qcom-ssc-block-bus: Remove some duplicated iounmap() calls [ Upstream commit a9ac4ba7dcace2b3b91e7b87bf0ba97c47edd94f ] reg_mpm_sscaon_config[01] are allocated with devm_ioremap_resource(). So, they will be unmapped automatically by the manage resource framework. Remove the incorrect explicit iounmap() calls from the remove function. Fixes: 97d485edc1d9 ("bus: add driver for initializing the SSC bus on (some) qcom SoCs") Signed-off-by: Christophe JAILLET Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/efd06711b126e761a06eb5ef82daf9ad4e116a10.1740932040.git.christophe.jaillet@wanadoo.fr Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c2fe2f6c40b59576a730c66bc37859fdd88151ea Author: Chen-Yu Tsai Date: Fri Feb 21 00:50:51 2025 +0800 arm64: dts: rockchip: Remove bluetooth node from rock-3a [ Upstream commit 6b68387cf5ff5d7b86b189135affb0c679e3384a ] The Bluetooth node described in the device tree is actually on an M.2 slot. What module is present depends on what the end user installed, and should be left to an overlay. Remove the existing bluetooth node. This gets rid of bogus timeout errors. Fixes: 8cf890aabd45 ("arm64: dts: rockchip: Add nodes for SDIO/UART Wi-Fi/Bluetooth modules to Radxa Rock 3A") Signed-off-by: Chen-Yu Tsai Link: https://lore.kernel.org/r/20250220165051.1889055-1-wens@kernel.org Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit e3e827424dde611ad29a7b1ef3021044ff9be810 Author: Chukun Pan Date: Sat Mar 8 18:00:01 2025 +0800 arm64: dts: rockchip: Move rk356x scmi SHMEM to reserved memory [ Upstream commit 8fbb9376f0c489dfdc7e20d16e90686b29dec8f2 ] 0x0 to 0xf0000000 are SDRAM memory areas where 0x10f000 is located. So move the SHMEM memory of arm_scmi to the reserved memory node. Fixes: a3adc0b9071d ("arm64: dts: rockchip: add core dtsi for RK3568 SoC") Signed-off-by: Chukun Pan Link: https://lore.kernel.org/r/20250308100001.572657-2-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 141a8fb0031a6a19a61862af9c4fb9808dea47cb Author: Baokun Li Date: Wed Jan 22 19:41:29 2025 +0800 ext4: show 'emergency_ro' when EXT4_FLAGS_EMERGENCY_RO is set [ Upstream commit 6b76715d5e41fc332b0b879e66fad6ef3db07a3f ] After commit d3476f3dad4a ("ext4: don't set SB_RDONLY after filesystem errors") in v6.12-rc1, the 'errors=remount-ro' mode no longer sets SB_RDONLY on errors, which results in us seeing the filesystem is still in rw state after errors. Therefore, after setting EXT4_FLAGS_EMERGENCY_RO, display the emergency_ro option so that users can query whether the current file system has become emergency read-only due to errors through commands such as 'mount' or 'cat /proc/fs/ext4/sdx/options'. Fixes: d3476f3dad4a ("ext4: don't set SB_RDONLY after filesystem errors") Signed-off-by: Baokun Li Reviewed-by: Jan Kara Reviewed-by: Zhang Yi Link: https://patch.msgid.link/20250122114130.229709-7-libaokun@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 4fd9adec1bf45bcbffb9b43ee65ce840211571e3 Author: Baokun Li Date: Wed Jan 22 19:41:28 2025 +0800 ext4: correct behavior under errors=remount-ro mode [ Upstream commit 8f984530c242c569bafecfa35bce969a9b8fb0dd ] And after commit 95257987a638 ("ext4: drop EXT4_MF_FS_ABORTED flag") in v6.6-rc1, the EXT4_FLAGS_SHUTDOWN bit is set in ext4_handle_error() under errors=remount-ro mode. This causes the read to fail even when the error is triggered in errors=remount-ro mode. To correct the behavior under errors=remount-ro, EXT4_FLAGS_SHUTDOWN is replaced by the newly introduced EXT4_FLAGS_EMERGENCY_RO. This new flag only prevents writes, matching the previous behavior with SB_RDONLY. Fixes: 95257987a638 ("ext4: drop EXT4_MF_FS_ABORTED flag") Closes: https://lore.kernel.org/all/22d652f6-cb3c-43f5-b2fe-0a4bb6516a04@huawei.com/ Suggested-by: Jan Kara Signed-off-by: Baokun Li Reviewed-by: Zhang Yi Reviewed-by: Jan Kara Link: https://patch.msgid.link/20250122114130.229709-6-libaokun@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 6b415a617bab5bce14e907671f56c88ee875bf1c Author: Baokun Li Date: Wed Jan 22 19:41:25 2025 +0800 ext4: add EXT4_FLAGS_EMERGENCY_RO bit [ Upstream commit f3054e53c2f367bd3cf6535afe9ab13198d2d739 ] EXT4_FLAGS_EMERGENCY_RO Indicates that the current file system has become read-only due to some error. Compared to SB_RDONLY, setting it does not require a lock because we won't clear it, which avoids over-coupling with vfs freeze. Also, add a helper function ext4_emergency_ro() to check if the bit is set. Signed-off-by: Baokun Li Reviewed-by: Jan Kara Reviewed-by: Zhang Yi Link: https://patch.msgid.link/20250122114130.229709-3-libaokun@huaweicloud.com Signed-off-by: Theodore Ts'o Stable-dep-of: 8f984530c242 ("ext4: correct behavior under errors=remount-ro mode") Signed-off-by: Sasha Levin commit c64bdb477c1e8dc3242b5ff1ad4f36a5831dd128 Author: Baokun Li Date: Wed Jan 22 19:41:24 2025 +0800 ext4: convert EXT4_FLAGS_* defines to enum [ Upstream commit 99708f8a9d30081a71638d6f4e216350a4340cc3 ] Do away with the defines and use an enum as it's cleaner. Signed-off-by: Baokun Li Reviewed-by: Jan Kara Reviewed-by: Zhang Yi Link: https://patch.msgid.link/20250122114130.229709-2-libaokun@huaweicloud.com Signed-off-by: Theodore Ts'o Stable-dep-of: 8f984530c242 ("ext4: correct behavior under errors=remount-ro mode") Signed-off-by: Sasha Levin commit c445a7fdae5b5561eec237f54b7ed6a2de59f53a Author: Charles Han Date: Fri Jan 10 17:24:21 2025 +0800 ext4: fix potential null dereference in ext4 kunit test [ Upstream commit 57e7239ce0ed14e81e414c99d57f516f6220a995 ] kunit_kzalloc() may return a NULL pointer, dereferencing it without NULL check may lead to NULL dereference. Add a NULL check for grp. Fixes: ac96b56a2fbd ("ext4: Add unit test for mb_mark_used") Fixes: b7098e1fa7bc ("ext4: Add unit test for mb_free_blocks") Signed-off-by: Charles Han Reviewed-by: Kemeng Shi Link: https://patch.msgid.link/20250110092421.35619-1-hanchunchao@inspur.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit b96e0af1b1c99cb7e6188b6fa4963a4e47beb01e Author: Ming Lei Date: Wed Mar 12 22:51:36 2025 +0800 block: fix adding folio to bio [ Upstream commit 26064d3e2b4d9a14df1072980e558c636fb023ea ] >4GB folio is possible on some ARCHs, such as aarch64, 16GB hugepage is supported, then 'offset' of folio can't be held in 'unsigned int', cause warning in bio_add_folio_nofail() and IO failure. Fix it by adjusting 'page' & trimming 'offset' so that `->bi_offset` won't be overflow, and folio can be added to bio successfully. Fixes: ed9832bc08db ("block: introduce folio awareness and add a bigger size from folio") Cc: Kundan Kumar Cc: Matthew Wilcox (Oracle) Cc: Christoph Hellwig Cc: Luis Chamberlain Cc: Gavin Shan Signed-off-by: Ming Lei Reviewed-by: Matthew Wilcox (Oracle) Link: https://lore.kernel.org/r/20250312145136.2891229-1-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit e14e98ce5205dbb3d2fb81ecf4006929f79b9360 Author: Chao Yu Date: Wed Mar 12 17:01:25 2025 +0800 f2fs: fix to avoid running out of free segments [ Upstream commit f7f8932ca6bb22494ef6db671633ad3b4d982271 ] If checkpoint is disabled, GC can not reclaim any segments, we need to detect such condition and bail out from fallocate() of a pinfile, rather than letting allocator running out of free segment, which may cause f2fs to be shutdown. reproducer: mkfs.f2fs -f /dev/vda 16777216 mount -o checkpoint=disable:10% /dev/vda /mnt/f2fs for ((i=0;i<4096;i++)) do { dd if=/dev/zero of=/mnt/f2fs/$i bs=1M count=1; } done sync for ((i=0;i<4096;i+=2)) do { rm /mnt/f2fs/$i; } done sync touch /mnt/f2fs/pinfile f2fs_io pinfile set /mnt/f2fs/pinfile f2fs_io fallocate 0 0 4201644032 /mnt/f2fs/pinfile cat /sys/kernel/debug/f2fs/status output: - Free: 0 (0) Fixes: f5a53edcf01e ("f2fs: support aligned pinned file") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit a40276382664500713c18b0ec318214b5a4edb27 Author: Johannes Berg Date: Tue Mar 11 12:10:03 2025 +0100 wifi: mac80211: remove SSID from ML reconf [ Upstream commit 899da1830db112e6bd54ed4573ace753eae6ef22 ] The ML reconfiguration frame shouldn't contain an SSID, remove it. Fixes: 36e05b0b8390 ("wifi: mac80211: Support dynamic link addition and removal") Reviewed-by: Ilan Peer Link: https://patch.msgid.link/20250311121004.fdf08f90bc30.I07f88d3a6f592a0df65d48f55d65c46a4d261007@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 32ed1cb03461c8d11e013310c31a54725d152f63 Author: Robin Murphy Date: Fri Feb 28 15:46:30 2025 +0000 iommu: Handle race with default domain setup [ Upstream commit b46064a18810bad3aea089a79993ca5ea7a3d2b2 ] It turns out that deferred default domain creation leaves a subtle race window during iommu_device_register() wherein a client driver may asynchronously probe in parallel and get as far as performing DMA API operations with dma-direct, only to be switched to iommu-dma underfoot once the default domain attachment finally happens, with obviously disastrous consequences. Even the wonky of_iommu_configure() path is at risk, since iommu_fwspec_init() will no longer defer client probe as the instance ops are (necessarily) already registered, and the "replay" iommu_probe_device() call can see dev->iommu_group already set and so think there's nothing to do either. Fortunately we already have the right tool in the right place in the form of iommu_device_use_default_domain(), which just needs to ensure that said default domain is actually ready to *be* used. Deferring the client probe shouldn't have too much impact, given that this only happens while the IOMMU driver is probing, and thus due to kick the deferred probe list again once it finishes. Reported-by: Charan Teja Kalla Fixes: 98ac73f99bc4 ("iommu: Require a default_domain for all iommu drivers") Reviewed-by: Jason Gunthorpe Signed-off-by: Robin Murphy Link: https://lore.kernel.org/r/e88b94c9b575034a2c98a48b3d383654cbda7902.1740753261.git.robin.murphy@arm.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 7f90e5d423cd2d4c74b2abb527872f335108637f Author: Chao Yu Date: Mon Feb 24 18:29:23 2025 +0800 f2fs: fix to avoid accessing uninitialized curseg [ Upstream commit 986c50f6bca109c6cf362b4e2babcb85aba958f6 ] syzbot reports a f2fs bug as below: F2FS-fs (loop3): Stopped filesystem due to reason: 7 kworker/u8:7: attempt to access beyond end of device BUG: unable to handle page fault for address: ffffed1604ea3dfa RIP: 0010:get_ckpt_valid_blocks fs/f2fs/segment.h:361 [inline] RIP: 0010:has_curseg_enough_space fs/f2fs/segment.h:570 [inline] RIP: 0010:__get_secs_required fs/f2fs/segment.h:620 [inline] RIP: 0010:has_not_enough_free_secs fs/f2fs/segment.h:633 [inline] RIP: 0010:has_enough_free_secs+0x575/0x1660 fs/f2fs/segment.h:649 f2fs_is_checkpoint_ready fs/f2fs/segment.h:671 [inline] f2fs_write_inode+0x425/0x540 fs/f2fs/inode.c:791 write_inode fs/fs-writeback.c:1525 [inline] __writeback_single_inode+0x708/0x10d0 fs/fs-writeback.c:1745 writeback_sb_inodes+0x820/0x1360 fs/fs-writeback.c:1976 wb_writeback+0x413/0xb80 fs/fs-writeback.c:2156 wb_do_writeback fs/fs-writeback.c:2303 [inline] wb_workfn+0x410/0x1080 fs/fs-writeback.c:2343 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3317 worker_thread+0x870/0xd30 kernel/workqueue.c:3398 kthread+0x7a9/0x920 kernel/kthread.c:464 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Commit 8b10d3653735 ("f2fs: introduce FAULT_NO_SEGMENT") allows to trigger no free segment fault in allocator, then it will update curseg->segno to NULL_SEGNO, though, CP_ERROR_FLAG has been set, f2fs_write_inode() missed to check the flag, and access invalid curseg->segno directly in below call path, then resulting in panic: - f2fs_write_inode - f2fs_is_checkpoint_ready - has_enough_free_secs - has_not_enough_free_secs - __get_secs_required - has_curseg_enough_space - get_ckpt_valid_blocks : access invalid curseg->segno To avoid this issue, let's: - check CP_ERROR_FLAG flag in prior to f2fs_is_checkpoint_ready() in f2fs_write_inode(). - in has_curseg_enough_space(), save curseg->segno into a temp variable, and verify its validation before use. Fixes: 8b10d3653735 ("f2fs: introduce FAULT_NO_SEGMENT") Reported-by: syzbot+b6b347b7a4ea1b2e29b6@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/67973c2b.050a0220.11b1bb.0089.GAE@google.com Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit d6b00db365b281269d78dfe7e77021def4453551 Author: Laurentiu Mihalcea Date: Wed Feb 26 11:45:13 2025 -0500 arm64: dts: imx8mp: change AUDIO_AXI_CLK_ROOT freq. to 800MHz [ Upstream commit c54e2f908da30a6c66195a6d0aba6412c673ec2c ] AUDIO_AXI_CLK_ROOT can't run at currently requested 600MHz w/ its parent SYS_PLL1 configured at 800MHz. Configure it to run at 800MHz as some applications running on the DSP expect the core to run at this frequency anyways. This change also affects the AUDIOMIX NoC. Fixes: b739681b3f8b ("arm64: dts: imx8mp: Fix SDMA2/3 clocks") Signed-off-by: Laurentiu Mihalcea Reviewed-by: Iuliana Prodan Reviewed-by: Peng Fan Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit c114e71216bbaf8c4630da96901fb4c7e91d71d6 Author: Laurentiu Mihalcea Date: Wed Feb 26 11:45:12 2025 -0500 arm64: dts: imx8mp: add AUDIO_AXI_CLK_ROOT to AUDIOMIX block [ Upstream commit cfe47a3d3f7440cd1bdf2a169b325257eba01534 ] Needed because the DSP and OCRAM_A components from AUDIOMIX are clocked by AUDIO_AXI_CLK_ROOT instead of AUDIO_AHB_CLK_ROOT. Fixes: b86c3afabb4f ("arm64: dts: imx8mp: Add SAI, SDMA, AudioMIX") Signed-off-by: Laurentiu Mihalcea Reviewed-by: Iuliana Prodan Reviewed-by: Peng Fan Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit f78c9a77a2df24c62058e0284f91201bf0f3cf22 Author: Max Merchel Date: Tue Feb 25 15:44:35 2025 +0100 ARM: dts: imx6ul-tqma6ul1: Change include order to disable fec2 node [ Upstream commit 22d8f69c8ddcd036d6e81589e95a058b86272bd1 ] TQMa6UL1 has only one FEC which needs to be disabled as one of the last steps. imx6ul-tqma6ul2.dtsi can't be included in imx6ul-tqma6ul1.dtsi as the defaults from imx6ul.dtsi will be applied again. Fixes: 7b8861d8e627 ("ARM: dts: imx6ul: add TQ-Systems MBa6ULx device trees") Signed-off-by: Max Merchel Signed-off-by: Alexander Stein Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 91aae8fc0d7f2fa71ad3de9dd945303ccef7a58b Author: Andreas Gruenbacher Date: Thu Mar 6 22:13:28 2025 +0100 gfs2: skip if we cannot defer delete [ Upstream commit 41a8e04c94b868023986ec35ca06756e31e1e229 ] In gfs2_evict_inode(), in the unlikely case that we cannot defer deleting the inode, it is not safe to fall back to deleting the inode; the only valid choice we have is to skip the delete. In addition, in evict_should_delete(), if we cannot lock the inode glock exclusively, we are in a bad enough state that skipping the delete is likely a better choice than trying to recover from the failure later. Fixes: c5b7a2400edc ("gfs2: Only defer deletes when we have an iopen glock") Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 4b8fbe391e676cc74066ab0c6f1fc1d3f6df2c40 Author: Andreas Gruenbacher Date: Mon Mar 3 11:28:23 2025 +0100 gfs2: minor evict fix [ Upstream commit e9e38ed7250f8ef6b2928216156c09df8b4834b3 ] In evict_should_delete(), when gfs2_upgrade_iopen_glock() fails, we detach the iopen glock from the inode without calling glock_clear_object(). This leads to a warning in glock_set_object() when the same inode is recreated and the glock is reused. Fix that by only detaching the iopen glock in gfs2_evict_inode(). In addition, remove the dequeue code from evict_should_delete(); we already perform a conditional dequeue in gfs2_evict_inode(). Signed-off-by: Andreas Gruenbacher Stable-dep-of: 41a8e04c94b8 ("gfs2: skip if we cannot defer delete") Signed-off-by: Sasha Levin commit 0496a0da3b27f2480b396cd3ab81a64e9937d23c Author: Xueqi Zhang Date: Fri Mar 7 13:45:08 2025 +0800 memory: mtk-smi: Add ostd setting for mt8192 [ Upstream commit 90a0fbaac4a588a1116a191521c3c837c25582ee ] Add initial ostd setting for mt8192. All the settings come from DE. These settings help adjust Multimedia HW's bandwidth limits to achieve a balanced bandwidth requirement. Without this, the VENC HW work abnormal while stress testing. Fixes: 02c02ddce427 ("memory: mtk-smi: Add mt8192 support") Signed-off-by: Xueqi Zhang Reviewed-by: Yong Wu Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20250307054515.23455-1-xueqi.zhang@mediatek.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit e0afb53483db92a8779c101822645820fd57eee1 Author: Yunhui Cui Date: Mon Mar 10 10:47:44 2025 +0800 iommu/vt-d: Fix system hang on reboot -f [ Upstream commit 9ce7603ad3cbae64003087de57834e8c5c856a20 ] We found that executing the command ./a.out &;reboot -f (where a.out is a program that only executes a while(1) infinite loop) can probabilistically cause the system to hang in the intel_iommu_shutdown() function, rendering it unresponsive. Through analysis, we identified that the factors contributing to this issue are as follows: 1. The reboot -f command does not prompt the kernel to notify the application layer to perform cleanup actions, allowing the application to continue running. 2. When the kernel reaches the intel_iommu_shutdown() function, only the BSP (Bootstrap Processor) CPU is operational in the system. 3. During the execution of intel_iommu_shutdown(), the function down_write (&dmar_global_lock) causes the process to sleep and be scheduled out. 4. At this point, though the processor's interrupt flag is not cleared, allowing interrupts to be accepted. However, only legacy devices and NMI (Non-Maskable Interrupt) interrupts could come in, as other interrupts routing have already been disabled. If no legacy or NMI interrupts occur at this stage, the scheduler will not be able to run. 5. If the application got scheduled at this time is executing a while(1)- type loop, it will be unable to be preempted, leading to an infinite loop and causing the system to become unresponsive. To resolve this issue, the intel_iommu_shutdown() function should not execute down_write(), which can potentially cause the process to be scheduled out. Furthermore, since only the BSP is running during the later stages of the reboot, there is no need for protection against parallel access to the DMAR (DMA Remapping) unit. Therefore, the following lines could be removed: down_write(&dmar_global_lock); up_write(&dmar_global_lock); After testing, the issue has been resolved. Fixes: 6c3a44ed3c55 ("iommu/vt-d: Turn off translations at shutdown") Co-developed-by: Ethan Zhao Signed-off-by: Ethan Zhao Signed-off-by: Yunhui Cui Link: https://lore.kernel.org/r/20250303062421.17929-1-cuiyunhui@bytedance.com Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 59df8da77ff875f780babf066d3418b6b192e6a6 Author: Vasant Hegde Date: Thu Feb 27 16:23:18 2025 +0000 iommu/amd: Fix header file [ Upstream commit ee4cf9260afe8e4be6b6d64f56fa7493d051d8de ] Move function declaration inside AMD_IOMMU_H defination. Fixes: fd5dff9de4be ("iommu/amd: Modify set_dte_entry() to use 256-bit DTE helpers") Fixes: 457da5764668 ("iommu/amd: Lock DTE before updating the entry with WRITE_ONCE()") Cc: Suravee Suthikulpanit Signed-off-by: Vasant Hegde Reviewed-by: Jason Gunthorpe Link: https://lore.kernel.org/r/20250227162320.5805-6-vasant.hegde@amd.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit b4830c18beb6baf145f11816c059e5c171441e8e Author: Lorenzo Bianconi Date: Tue Mar 4 15:38:05 2025 +0100 net: airoha: Fix lan4 support in airoha_qdma_get_gdm_port() [ Upstream commit 35ea4f06fd33fc32f556a0c26d1d8340497fa7f8 ] EN7581 SoC supports lan{1,4} ports on MT7530 DSA switch. Fix lan4 reported value in airoha_qdma_get_gdm_port routine. Fixes: 23020f0493270 ("net: airoha: Introduce ethernet support for EN7581 SoC") Signed-off-by: Lorenzo Bianconi Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250304-airoha-eth-fix-lan4-v1-1-832417da4bb5@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a4bc6795e0b8942d129740f2c074c58872cee959 Author: Arnd Bergmann Date: Tue Mar 4 15:43:34 2025 +0100 firmware: arm_scmi: use ioread64() instead of ioread64_hi_lo() [ Upstream commit 3b8c56d8072750fd9625f03b92d8d6000c98628f ] The scmi_common_fastchannel_db_ring() function calls either ioread64() or ioread64_hi_lo() depending on whether it is compiler for 32-bit or 64-bit architectures. The same logic is used to define ioread64() itself in the linux/io-64-nonatomic-hi-lo.h header file, so the special case is not really needed. The behavior here should not change at all. Fixes: 6f9ea4dabd2d ("firmware: arm_scmi: Generalize the fast channel support") Reviewed-by: Sudeep Holla Link: https://lore.kernel.org/r/20250304144346.1025658-1-arnd@kernel.org Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit aa64194db3370b0d20d008752b354f19b0e9a65c Author: Zheng Qixing Date: Thu Feb 27 15:55:07 2025 +0800 badblocks: use sector_t instead of int to avoid truncation of badblocks length [ Upstream commit d301f164c3fbff611bd71f57dfa553b9219f0f5e ] There is a truncation of badblocks length issue when set badblocks as follow: echo "2055 4294967299" > bad_blocks cat bad_blocks 2055 3 Change 'sectors' argument type from 'int' to 'sector_t'. This change avoids truncation of badblocks length for large sectors by replacing 'int' with 'sector_t' (u64), enabling proper handling of larger disk sizes and ensuring compatibility with 64-bit sector addressing. Fixes: 9e0e252a048b ("badblocks: Add core badblock management code") Signed-off-by: Zheng Qixing Reviewed-by: Yu Kuai Acked-by: Coly Li Link: https://lore.kernel.org/r/20250227075507.151331-13-zhengqixing@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 6ac9e65d930552563942bc4e97e8bb7d20ef5903 Author: Zheng Qixing Date: Thu Feb 27 15:55:05 2025 +0800 badblocks: return boolean from badblocks_set() and badblocks_clear() [ Upstream commit c8775aefba959cdfbaa25408a84d3dd15bbeb991 ] Change the return type of badblocks_set() and badblocks_clear() from int to bool, indicating success or failure. Specifically: - _badblocks_set() and _badblocks_clear() functions now return true for success and false for failure. - All calls to these functions are updated to handle the new boolean return type. - This change improves code clarity and ensures a more consistent handling of success and failure states. Signed-off-by: Zheng Qixing Reviewed-by: Yu Kuai Acked-by: Coly Li Acked-by: Ira Weiny Link: https://lore.kernel.org/r/20250227075507.151331-11-zhengqixing@huaweicloud.com Signed-off-by: Jens Axboe Stable-dep-of: d301f164c3fb ("badblocks: use sector_t instead of int to avoid truncation of badblocks length") Signed-off-by: Sasha Levin commit dd2c2c13c03c25166fc6caa85c27dcf10fe79280 Author: Zheng Qixing Date: Thu Feb 27 15:55:04 2025 +0800 badblocks: fix missing bad blocks on retry in _badblocks_check() [ Upstream commit 5236f041fa6c81c71eabad44897e54a0d6d5bbf6 ] The bad blocks check would miss bad blocks when retrying under contention, as checking parameters are not reset. These stale values from the previous attempt could lead to incorrect scanning in the subsequent retry. Move seqlock to outer function and reinitialize checking state for each retry. This ensures a clean state for each check attempt, preventing any missed bad blocks. Fixes: 3ea3354cb9f0 ("badblocks: improve badblocks_check() for multiple ranges handling") Signed-off-by: Zheng Qixing Reviewed-by: Yu Kuai Acked-by: Coly Li Link: https://lore.kernel.org/r/20250227075507.151331-10-zhengqixing@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c58df052cf56edf3cd7a01536017cd6b31498aed Author: Li Nan Date: Thu Feb 27 15:55:03 2025 +0800 badblocks: fix merge issue when new badblocks align with pre+1 [ Upstream commit 9ec65dec634a752ab0a1203510ee190356e4cf1a ] There is a merge issue when adding badblocks as follow: echo 0 10 > bad_blocks echo 30 10 > bad_blocks echo 20 10 > bad_blocks cat bad_blocks 0 10 20 10 //should be merged with (30 10) 30 10 In this case, if new badblocks does not intersect with prev, it is added by insert_at(). If there is an intersection with prev+1, the merge will be processed in the next re_insert loop. However, when the end of the new badblocks is exactly equal to the offset of prev+1, no further re_insert loop occurs, and the two badblocks are not merge. Fix it by inc prev, badblocks can be merged during the subsequent code. Fixes: aa511ff8218b ("badblocks: switch to the improved badblock handling code") Signed-off-by: Li Nan Reviewed-by: Yu Kuai Link: https://lore.kernel.org/r/20250227075507.151331-9-zhengqixing@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit a517d3dac67c735d8644ac2ee6c2c5a6f1f60a10 Author: Li Nan Date: Thu Feb 27 15:55:01 2025 +0800 badblocks: fix the using of MAX_BADBLOCKS [ Upstream commit 37446680dfbfbba7cbedd680047182f70a0b857b ] The number of badblocks cannot exceed MAX_BADBLOCKS, but it should be allowed to equal MAX_BADBLOCKS. Fixes: aa511ff8218b ("badblocks: switch to the improved badblock handling code") Fixes: c3c6a86e9efc ("badblocks: add helper routines for badblock ranges handling") Signed-off-by: Li Nan Reviewed-by: Zhu Yanjun Reviewed-by: Yu Kuai Acked-by: Coly Li Link: https://lore.kernel.org/r/20250227075507.151331-7-zhengqixing@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 8e5785cba5420dad67d3c0ad04431acdd3902439 Author: Li Nan Date: Thu Feb 27 15:55:00 2025 +0800 badblocks: return error if any badblock set fails [ Upstream commit 7f500f0a59b1d7345a05ec4ae703babf34b7e470 ] _badblocks_set() returns success if at least one badblock is set successfully, even if others fail. This can lead to data inconsistencies in raid, where a failed badblock set should trigger the disk to be kicked out to prevent future reads from failed write areas. _badblocks_set() should return error if any badblock set fails. Instead of relying on 'rv', directly returning 'sectors' for clearer logic. If all badblocks are successfully set, 'sectors' will be 0, otherwise it indicates the number of badblocks that have not been set yet, thus signaling failure. By the way, it can also fix an issue: when a newly set unack badblock is included in an existing ack badblock, the setting will return an error. ··· echo "0 100" /sys/block/md0/md/dev-loop1/bad_blocks echo "0 100" /sys/block/md0/md/dev-loop1/unacknowledged_bad_blocks -bash: echo: write error: No space left on device ``` After fix, it will return success. Fixes: aa511ff8218b ("badblocks: switch to the improved badblock handling code") Signed-off-by: Li Nan Reviewed-by: Yu Kuai Acked-by: Coly Li Link: https://lore.kernel.org/r/20250227075507.151331-6-zhengqixing@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit a87d76deebf87b36ef541c91fc73f43815870d0b Author: Li Nan Date: Thu Feb 27 15:54:59 2025 +0800 badblocks: return error directly when setting badblocks exceeds 512 [ Upstream commit 28243dcd1f49cc8be398a1396d16a45527882ce5 ] In the current handling of badblocks settings, a lot of processing has been done for scenarios where the number of badblocks exceeds 512. This makes the code look quite complex and also introduces some issues, For example, if there is 512 badblocks already: for((i=0; i<510; i++)); do ((sector=i*2)); echo "$sector 1" > bad_blocks; done echo 2100 10 > bad_blocks echo 2200 10 > bad_blocks Set new one, exceed 512: echo 2000 500 > bad_blocks Expected: 2000 500 Actual: 2100 400 In fact, a disk shouldn't have too many badblocks, and for disks with 512 badblocks, attempting to set more bad blocks doesn't make much sense. At that point, the more appropriate action would be to replace the disk. Therefore, to resolve these issues and simplify the code somewhat, return error directly when setting badblocks exceeds 512. Fixes: aa511ff8218b ("badblocks: switch to the improved badblock handling code") Signed-off-by: Li Nan Reviewed-by: Yu Kuai Link: https://lore.kernel.org/r/20250227075507.151331-5-zhengqixing@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 4048fdec7ae21c5518aa6e05b5e82b6da2f4b603 Author: Li Nan Date: Thu Feb 27 15:54:58 2025 +0800 badblocks: attempt to merge adjacent badblocks during ack_all_badblocks [ Upstream commit 32e9ad4d11f69949ff331e35a417871ee0d31d99 ] If ack and unack badblocks are adjacent, they will not be merged and will remain as two separate badblocks. Even after the bad blocks are written to disk and both become ack, they will still remain as two independent bad blocks. This is not ideal as it wastes the limited space for badblocks. Therefore, during ack_all_badblocks(), attempt to merge badblocks if they are adjacent. Fixes: aa511ff8218b ("badblocks: switch to the improved badblock handling code") Signed-off-by: Li Nan Reviewed-by: Yu Kuai Acked-by: Coly Li Link: https://lore.kernel.org/r/20250227075507.151331-4-zhengqixing@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ebd06a54fd717cedf4f482c2368a46eb41a59418 Author: Li Nan Date: Thu Feb 27 15:54:57 2025 +0800 badblocks: factor out a helper try_adjacent_combine [ Upstream commit 270b68fee9688428e0a98d4a2c3e6d4c434a84ba ] Factor out try_adjacent_combine(), and it will be used in the later patch. Signed-off-by: Li Nan Reviewed-by: Yu Kuai Link: https://lore.kernel.org/r/20250227075507.151331-3-zhengqixing@huaweicloud.com Signed-off-by: Jens Axboe Stable-dep-of: 32e9ad4d11f6 ("badblocks: attempt to merge adjacent badblocks during ack_all_badblocks") Signed-off-by: Sasha Levin commit 319613b3837d12d8660d8d9f7b09b0730328c0d7 Author: Li Nan Date: Thu Feb 27 15:54:56 2025 +0800 badblocks: Fix error shitf ops [ Upstream commit 7d83c5d73c1a3c7b71ba70d0ad2ae66e7a0e7ace ] 'bb->shift' is used directly in badblocks. It is wrong, fix it. Fixes: 3ea3354cb9f0 ("badblocks: improve badblocks_check() for multiple ranges handling") Signed-off-by: Li Nan Reviewed-by: Yu Kuai Acked-by: Coly Li Link: https://lore.kernel.org/r/20250227075507.151331-2-zhengqixing@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit e55b0170bde4f5f4d4297160134ee78bec29265f Author: Anuj Gupta Date: Wed Mar 5 12:00:33 2025 +0530 block: Correctly initialize BLK_INTEGRITY_NOGENERATE and BLK_INTEGRITY_NOVERIFY [ Upstream commit 85f72925000e924291a0ebf63d2234994a4f22bd ] Currently, BLK_INTEGRITY_NOGENERATE and BLK_INTEGRITY_NOVERIFY are not explicitly set during integrity initialization. This can lead to incorrect reporting of read_verify and write_generate sysfs values, particularly when a device does not support integrity. Ensure that these flags are correctly initialized by default. Reported-by: M Nikhil Link: https://lore.kernel.org/linux-block/f6130475-3ccd-45d2-abde-3ccceada0f0a@linux.ibm.com/ Fixes: 9f4aa46f2a74 ("block: invert the BLK_INTEGRITY_{GENERATE,VERIFY} flags") Signed-off-by: Anuj Gupta Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20250305063033.1813-3-anuj20.g@samsung.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit fb489ec3ab1ad2d36f35465954247e240821a592 Author: Anuj Gupta Date: Wed Mar 5 12:00:32 2025 +0530 block: ensure correct integrity capability propagation in stacked devices [ Upstream commit 677e332e4885a17def5efa4788b6e725a737b63c ] queue_limits_stack_integrity() incorrectly sets BLK_INTEGRITY_DEVICE_CAPABLE for a DM device even when none of its underlying devices support integrity. This happens because the flag is inherited unconditionally. Ensure that integrity capabilities are correctly propagated only when the underlying devices actually support integrity. Reported-by: M Nikhil Link: https://lore.kernel.org/linux-block/f6130475-3ccd-45d2-abde-3ccceada0f0a@linux.ibm.com/ Fixes: c6e56cf6b2e7 ("block: move integrity information into queue_limits") Signed-off-by: Anuj Gupta Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20250305063033.1813-2-anuj20.g@samsung.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 31d3156efe909b53ba174861a3da880c688f5edc Author: Xiao Ni Date: Thu Mar 6 17:49:38 2025 +0800 md/raid10: wait barrier before returning discard request with REQ_NOWAIT [ Upstream commit 3db4404435397a345431b45f57876a3df133f3b4 ] raid10_handle_discard should wait barrier before returning a discard bio which has REQ_NOWAIT. And there is no need to print warning calltrace if a discard bio has REQ_NOWAIT flag. Quality engineer usually checks dmesg and reports error if dmesg has warning/error calltrace. Fixes: c9aa889b035f ("md: raid10 add nowait support") Signed-off-by: Xiao Ni Acked-by: Coly Li Link: https://lore.kernel.org/linux-raid/20250306094938.48952-1-xni@redhat.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 12fc640f103d17412f2cd1428e8063a4a1a1e72b Author: AngeloGioacchino Del Regno Date: Wed Feb 12 11:00:10 2025 +0100 soc: mediatek: mt8365-mmsys: Fix routing table masks and values [ Upstream commit d294d56cb9462e918421fe2bbe5f52a8da82603a ] The mmsys driver reads the routing table and writes to the hardware `val & mask`, but multiple entries in the mmsys routing table for the MT8365 SoC are setting a 0x0 mask: this effectively writes .. nothing .. to the hardware. That would never work, and if the display controller was actually working with the mmsys doing no routing at all, that was only because the bootloader was correctly setting the display controller routing registers before booting the kernel, and the mmsys was never reset. Make this table to actually set the routing by adding the correct register masks to it. While at it, also change MOUT val definitions to BIT(x), as the MOUT registers are effectively checking for each bit to enable output to the corresponding HW. Please note that, for this SoC, only the MOUT registers are checking bits (as those can enable multiple outputs), while the others are purely reading a number to select an input. Fixes: bc3fc5c05100 ("soc: mediatek: mmsys: add MT8365 support") Link: https://lore.kernel.org/r/20250212100012.33001-7-angelogioacchino.delregno@collabora.com Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit e4b236d373527fb1d64a3e1d388b4b21e27c8a70 Author: AngeloGioacchino Del Regno Date: Wed Feb 12 11:00:09 2025 +0100 soc: mediatek: mt8167-mmsys: Fix missing regval in all entries [ Upstream commit 5424793452d134ec1a173bd748c757144f25b1e2 ] The mmsys routing table for this SoC was effectively missing initialization of the val variable of struct mtk_mmsys_routes: this means that `val` was incorrectly initialized to zero, hence the registers were wrongly initialized. Add the required regval to all of the entries of the routing table for this SoC to fix display controller functionality. Fixes: 060f7875bd23 ("soc: mediatek: mmsys: Add support for MT8167 SoC") Link: https://lore.kernel.org/r/20250212100012.33001-6-angelogioacchino.delregno@collabora.com Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit 789bd8e651f8c24570721d243b117c93dfe64c02 Author: AngeloGioacchino Del Regno Date: Wed Feb 12 11:00:06 2025 +0100 soc: mediatek: mtk-mmsys: Fix MT8188 VDO1 DPI1 output selection [ Upstream commit 881d5094b138d002aab14922d41ec2058b9570c7 ] The VDO1_MERGE4 hardware (merge5 software component) should be set to enable output to DPI1_SEL by setting BIT(2) but, despite the intention being exactly that, this won't work because the declared register mask is wrong as it is set as GENMASK(1, 0). Register MERGE4_MOUT_EN in VDO1 has four used bits [3, 0] so fix the mask to reflect that. That, in turn, allows the mmsys driver to actually set BIT(2) in this register, fixing the MERGE4 output to DPI1 selection. Fixes: c0349314d5a0 ("soc: mediatek: Support MT8188 VDOSYS1 in mtk-mmsys") Link: https://lore.kernel.org/r/20250212100012.33001-3-angelogioacchino.delregno@collabora.com Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit 1c5ceca353089c7948a1064f220aa21e4f904096 Author: Yu Kuai Date: Thu Feb 27 20:06:45 2025 +0800 blk-throttle: fix lower bps rate by throtl_trim_slice() [ Upstream commit 29cb955934302a5da525db6b327c795572538426 ] The bio submission time may be a few jiffies more than the expected waiting time, due to 'extra_bytes' can't be divided in tg_within_bps_limit(), and also due to timer wakeup delay. In this case, adjust slice_start to jiffies will discard the extra wait time, causing lower rate than expected. Current in-tree code already covers deviation by rounddown(), but turns out it is not enough, because jiffies - slice_start can be a multiple of throtl_slice. For example, assume bps_limit is 1000bytes, 1 jiffes is 10ms, and slice is 20ms(2 jiffies), expected rate is 1000 / 1000 * 20 = 20 bytes per slice. If user issues two 21 bytes IO, then wait time will be 30ms for the first IO: bytes_allowed = 20, extra_bytes = 1; jiffy_wait = 1 + 2 = 3 jiffies and consider extra 1 jiffies by timer, throtl_trim_slice() will be called at: jiffies = 40ms slice_start = 0ms, slice_end= 40ms bytes_disp = 21 In this case, before the patch, real rate in the first two slices is 10.5 bytes per slice, and slice will be updated to: jiffies = 40ms slice_start = 40ms, slice_end = 60ms, bytes_disp = 0; Hence the second IO will have to wait another 30ms; With the patch, the real rate in the first slice is 20 bytes per slice, which is the same as expected, and slice will be updated: jiffies=40ms, slice_start = 20ms, slice_end = 60ms, bytes_disp = 1; And now, there is still 19 bytes allowed in the second slice, and the second IO will only have to wait 10ms; This problem will cause blktests throtl/001 failure in case of CONFIG_HZ_100=y, fix it by preserving one extra finished slice in throtl_trim_slice(). Fixes: e43473b7f223 ("blkio: Core implementation of throttle policy") Reported-by: Ming Lei Closes: https://lore.kernel.org/linux-block/20250222092823.210318-3-yukuai1@huaweicloud.com/ Reviewed-by: Ming Lei Acked-by: Tejun Heo Signed-off-by: Yu Kuai Link: https://lore.kernel.org/r/20250227120645.812815-1-yukuai1@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 0d5fc3caa115d68ff161ad4b5d0609c6b5e46ab1 Author: Ping-Ke Shih Date: Thu Feb 27 21:19:07 2025 +0800 wifi: rtw89: pci: correct ISR RDU bit for 8922AE [ Upstream commit 3218f5bd8e2e4abc156493f8121b8db53b49ee9e ] The interrupt status (ISR) bits of RX desc unavailable (RDU) for 8922AE are B_BE_RDU_CH1_INT_V1 and B_BE_RDU_CH0_INT_V1. With wrong bits, if it happens, driver can't recognize the situation and prompt a message. Fix the definition accordingly. Fixes: aa70f76120ee ("wifi: rtw89: pci: generalize interrupt status bits of interrupt handlers") Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250227131907.9864-1-pkshih@realtek.com Signed-off-by: Sasha Levin commit 1e67b2660849436a2f33f24f0ac4a4478d87b2dc Author: Ping-Ke Shih Date: Thu Feb 27 21:12:27 2025 +0800 wifi: rtw89: fw: correct debug message format in rtw89_build_txpwr_trk_tbl_from_elm() [ Upstream commit 88b46320fc9d915aa0c1c765db5ccd2db12fe92e ] The format should be "%08x". Fix the mistakes. Fixes: d60e73e5dd70 ("wifi: rtw89: fw: load TX power track tables from fw_element") Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250227131228.8457-4-pkshih@realtek.com Signed-off-by: Sasha Levin commit 20d60f73f67590606e1c3cb75639096980604e0a Author: Michael Walle Date: Fri Feb 21 10:14:47 2025 +0100 arm64: dts: ti: k3-j722s: fix pinctrl settings [ Upstream commit 06daad327d043c23bc1ab4cdb519f589094b9e98 ] It appears that pinctrl-single is misused on this SoC to control both the mux and the input and output and bias settings. This results in non-working pinctrl configurations for GPIOs within the device tree. This is what happens: (1) During startup the pinctrl settings are applied according to the device tree. I.e. the pin is configured as output and with pull-ups enabled. (2) During startup a device driver requests a GPIO. (3) pinctrl-single is applying the default GPIO setting according to the pinctrl-single,gpio-range property. This would work as expected if the pinctrl-single is only controlling the function mux, but it also controls the input/output buffer enable, the pull-up and pull-down settings etc (pinctrl-single,function-mask covers the entire pad setting instead of just the mux field). Remove the pinctrl-single,gpio-range property, so that no settings are applied during a gpio_request() call. Fixes: 5e5c50964e2e ("arm64: dts: ti: k3-j722s: Add gpio-ranges properties") Signed-off-by: Michael Walle Link: https://lore.kernel.org/r/20250221091447.595199-2-mwalle@kernel.org Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin commit b8d6bc800179659cc8efe3d6d261df16d89b1113 Author: Michael Walle Date: Fri Feb 21 10:14:46 2025 +0100 arm64: dts: ti: k3-am62p: fix pinctrl settings [ Upstream commit 33bab9d84e52188cf73c3573fd7cf3ec0e01d007 ] It appears that pinctrl-single is misused on this SoC to control both the mux and the input and output and bias settings. This results in non-working pinctrl configurations for GPIOs within the device tree. This is what happens: (1) During startup the pinctrl settings are applied according to the device tree. I.e. the pin is configured as output and with pull-ups enabled. (2) During startup a device driver requests a GPIO. (3) pinctrl-single is applying the default GPIO setting according to the pinctrl-single,gpio-range property. This would work as expected if the pinctrl-single is only controlling the function mux, but it also controls the input/output buffer enable, the pull-up and pull-down settings etc (pinctrl-single,function-mask covers the entire pad setting instead of just the mux field). Remove the pinctrl-single,gpio-range property, so that no settings are applied during a gpio_request() call. Fixes: d72d73a44c3c ("arm64: dts: ti: k3-am62p: Add gpio-ranges properties") Signed-off-by: Michael Walle Link: https://lore.kernel.org/r/20250221091447.595199-1-mwalle@kernel.org Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin commit b2bbcc5592641fd6fcbde2d546a4b3ec342bd43d Author: Francesco Dolcini Date: Thu Feb 6 16:39:11 2025 +0100 arm64: dts: ti: k3-am62p: Enable AUDIO_REFCLKx [ Upstream commit 6a02c9aa222ce0fff47f526686690f84b7a97f4e ] On AM62P-based SoCs the AUDIO_REFCLKx clocks can be used as an input to external peripherals when configured through CTRL_MMR, so add the clock nodes. Link: http://downloads.ti.com/tisci/esd/latest/5_soc_doc/am62px/clocks.html Signed-off-by: Francesco Dolcini Link: https://lore.kernel.org/r/20250206153911.414702-1-francesco@dolcini.it Signed-off-by: Vignesh Raghavendra Stable-dep-of: 33bab9d84e52 ("arm64: dts: ti: k3-am62p: fix pinctrl settings") Signed-off-by: Sasha Levin commit 0e0b27dbede5ed9f1e123ac638feac71ed73c240 Author: Tomas Glozar Date: Tue Mar 4 15:22:28 2025 +0100 tools/rv: Keep user LDFLAGS in build [ Upstream commit e82c78afa3d48f6512570e7d39258cd68e7bae0a ] rv, unlike rtla and perf, drops LDFLAGS supplied by the user and honors only EXTRA_LDFLAGS. This is inconsistent with both perf and rtla and can lead to all kinds of unexpected behavior. For example, on Fedora and RHEL, it causes rv to be build without PIE, unlike the aforementioned perf and rtla: $ file /usr/bin/{rv,rtla,perf} /usr/bin/rv: ELF 64-bit LSB executable, ... /usr/bin/rtla: ELF 64-bit LSB pie executable, ... /usr/bin/perf: ELF 64-bit LSB pie executable, ... Keep both LDFLAGS and EXTRA_LDFLAGS for the build. Cc: John Kacur Cc: Luis Goncalves Cc: Gabriele Monaco Link: https://lore.kernel.org/20250304142228.767658-1-tglozar@redhat.com Fixes: 012e4e77df73 ("tools/verification: Use tools/build makefiles on rv") Signed-off-by: Tomas Glozar Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit 397b14c3f8532274ff61ae08a18268d153e50334 Author: Gabriele Monaco Date: Tue Feb 18 13:31:06 2025 +0100 tracing: Fix DECLARE_TRACE_CONDITION [ Upstream commit 486df3466daf7b185f534a7408fa6f9dbb16dbeb ] Commit 287050d39026 ("tracing: Add TRACE_EVENT_CONDITIONAL()") adds macros to define conditional trace events (TRACE_EVENT_CONDITIONAL) and tracepoints (DECLARE_TRACE_CONDITION), but sets up functionality for direct use only for the former. Add preprocessor bits in define_trace.h to allow usage of DECLARE_TRACE_CONDITION just like DECLARE_TRACE. Cc: Mathieu Desnoyers Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Juri Lelli Link: https://lore.kernel.org/20250218123121.253551-2-gmonaco@redhat.com Fixes: 287050d39026 ("tracing: Add TRACE_EVENT_CONDITIONAL()") Link: https://lore.kernel.org/linux-trace-kernel/20250128111926.303093-1-gmonaco@redhat.com Reviewed-by: Masami Hiramatsu (Google) Signed-off-by: Gabriele Monaco Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit bc3a9788961631359527763d7e1fcf26554c7cb1 Author: Su Yue Date: Mon Mar 3 11:39:18 2025 +0800 md/md-bitmap: fix wrong bitmap_limit for clustermd when write sb [ Upstream commit 6130825f34d41718c98a9b1504a79a23e379701e ] In clustermd, separate write-intent-bitmaps are used for each cluster node: 0 4k 8k 12k ------------------------------------------------------------------- | idle | md super | bm super [0] + bits | | bm bits[0, contd] | bm super[1] + bits | bm bits[1, contd] | | bm super[2] + bits | bm bits [2, contd] | bm super[3] + bits | | bm bits [3, contd] | | | So in node 1, pg_index in __write_sb_page() could equal to bitmap->storage.file_pages. Then bitmap_limit will be calculated to 0. md_super_write() will be called with 0 size. That means the first 4k sb area of node 1 will never be updated through filemap_write_page(). This bug causes hang of mdadm/clustermd_tests/01r1_Grow_resize. Here use (pg_index % bitmap->storage.file_pages) to make calculation of bitmap_limit correct. Fixes: ab99a87542f1 ("md/md-bitmap: fix writing non bitmap pages") Signed-off-by: Su Yue Reviewed-by: Heming Zhao Link: https://lore.kernel.org/linux-raid/20250303033918.32136-1-glass.su@suse.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 8a0adf3d778c4a0893c6d34a9e1b0082a6f1c495 Author: Yu Kuai Date: Thu Feb 27 20:16:57 2025 +0800 md/raid1,raid10: don't ignore IO flags [ Upstream commit e879a0d9cb086c8e52ce6c04e5bfa63825a6213c ] If blk-wbt is enabled by default, it's found that raid write performance is quite bad because all IO are throttled by wbt of underlying disks, due to flag REQ_IDLE is ignored. And turns out this behaviour exist since blk-wbt is introduced. Other than REQ_IDLE, other flags should not be ignored as well, for example REQ_META can be set for filesystems, clearing it can cause priority reverse problems; And REQ_NOWAIT should not be cleared as well, because io will wait instead of failing directly in underlying disks. Fix those problems by keep IO flags from master bio. Fises: f51d46d0e7cb ("md: add support for REQ_NOWAIT") Fixes: e34cbd307477 ("blk-wbt: add general throttling mechanism") Fixes: 5404bc7a87b9 ("[PATCH] Allow file systems to differentiate between data and meta reads") Link: https://lore.kernel.org/linux-raid/20250227121657.832356-1-yukuai1@huaweicloud.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 5462544ccbad3fc938a71b01fa5bd3a0dc2b750a Author: Yu Kuai Date: Thu Feb 20 20:43:48 2025 +0800 md: fix mddev uaf while iterating all_mddevs list [ Upstream commit 8542870237c3a48ff049b6c5df5f50c8728284fa ] While iterating all_mddevs list from md_notify_reboot() and md_exit(), list_for_each_entry_safe is used, and this can race with deletint the next mddev, causing UAF: t1: spin_lock //list_for_each_entry_safe(mddev, n, ...) mddev_get(mddev1) // assume mddev2 is the next entry spin_unlock t2: //remove mddev2 ... mddev_free spin_lock list_del spin_unlock kfree(mddev2) mddev_put(mddev1) spin_lock //continue dereference mddev2->all_mddevs The old helper for_each_mddev() actually grab the reference of mddev2 while holding the lock, to prevent from being freed. This problem can be fixed the same way, however, the code will be complex. Hence switch to use list_for_each_entry, in this case mddev_put() can free the mddev1 and it's not safe as well. Refer to md_seq_show(), also factor out a helper mddev_put_locked() to fix this problem. Cc: Christoph Hellwig Link: https://lore.kernel.org/linux-raid/20250220124348.845222-1-yukuai1@huaweicloud.com Fixes: f26514342255 ("md: stop using for_each_mddev in md_notify_reboot") Fixes: 16648bac862f ("md: stop using for_each_mddev in md_exit") Reported-and-tested-by: Guillaume Morin Closes: https://lore.kernel.org/all/Z7Y0SURoA8xwg7vn@bender.morinfr.org/ Signed-off-by: Yu Kuai Reviewed-by: Christoph Hellwig Signed-off-by: Sasha Levin commit ab2ad3be21305c6863cebf2b4076574e41054f3d Author: Chao Yu Date: Mon Mar 3 11:25:00 2025 +0800 f2fs: fix to call f2fs_recover_quota_end() correctly [ Upstream commit d8f5b91d77a651705d3f76ba0ebd5d7981533333 ] f2fs_recover_quota_begin() and f2fs_recover_quota_end() should be called in pair, there is some cases we may skip calling f2fs_recover_quota_end(), fix it. Fixes: e1bb7d3d9cbf ("f2fs: fix to recover quota data correctly") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 7215cf8ef54bdc9082dffac4662416d54961e258 Author: Chao Yu Date: Mon Mar 3 11:23:29 2025 +0800 f2fs: fix potential deadloop in prepare_compress_overwrite() [ Upstream commit 3147ee567dd9004a49826ddeaf0a4b12865d4409 ] Jan Prusakowski reported a kernel hang issue as below: When running xfstests on linux-next kernel (6.14.0-rc3, 6.12) I encountered a problem in generic/475 test where fsstress process gets blocked in __f2fs_write_data_pages() and the test hangs. The options I used are: MKFS_OPTIONS -- -O compression -O extra_attr -O project_quota -O quota /dev/vdc MOUNT_OPTIONS -- -o acl,user_xattr -o discard,compress_extension=* /dev/vdc /vdc INFO: task kworker/u8:0:11 blocked for more than 122 seconds. Not tainted 6.14.0-rc3-xfstests-lockdep #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u8:0 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208160 flags:0x00004000 Workqueue: writeback wb_workfn (flush-253:0) Call Trace: __schedule+0x309/0x8e0 schedule+0x3a/0x100 schedule_preempt_disabled+0x15/0x30 __mutex_lock+0x59a/0xdb0 __f2fs_write_data_pages+0x3ac/0x400 do_writepages+0xe8/0x290 __writeback_single_inode+0x5c/0x360 writeback_sb_inodes+0x22f/0x570 wb_writeback+0xb0/0x410 wb_do_writeback+0x47/0x2f0 wb_workfn+0x5a/0x1c0 process_one_work+0x223/0x5b0 worker_thread+0x1d5/0x3c0 kthread+0xfd/0x230 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30 The root cause is: once generic/475 starts toload error table to dm device, f2fs_prepare_compress_overwrite() will loop reading compressed cluster pages due to IO error, meanwhile it has held .writepages lock, it can block all other writeback tasks. Let's fix this issue w/ below changes: - add f2fs_handle_page_eio() in prepare_compress_overwrite() to detect IO error. - detect cp_error earler in f2fs_read_multi_pages(). Fixes: 4c8ff7095bef ("f2fs: support data compression") Reported-by: Jan Prusakowski Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 57442fd1b9b415437ed744762cb98aefec475221 Author: Stefan Eichenberger Date: Mon Feb 17 15:46:04 2025 +0100 arm64: dts: ti: k3-am62-verdin-dahlia: add Microphone Jack to sound card [ Upstream commit 7139df64e7c13c079b754476355c62b490213055 ] The simple-audio-card's microphone widget currently connects to the headphone jack. Routing the microphone input to the microphone jack allows for independent operation of the microphone and headphones. This resolves the following boot-time kernel log message, which indicated a conflict when the microphone and headphone functions were not separated: debugfs: File 'Headphone Jack' in directory 'dapm' already present! Fixes: f5bf894c865b ("arm64: dts: ti: verdin-am62: dahlia: add sound card") Signed-off-by: Stefan Eichenberger Reviewed-by: Francesco Dolcini Reviewed-by: Jai Luthra Link: https://lore.kernel.org/r/20250217144643.178222-1-eichest@gmail.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin commit 542c4280b726985cc195ed722aed6ac20dbbf27d Author: Leo Stone Date: Thu Feb 27 23:54:20 2025 +0800 f2fs: add check for deleted inode [ Upstream commit 81edb983b3f5d6900d3e337b9af7b1bec4bef0f2 ] The syzbot reproducer mounts a f2fs image, then tries to unlink an existing file. However, the unlinked file already has a link count of 0 when it is read for the first time in do_read_inode(). Add a check to sanity_check_inode() for i_nlink == 0. [Chao Yu: rebase the code and fix orphan inode recovery issue] Reported-by: syzbot+b01a36acd7007e273a83@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b01a36acd7007e273a83 Fixes: 39a53e0ce0df ("f2fs: add superblock and major in-memory structure") Signed-off-by: Leo Stone Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit be3230dc67fd2868b0c433c593821bb7814ed38f Author: Chao Yu Date: Mon Feb 24 14:20:07 2025 +0800 f2fs: fix to set .discard_granularity correctly [ Upstream commit 1b60b23975d6d81703826e3797738e471c3009c6 ] commit 4f993264fe29 ("f2fs: introduce discard_unit mount option") introduced a bug, when we enable discard_unit=section option, it will set .discard_granularity to BLKS_PER_SEC(), however discard granularity only supports [1, 512], once section size is not equal to segment size, it will cause issue_discard_thread() in DPOLICY_BG mode will not select discard entry w/ any granularity to issue. Fixes: 4f993264fe29 ("f2fs: introduce discard_unit mount option") Reviewed-by: Daeho Jeong Signed-off-by: Yohan Joung Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 35b33ba76765ce9e72949d957f3cf1feafd2955c Author: Manivannan Sadhasivam Date: Tue Feb 25 11:04:46 2025 +0530 wifi: ath12k: Clear affinity hint before calling ath12k_pci_free_irq() in error path [ Upstream commit b43b1e2c52db77c872bd60d30cdcc72c47df70c7 ] If a shared IRQ is used by the driver due to platform limitation, then the IRQ affinity hint is set right after the allocation of IRQ vectors in ath12k_pci_msi_alloc(). This does no harm unless one of the functions requesting the IRQ fails and attempt to free the IRQ. This may end up with a warning from the IRQ core that is expecting the affinity hint to be cleared before freeing the IRQ: kernel/irq/manage.c: /* make sure affinity_hint is cleaned up */ if (WARN_ON_ONCE(desc->affinity_hint)) desc->affinity_hint = NULL; So to fix this issue, clear the IRQ affinity hint before calling ath12k_pci_free_irq() in the error path. The affinity will be cleared once again further down the error path due to code organization, but that does no harm. Fixes: a3012f206d07 ("wifi: ath12k: set IRQ affinity to CPU0 in case of one MSI vector") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20250225053447.16824-3-manivannan.sadhasivam@linaro.org Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 3fc42cfcc6e336f25dee79b34e57c4a63cd652a5 Author: Manivannan Sadhasivam Date: Tue Feb 25 11:04:45 2025 +0530 wifi: ath11k: Clear affinity hint before calling ath11k_pcic_free_irq() in error path [ Upstream commit 68410c5bd381a81bcc92b808e7dc4e6b9ed25d11 ] If a shared IRQ is used by the driver due to platform limitation, then the IRQ affinity hint is set right after the allocation of IRQ vectors in ath11k_pci_alloc_msi(). This does no harm unless one of the functions requesting the IRQ fails and attempt to free the IRQ. This results in the below warning: WARNING: CPU: 7 PID: 349 at kernel/irq/manage.c:1929 free_irq+0x278/0x29c Call trace: free_irq+0x278/0x29c ath11k_pcic_free_irq+0x70/0x10c [ath11k] ath11k_pci_probe+0x800/0x820 [ath11k_pci] local_pci_probe+0x40/0xbc The warning is due to not clearing the affinity hint before freeing the IRQs. So to fix this issue, clear the IRQ affinity hint before calling ath11k_pcic_free_irq() in the error path. The affinity will be cleared once again further down the error path due to code organization, but that does no harm. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-05266-QCAHSTSWPLZ_V2_TO_X86-1 Cc: Baochen Qiang Fixes: 39564b475ac5 ("wifi: ath11k: fix boot failure with one MSI vector") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20250225053447.16824-2-manivannan.sadhasivam@linaro.org Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 60e93fa7c6f71d992d433cdbebd03881559222a0 Author: Louis-Alexis Eyraud Date: Fri Feb 21 09:49:52 2025 +0100 arm64: dts: mediatek: mt8390-genio-common: Fix duplicated regulator name [ Upstream commit 18aa138d125dd56838edbdb8c813e91e5e95d496 ] usb_p2_vbus regulator has the same regulator-name property value as sdio_fixed_3v3, so change it to avoid this. Fixes: a4fd1943bf9b ("arm64: dts: mediatek: mt8390-genio-700-evk: update regulator names") Signed-off-by: Louis-Alexis Eyraud Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20250221-fix-mtk8390-genio-common-dup-regulator-name-v1-1-92f7b9f7a414@collabora.com Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit 29101147f1a3688fd7b8987cb8f9a6c166ab959a Author: Louis-Alexis Eyraud Date: Thu Feb 6 11:38:10 2025 +0100 arm64: dts: mediatek: mt8390-genio-700-evk: Move common parts to dtsi [ Upstream commit 73955991b8fb959eb3d8b5307255810e4fb37b24 ] In preparation for introducing the Genio 510 EVK board support, split mt8390-genio-700-evk.dts file in two to create mt8390-genio-common.dtsi file, containing common definitions for both boards. Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Louis-Alexis Eyraud Link: https://lore.kernel.org/r/20250206-dts_mt8370-genio-510-v3-3-5ca5c3257a4c@collabora.com Signed-off-by: AngeloGioacchino Del Regno Stable-dep-of: 18aa138d125d ("arm64: dts: mediatek: mt8390-genio-common: Fix duplicated regulator name") Signed-off-by: Sasha Levin commit 1498a4348f67ace77382e6163a85a8a4ecbc7423 Author: Ahmad Fatoum Date: Mon Jan 6 17:06:37 2025 +0100 arm64: dts: imx8mp-skov: operate CPU at 850 mV by default [ Upstream commit 3d8ffe5702b24a0bd9d97446c0740110325f379b ] The Skov i.MX8MP boards are passively cooled and heatsink is specced for continuous operation at 1.2 GHz only. Short bouts of 1.6 GHz are ok, but these should be invoked intentionally, not as part of suspend/resume cycles. Therefore, configure RUN frequency as 850 mV and remove the higher voltage operating points from those permissible for suspend. Fixes: 6d382d51d979 ("arm64: dts: freescale: Add SKOV IMX8MP CPU revB board") Signed-off-by: Ahmad Fatoum Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit b04f6aca0f1d7b0b94a89031d008447db1259766 Author: Ahmad Fatoum Date: Mon Jan 6 17:06:36 2025 +0100 arm64: dts: imx8mp-skov: correct PMIC board limits [ Upstream commit d19a6f79961df1c29d8b2ac93b01b96788f209fa ] The PMIC voltage constraints in the device tree currently describe the permissible range of the PMIC. This is unnecessary as this information already exists in the driver and wrong as it doesn't account for board-specific constraints, e.g. a 2.1V on VDD_SOC would fry the SoC and a maximum voltage of 3.4V on the VDD_3V3 rail may be unexpected across the board. Fix this by adjusting constraints to reflect the board limits. Fixes: 6d382d51d979 ("arm64: dts: freescale: Add SKOV IMX8MP CPU revB board") Signed-off-by: Ahmad Fatoum Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 7f753cdef42971b60eeb3085bd053796eaaf0c5a Author: Baochen Qiang Date: Mon Dec 9 10:41:46 2024 +0800 wifi: ath12k: use link specific bss_conf as well in ath12k_mac_vif_cache_flush() [ Upstream commit 11d963d44c77261d6a948f3745bbd678eef4b83b ] Commit 3952657848c0 ("wifi: ath12k: Use mac80211 vif's link_conf instead of bss_conf") aims at, where applicable, replacing all usage of vif's bss_conf with link specific bss_conff, but missed one instance in ath12k_mac_vif_cache_flush(). This results in wrong configurations passed to ath12k_mac_bss_info_changed() when the link in question is not the default link. Change to use the link specific bss_conf to fix this issue. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0-03427-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.15378.4 Fixes: 3952657848c0 ("wifi: ath12k: Use mac80211 vif's link_conf instead of bss_conf") Signed-off-by: Baochen Qiang Link: https://patch.msgid.link/20241209024146.3282-1-quic_bqiang@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit aa7cf8d670acbf4032593c6225b966669d9c1206 Author: Hrushikesh Salunke Date: Thu Jan 16 18:27:26 2025 +0530 arm64: dts: ti: k3-j722s-evm: Fix USB2.0_MUX_SEL to select Type-C [ Upstream commit bc8d9e6b5821c40ab5dd3a81e096cb114939de50 ] J722S SOC has two usb controllers USB0 and USB1. USB0 is brought out on the EVM as a stacked USB connector which has one Type-A and one Type-C port. These Type-A and Type-C ports are connected to MUX so only one of them can be enabled at a time. Commit under Fixes, tries to enable the USB0 instance of USB to interface with the Type-C port via the USB hub, by configuring the USB2.0_MUX_SEL to GPIO_ACTIVE_HIGH. But it is observed on J722S-EVM that Type-A port is enabled instead of Type-C port. Fix this by setting USB2.0_MUX_SEL to GPIO_ACTIVE_LOW to enable Type-C port. Fixes: 485705df5d5f ("arm64: dts: ti: k3-j722s: Enable PCIe and USB support on J722S-EVM") Signed-off-by: Hrushikesh Salunke Reviewed-by: Roger Quadros Link: https://lore.kernel.org/r/20250116125726.2549489-1-h-salunke@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin commit 5e9d4c2b39cca9007a61672e38ebd950ef1ddc4d Author: Sudeep Holla Date: Sun Feb 23 21:39:09 2025 +0000 firmware: arm_ffa: Skip the first/partition ID when parsing vCPU list [ Upstream commit c67c2332f8c80b03990914dfb66950c8d2fb87d8 ] The FF-A notification id list received in response to the call FFA_NOTIFICATION_INFO_GET is encoded as: partition ID followed by 0 or more vCPU ID. The count includes all of them. Fix the issue by skipping the first/partition ID so that only the list of vCPU IDs are processed correctly for a given partition ID. The first/ partition ID is read before the start of the loop. Fixes: 3522be48d82b ("firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interface") Reported-by: Andrei Homescu Message-Id: <20250223213909.1197786-1-sudeep.holla@arm.com> Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit cf08b70d8eb56674a4ee2b2826ad5885a18f4620 Author: Geert Uytterhoeven Date: Tue Oct 8 11:14:21 2024 +0200 arm64: dts: renesas: r8a77990: Re-add voltages to OPP table [ Upstream commit c193f877770291f30d1e00bc6f2bb0757fe7a532 ] When CONFIG_ENERGY_MODEL=y: cpu cpu0: EM: invalid perf. state: -22 When removing the (incorrect) voltages from the Operating Points Parameters tables, it was assumed they were optional, and unused, when none of the CPU nodes is tied to a regulator using the "cpu-supply" property. This assumption turned out to be incorrect, causing the reported error message. Fix this by re-adding the (correct) voltages. Note that because all voltages are identical, all operating points are considered to have the same efficiency, and the energy model always picks the one with the highest clock rate. Reported-by: Renesas Test Team via Kuninori Morimoto Fixes: fb76b0fae3ca8803 ("arm64: dts: renesas: r8a77990: Remove bogus voltages from OPP table") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/80890bc244670bc3e8d6fc89fb2c3cb23e7025f5.1728377971.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit 3b639fe66528e1606254fac85ec2208b046bd200 Author: Geert Uytterhoeven Date: Tue Oct 8 11:14:20 2024 +0200 arm64: dts: renesas: r8a774c0: Re-add voltages to OPP table [ Upstream commit ea34dd0f029f4a30c055ddb6daaf7a6f3bee21ed ] When CONFIG_ENERGY_MODEL=y: cpu cpu0: EM: invalid perf. state: -22 When removing the (incorrect) voltages from the Operating Points Parameters tables, it was assumed they were optional, and unused, when none of the CPU nodes is tied to a regulator using the "cpu-supply" property. This assumption turned out to be incorrect, causing the reported error message. Fix this by re-adding the (correct) voltages. Note that because all voltages are identical, all operating points are considered to have the same efficiency, and the energy model always picks the one with the highest clock rate. Reported-by: Renesas Test Team via Kuninori Morimoto Fixes: 554edc3e9239bb81 ("arm64: dts: renesas: r8a774c0: Remove bogus voltages from OPP table") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/2046da75f3db95b62f86c0482063c4d04c2b47d5.1728377971.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit c44f8d32abdf76d5eb02e75faaa77f52149807c8 Author: Sudeep Holla Date: Fri Feb 21 09:56:32 2025 +0000 firmware: arm_ffa: Explicitly cast return value from NOTIFICATION_INFO_GET [ Upstream commit 3e282f41585c4dd49b688bd6395fd6f21a57c9f7 ] The return value ret.a2 is of type unsigned long and FFA_RET_NO_DATA is a negative value. Since the return value from the firmware can be just 32-bit even on 64-bit systems as FFA specification mentions it as int32 error code in w0 register, explicitly casting to s32 ensures correct sign interpretation when comparing against a signed error code FFA_RET_NO_DATA. Without casting, comparison between unsigned long and a negative constant could lead to unintended results due to type promotions. Fixes: 3522be48d82b ("firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interface") Reported-by: Andrei Homescu Message-Id: <20250221095633.506678-2-sudeep.holla@arm.com> Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 62dbf901a528c83d4db8028b704471c05a96788b Author: Sudeep Holla Date: Fri Feb 21 09:56:31 2025 +0000 firmware: arm_ffa: Explicitly cast return value from FFA_VERSION before comparison [ Upstream commit cecf6a504137aa238d768ae440a1f6488cb2f436 ] The return value ver.a0 is unsigned long type and FFA_RET_NOT_SUPPORTED is a negative value. Since the return value from the firmware can be just 32-bit even on 64-bit systems as FFA specification mentions it as int32 error code in w0 register, explicitly casting to s32 ensures correct sign interpretation when comparing against a signed error code FFA_RET_NOT_SUPPORTED. Without casting, comparison between unsigned long and a negative constant could lead to unintended results due to type promotions. Fixes: 3bbfe9871005 ("firmware: arm_ffa: Add initial Arm FFA driver support") Reported-by: Andrei Homescu Message-Id: <20250221095633.506678-1-sudeep.holla@arm.com> Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit c1827363a0fd60a534eb42d9ec90263ca341a943 Author: Asahi Lina Date: Wed Feb 19 10:13:53 2025 +0100 iommu/io-pgtable-dart: Only set subpage protection disable for DART 1 [ Upstream commit 5276c1e07679c44ee021e88045bbb5190831b328 ] Subpage protection can't be disabled on t6000-style darts, as such the disable flag no longer applies, and probably even affects something else. Fixes: dc09fe1c5edd ("iommu/io-pgtable-dart: Add DART PTE support for t6000") Signed-off-by: Asahi Lina Signed-off-by: Sasha Finkelstein Reviewed-by: Sven Peter Link: https://lore.kernel.org/r/20250219-dart2-no-sp-disable-v1-1-9f324cfa4e70@gmail.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 7a59fa699da9e00f575c7a485040672104682cc3 Author: Leon Romanovsky Date: Wed Feb 19 15:50:57 2025 +0200 xfrm: delay initialization of offload path till its actually requested [ Upstream commit 585b64f5a62089ef42889b106b063d089feb6599 ] XFRM offload path is probed even if offload isn't needed at all. Let's make sure that x->type_offload pointer stays NULL for such path to reduce ambiguity. Fixes: 9d389d7f84bb ("xfrm: Add a xfrm type offload.") Signed-off-by: Leon Romanovsky Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 70f63c5ec5c4cff9ae139ad132930d1d8281a1e9 Author: Dmitry Antipov Date: Thu Feb 13 12:50:06 2025 +0300 wifi: rtw89: rtw8852b{t}: fix TSSI debug timestamps [ Upstream commit bfc8e71ef6b7913f0129aff47951cab73a175259 ] Since the vendor driver is claimed to measure 'tssi_alimk_time' of 'struct rtw89_tssi_info' in microseconds, adjust rtw8852b{t}-specific '_tssi_alimentk()' to not mess the former with nanoseconds and print both per-call and accumulated times. Compile tested only. Fixes: 7f18a70d7b4d ("wifi: rtw89: 8852b: rfk: add TSSI") Signed-off-by: Dmitry Antipov Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250213095006.1308810-1-dmantipov@yandex.ru Signed-off-by: Sasha Levin commit 6de55841999d199ab9f6374fe891f0fa5f7762b2 Author: Nicolas Escande Date: Fri Jan 24 12:33:31 2025 +0100 wifi: ath12k: Add missing htt_metadata flag in ath12k_dp_tx() [ Upstream commit af1c6007a64e78b729eb5a8d149637a820077bee ] When AP-VLAN support was added, the HTT_TCL_META_DATA_VALID_HTT flag was not added to the tx_info's meta_data_flags. Without this flag the firmware seems to reject all the broadcast (ap-vlan) frames. So add the flag, just as ath11k did it in the downstream QSDK project[1]. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Fixes: 26dd8ccdba4d ("wifi: ath12k: dynamic VLAN support") Signed-off-by: Nicolas Escande Link: https://git.codelinaro.org/clo/qsdk/oss/system/feeds/wlan-open/-/blob/win.wlan_host_opensource.3.0.r24/patches/ath11k/207-ath11k-Add-support-for-dynamic-vlan.patch # [1] Link: https://patch.msgid.link/20250124113331.93476-1-nico.escande@gmail.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit f605bc3e162f5c6faa9bd3602ce496053d06a4bb Author: Vasiliy Kovalev Date: Tue Dec 24 17:49:14 2024 +0300 jfs: add check read-only before truncation in jfs_truncate_nolock() [ Upstream commit b5799dd77054c1ec49b0088b006c9908e256843b ] Added a check for "read-only" mode in the `jfs_truncate_nolock` function to avoid errors related to writing to a read-only filesystem. Call stack: block_write_begin() { jfs_write_failed() { jfs_truncate() { jfs_truncate_nolock() { txEnd() { ... log = JFS_SBI(tblk->sb)->log; // (log == NULL) If the `isReadOnly(ip)` condition is triggered in `jfs_truncate_nolock`, the function execution will stop, and no further data modification will occur. Instead, the `xtTruncate` function will be called with the "COMMIT_WMAP" flag, preventing modifications in "read-only" mode. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+4e89b5368baba8324e07@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=4e89b5368baba8324e07 Signed-off-by: Vasiliy Kovalev Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit 15469c408af2d7a52fb186a92f2f091b0f13b1fb Author: Vasiliy Kovalev Date: Tue Dec 24 17:49:13 2024 +0300 jfs: add check read-only before txBeginAnon() call [ Upstream commit 0176e69743ecc02961f2ae1ea42439cd2bf9ed58 ] Added a read-only check before calling `txBeginAnon` in `extAlloc` and `extRecord`. This prevents modification attempts on a read-only mounted filesystem, avoiding potential errors or crashes. Call trace: txBeginAnon+0xac/0x154 extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78 jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248 __block_write_begin_int+0x580/0x166c fs/buffer.c:2128 __block_write_begin fs/buffer.c:2177 [inline] block_write_begin+0x98/0x11c fs/buffer.c:2236 jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+4e89b5368baba8324e07@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=4e89b5368baba8324e07 Signed-off-by: Vasiliy Kovalev Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit 8987891c4653874d5e3f5d11f063912f4e0b58eb Author: Dmitry Antipov Date: Thu Nov 7 08:42:28 2024 +0300 jfs: reject on-disk inodes of an unsupported type [ Upstream commit 8c3f9a70d2d4dd6c640afe294b05c6a0a45434d9 ] Syzbot has reported the following BUG: kernel BUG at fs/inode.c:668! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 3 UID: 0 PID: 139 Comm: jfsCommit Not tainted 6.12.0-rc4-syzkaller-00085-g4e46774408d9 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 RIP: 0010:clear_inode+0x168/0x190 Code: 4c 89 f7 e8 ba fe e5 ff e9 61 ff ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 7c c1 4c 89 f7 e8 90 ff e5 ff eb b7 0b e8 01 5d 7f ff 90 0f 0b e8 f9 5c 7f ff 90 0f 0b e8 f1 5c 7f RSP: 0018:ffffc900027dfae8 EFLAGS: 00010093 RAX: ffffffff82157a87 RBX: 0000000000000001 RCX: ffff888104d4b980 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000 RBP: ffffc900027dfc90 R08: ffffffff82157977 R09: fffff520004fbf38 R10: dffffc0000000000 R11: fffff520004fbf38 R12: dffffc0000000000 R13: ffff88811315bc00 R14: ffff88811315bda8 R15: ffff88811315bb80 FS: 0000000000000000(0000) GS:ffff888135f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005565222e0578 CR3: 0000000026ef0000 CR4: 00000000000006f0 Call Trace: ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? clear_inode+0x168/0x190 ? do_error_trap+0x1dc/0x2c0 ? clear_inode+0x168/0x190 ? __pfx_do_error_trap+0x10/0x10 ? report_bug+0x3cd/0x500 ? handle_invalid_op+0x34/0x40 ? clear_inode+0x168/0x190 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? clear_inode+0x57/0x190 ? clear_inode+0x167/0x190 ? clear_inode+0x168/0x190 ? clear_inode+0x167/0x190 jfs_evict_inode+0xb5/0x440 ? __pfx_jfs_evict_inode+0x10/0x10 evict+0x4ea/0x9b0 ? __pfx_evict+0x10/0x10 ? iput+0x713/0xa50 txUpdateMap+0x931/0xb10 ? __pfx_txUpdateMap+0x10/0x10 jfs_lazycommit+0x49a/0xb80 ? _raw_spin_unlock_irqrestore+0x8f/0x140 ? lockdep_hardirqs_on+0x99/0x150 ? __pfx_jfs_lazycommit+0x10/0x10 ? __pfx_default_wake_function+0x10/0x10 ? __kthread_parkme+0x169/0x1d0 ? __pfx_jfs_lazycommit+0x10/0x10 kthread+0x2f2/0x390 ? __pfx_jfs_lazycommit+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x4d/0x80 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 This happens when 'clear_inode()' makes an attempt to finalize an underlying JFS inode of unknown type. According to JFS layout description from https://jfs.sourceforge.net/project/pub/jfslayout.pdf, inode types from 5 to 15 are reserved for future extensions and should not be encountered on a valid filesystem. So add an extra check for valid inode type in 'copy_from_dinode()'. Reported-by: syzbot+ac2116e48989e84a2893@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ac2116e48989e84a2893 Fixes: 79ac5a46c5c1 ("jfs_lookup(): don't bother with . or ..") Signed-off-by: Dmitry Antipov Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit c29d42b2f37a0eedf6dc3004623357959a8ff474 Author: Robin van der Gracht Date: Mon Jan 27 13:16:44 2025 +0100 can: rockchip_canfd: rkcanfd_chip_fifo_setup(): remove duplicated setup of RX FIFO [ Upstream commit d9e1cc087a55286fe028e0f078159b30d7da90bd ] The rockchip_canfd driver doesn't make use of the TXE FIFO. Although the comment states that the TXE FIFO is setup, it's actually a setup of the RX FIFO. The regular setup of the RX FIFO follows. Remove the duplicated setup of the RX FIFO. Fixes: ff60bfbaf67f ("can: rockchip_canfd: add driver for Rockchip CAN-FD controller") Signed-off-by: Robin van der Gracht Link: https://patch.msgid.link/20250219-rk3568-canfd-v1-1-453869358c72@pengutronix.de Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit d8a0897c7cd0950301c1b326c1c7963370fd3aec Author: Bart Van Assche Date: Mon Feb 10 12:39:36 2025 -0800 scsi: mpt3sas: Fix a locking bug in an error path [ Upstream commit 38afcf0660f5c408ba6c2f0ba3a9729e0102fe2e ] Call mutex_unlock(&ioc->hostdiag_unlock_mutex) once from error paths instead of twice. This patch fixes the following Clang -Wthread-safety errors: drivers/scsi/mpt3sas/mpt3sas_base.c:8085:2: error: mutex 'ioc->hostdiag_unlock_mutex' is not held on every path through here [-Werror,-Wthread-safety-analysis] 8085 | pci_cfg_access_unlock(ioc->pdev); | ^ drivers/scsi/mpt3sas/mpt3sas_base.c:8019:2: note: mutex acquired here 8019 | mutex_lock(&ioc->hostdiag_unlock_mutex); | ^ ./include/linux/mutex.h:171:26: note: expanded from macro 'mutex_lock' 171 | #define mutex_lock(lock) mutex_lock_nested(lock, 0) | ^ drivers/scsi/mpt3sas/mpt3sas_base.c:8085:2: error: mutex 'ioc->hostdiag_unlock_mutex' is not held on every path through here [-Werror,-Wthread-safety-analysis] 8085 | pci_cfg_access_unlock(ioc->pdev); | ^ drivers/scsi/mpt3sas/mpt3sas_base.c:8019:2: note: mutex acquired here 8019 | mutex_lock(&ioc->hostdiag_unlock_mutex); | ^ ./include/linux/mutex.h:171:26: note: expanded from macro 'mutex_lock' 171 | #define mutex_lock(lock) mutex_lock_nested(lock, 0) | ^ drivers/scsi/mpt3sas/mpt3sas_base.c:8087:2: error: releasing mutex 'ioc->hostdiag_unlock_mutex' that was not held [-Werror,-Wthread-safety-analysis] 8087 | mutex_unlock(&ioc->hostdiag_unlock_mutex); | ^ Cc: Ranjan Kumar Fixes: c0767560b012 ("scsi: mpt3sas: Reload SBR without rebooting HBA") Signed-off-by: Bart Van Assche Link: https://lore.kernel.org/r/20250210203936.2946494-3-bvanassche@acm.org Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit b2bf6a2d0962801a915827dc082a24fa63b3dd60 Author: Bart Van Assche Date: Mon Feb 10 12:39:35 2025 -0800 scsi: mpi3mr: Fix locking in an error path [ Upstream commit c733741ae1c3a5927f72664b0d760d5f4c14f96b ] Make all error paths unlock rioc->bsg_cmds.mutex. This patch fixes the following Clang -Wthread-safety errors: drivers/scsi/mpi3mr/mpi3mr_app.c:2835:1: error: mutex 'mrioc->bsg_cmds.mutex' is not held on every path through here [-Werror,-Wthread-safety-analysis] 2835 | } | ^ drivers/scsi/mpi3mr/mpi3mr_app.c:2332:6: note: mutex acquired here 2332 | if (mutex_lock_interruptible(&mrioc->bsg_cmds.mutex)) | ^ ./include/linux/mutex.h:172:40: note: expanded from macro 'mutex_lock_interruptible' 172 | #define mutex_lock_interruptible(lock) mutex_lock_interruptible_nested(lock, 0) | ^ Cc: Sathya Prakash Fixes: fb231d7deffb ("scsi: mpi3mr: Support for preallocation of SGL BSG data buffers part-2") Signed-off-by: Bart Van Assche Link: https://lore.kernel.org/r/20250210203936.2946494-2-bvanassche@acm.org Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 0b46161b0c2643a1b4998d4f933c5f969736d605 Author: Macpaul Lin Date: Mon Feb 17 19:37:36 2025 +0800 arm64: dts: mediatek: mt6359: fix dtbs_check error for audio-codec [ Upstream commit 76b35f59bbe66d3eda8a98021bc01f9200131f09 ] This change fixes these dtbs_check errors for audio-codec: 1. pmic: 'mt6359codec' does not match any of the regexes: 'pinctrl-[0-9]+' - Replace device node name to generic 'audio-codec' 2. pmic: regulators: 'compatible' is a required property - Add 'mediatek,mt6359-codec' to compatible. Fixes: 3b7d143be4b7 ("arm64: dts: mt6359: add PMIC MT6359 related nodes") Signed-off-by: Macpaul Lin Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20250217113736.1867808-1-macpaul.lin@mediatek.com Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit c062f008c98f5a1a19d78c513649f7dce4eaedfc Author: Sudeep Holla Date: Mon Feb 17 15:38:49 2025 +0000 firmware: arm_ffa: Unregister the FF-A devices when cleaning up the partitions [ Upstream commit 46dcd68aaccac0812c12ec3f4e59c8963e2760ad ] Both the FF-A core and the bus were in a single module before the commit 18c250bd7ed0 ("firmware: arm_ffa: Split bus and driver into distinct modules"). The arm_ffa_bus_exit() takes care of unregistering all the FF-A devices. Now that there are 2 distinct modules, if the core driver is unloaded and reloaded, it will end up adding duplicate FF-A devices as the previously registered devices weren't unregistered when we cleaned up the modules. Fix the same by unregistering all the FF-A devices on the FF-A bus during the cleaning up of the partitions and hence the cleanup of the module. Fixes: 18c250bd7ed0 ("firmware: arm_ffa: Split bus and driver into distinct modules") Tested-by: Viresh Kumar Message-Id: <20250217-ffa_updates-v3-8-bd1d9de615e7@arm.com> Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit e94ede618a61b0046d19450b500d396724890620 Author: Viresh Kumar Date: Mon Feb 17 15:38:47 2025 +0000 firmware: arm_ffa: Refactor addition of partition information into XArray [ Upstream commit 3c3d6767466ea316869c9f2bdd976aec8ce44545 ] Move the common code handling addition of the FF-A partition information into the XArray as a new routine. No functional change. Signed-off-by: Viresh Kumar Message-Id: <20250217-ffa_updates-v3-6-bd1d9de615e7@arm.com> Signed-off-by: Sudeep Holla Stable-dep-of: 46dcd68aacca ("firmware: arm_ffa: Unregister the FF-A devices when cleaning up the partitions") Signed-off-by: Sasha Levin commit 3dac0382bfde660ee0548db9668fe81e3d563886 Author: Jens Axboe Date: Sat Feb 8 10:50:34 2025 -0700 io_uring/net: improve recv bundles [ Upstream commit 7c71a0af81ba72de9b2c501065e4e718aba9a271 ] Current recv bundles are only supported for multishot receives, and additionally they also always post at least 2 CQEs if more data is available than what a buffer will hold. This happens because the initial bundle recv will do a single buffer, and then do the rest of what is in the socket as a followup receive. As shown in a test program, if 1k buffers are available and 32k is available to receive in the socket, you'd get the following completions: bundle=1, mshot=0 cqe res 1024 cqe res 1024 [...] cqe res 1024 bundle=1, mshot=1 cqe res 1024 cqe res 31744 where bundle=1 && mshot=0 will post 32 1k completions, and bundle=1 && mshot=1 will post a 1k completion and then a 31k completion. To support bundle recv without multishot, it's possible to simply retry the recv immediately and post a single completion, rather than split it into two completions. With the below patch, the same test looks as follows: bundle=1, mshot=0 cqe res 32768 bundle=1, mshot=1 cqe res 32768 where mshot=0 works fine for bundles, and both of them post just a single 32k completion rather than split it into separate completions. Posting fewer completions is always a nice win, and not needing multishot for proper bundle efficiency is nice for cases that can't necessarily use multishot. Reported-by: Norman Maurer Link: https://lore.kernel.org/r/184f9f92-a682-4205-a15d-89e18f664502@kernel.dk Fixes: 2f9c9515bdfd ("io_uring/net: support bundles for recv") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 8e1844027c0ca4eacc7842cd786895598a740499 Author: Pavel Begunkov Date: Fri Jan 31 17:28:21 2025 +0000 io_uring: check for iowq alloc_workqueue failure [ Upstream commit 7215469659cb9751a9bf80e43b24a48749004d26 ] alloc_workqueue() can fail even during init in io_uring_init(), check the result and panic if anything went wrong. Fixes: 73eaa2b583493 ("io_uring: use private workqueue for exit work") Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/3a046063902f888f66151f89fa42f84063b9727b.1738343083.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f1d94b5d4286fc2d1cfd178e5d0de66e4629fac2 Author: Max Kellermann Date: Tue Jan 28 14:39:24 2025 +0100 io_uring/io-wq: do not use bogus hash value [ Upstream commit 486ba4d84d62e92716cd395c4b1612b8ce70a257 ] Previously, the `hash` variable was initialized with `-1` and only updated by io_get_next_work() if the current work was hashed. Commit 60cf46ae6054 ("io-wq: hash dependent work") changed this to always call io_get_work_hash() even if the work was not hashed. This caused the `hash != -1U` check to always be true, adding some overhead for the `hash->wait` code. This patch fixes the regression by checking the `IO_WQ_WORK_HASHED` flag. Perf diff for a flood of `IORING_OP_NOP` with `IOSQE_ASYNC`: 38.55% -1.57% [kernel.kallsyms] [k] queued_spin_lock_slowpath 6.86% -0.72% [kernel.kallsyms] [k] io_worker_handle_work 0.10% +0.67% [kernel.kallsyms] [k] put_prev_entity 1.96% +0.59% [kernel.kallsyms] [k] io_nop_prep 3.31% -0.51% [kernel.kallsyms] [k] try_to_wake_up 7.18% -0.47% [kernel.kallsyms] [k] io_wq_free_work Fixes: 60cf46ae6054 ("io-wq: hash dependent work") Cc: Pavel Begunkov Signed-off-by: Max Kellermann Link: https://lore.kernel.org/r/20250128133927.3989681-6-max.kellermann@ionos.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f69a33f4995fc5534199ee0550f35142c6b3c417 Author: Max Kellermann Date: Tue Jan 28 14:39:23 2025 +0100 io_uring/io-wq: cache work->flags in variable [ Upstream commit 6ee78354eaa602002448f098b34678396d99043d ] This eliminates several redundant atomic reads and therefore reduces the duration the surrounding spinlocks are held. In several io_uring benchmarks, this reduced the CPU time spent in queued_spin_lock_slowpath() considerably: io_uring benchmark with a flood of `IORING_OP_NOP` and `IOSQE_ASYNC`: 38.86% -1.49% [kernel.kallsyms] [k] queued_spin_lock_slowpath 6.75% +0.36% [kernel.kallsyms] [k] io_worker_handle_work 2.60% +0.19% [kernel.kallsyms] [k] io_nop 3.92% +0.18% [kernel.kallsyms] [k] io_req_task_complete 6.34% -0.18% [kernel.kallsyms] [k] io_wq_submit_work HTTP server, static file: 42.79% -2.77% [kernel.kallsyms] [k] queued_spin_lock_slowpath 2.08% +0.23% [kernel.kallsyms] [k] io_wq_submit_work 1.19% +0.20% [kernel.kallsyms] [k] amd_iommu_iotlb_sync_map 1.46% +0.15% [kernel.kallsyms] [k] ep_poll_callback 1.80% +0.15% [kernel.kallsyms] [k] io_worker_handle_work HTTP server, PHP: 35.03% -1.80% [kernel.kallsyms] [k] queued_spin_lock_slowpath 0.84% +0.21% [kernel.kallsyms] [k] amd_iommu_iotlb_sync_map 1.39% +0.12% [kernel.kallsyms] [k] _copy_to_iter 0.21% +0.10% [kernel.kallsyms] [k] update_sd_lb_stats Signed-off-by: Max Kellermann Link: https://lore.kernel.org/r/20250128133927.3989681-5-max.kellermann@ionos.com Signed-off-by: Jens Axboe Stable-dep-of: 486ba4d84d62 ("io_uring/io-wq: do not use bogus hash value") Signed-off-by: Sasha Levin commit afde54f2901d7b18aeab30c680adab90d6bd8ca9 Author: Max Kellermann Date: Tue Jan 28 14:39:20 2025 +0100 io_uring/io-wq: eliminate redundant io_work_get_acct() calls [ Upstream commit 3c75635f8ed482300931327847c50068a865a648 ] Instead of calling io_work_get_acct() again, pass acct to io_wq_insert_work() and io_wq_remove_pending(). This atomic access in io_work_get_acct() was done under the `acct->lock`, and optimizing it away reduces lock contention a bit. Signed-off-by: Max Kellermann Link: https://lore.kernel.org/r/20250128133927.3989681-2-max.kellermann@ionos.com Signed-off-by: Jens Axboe Stable-dep-of: 486ba4d84d62 ("io_uring/io-wq: do not use bogus hash value") Signed-off-by: Sasha Levin commit 0239da0f7b30644d54a6deca63c15c16fcd5ecce Author: Nicolas Bouchinet Date: Wed Jan 15 14:22:08 2025 +0100 coredump: Fixes core_pipe_limit sysctl proc_handler [ Upstream commit 049439e22825507a90d4dedf3934e24fd0a8ff62 ] proc_dointvec converts a string to a vector of signed int, which is stored in the unsigned int .data core_pipe_limit. It was thus authorized to write a negative value to core_pipe_limit sysctl which once stored in core_pipe_limit, leads to the signed int dump_count check against core_pipe_limit never be true. The same can be achieved with core_pipe_limit set to INT_MAX. Any negative write or >= to INT_MAX in core_pipe_limit sysctl would hypothetically allow a user to create very high load on the system by running processes that produces a coredump in case the core_pattern sysctl is configured to pipe core files to user space helper. Memory or PID exhaustion should happen before but it anyway breaks the core_pipe_limit semantic. This commit fixes this by changing core_pipe_limit sysctl's proc_handler to proc_dointvec_minmax and bound checking between SYSCTL_ZERO and SYSCTL_INT_MAX. Fixes: a293980c2e26 ("exec: let do_coredump() limit the number of concurrent dumps to pipes") Signed-off-by: Nicolas Bouchinet Reviewed-by: Jan Kara Reviewed-by: Kees Cook Signed-off-by: Joel Granados Signed-off-by: Sasha Levin commit a815ac87c06d5f37f92e3782008234154a7f120e Author: Zheng Qixing Date: Sat Feb 15 10:01:37 2025 +0800 md/raid1: fix memory leak in raid1_run() if no active rdev [ Upstream commit 5fbcf76e0dfe68578ffa2a8a691cc44cf586ae35 ] When `raid1_set_limits()` fails or when the array has no active `rdev`, the allocated memory for `conf` is not properly freed. Add raid1_free() call to properly free the conf in error path. Fixes: 799af947ed13 ("md/raid1: don't free conf on raid0_run failure") Signed-off-by: Zheng Qixing Link: https://lore.kernel.org/linux-raid/20250215020137.3703757-1-zhengqixing@huaweicloud.com Singed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit f97c13dc53c803dded6b6c1f731f40aed73a09cc Author: Li Nan Date: Thu Feb 13 21:15:30 2025 +0800 md: ensure resync is prioritized over recovery [ Upstream commit 4b10a3bc67c1232f76aa1e04778ca26d6c0ddf7f ] If a new disk is added during resync, the resync process is interrupted, and recovery is triggered, causing the previous resync to be lost. In reality, disk addition should not terminate resync, fix it. Steps to reproduce the issue: mdadm -CR /dev/md0 -l1 -n3 -x1 /dev/sd[abcd] mdadm --fail /dev/md0 /dev/sdc Fixes: 24dd469d728d ("[PATCH] md: allow a manual resync with md") Signed-off-by: Li Nan Reviewed-by: Yu Kuai Link: https://lore.kernel.org/linux-raid/20250213131530.3698600-1-linan666@huaweicloud.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin commit 07d53c2cd7b26779530a5f71840b95a12a3a1b84 Author: Paul Menzel Date: Fri Jan 31 18:16:40 2025 +0100 scsi: mpt3sas: Reduce log level of ignore_delay_remove message to KERN_INFO [ Upstream commit fb27da6e06a0869d2e36255bb7e0b6102daf712f ] On several systems with Dell HBA controller Linux prints the warning below: $ dmesg | grep -e "Linux version" -e "DMI: Dell" -e "ignore_delay_remove" [ 0.000000] Linux version 6.12.11.mx64.479 (root@lucy.molgen.mpg.de) (gcc (GCC) 12.3.0, GNU ld (GNU Binutils) 2.41) #1 SMP PREEMPT_DYNAMIC Fri Jan 24 13:30:47 CET 2025 [ 0.000000] DMI: Dell Inc. PowerEdge R7625/0M7YXP, BIOS 1.10.6 12/06/2024 [ 9.386551] scsi 0:0:4:0: set ignore_delay_remove for handle(0x0012) A user does not know, what to do about it, and everything seems to work as expected. Therefore, remove the log level from warning to info. Device information: $ dmesg | grep -e 0:4:0 -e '12)' [ 8.857606] mpt3sas_cm0: config page(0x00000000db0e4179) - dma(0xfd5f6000): size(512) [ 9.133856] scsi 0:0:0:0: SATA: handle(0x0017), sas_addr(0x3c0470e0d40cc20c), phy(12), device_name(0x5000039db8d2284b) [ 9.366341] mpt3sas_cm0: handle(0x12) sas_address(0x3c0570e0d40cc208) port_type(0x0) [ 9.378867] scsi 0:0:4:0: Enclosure DP BP_PSV 7.10 PQ: 0 ANSI: 7 [ 9.386551] scsi 0:0:4:0: set ignore_delay_remove for handle(0x0012) [ 9.387465] scsi 0:0:4:0: SES: handle(0x0012), sas_addr(0x3c0570e0d40cc208), phy(17), device_name(0x3c0570e0d40cc208) [ 9.387465] scsi 0:0:4:0: enclosure logical id (0x3c0470e0d4092108), slot(8) [ 9.387465] scsi 0:0:4:0: enclosure level(0x0001), connector name( C0 ) [ 9.390495] scsi 0:0:4:0: qdepth(1), tagged(0), scsi_level(8), cmd_que(0) [ 9.401700] end_device-0:4: add: handle(0x0012), sas_addr(0x3c0570e0d40cc208) [ 9.471916] ses 0:0:4:0: Attached Enclosure device [ 9.480088] ses 0:0:4:0: Attached scsi generic sg4 type 13 $ lspci -nn -k -s 41: 41:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI Fusion-MPT 12GSAS/PCIe Secure SAS38xx [1000:00e6] DeviceName: SL3 NonRAID Subsystem: Dell HBA355i Front [1028:200c] Kernel driver in use: mpt3sas Fixes: 30158dc9bbc9 ("mpt3sas: Never block the Enclosure device") Cc: Tomas Henzl Signed-off-by: Paul Menzel Link: https://lore.kernel.org/r/20250131171640.30721-1-pmenzel@molgen.mpg.de Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 9392862608d081a8346a3b841f862d732fce954b Author: Chao Yu Date: Tue Feb 11 14:36:57 2025 +0800 f2fs: fix to avoid panic once fallocation fails for pinfile [ Upstream commit 48ea8b200414ac69ea96f4c231f5c7ef1fbeffef ] syzbot reports a f2fs bug as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2746! CPU: 0 UID: 0 PID: 5323 Comm: syz.0.0 Not tainted 6.13.0-rc2-syzkaller-00018-g7cb1b4663150 #0 RIP: 0010:get_new_segment fs/f2fs/segment.c:2746 [inline] RIP: 0010:new_curseg+0x1f52/0x1f70 fs/f2fs/segment.c:2876 Call Trace: __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3210 f2fs_allocate_new_section fs/f2fs/segment.c:3224 [inline] f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3238 f2fs_expand_inode_data+0x696/0xca0 fs/f2fs/file.c:1830 f2fs_fallocate+0x537/0xa10 fs/f2fs/file.c:1940 vfs_fallocate+0x569/0x6e0 fs/open.c:327 do_vfs_ioctl+0x258c/0x2e40 fs/ioctl.c:885 __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x80/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Concurrent pinfile allocation may run out of free section, result in panic in get_new_segment(), let's expand pin_sem lock coverage to include f2fs_gc(), so that we can make sure to reclaim enough free space for following allocation. In addition, do below changes to enhance error path handling: - call f2fs_bug_on() only in non-pinfile allocation path in get_new_segment(). - call reset_curseg_fields() to reset all fields of curseg in new_curseg() Fixes: f5a53edcf01e ("f2fs: support aligned pinned file") Reported-by: syzbot+15669ec8c35ddf6c3d43@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-f2fs-devel/675cd64e.050a0220.37aaf.00bb.GAE@google.com Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 963ce964ea00d304a2e1011b812bd89d7b642771 Author: Bart Van Assche Date: Thu Feb 6 14:13:17 2025 -0800 wifi: ath12k: Fix locking in "QMI firmware ready" error paths [ Upstream commit b9c7299a3341a737622e4de45b9c27e60ad01e3b ] If ag->mutex has been locked, unlock it before returning. If it has not been locked, do not unlock it before returning. These bugs have been detected by the Clang thread-safety analyzer. Cc: Karthikeyan Periyasamy Cc: Jeff Johnson Fixes: ee146e11b4d9 ("wifi: ath12k: refactor core start based on hardware group") Signed-off-by: Bart Van Assche Reviewed-by: Aditya Kumar Singh Link: https://patch.msgid.link/20250206221317.3845663-1-bvanassche@acm.org Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit b85758e76b6452740fc2a08ced6759af64c0d59a Author: Kang Yang Date: Thu Dec 19 19:05:31 2024 +0800 wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor mode [ Upstream commit 63b7af49496d0e32f7a748b6af3361ec138b1bd3 ] ath11k_hal_srng_* should be used with srng->lock to protect srng data. For ath11k_dp_rx_mon_dest_process() and ath11k_dp_full_mon_process_rx(), they use ath11k_hal_srng_* for many times but never call srng->lock. So when running (full) monitor mode, warning will occur: RIP: 0010:ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] Call Trace: ? ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] ath11k_dp_rx_process_mon_status+0xc45/0x1190 [ath11k] ? idr_alloc_u32+0x97/0xd0 ath11k_dp_rx_process_mon_rings+0x32a/0x550 [ath11k] ath11k_dp_service_srng+0x289/0x5a0 [ath11k] ath11k_pcic_ext_grp_napi_poll+0x30/0xd0 [ath11k] __napi_poll+0x30/0x1f0 net_rx_action+0x198/0x320 __do_softirq+0xdd/0x319 So add srng->lock for them to avoid such warnings. Inorder to fetch the srng->lock, should change srng's definition from 'void' to 'struct hal_srng'. And initialize them elsewhere to prevent one line of code from being too long. This is consistent with other ring process functions, such as ath11k_dp_process_rx(). Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Kang Yang Acked-by: Jeff Johnson Link: https://patch.msgid.link/20241219110531.2096-3-quic_kangyang@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit b4991fc41745645f8050506f5a8578bd11e6b378 Author: P Praneesh Date: Thu Dec 19 19:05:30 2024 +0800 wifi: ath11k: fix RCU stall while reaping monitor destination ring [ Upstream commit 16c6c35c03ea73054a1f6d3302a4ce4a331b427d ] While processing the monitor destination ring, MSDUs are reaped from the link descriptor based on the corresponding buf_id. However, sometimes the driver cannot obtain a valid buffer corresponding to the buf_id received from the hardware. This causes an infinite loop in the destination processing, resulting in a kernel crash. kernel log: ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309 ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failed ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309 ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failed Fix this by skipping the problematic buf_id and reaping the next entry, replacing the break with the next MSDU processing. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: P Praneesh Signed-off-by: Kang Yang Acked-by: Kalle Valo Acked-by: Jeff Johnson Link: https://patch.msgid.link/20241219110531.2096-2-quic_kangyang@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit b73c4ad4d387fe5bc988145bd9f1bc0de76afd5c Author: Thadeu Lima de Souza Cascardo Date: Mon Feb 10 13:16:22 2025 -0600 dlm: prevent NPD when writing a positive value to event_done [ Upstream commit 8e2bad543eca5c25cd02cbc63d72557934d45f13 ] do_uevent returns the value written to event_done. In case it is a positive value, new_lockspace would undo all the work, and lockspace would not be set. __dlm_new_lockspace, however, would treat that positive value as a success due to commit 8511a2728ab8 ("dlm: fix use count with multiple joins"). Down the line, device_create_lockspace would pass that NULL lockspace to dlm_find_lockspace_local, leading to a NULL pointer dereference. Treating such positive values as successes prevents the problem. Given this has been broken for so long, this is unlikely to break userspace expectations. Fixes: 8511a2728ab8 ("dlm: fix use count with multiple joins") Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit d7acf0a6c87aa282c86a36dbaa2f92fda88c5884 Author: Chao Yu Date: Sat Feb 8 10:33:21 2025 +0800 f2fs: quota: fix to avoid warning in dquot_writeback_dquots() [ Upstream commit eb85c2410d6f581e957cd03a644ff6ddbe592af9 ] F2FS-fs (dm-59): checkpoint=enable has some unwritten data. ------------[ cut here ]------------ WARNING: CPU: 6 PID: 8013 at fs/quota/dquot.c:691 dquot_writeback_dquots+0x2fc/0x308 pc : dquot_writeback_dquots+0x2fc/0x308 lr : f2fs_quota_sync+0xcc/0x1c4 Call trace: dquot_writeback_dquots+0x2fc/0x308 f2fs_quota_sync+0xcc/0x1c4 f2fs_write_checkpoint+0x3d4/0x9b0 f2fs_issue_checkpoint+0x1bc/0x2c0 f2fs_sync_fs+0x54/0x150 f2fs_do_sync_file+0x2f8/0x814 __f2fs_ioctl+0x1960/0x3244 f2fs_ioctl+0x54/0xe0 __arm64_sys_ioctl+0xa8/0xe4 invoke_syscall+0x58/0x114 checkpoint and f2fs_remount may race as below, resulting triggering warning in dquot_writeback_dquots(). atomic write remount - do_remount - down_write(&sb->s_umount); - f2fs_remount - ioctl - f2fs_do_sync_file - f2fs_sync_fs - f2fs_write_checkpoint - block_operations - locked = down_read_trylock(&sbi->sb->s_umount) : fail to lock due to the write lock was held by remount - up_write(&sb->s_umount); - f2fs_quota_sync - dquot_writeback_dquots - WARN_ON_ONCE(!rwsem_is_locked(&sb->s_umount)) : trigger warning because s_umount lock was unlocked by remount If checkpoint comes from mount/umount/remount/freeze/quotactl, caller of checkpoint has already held s_umount lock, calling dquot_writeback_dquots() in the context should be safe. So let's record task to sbi->umount_lock_holder, so that checkpoint can know whether the lock has held in the context or not by checking current w/ it. In addition, in order to not misrepresent caller of checkpoint, we should not allow to trigger async checkpoint for those callers: mount/umount/remount/ freeze/quotactl. Fixes: af033b2aa8a8 ("f2fs: guarantee journalled quota data by checkpoint") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit c3707b2dd7eb6b610b3de1f683c049966461176e Author: Tom Rini Date: Thu Jan 23 11:49:01 2025 -0600 ARM: dts: omap4-panda-a4: Add missing model and compatible properties [ Upstream commit ea07a4775df03852c353514b5b7646a17bd425be ] When moving the model and compatible properties out of the common Pandaboard files and in to the specific boards, the omap4-panda-a4 file wasn't updated as well and so has lacked a model and compatible entry ever since. Fixes: a1a57abaaf82 ("ARM: dts: omap4-panda: Fix model and SoC family details") Signed-off-by: Tom Rini Link: https://lore.kernel.org/r/20250123174901.1182176-2-trini@konsulko.com Signed-off-by: Kevin Hilman Signed-off-by: Sasha Levin commit f952fb83c9c6f908d27500764c4aee1df04b9d3f Author: Wen Gong Date: Fri Jan 17 14:17:36 2025 +0800 wifi: ath11k: update channel list in reg notifier instead reg worker [ Upstream commit 933ab187e679e6fbdeea1835ae39efcc59c022d2 ] Currently when ath11k gets a new channel list, it will be processed according to the following steps: 1. update new channel list to cfg80211 and queue reg_work. 2. cfg80211 handles new channel list during reg_work. 3. update cfg80211's handled channel list to firmware by ath11k_reg_update_chan_list(). But ath11k will immediately execute step 3 after reg_work is just queued. Since step 2 is asynchronous, cfg80211 may not have completed handling the new channel list, which may leading to an out-of-bounds write error: BUG: KASAN: slab-out-of-bounds in ath11k_reg_update_chan_list Call Trace: ath11k_reg_update_chan_list+0xbfe/0xfe0 [ath11k] kfree+0x109/0x3a0 ath11k_regd_update+0x1cf/0x350 [ath11k] ath11k_regd_update_work+0x14/0x20 [ath11k] process_one_work+0xe35/0x14c0 Should ensure step 2 is completely done before executing step 3. Thus Wen raised patch[1]. When flag NL80211_REGDOM_SET_BY_DRIVER is set, cfg80211 will notify ath11k after step 2 is done. So enable the flag NL80211_REGDOM_SET_BY_DRIVER then cfg80211 will notify ath11k after step 2 is done. At this time, there will be no KASAN bug during the execution of the step 3. [1] https://patchwork.kernel.org/project/linux-wireless/patch/20230201065313.27203-1-quic_wgong@quicinc.com/ Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3 Fixes: f45cb6b29cd3 ("wifi: ath11k: avoid deadlock during regulatory update in ath11k_regd_update()") Signed-off-by: Wen Gong Signed-off-by: Kang Yang Reviewed-by: Aditya Kumar Singh Link: https://patch.msgid.link/20250117061737.1921-2-quic_kangyang@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit d073d620882ba00ac926c6327d47ae29ae4622cf Author: Chen-Yu Tsai Date: Wed Jan 8 16:34:23 2025 +0800 arm64: dts: mediatek: mt8173: Fix some node names [ Upstream commit be035e4a26edf8fdcbc4fe95d16c28deade13bb0 ] Some node names are incorrect, causing DT validations due to mismatches. Fixes: b3a372484157 ("arm64: dts: Add mediatek MT8173 SoC and evaluation board dts and Makefile") Fixes: f2ce70149568 ("arm64: dts: mt8173: Add clock controller device nodes") Cc: Eddie Huang Cc: Sascha Hauer Signed-off-by: Chen-Yu Tsai Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20250108083424.2732375-3-wenst@chromium.org Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit bc3b7a08a3e4e74c1f7384108c2425d13ee1f279 Author: Chen-Yu Tsai Date: Wed Jan 8 16:34:21 2025 +0800 arm64: dts: mediatek: mt8173-elm: Drop pmic's #address-cells and #size-cells [ Upstream commit aaa0b40e157c65aaa5e0ad903675f245333381bb ] The PMIC has child nodes for each of its functions. It is not an actual bus and no addressing is involved. Dropping the bogus properties fixes a DT validation error: arch/arm64/boot/dts/mediatek/mt8173-elm.dtb: pmic: '#address-cells', '#size-cells' do not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/mfd/mediatek,mt6397.yaml# Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202412212322.JTFpRD7X-lkp@intel.com/ Fixes: 689b937bedde ("arm64: dts: mediatek: add mt8173 elm and hana board") Signed-off-by: Chen-Yu Tsai Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20250108083424.2732375-1-wenst@chromium.org Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit 2144e32b371887d694d0e8b81827035e7328ba44 Author: Yu Zhang(Yuriy) Date: Fri Jan 24 15:59:53 2025 +0800 wifi: ath11k: fix wrong overriding for VHT Beamformee STS Capability [ Upstream commit 9d13950acb2a51342c93c69f1a5bf285adb90d88 ] Current code in ath11k_mac_set_txbf_conf overrides nsts, which is incorrect as it confuses nss and nsts. nss is Number of Spatial Streams，nsts is Number of Space-Time Streams. As mentioned in Fixes: 55b5ee3357d7, the nss used when acting as a beamformee in VHT mode should be reported by the firmware and should not be greater than the number of receiving antennas - 1. The num_rx_chains related nss rather than nsts. If STBC is enabled, nsts is greater than nss. About nss are mapped to nsts, refer to IEEE Std 802.11-2020: 19.3.11.9.2 Space-time block coding (STBC), Table 19-18—Constellation mapper output to spatial mapper input for STBC. Remove wrong overriding for nsts of VHT Beamformee STS Capability, acting DL MU-MIMO in VHT mode is working properly. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04479-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1 Fixes: 55b5ee3357d7 ("wifi: ath11k: fix number of VHT beamformee spatial streams") Signed-off-by: Yu Zhang (Yuriy) Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250124075953.2282354-1-quic_yuzha@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 997a097707cdf330ba30ad9f2d3918bbcedabacd Author: Dmitry Antipov Date: Thu Jan 23 17:10:58 2025 +0300 wifi: ath9k: do not submit zero bytes to the entropy pool [ Upstream commit 0f2b59a98027a781eee1cbd48c7c8fdf87cb73f6 ] In 'ath_cmn_process_fft()', it doesn't make too much sense to add zero bytes in attempt to improve randomness. So swap calls to 'memset()' and 'add_device_randomness()' to feed the pool with actual FFT results rather than zeroes. Compile tested only. Signed-off-by: Dmitry Antipov Fixes: 2aa56cca3571 ("ath9k: Mix the received FFT bins to the random pool") Acked-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20250123141058.1696502-1-dmantipov@yandex.ru Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 3cbc1d7b193c3bef59e9116847c828eb858b2d23 Author: Rameshkumar Sundaram Date: Thu Jan 2 10:00:48 2025 +0530 wifi: ath12k: Fix pdev lookup in WBM error processing [ Upstream commit 4e635b81db9d69bbb836afae8cb402978ff966a4 ] Currently in ath12k_dp_rx_process_wbm_err(), when processing packets received on the WBM error ring, pdev validation is done based upon the hw_link_id. But hw_link_id corresponds to link id of a given partner pdev in a MLO hardware group, and is not the correct index to use to lookup a pdev in an SoC(ab). As a result, pdev validation fails, and the reaped packets are dropped instead of being processed. The correct index to use is the pdev_id, which is already derived in the function. So update the logic to validate the pdev based upon the pdev_id instead of the hw_link_id. This matches the logic used in other Rx ring processing functions. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: 1a73acb5fba4 ("wifi: ath12k: move to HW link id based receive handling") Signed-off-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20250102043048.2596791-1-quic_ramess@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 17a0aebaece8874bd65c625f870e42099367cf40 Author: Sathishkumar Muruganandam Date: Tue Jan 7 09:31:39 2025 +0530 wifi: ath12k: encode max Tx power in scan channel list command [ Upstream commit 07c34cad10ab0ac8b06ede8a7fbc55ecf2efa3e6 ] Currently, when sending the scan channel list command to the firmware, the maximum Tx power is not encoded in the reg2 member. This omission causes the firmware to be unaware of the host's maximum Tx power, leading to incorrect Tx power derivation at firmware level. To resolve this issue, encode the maximum Tx power in the scan channel list command before sending it to firmware. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Sathishkumar Muruganandam Signed-off-by: Aditya Kumar Singh Tested-by: Nicolas Escande Link: https://patch.msgid.link/20250107-add_max_reg_pwr_in_scan_ch_list_cmd-v1-1-70d9963a21e4@quicinc.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 8c651e02f363a9cac4057b85fa1fbc44a8c58fea Author: Nicolas Escande Date: Wed Jan 22 17:01:12 2025 +0100 wifi: ath12k: fix skb_ext_desc leak in ath12k_dp_tx() error path [ Upstream commit 28a9972e0f0693cd4d08f431c992fa6be39c788c ] When vlan support was added, we missed that when ath12k_dp_prepare_htt_metadata() returns an error we also need to free the skb holding the metadata before going on with the cleanup process. Compile tested only. Fixes: 26dd8ccdba4d ("wifi: ath12k: dynamic VLAN support") Signed-off-by: Nicolas Escande Reviewed-by: Aditya Kumar Singh Link: https://patch.msgid.link/20250122160112.3234558-1-nico.escande@gmail.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 2b7c0c6c483e6be8cbb4ddfd1be4b960029799ba Author: Liang Jie Date: Sun Jan 12 18:51:44 2025 +0800 wifi: rtw89: Correct immediate cfg_len calculation for scan_offload_be [ Upstream commit 361cb056e2468be534f47c1a6745f96581a721e3 ] Ensures the correct calculation of `cfg_len` prior to the allocation of the skb in the `rtw89_fw_h2c_scan_offload_be` function, particularly when the `SCAN_OFFLOAD_BE_V0` firmware feature is enabled. It addresses an issue where an incorrect skb size might be allocated due to a delayed setting of `cfg_len`, potentially leading to memory inefficiencies. By moving the conditional check and assignment of `cfg_len` before skb allocation, the patch guarantees that `len`, which depends on `cfg_len`, is accurately computed, ensuring proper skb size and preventing any unnecessary memory reservation for firmware operations not supporting beyond the `w8` member of the command data structure. This correction helps to optimize memory usage and maintain consistent behavior across different firmware versions. Fixes: 6ca6b918f280 ("wifi: rtw89: 8922a: Add new fields for scan offload H2C command") Signed-off-by: Liang Jie Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250112105144.615474-1-buaajxlj@163.com Signed-off-by: Sasha Levin commit 7bbf4de7f504541451ce8bd522bcfe3e2bc6a587 Author: Takashi Iwai Date: Mon Mar 24 16:32:32 2025 +0100 ALSA: hda/realtek: Fix built-in mic assignment on ASUS VivoBook X515UA [ Upstream commit 829ee558f3527fd602c6e2e9f270959d1de09fe0 ] ASUS VivoBook X515UA with PCI SSID 1043:106f had a default quirk pickup via pin table that applies ALC256_FIXUP_ASUS_MIC, but this adds a bogus built-in mic pin 0x13 enabled. This was no big problem because the pin 0x13 was assigned as the secondary mic, but the recent fix made the entries sorted, hence this bogus pin appeared now as the primary input and it broke. For fixing the bug, put the right quirk entry for this device pointing to ALC256_FIXUP_ASUS_MIC_NO_PRESENCE. Fixes: 3b4309546b48 ("ALSA: hda: Fix headset detection failure due to unstable sort") Link: https://bugzilla.kernel.org/show_bug.cgi?id=219897 Link: https://patch.msgid.link/20250324153233.21195-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit b074f47e55df93832bbbca1b524c501e6fea1c0d Author: Takashi Iwai Date: Fri Mar 21 18:26:52 2025 +0100 ALSA: timer: Don't take register_mutex with copy_from/to_user() [ Upstream commit 3424c8f53bc63c87712a7fc22dc13d0cc85fb0d6 ] The infamous mmap_lock taken in copy_from/to_user() can be often problematic when it's called inside another mutex, as they might lead to deadlocks. In the case of ALSA timer code, the bad pattern is with guard(mutex)(®ister_mutex) that covers copy_from/to_user() -- which was mistakenly introduced at converting to guard(), and it had been carefully worked around in the past. This patch fixes those pieces simply by moving copy_from/to_user() out of the register mutex lock again. Fixes: 3923de04c817 ("ALSA: pcm: oss: Use guard() for setup") Reported-by: syzbot+2b96f44164236dda0f3b@syzkaller.appspotmail.com Closes: https://lore.kernel.org/67dd86c8.050a0220.25ae54.0059.GAE@google.com Link: https://patch.msgid.link/20250321172653.14310-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 8ba99115b1c2eaf398eb86b5dd1c93ff3fd754cf Author: Olivia Mackintosh Date: Sun Mar 16 15:33:23 2025 +0000 ALSA: usb-audio: separate DJM-A9 cap lvl options [ Upstream commit 38e94cefbf45c1edc5b751ab90a3088f7c6fac1a ] Mixer quicks for the Pioneer DJM-A9 mixer was added in 5289d00 with additional capture level values added to the common DJM array of values. This breaks the existing DJM mixers however as alsa-utils relies on enumeration of the actual mixer options based on the value array which results in error when storing state. This commit just separates the A9 values into a separate array and references them in the corresponding mixer control. Fixes: 5289d0069639 ("ALSA: usb-audio: Add Pioneer DJ/AlphaTheta DJM-A9 Mixer") Signed-off-by: Olivia Mackintosh Link: https://patch.msgid.link/20250316153323.16381-1-livvy@base.nu Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit eb5374d2a3085031cb0d4208a496569386dae421 Author: Jayesh Choudhary Date: Tue Mar 18 17:05:24 2025 +0530 ASoC: ti: j721e-evm: Fix clock configuration for ti,j7200-cpb-audio compatible [ Upstream commit 45ff65e30deb919604e68faed156ad96ce7474d9 ] For 'ti,j7200-cpb-audio' compatible, there is support for only one PLL for 48k. For 11025, 22050, 44100 and 88200 sampling rates, due to absence of J721E_CLK_PARENT_44100, we get EINVAL while running any audio application. Add support for these rates by using the 48k parent clock and adjusting the clock for these rates later in j721e_configure_refclk. Fixes: 6748d0559059 ("ASoC: ti: Add custom machine driver for j721e EVM (CPB and IVI)") Signed-off-by: Jayesh Choudhary Link: https://patch.msgid.link/20250318113524.57100-1-j-choudhary@ti.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1f576a3fd06d0e016c1caa692a8cb0cfdb2d9218 Author: Ritu Chaudhary Date: Tue Mar 11 06:20:10 2025 +0000 ASoC: tegra: Use non-atomic timeout for ADX status register [ Upstream commit f1d742c35b659fb0122da0a8ff09ad9309cb29d8 ] ADX startup() callback uses atomic poll timeout on ADX status register. This is unnecessary because: - The startup() callback itself is non-atomic. - The subsequent timeout call in the same function already uses a non-atomic version. Using atomic version can hog CPU when it is not really needed, so replace it with non-atomic version. Fixes: a99ab6f395a9e ("ASoC: tegra: Add Tegra210 based ADX driver") Signed-off-by: Ritu Chaudhary Signed-off-by: Sheetal Link: https://patch.msgid.link/20250311062010.33412-1-sheetal@nvidia.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9dfdd01dac5036ced73ebd51dabbeb839b05d2ad Author: Takashi Iwai Date: Sat Mar 15 15:30:19 2025 +0100 ALSA: hda/realtek: Always honor no_shutup_pins [ Upstream commit 5a0c72c1da3cbc0cd4940a95d1be2830104c6edf ] The workaround for Dell machines to skip the pin-shutup for mic pins introduced alc_headset_mic_no_shutup() that is replaced from the generic snd_hda_shutup_pins() for certain codecs. The problem is that the call is done unconditionally even if spec->no_shutup_pins is set. This seems causing problems on other platforms like Lenovo. This patch corrects the behavior and the driver honors always spec->no_shutup_pins flag and skips alc_headset_mic_no_shutup() if it's set. Fixes: dad3197da7a3 ("ALSA: hda/realtek - Fixup headphone noise via runtime suspend") Reported-and-tested-by: Oleg Gorobets Link: https://patch.msgid.link/20250315143020.27184-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 5c8627d52254f71cbdd79d41723613001e42adf1 Author: Maud Spierings Date: Wed Feb 26 15:19:13 2025 +0100 dt-bindings: vendor-prefixes: add GOcontroll [ Upstream commit 5f0d2de417166698c8eba433b696037ce04730da ] GOcontroll produces embedded linux systems and IO modules to use in these systems, add its prefix. Acked-by: Rob Herring (Arm) Signed-off-by: Maud Spierings Link: https://patch.msgid.link/20250226-initial_display-v2-2-23fafa130817@gocontroll.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 232a32e8a7e9be8a2ee238df9b5304eed2f4e195 Author: Kuninori Morimoto Date: Fri Feb 28 00:29:30 2025 +0000 ASoC: simple-card-utils: Don't use __free(device_node) at graph_util_parse_dai() [ Upstream commit de74ec718e0788e1998eb7289ad07970e27cae27 ] commit 419d1918105e ("ASoC: simple-card-utils: use __free(device_node) for device node") uses __free(device_node) for dlc->of_node, but we need to keep it while driver is in use. Don't use __free(device_node) in graph_util_parse_dai(). Fixes: 419d1918105e ("ASoC: simple-card-utils: use __free(device_node) for device node") Reported-by: Thuan Nguyen Reported-by: Detlev Casanova Signed-off-by: Kuninori Morimoto Tested-by: Thuan Nguyen Tested-by: Detlev Casanova Link: https://patch.msgid.link/87eczisyhh.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 04395075425e7ce958bacd4585b76fd3bfa52e8a Author: Jiri Kosina Date: Wed Mar 12 09:08:22 2025 +0100 HID: remove superfluous (and wrong) Makefile entry for CONFIG_INTEL_ISH_FIRMWARE_DOWNLOADER [ Upstream commit fe0fb58325e519008e2606a5aa2cff7ad23e212d ] The line obj-$(INTEL_ISH_FIRMWARE_DOWNLOADER) += intel-ish-hid/ in top-level HID Makefile is both superfluous (as CONFIG_INTEL_ISH_FIRMWARE_DOWNLOADER depends on CONFIG_INTEL_ISH_HID, which contains intel-ish-hid/ already) and wrong (as it's missing the CONFIG_ prefix). Just remove it. Fixes: 91b228107da3e ("HID: intel-ish-hid: ISH firmware loader client driver") Reported-by: Jiri Slaby Acked-by: Srinivas Pandruvada Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 07f85bc6fe350c8ecfce69b5c964a7db5da83839 Author: Venkata Prasad Potturu Date: Tue Mar 11 00:02:01 2025 +0530 ASoC: amd: acp: Fix for enabling DMIC on acp platforms via _DSD entry [ Upstream commit 02e1cf7a352a3ba5f768849f2b4fcaaaa19f89e3 ] Add condition check to register ACP PDM sound card by reading _WOV acpi entry. Fixes: 09068d624c49 ("ASoC: amd: acp: fix for acp platform device creation failure") Signed-off-by: Venkata Prasad Potturu Link: https://patch.msgid.link/20250310183201.11979-15-venkataprasad.potturu@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a4347e990f0850bdb2bc38998f073ffbf9021c17 Author: Vitaliy Shevtsov Date: Tue Mar 4 16:56:37 2025 +0500 ASoC: cs35l41: check the return value from spi_setup() [ Upstream commit ad5a0970f86d82e39ebd06d45a1f7aa48a1316f8 ] Currently the return value from spi_setup() is not checked for a failure. It is unlikely it will ever fail in this particular case but it is still better to add this check for the sake of completeness and correctness. This is cheap since it is performed once when the device is being probed. Handle spi_setup() return value. Found by Linux Verification Center (linuxtesting.org) with Svace. Fixes: 872fc0b6bde8 ("ASoC: cs35l41: Set the max SPI speed for the whole device") Signed-off-by: Vitaliy Shevtsov Link: https://patch.msgid.link/20250304115643.2748-1-v.shevtsov@mt-integration.ru Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d557e506b0bf4cdc5524812573d8d217e11994e4 Author: Armin Wolf Date: Wed Mar 5 06:30:07 2025 +0100 platform/x86: dell-ddv: Fix temperature calculation [ Upstream commit 7a248294a3145bc65eb0d8980a0a8edbb1b92db4 ] On the Dell Inspiron 3505 the battery temperature is always 0.1 degrees larger than the temperature show inside the OEM application. Emulate this behaviour to avoid showing strange looking values like 29.1 degrees. Fixes: 0331b1b0ba653 ("platform/x86: dell-ddv: Fix temperature scaling") Signed-off-by: Armin Wolf Reviewed-by: Sebastian Reichel Link: https://lore.kernel.org/r/20250305053009.378609-2-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 18cbe13aeefb63b2124bbac57471decea3fb0bbe Author: Ilpo Järvinen Date: Tue Mar 4 18:06:39 2025 +0200 platform/x86: dell-uart-backlight: Make dell_uart_bl_serdev_driver static [ Upstream commit 4878e0b14c3e31a87ab147bd2dae443394cb5a2c ] Sparse reports: dell-uart-backlight.c:328:29: warning: symbol 'dell_uart_bl_serdev_driver' was not declared. Should it be static? Fix it by making the symbol static. Fixes: 484bae9e4d6ac ("platform/x86: Add new Dell UART backlight driver") Reviewed-by: Mario Limonciello Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/20250304160639.4295-2-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen Reviewed-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit d745fe93d4d9267582a881487bc9bc6641a61657 Author: Ilpo Järvinen Date: Tue Mar 4 18:06:38 2025 +0200 platform/x86: lenovo-yoga-tab2-pro-1380-fastcharger: Make symbol static [ Upstream commit 886ca11a0c70efe5627a18557062e8a44370d78f ] Sparse reports: lenovo-yoga-tab2-pro-1380-fastcharger.c:222:29: warning: symbol 'yt2_1380_fc_serdev_driver' was not declared. Should it be static? Fix that by making the symbol static. Fixes: b2ed33e8d486a ("platform/x86: Add lenovo-yoga-tab2-pro-1380-fastcharger driver") Reviewed-by: Mario Limonciello Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/20250304160639.4295-1-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen Reviewed-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit f9cce4a76d398078bfed97fe83ab0de5fbf38df8 Author: Andy Shevchenko Date: Mon Feb 24 14:36:25 2025 +0200 auxdisplay: panel: Fix an API misuse in panel.c [ Upstream commit 72e1c440c848624ad4cfac93d69d8a999a20355b ] Variable allocated by charlcd_alloc() should be released by charlcd_free(). The following patch changed kfree() to charlcd_free() to fix an API misuse. Reviewed-by: Geert Uytterhoeven Fixes: 718e05ed92ec ("auxdisplay: Introduce hd44780_common.[ch]") Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit f48140589d9157d51a011dfa5b48968ade87f6c5 Author: Joe Hattori Date: Thu Dec 5 11:06:21 2024 +0900 media: platform: allgro-dvt: unregister v4l2_device on the error path [ Upstream commit c2b96a6818159fba8a3bcc38262da9e77f9b3ec7 ] In allegro_probe(), the v4l2 device is not unregistered in the error path, which results in a memory leak. Fix it by calling v4l2_device_unregister() before returning error. Fixes: d74d4e2359ec ("media: allegro: move driver out of staging") Signed-off-by: Joe Hattori Reviewed-by: Michael Tretter Signed-off-by: Sebastian Fricke Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 80750c3ab8c00df416550f1de29ca838d9f17b17 Author: Benjamin Gaignard Date: Mon Jan 20 09:10:52 2025 +0100 media: verisilicon: HEVC: Initialize start_bit field [ Upstream commit 7fcb42b3835e90ef18d68555934cf72adaf58402 ] The HEVC driver needs to set the start_bit field explicitly to avoid causing corrupted frames when the VP9 decoder is used in parallel. The reason for this problem is that the VP9 and the HEVC decoder share this register. Fixes: cb5dd5a0fa51 ("media: hantro: Introduce G2/HEVC decoder") Signed-off-by: Benjamin Gaignard Tested-by: Nicolas Dufresne Reviewed-by: Nicolas Dufresne Signed-off-by: Sebastian Fricke Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 41f6fbcd3d3bb6b789aad098a0afe4f32bddbc9b Author: Geert Uytterhoeven Date: Thu Feb 20 08:48:42 2025 +0100 auxdisplay: MAX6959 should select BITREVERSE [ Upstream commit fce85f3da08b76c1b052f53a9f6f9c40a8a10660 ] If CONFIG_BITREVERSE is not enabled: max6959.c:(.text+0x92): undefined reference to `byte_rev_table' Fixes: a9bcd02fa42217c7 ("auxdisplay: Add driver for MAX695x 7-segment LED controllers") Reported-by: kernel test robot Closes: https://lore.kernel.org/202502161703.3Vr4M7qg-lkp@intel.com/ Signed-off-by: Geert Uytterhoeven Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit bc8848e13fd172307a99732401d7bfae569f51ab Author: Frieder Schrempf Date: Wed Dec 18 16:27:28 2024 +0100 regulator: pca9450: Fix enable register for LDO5 [ Upstream commit f5aab0438ef17f01c5ecd25e61ae6a03f82a4586 ] The LDO5 regulator has two configuration registers, but only LDO5CTRL_L contains the bits for enabling/disabling the regulator. Fixes: 0935ff5f1f0a ("regulator: pca9450: add pca9450 pmic driver") Signed-off-by: Frieder Schrempf Reviewed-by: Marek Vasut Link: https://patch.msgid.link/20241218152842.97483-6-frieder@fris.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1521cc04f0b6e737ff30105aa57fa9dde8493231 Author: Atish Patra Date: Mon Mar 17 00:41:44 2025 -0700 RISC-V: KVM: Teardown riscv specific bits after kvm_exit [ Upstream commit 2d117e67f318303f6ab699a5511d1fac3f170545 ] During a module removal, kvm_exit invokes arch specific disable call which disables AIA. However, we invoke aia_exit before kvm_exit resulting in the following warning. KVM kernel module can't be inserted afterwards due to inconsistent state of IRQ. [25469.031389] percpu IRQ 31 still enabled on CPU0! [25469.031732] WARNING: CPU: 3 PID: 943 at kernel/irq/manage.c:2476 __free_percpu_irq+0xa2/0x150 [25469.031804] Modules linked in: kvm(-) [25469.031848] CPU: 3 UID: 0 PID: 943 Comm: rmmod Not tainted 6.14.0-rc5-06947-g91c763118f47-dirty #2 [25469.031905] Hardware name: riscv-virtio,qemu (DT) [25469.031928] epc : __free_percpu_irq+0xa2/0x150 [25469.031976] ra : __free_percpu_irq+0xa2/0x150 [25469.032197] epc : ffffffff8007db1e ra : ffffffff8007db1e sp : ff2000000088bd50 [25469.032241] gp : ffffffff8131cef8 tp : ff60000080b96400 t0 : ff2000000088baf8 [25469.032285] t1 : fffffffffffffffc t2 : 5249207570637265 s0 : ff2000000088bd90 [25469.032329] s1 : ff60000098b21080 a0 : 037d527a15eb4f00 a1 : 037d527a15eb4f00 [25469.032372] a2 : 0000000000000023 a3 : 0000000000000001 a4 : ffffffff8122dbf8 [25469.032410] a5 : 0000000000000fff a6 : 0000000000000000 a7 : ffffffff8122dc10 [25469.032448] s2 : ff60000080c22eb0 s3 : 0000000200000022 s4 : 000000000000001f [25469.032488] s5 : ff60000080c22e00 s6 : ffffffff80c351c0 s7 : 0000000000000000 [25469.032582] s8 : 0000000000000003 s9 : 000055556b7fb490 s10: 00007ffff0e12fa0 [25469.032621] s11: 00007ffff0e13e9a t3 : ffffffff81354ac7 t4 : ffffffff81354ac7 [25469.032664] t5 : ffffffff81354ac8 t6 : ffffffff81354ac7 [25469.032698] status: 0000000200000100 badaddr: ffffffff8007db1e cause: 0000000000000003 [25469.032738] [] __free_percpu_irq+0xa2/0x150 [25469.032797] [] free_percpu_irq+0x30/0x5e [25469.032856] [] kvm_riscv_aia_exit+0x40/0x42 [kvm] [25469.033947] [] cleanup_module+0x10/0x32 [kvm] [25469.035300] [] __riscv_sys_delete_module+0x18e/0x1fc [25469.035374] [] syscall_handler+0x3a/0x46 [25469.035456] [] do_trap_ecall_u+0x72/0x134 [25469.035536] [] handle_exception+0x148/0x156 Invoke aia_exit and other arch specific cleanup functions after kvm_exit so that disable gets a chance to be called first before exit. Fixes: 54e43320c2ba ("RISC-V: KVM: Initial skeletal support for AIA") Fixes: eded6754f398 ("riscv: KVM: add basic support for host vs guest profiling") Signed-off-by: Atish Patra Reviewed-by: Anup Patel Reviewed-by: Sean Christopherson Link: https://lore.kernel.org/r/20250317-kvm_exit_fix-v1-1-aa5240c5dbd2@rivosinc.com Signed-off-by: Anup Patel Signed-off-by: Sasha Levin commit 2c03a07832ab7fb7c869c3816ae1705375d04daa Author: Vitaly Kuznetsov Date: Tue Dec 10 16:16:50 2024 +0100 x86/entry: Add __init to ia32_emulation_override_cmdline() [ Upstream commit d55f31e29047f2f987286d55928ae75775111fe7 ] ia32_emulation_override_cmdline() is an early_param() arg and these are only needed at boot time. In fact, all other early_param() functions in arch/x86 seem to have '__init' annotation and ia32_emulation_override_cmdline() is the only exception. Fixes: a11e097504ac ("x86: Make IA32_EMULATION boot time configurable") Signed-off-by: Vitaly Kuznetsov Signed-off-by: Dave Hansen Signed-off-by: Ingo Molnar Reviewed-by: Nikolay Borisov Link: https://lore.kernel.org/all/20241210151650.1746022-1-vkuznets%40redhat.com Signed-off-by: Sasha Levin commit 3c9e5d501465bf172f46829136cd32e0a35a3742 Author: Chao Gao Date: Mon Mar 17 22:06:11 2025 +0800 x86/fpu/xstate: Fix inconsistencies in guest FPU xfeatures [ Upstream commit dda366083e5ff307a4a728757db874bbfe7550be ] Guest FPUs manage vCPU FPU states. They are allocated via fpu_alloc_guest_fpstate() and are resized in fpstate_realloc() when XFD features are enabled. Since the introduction of guest FPUs, there have been inconsistencies in the kernel buffer size and xfeatures: 1. fpu_alloc_guest_fpstate() uses fpu_user_cfg since its introduction. See: 69f6ed1d14c6 ("x86/fpu: Provide infrastructure for KVM FPU cleanup") 36487e6228c4 ("x86/fpu: Prepare guest FPU for dynamically enabled FPU features") 2. __fpstate_reset() references fpu_kernel_cfg to set storage attributes. 3. fpu->guest_perm uses fpu_kernel_cfg, affecting fpstate_realloc(). A recent commit in the tip:x86/fpu tree partially addressed the inconsistency between (1) and (3) by using fpu_kernel_cfg for size calculation in (1), but left fpu_guest->xfeatures and fpu_guest->perm still referencing fpu_user_cfg: https://lore.kernel.org/all/20250218141045.85201-1-stanspas@amazon.de/ 1937e18cc3cf ("x86/fpu: Fix guest FPU state buffer allocation size") The inconsistencies within fpu_alloc_guest_fpstate() and across the mentioned functions cause confusion. Fix them by using fpu_kernel_cfg consistently in fpu_alloc_guest_fpstate(), except for fields related to the UABI buffer. Referencing fpu_kernel_cfg won't impact functionalities, as: 1. fpu_guest->perm is overwritten shortly in fpu_init_guest_permissions() with fpstate->guest_perm, which already uses fpu_kernel_cfg. 2. fpu_guest->xfeatures is solely used to check if XFD features are enabled. Including supervisor xfeatures doesn't affect the check. Fixes: 36487e6228c4 ("x86/fpu: Prepare guest FPU for dynamically enabled FPU features") Suggested-by: Chang S. Bae Signed-off-by: Chao Gao Signed-off-by: Ingo Molnar Cc: Andy Lutomirski Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Oleg Nesterov Cc: Dave Hansen Cc: Juergen Gross Cc: Stefano Stabellini Cc: Paolo Bonzini Cc: Vitaly Kuznetsov Cc: Sean Christopherson Cc: David Woodhouse Link: https://lore.kernel.org/r/20250317140613.1761633-1-chao.gao@intel.com Signed-off-by: Sasha Levin commit 022d5c7826fa4fe09b6e7080e9253b3a33c3a0cb Author: Josh Poimboeuf Date: Fri Mar 14 12:28:59 2025 -0700 x86/traps: Make exc_double_fault() consistently noreturn [ Upstream commit 8085fcd78c1a3dbdf2278732579009d41ce0bc4e ] The CONFIG_X86_ESPFIX64 version of exc_double_fault() can return to its caller, but the !CONFIG_X86_ESPFIX64 version never does. In the latter case the compiler and/or objtool may consider it to be implicitly noreturn. However, due to the currently inflexible way objtool detects noreturns, a function's noreturn status needs to be consistent across configs. The current workaround for this issue is to suppress unreachable warnings for exc_double_fault()'s callers. Unfortunately that can result in ORC coverage gaps and potentially worse issues like inert static calls and silently disabled CPU mitigations. Instead, prevent exc_double_fault() from ever being implicitly marked noreturn by forcing a return behind a never-taken conditional. Until a more integrated noreturn detection method exists, this is likely the least objectionable workaround. Fixes: 55eeab2a8a11 ("objtool: Ignore exc_double_fault() __noreturn warnings") Signed-off-by: Josh Poimboeuf Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Brendan Jackman Link: https://lore.kernel.org/r/d1f4026f8dc35d0de6cc61f2684e0cb6484009d1.1741975349.git.jpoimboe@kernel.org Signed-off-by: Sasha Levin commit 5bb1aabd3bf9306ba4db8873648e7f2eb657ca78 Author: Juri Lelli Date: Thu Mar 13 18:10:21 2025 +0100 sched/deadline: Rebuild root domain accounting after every update [ Upstream commit 2ff899e3516437354204423ef0a94994717b8e6a ] Rebuilding of root domains accounting information (total_bw) is currently broken on some cases, e.g. suspend/resume on aarch64. Problem is that the way we keep track of domain changes and try to add bandwidth back is convoluted and fragile. Fix it by simplify things by making sure bandwidth accounting is cleared and completely restored after root domains changes (after root domains are again stable). To be sure we always call dl_rebuild_rd_accounting while holding cpuset_mutex we also add cpuset_reset_sched_domains() wrapper. Fixes: 53916d5fd3c0 ("sched/deadline: Check bandwidth overflow earlier for hotplug") Reported-by: Jon Hunter Co-developed-by: Waiman Long Signed-off-by: Waiman Long Signed-off-by: Juri Lelli Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dietmar Eggemann Tested-by: Dietmar Eggemann Link: https://lore.kernel.org/r/Z9MRfeJKJUOyUSto@jlelli-thinkpadt14gen4.remote.csb Signed-off-by: Sasha Levin commit c464d471d807900050d57f3171a2e15cda754f7f Author: Juri Lelli Date: Thu Mar 13 18:05:46 2025 +0100 sched/deadline: Generalize unique visiting of root domains [ Upstream commit 45007c6fb5860cf63556a9cadc87c8984927e23d ] Bandwidth checks and updates that work on root domains currently employ a cookie mechanism for efficiency. This mechanism is very much tied to when root domains are first created and initialized. Generalize the cookie mechanism so that it can be used also later at runtime while updating root domains. Also, additionally guard it with sched_domains_mutex, since domains need to be stable while updating them (and it will be required for further dynamic changes). Fixes: 53916d5fd3c0 ("sched/deadline: Check bandwidth overflow earlier for hotplug") Reported-by: Jon Hunter Signed-off-by: Juri Lelli Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Valentin Schneider Reviewed-by: Dietmar Eggemann Tested-by: Waiman Long Tested-by: Jon Hunter Tested-by: Dietmar Eggemann Link: https://lore.kernel.org/r/Z9MQaiXPvEeW_v7x@jlelli-thinkpadt14gen4.remote.csb Signed-off-by: Sasha Levin commit d06ebcfb9a80aaf270a3571c425c7984057f7dc4 Author: Juri Lelli Date: Thu Mar 13 18:03:32 2025 +0100 sched/topology: Wrappers for sched_domains_mutex [ Upstream commit 56209334dda1832c0a919e1d74768c6d0f3b2ca9 ] Create wrappers for sched_domains_mutex so that it can transparently be used on both CONFIG_SMP and !CONFIG_SMP, as some function will need to do. Fixes: 53916d5fd3c0 ("sched/deadline: Check bandwidth overflow earlier for hotplug") Reported-by: Jon Hunter Signed-off-by: Juri Lelli Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Valentin Schneider Reviewed-by: Dietmar Eggemann Tested-by: Waiman Long Tested-by: Jon Hunter Tested-by: Dietmar Eggemann Link: https://lore.kernel.org/r/Z9MP5Oq9RB8jBs3y@jlelli-thinkpadt14gen4.remote.csb Signed-off-by: Sasha Levin commit c43b47287f3342ece0c5e9d6f7ec54024df5411f Author: Juri Lelli Date: Thu Mar 13 18:00:04 2025 +0100 sched/deadline: Ignore special tasks when rebuilding domains [ Upstream commit f6147af176eaa4027b692fdbb1a0a60dfaa1e9b6 ] SCHED_DEADLINE special tasks get a fake bandwidth that is only used to make sure sleeping and priority inheritance 'work', but it is ignored for runtime enforcement and admission control. Be consistent with it also when rebuilding root domains. Fixes: 53916d5fd3c0 ("sched/deadline: Check bandwidth overflow earlier for hotplug") Reported-by: Jon Hunter Signed-off-by: Juri Lelli Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Valentin Schneider Reviewed-by: Dietmar Eggemann Tested-by: Waiman Long Tested-by: Jon Hunter Tested-by: Dietmar Eggemann Link: https://lore.kernel.org/r/20250313170011.357208-2-juri.lelli@redhat.com Signed-off-by: Sasha Levin commit 1c919ed40627b7497a9037872a79c9e2e347ca35 Author: Kan Liang Date: Fri Mar 14 10:26:58 2025 -0700 perf/x86/lbr: Fix shorter LBRs call stacks for the system-wide mode [ Upstream commit 3cec9fd03543c1e2919f906353e5cba079ae0a7c ] In the system-wide mode, LBR callstacks are shorter in comparison to the per-process mode. LBR MSRs are reset during a context switch in the system-wide mode. For the LBR call stack, the LBRs should be always saved/restored during a context switch. Use the space in task_struct to save/restore the LBR call stack data. For a system-wide event, it's unnecessagy to update the lbr_callstack_users for each threads. Add a variable in x86_pmu to indicate whether the system-wide event is active. Fixes: 76cb2c617f12 ("perf/x86/intel: Save/restore LBR stack during context switch") Reported-by: Andi Kleen Reported-by: Alexey Budankov Debugged-by: Alexey Budankov Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20250314172700.438923-5-kan.liang@linux.intel.com Signed-off-by: Sasha Levin commit c5b249ffa6064c1edf0666e719b9b1739192c3af Author: Kan Liang Date: Fri Mar 14 10:26:57 2025 -0700 perf: Supply task information to sched_task() [ Upstream commit d57e94f5b891925e4f2796266eba31edd5a01903 ] To save/restore LBR call stack data in system-wide mode, the task_struct information is required. Extend the parameters of sched_task() to supply task_struct information. When schedule in, the LBR call stack data for new task will be restored. When schedule out, the LBR call stack data for old task will be saved. Only need to pass the required task_struct information. Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20250314172700.438923-4-kan.liang@linux.intel.com Stable-dep-of: 3cec9fd03543 ("perf/x86/lbr: Fix shorter LBRs call stacks for the system-wide mode") Signed-off-by: Sasha Levin commit d30f2fbaf7e904e57bd06685e03036dac0a12553 Author: Kan Liang Date: Fri Mar 14 10:26:54 2025 -0700 perf: Save PMU specific data in task_struct [ Upstream commit cb4369129339060218baca718a578bb0b826e734 ] Some PMU specific data has to be saved/restored during context switch, e.g. LBR call stack data. Currently, the data is saved in event context structure, but only for per-process event. For system-wide event, because of missing the LBR call stack data after context switch, LBR callstacks are always shorter in comparison to per-process mode. For example, Per-process mode: $perf record --call-graph lbr -- taskset -c 0 ./tchain_edit - 99.90% 99.86% tchain_edit tchain_edit [.] f3 99.86% _start __libc_start_main generic_start_main main f1 - f2 f3 System-wide mode: $perf record --call-graph lbr -a -- taskset -c 0 ./tchain_edit - 99.88% 99.82% tchain_edit tchain_edit [.] f3 - 62.02% main f1 f2 f3 - 28.83% f1 - f2 f3 - 28.83% f1 - f2 f3 - 8.88% generic_start_main main f1 f2 f3 It isn't practical to simply allocate the data for system-wide event in CPU context structure for all tasks. We have no idea which CPU a task will be scheduled to. The duplicated LBR data has to be maintained on every CPU context structure. That's a huge waste. Otherwise, the LBR data still lost if the task is scheduled to another CPU. Save the pmu specific data in task_struct. The size of pmu specific data is 788 bytes for LBR call stack. Usually, the overall amount of threads doesn't exceed a few thousands. For 10K threads, keeping LBR data would consume additional ~8MB. The additional space will only be allocated during LBR call stack monitoring. It will be released when the monitoring is finished. Furthermore, moving task_ctx_data from perf_event_context to task_struct can reduce complexity and make things clearer. E.g. perf doesn't need to swap task_ctx_data on optimized context switch path. This patch set is just the first step. There could be other optimization/extension on top of this patch set. E.g. for cgroup profiling, perf just needs to save/store the LBR call stack information for tasks in specific cgroup. That could reduce the additional space. Also, the LBR call stack can be available for software events, or allow even debugging use cases, like LBRs on crash later. Because of the alignment requirement of Intel Arch LBR, the Kmem cache is used to allocate the PMU specific data. It's required when child task allocates the space. Save it in struct perf_ctx_data. The refcount in struct perf_ctx_data is used to track the users of pmu specific data. Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Alexey Budankov Link: https://lore.kernel.org/r/20250314172700.438923-1-kan.liang@linux.intel.com Stable-dep-of: 3cec9fd03543 ("perf/x86/lbr: Fix shorter LBRs call stacks for the system-wide mode") Signed-off-by: Sasha Levin commit 39cd09fd809aab05dc1b0ade16e41d4049611d26 Author: Tao Chen Date: Fri Mar 14 11:00:36 2025 +0800 perf/ring_buffer: Allow the EPOLLRDNORM flag for poll [ Upstream commit c96fff391c095c11dc87dab35be72dee7d217cde ] The poll man page says POLLRDNORM is equivalent to POLLIN. For poll(), it seems that if user sets pollfd with POLLRDNORM in userspace, perf_poll will not return until timeout even if perf_output_wakeup called, whereas POLLIN returns. Fixes: 76369139ceb9 ("perf: Split up buffer handling from core code") Signed-off-by: Tao Chen Signed-off-by: Ingo Molnar Cc: Peter Zijlstra Cc: Arnaldo Carvalho de Melo Cc: "H. Peter Anvin" Cc: Linus Torvalds Link: https://lore.kernel.org/r/20250314030036.2543180-1-chen.dylane@linux.dev Signed-off-by: Sasha Levin commit de2530c4133fbeff459e4d9407c64067779a37a6 Author: Jacky Bai Date: Thu Mar 13 09:39:28 2025 +0800 cpufreq: Init cpufreq only for present CPUs [ Upstream commit 45f589b7167f36290d29c79e3a442dc0b13c086a ] for_each_possible_cpu() is currently used to initialize cpufreq. However, in cpu_dev_register_generic(), for_each_present_cpu() is used to register CPU devices which means the CPU devices are only registered for present CPUs and not all possible CPUs. With nosmp or maxcpus=0, only the boot CPU is present, lead to the cpufreq probe failure or defer probe due to no cpu device available for not present CPUs. Change for_each_possible_cpu() to for_each_present_cpu() in the above cpufreq drivers to ensure it only registers cpufreq for CPUs that are actually present. Fixes: b0c69e1214bc ("drivers: base: Use present CPUs in GENERIC_CPU_DEVICES") Reviewed-by: Sudeep Holla Signed-off-by: Jacky Bai Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 8fe0068e9517f126c176d5756093c113e3b80979 Author: Sebastian Andrzej Siewior Date: Wed Feb 12 11:36:18 2025 +0100 lockdep: Don't disable interrupts on RT in disable_irq_nosync_lockdep.*() [ Upstream commit 87886b32d669abc11c7be95ef44099215e4f5788 ] disable_irq_nosync_lockdep() disables interrupts with lockdep enabled to avoid false positive reports by lockdep that a certain lock has not been acquired with disabled interrupts. The user of this macros expects that a lock can be acquried without disabling interrupts because the IRQ line triggering the interrupt is disabled. This triggers a warning on PREEMPT_RT because after disable_irq_nosync_lockdep.*() the following spinlock_t now is acquired with disabled interrupts. On PREEMPT_RT there is no difference between spin_lock() and spin_lock_irq() so avoiding disabling interrupts in this case works for the two remaining callers as of today. Don't disable interrupts on PREEMPT_RT in disable_irq_nosync_lockdep.*(). Closes: https://lore.kernel.org/760e34f9-6034-40e0-82a5-ee9becd24438@roeck-us.net Fixes: e8106b941ceab ("[PATCH] lockdep: core, add enable/disable_irq_irqsave/irqrestore() APIs") Reported-by: Guenter Roeck Suggested-by: "Steven Rostedt (Google)" Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Peter Zijlstra (Intel) Tested-by: Guenter Roeck Link: https://lore.kernel.org/r/20250212103619.2560503-2-bigeasy@linutronix.de Signed-off-by: Sasha Levin commit 46d6456e05e20e443d763daba15818b64d4c4eb5 Author: Rafael J. Wysocki Date: Thu Mar 13 17:00:00 2025 +0100 PM: sleep: Fix handling devices with direct_complete set on errors [ Upstream commit 03f1444016b71feffa1dfb8a51f15ba592f94b13 ] When dpm_suspend() fails, some devices with power.direct_complete set may not have been handled by device_suspend() yet, so runtime PM has not been disabled for them yet even though power.direct_complete is set. Since device_resume() expects that runtime PM has been disabled for all devices with power.direct_complete set, it will attempt to reenable runtime PM for the devices that have not been processed by device_suspend() which does not make sense. Had those devices had runtime PM disabled before device_suspend() had run, device_resume() would have inadvertently enable runtime PM for them, but this is not expected to happen because it would require ->prepare() callbacks to return positive values for devices with runtime PM disabled, which would be invalid. In practice, this issue is most likely benign because pm_runtime_enable() will not allow the "disable depth" counter to underflow, but it causes a warning message to be printed for each affected device. To allow device_resume() to distinguish the "direct complete" devices that have been processed by device_suspend() from those which have not been handled by it, make device_suspend() set power.is_suspended for "direct complete" devices. Next, move the power.is_suspended check in device_resume() before the power.direct_complete check in it to make it skip the "direct complete" devices that have not been handled by device_suspend(). This change is based on a preliminary patch from Saravana Kannan. Fixes: aae4518b3124 ("PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily") Link: https://lore.kernel.org/linux-pm/20241114220921.2529905-2-saravanak@google.com/ Reported-by: Saravana Kannan Signed-off-by: Rafael J. Wysocki Reviewed-by: Saravana Kannan Link: https://patch.msgid.link/12627587.O9o76ZdvQC@rjwysocki.net Signed-off-by: Sasha Levin commit 8e8f1ddf4186731649df8bc9646017369eb19186 Author: Chenyuan Yang Date: Wed Mar 12 23:36:11 2025 -0500 thermal: int340x: Add NULL check for adev [ Upstream commit 2542a3f70e563a9e70e7ded314286535a3321bdb ] Not all devices have an ACPI companion fwnode, so adev might be NULL. This is similar to the commit cd2fd6eab480 ("platform/x86: int3472: Check for adev == NULL"). Add a check for adev not being set and return -ENODEV in that case to avoid a possible NULL pointer deref in int3402_thermal_probe(). Note, under the same directory, int3400_thermal_probe() has such a check. Fixes: 77e337c6e23e ("Thermal: introduce INT3402 thermal driver") Signed-off-by: Chenyuan Yang Acked-by: Uwe Kleine-König Link: https://patch.msgid.link/20250313043611.1212116-1-chenyuan0y@gmail.com [ rjw: Subject edit, added Fixes: ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit e4cd170e26773259f869728e19df205b0cdd28e9 Author: Jacky Bai Date: Fri Mar 7 22:55:47 2025 +0800 cpuidle: Init cpuidle only for present CPUs [ Upstream commit 68cb0139fec8e05b93978dc0ef1bc8df90a86419 ] for_each_possible_cpu() is currently used to initialize cpuidle in below cpuidle drivers: drivers/cpuidle/cpuidle-arm.c drivers/cpuidle/cpuidle-big_little.c drivers/cpuidle/cpuidle-psci.c drivers/cpuidle/cpuidle-qcom-spm.c drivers/cpuidle/cpuidle-riscv-sbi.c However, in cpu_dev_register_generic(), for_each_present_cpu() is used to register CPU devices which means the CPU devices are only registered for present CPUs and not all possible CPUs. With nosmp or maxcpus=0, only the boot CPU is present, lead to the failure: | Failed to register cpuidle device for cpu1 Then rollback to cancel all CPUs' cpuidle registration. Change for_each_possible_cpu() to for_each_present_cpu() in the above cpuidle drivers to ensure it only registers cpuidle devices for CPUs that are actually present. Fixes: b0c69e1214bc ("drivers: base: Use present CPUs in GENERIC_CPU_DEVICES") Reviewed-by: Dhruva Gole Reviewed-by: Sudeep Holla Tested-by: Yuanjie Yang Signed-off-by: Jacky Bai Reviewed-by: Ulf Hansson Link: https://patch.msgid.link/20250307145547.2784821-1-ping.bai@nxp.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 93a418fc61da13d1ee4047d4d1327990f7a2816a Author: James Morse Date: Tue Mar 11 18:36:46 2025 +0000 x86/resctrl: Fix allocation of cleanest CLOSID on platforms with no monitors [ Upstream commit a121798ae669351ec0697c94f71c3a692b2a755b ] Commit 6eac36bb9eb0 ("x86/resctrl: Allocate the cleanest CLOSID by searching closid_num_dirty_rmid") added logic that causes resctrl to search for the CLOSID with the fewest dirty cache lines when creating a new control group, if requested by the arch code. This depends on the values read from the llc_occupancy counters. The logic is applicable to architectures where the CLOSID effectively forms part of the monitoring identifier and so do not allow complete freedom to choose an unused monitoring identifier for a given CLOSID. This support missed that some platforms may not have these counters. This causes a NULL pointer dereference when creating a new control group as the array was not allocated by dom_data_init(). As this feature isn't necessary on platforms that don't have cache occupancy monitors, add this to the check that occurs when a new control group is allocated. Fixes: 6eac36bb9eb0 ("x86/resctrl: Allocate the cleanest CLOSID by searching closid_num_dirty_rmid") Signed-off-by: James Morse Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Shaopeng Tan Reviewed-by: David Hildenbrand Reviewed-by: Reinette Chatre Reviewed-by: Tony Luck Reviewed-by: Fenghua Yu Reviewed-by: Babu Moger Tested-by: Carl Worth # arm64 Tested-by: Shaopeng Tan Tested-by: Peter Newman Tested-by: Amit Singh Tomar # arm64 Tested-by: Shanker Donthineni # arm64 Tested-by: Babu Moger Link: https://lore.kernel.org/r/20250311183715.16445-2-james.morse@arm.com Signed-off-by: Sasha Levin commit d6e73e4b864753d2e17ce810e0b666c1c381a590 Author: Suzuki K Poulose Date: Thu Feb 27 14:41:50 2025 +0000 arm64: realm: Use aliased addresses for device DMA to shared buffers [ Upstream commit 7d953a06241624ee2efb172d037a4168978f4147 ] When a device performs DMA to a shared buffer using physical addresses, (without Stage1 translation), the device must use the "{I}PA address" with the top bit set in Realm. This is to make sure that a trusted device will be able to write to shared buffers as well as the protected buffers. Thus, a Realm must always program the full address including the "protection" bit, like AMD SME encryption bits. Enable this by providing arm64 specific dma_addr_{encrypted, canonical} helpers for Realms. Please note that the VMM needs to similarly make sure that the SMMU Stage2 in the Non-secure world is setup accordingly to map IPA at the unprotected alias. Cc: Will Deacon Cc: Jean-Philippe Brucker Cc: Robin Murphy Cc: Steven Price Cc: Christoph Hellwig Cc: Marek Szyprowski Cc: Tom Lendacky Cc: Aneesh Kumar K.V Signed-off-by: Suzuki K Poulose Reviewed-by: Gavin Shan Acked-by: Catalin Marinas Reviewed-by: Robin Murphy Acked-by: Marek Szyprowski Fixes: 42be24a4178f ("arm64: Enable memory encrypt for Realms") Acked-by: Will Deacon Link: https://lore.kernel.org/r/20250227144150.1667735-4-suzuki.poulose@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 54263c3afd19d2016a8298318f23863b4135030a Author: Suzuki K Poulose Date: Thu Feb 27 14:41:49 2025 +0000 dma: Introduce generic dma_addr_*crypted helpers [ Upstream commit b66e2ee7b6c8d45bbe4b6f6885ee27511506812c ] AMD SME added __sme_set/__sme_clr primitives to modify the DMA address for encrypted/decrypted traffic. However this doesn't fit in with other models, e.g., Arm CCA where the meanings are the opposite. i.e., "decrypted" traffic has a bit set and "encrypted" traffic has the top bit cleared. In preparation for adding the support for Arm CCA DMA conversions, convert the existing primitives to more generic ones that can be provided by the backends. i.e., add helpers to 1. dma_addr_encrypted - Convert a DMA address to "encrypted" [ == __sme_set() ] 2. dma_addr_unencrypted - Convert a DMA address to "decrypted" [ None exists today ] 3. dma_addr_canonical - Clear any "encryption"/"decryption" bits from DMA address [ SME uses __sme_clr() ] and convert to a canonical DMA address. Since the original __sme_xxx helpers come from linux/mem_encrypt.h, use that as the home for the new definitions and provide dummy ones when none is provided by the architectures. With the above, phys_to_dma_unencrypted() uses the newly added dma_addr_unencrypted() helper and to make it a bit more easier to read and avoid double conversion, provide __phys_to_dma(). Suggested-by: Robin Murphy Cc: Will Deacon Cc: Jean-Philippe Brucker Cc: Robin Murphy Cc: Steven Price Cc: Christoph Hellwig Cc: Marek Szyprowski Cc: Tom Lendacky Cc: Aneesh Kumar K.V Signed-off-by: Suzuki K Poulose Reviewed-by: Robin Murphy Reviewed-by: Gavin Shan Acked-by: Marek Szyprowski Fixes: 42be24a4178f ("arm64: Enable memory encrypt for Realms") Acked-by: Will Deacon Link: https://lore.kernel.org/r/20250227144150.1667735-3-suzuki.poulose@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 11b3d9e188f5ec00bb09de602441ccd3c16d10c7 Author: Suzuki K Poulose Date: Thu Feb 27 14:41:48 2025 +0000 dma: Fix encryption bit clearing for dma_to_phys [ Upstream commit c380931712d16e23f6aa90703f438330139e9731 ] phys_to_dma() sets the encryption bit on the translated DMA address. But dma_to_phys() clears the encryption bit after it has been translated back to the physical address, which could fail if the device uses DMA ranges. AMD SME doesn't use the DMA ranges and thus this is harmless. But as we are about to add support for other architectures, let us fix this. Reported-by: Aneesh Kumar K.V Link: https://lkml.kernel.org/r/yq5amsen9stc.fsf@kernel.org Cc: Will Deacon Cc: Jean-Philippe Brucker Cc: Robin Murphy Cc: Steven Price Cc: Christoph Hellwig Cc: Marek Szyprowski Cc: Tom Lendacky Reviewed-by: Robin Murphy Acked-by: Tom Lendacky Signed-off-by: Suzuki K Poulose Reviewed-by: Gavin Shan Acked-by: Marek Szyprowski Fixes: 42be24a4178f ("arm64: Enable memory encrypt for Realms") Acked-by: Will Deacon Link: https://lore.kernel.org/r/20250227144150.1667735-2-suzuki.poulose@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit dd94d11db666285a0f513b65b289f4bb238b2bef Author: Qiuxu Zhuo Date: Mon Mar 10 09:14:03 2025 +0800 EDAC/ie31200: Fix the error path order of ie31200_init() [ Upstream commit 231e341036d9988447e3b3345cf741a98139199e ] The error path order of ie31200_init() is incorrect, fix it. Fixes: 709ed1bcef12 ("EDAC/ie31200: Fallback if host bridge device is already initialized") Signed-off-by: Qiuxu Zhuo Signed-off-by: Tony Luck Tested-by: Gary Wang Link: https://lore.kernel.org/r/20250310011411.31685-4-qiuxu.zhuo@intel.com Signed-off-by: Sasha Levin commit f5a19bf81d24a04b2ca1a25d3709125f2ab6c1f0 Author: Qiuxu Zhuo Date: Mon Mar 10 09:14:02 2025 +0800 EDAC/ie31200: Fix the DIMM size mask for several SoCs [ Upstream commit 3427befbbca6b19fe0e37f91d66ce5221de70bf1 ] The DIMM size mask for {Sky, Kaby, Coffee} Lake is not bits{7:0}, but bits{5:0}. Fix it. Fixes: 953dee9bbd24 ("EDAC, ie31200_edac: Add Skylake support") Signed-off-by: Qiuxu Zhuo Signed-off-by: Tony Luck Tested-by: Gary Wang Link: https://lore.kernel.org/r/20250310011411.31685-3-qiuxu.zhuo@intel.com Signed-off-by: Sasha Levin commit 34f47ad1b6a23ce4265fdc838a1c982d28040118 Author: Qiuxu Zhuo Date: Mon Mar 10 09:14:01 2025 +0800 EDAC/ie31200: Fix the size of EDAC_MC_LAYER_CHIP_SELECT layer [ Upstream commit d59d844e319d97682c8de29b88d2d60922a683b3 ] The EDAC_MC_LAYER_CHIP_SELECT layer pertains to the rank, not the DIMM. Fix its size to reflect the number of ranks instead of the number of DIMMs. Also delete the unused macros IE31200_{DIMMS,RANKS}. Fixes: 7ee40b897d18 ("ie31200_edac: Introduce the driver") Signed-off-by: Qiuxu Zhuo Signed-off-by: Tony Luck Tested-by: Gary Wang Link: https://lore.kernel.org/r/20250310011411.31685-2-qiuxu.zhuo@intel.com Signed-off-by: Sasha Levin commit f8619bb4e82e8459799790a4f517d2d8d8a13568 Author: Tim Schumacher Date: Fri Mar 7 10:56:43 2025 +0100 selinux: Chain up tool resolving errors in install_policy.sh [ Upstream commit 6ae0042f4d3f331e841495eb0a3d51598e593ec2 ] Subshell evaluations are not exempt from errexit, so if a command is not available, `which` will fail and exit the script as a whole. This causes the helpful error messages to not be printed if they are tacked on using a `$?` comparison. Resolve the issue by using chains of logical operators, which are not subject to the effects of errexit. Fixes: e37c1877ba5b1 ("scripts/selinux: modernize mdp") Signed-off-by: Tim Schumacher Signed-off-by: Paul Moore Signed-off-by: Sasha Levin commit 54a0912eba247b2d3eb1e4b6c4028c180d194663 Author: Maksim Davydov Date: Wed Jan 15 16:17:04 2025 +0300 x86/split_lock: Fix the delayed detection logic [ Upstream commit c929d08df8bee855528b9d15b853c892c54e1eee ] If the warning mode with disabled mitigation mode is used, then on each CPU where the split lock occurred detection will be disabled in order to make progress and delayed work will be scheduled, which then will enable detection back. Now it turns out that all CPUs use one global delayed work structure. This leads to the fact that if a split lock occurs on several CPUs at the same time (within 2 jiffies), only one CPU will schedule delayed work, but the rest will not. The return value of schedule_delayed_work_on() would have shown this, but it is not checked in the code. A diagram that can help to understand the bug reproduction: - sld_update_msr() enables/disables SLD on both CPUs on the same core - schedule_delayed_work_on() internally checks WORK_STRUCT_PENDING_BIT. If a work has the 'pending' status, then schedule_delayed_work_on() will return an error code and, most importantly, the work will not be placed in the workqueue. Let's say we have a multicore system on which split_lock_mitigate=0 and a multithreaded application is running that calls splitlock in multiple threads. Due to the fact that sld_update_msr() affects the entire core (both CPUs), we will consider 2 CPUs from different cores. Let the 2 threads of this application schedule to CPU0 (core 0) and to CPU 2 (core 1), then: | || | | CPU 0 (core 0) || CPU 2 (core 1) | |_________________________________||___________________________________| | || | | 1) SPLIT LOCK occured || | | || | | 2) split_lock_warn() || | | || | | 3) sysctl_sld_mitigate == 0 || | | (work = &sl_reenable) || | | || | | 4) schedule_delayed_work_on() || | | (reenable will be called || | | after 2 jiffies on CPU 0) || | | || | | 5) disable SLD for core 0 || | | || | | ------------------------- || | | || | | || 6) SPLIT LOCK occured | | || | | || 7) split_lock_warn() | | || | | || 8) sysctl_sld_mitigate == 0 | | || (work = &sl_reenable, | | || the same address as in 3) ) | | || | | 2 jiffies || 9) schedule_delayed_work_on() | | || fials because the work is in | | || the pending state since 4). | | || The work wasn't placed to the | | || workqueue. reenable won't be | | || called on CPU 2 | | || | | || 10) disable SLD for core 0 | | || | | || From now on SLD will | | || never be reenabled on core 1 | | || | | ------------------------- || | | || | | 11) enable SLD for core 0 by || | | __split_lock_reenable || | | || | If the application threads can be scheduled to all processor cores, then over time there will be only one core left, on which SLD will be enabled and split lock will be able to be detected; and on all other cores SLD will be disabled all the time. Most likely, this bug has not been noticed for so long because sysctl_sld_mitigate default value is 1, and in this case a semaphore is used that does not allow 2 different cores to have SLD disabled at the same time, that is, strictly only one work is placed in the workqueue. In order to fix the warning mode with disabled mitigation mode, delayed work has to be per-CPU. Implement it. Fixes: 727209376f49 ("x86/split_lock: Add sysctl to control the misery mode") Signed-off-by: Maksim Davydov Signed-off-by: Ingo Molnar Tested-by: Guilherme G. Piccoli Cc: Thomas Gleixner Cc: Ravi Bangoria Cc: Tom Lendacky Link: https://lore.kernel.org/r/20250115131704.132609-1-davydov-max@yandex-team.ru Signed-off-by: Sasha Levin commit 2f7fe7a981e0848133249d8f9222995aa262d8f3 Author: Li Huafei Date: Tue Oct 22 03:30:03 2024 +0800 watchdog/hardlockup/perf: Fix perf_event memory leak [ Upstream commit d6834d9c990333bfa433bc1816e2417f268eebbe ] During stress-testing, we found a kmemleak report for perf_event: unreferenced object 0xff110001410a33e0 (size 1328): comm "kworker/4:11", pid 288, jiffies 4294916004 hex dump (first 32 bytes): b8 be c2 3b 02 00 11 ff 22 01 00 00 00 00 ad de ...;...."....... f0 33 0a 41 01 00 11 ff f0 33 0a 41 01 00 11 ff .3.A.....3.A.... backtrace (crc 24eb7b3a): [<00000000e211b653>] kmem_cache_alloc_node_noprof+0x269/0x2e0 [<000000009d0985fa>] perf_event_alloc+0x5f/0xcf0 [<00000000084ad4a2>] perf_event_create_kernel_counter+0x38/0x1b0 [<00000000fde96401>] hardlockup_detector_event_create+0x50/0xe0 [<0000000051183158>] watchdog_hardlockup_enable+0x17/0x70 [<00000000ac89727f>] softlockup_start_fn+0x15/0x40 ... Our stress test includes CPU online and offline cycles, and updating the watchdog configuration. After reading the code, I found that there may be a race between cleaning up perf_event after updating watchdog and disabling event when the CPU goes offline: CPU0 CPU1 CPU2 (update watchdog) (hotplug offline CPU1) ... _cpu_down(CPU1) cpus_read_lock() // waiting for cpu lock softlockup_start_all smp_call_on_cpu(CPU1) softlockup_start_fn ... watchdog_hardlockup_enable(CPU1) perf create E1 watchdog_ev[CPU1] = E1 cpus_read_unlock() cpus_write_lock() cpuhp_kick_ap_work(CPU1) cpuhp_thread_fun ... watchdog_hardlockup_disable(CPU1) watchdog_ev[CPU1] = NULL dead_event[CPU1] = E1 __lockup_detector_cleanup for each dead_events_mask release each dead_event /* * CPU1 has not been added to * dead_events_mask, then E1 * will not be released */ CPU1 -> dead_events_mask cpumask_clear(&dead_events_mask) // dead_events_mask is cleared, E1 is leaked In this case, the leaked perf_event E1 matches the perf_event leak reported by kmemleak. Due to the low probability of problem recurrence (only reported once), I added some hack delays in the code: static void __lockup_detector_reconfigure(void) { ... watchdog_hardlockup_start(); cpus_read_unlock(); + mdelay(100); /* * Must be called outside the cpus locked section to prevent * recursive locking in the perf code. ... } void watchdog_hardlockup_disable(unsigned int cpu) { ... perf_event_disable(event); this_cpu_write(watchdog_ev, NULL); this_cpu_write(dead_event, event); + mdelay(100); cpumask_set_cpu(smp_processor_id(), &dead_events_mask); atomic_dec(&watchdog_cpus); ... } void hardlockup_detector_perf_cleanup(void) { ... perf_event_release_kernel(event); per_cpu(dead_event, cpu) = NULL; } + mdelay(100); cpumask_clear(&dead_events_mask); } Then, simultaneously performing CPU on/off and switching watchdog, it is almost certain to reproduce this leak. The problem here is that releasing perf_event is not within the CPU hotplug read-write lock. Commit: 941154bd6937 ("watchdog/hardlockup/perf: Prevent CPU hotplug deadlock") introduced deferred release to solve the deadlock caused by calling get_online_cpus() when releasing perf_event. Later, commit: efe951d3de91 ("perf/x86: Fix perf,x86,cpuhp deadlock") removed the get_online_cpus() call on the perf_event release path to solve another deadlock problem. Therefore, it is now possible to move the release of perf_event back into the CPU hotplug read-write lock, and release the event immediately after disabling it. Fixes: 941154bd6937 ("watchdog/hardlockup/perf: Prevent CPU hotplug deadlock") Signed-off-by: Li Huafei Signed-off-by: Ingo Molnar Cc: Thomas Gleixner Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20241021193004.308303-1-lihuafei1@huawei.com Signed-off-by: Sasha Levin commit 1b2a727ed192c91bfea5c99d0440ec441c20093b Author: Kees Cook Date: Tue Mar 4 14:56:11 2025 -0800 kunit/stackinit: Use fill byte different from Clang i386 pattern [ Upstream commit d985e4399adffb58e10b38dbb5479ef29d53cde6 ] The byte initialization values used with -ftrivial-auto-var-init=pattern (CONFIG_INIT_STACK_ALL_PATTERN=y) depends on the compiler, architecture, and byte position relative to struct member types. On i386 with Clang, this includes the 0xFF value, which means it looks like nothing changes between the leaf byte filling pass and the expected "stack wiping" pass of the stackinit test. Use the byte fill value of 0x99 instead, fixing the test for i386 Clang builds. Reported-by: ernsteiswuerfel Closes: https://github.com/ClangBuiltLinux/linux/issues/2071 Fixes: 8c30d32b1a32 ("lib/test_stackinit: Handle Clang auto-initialization pattern") Tested-by: Nathan Chancellor Link: https://lore.kernel.org/r/20250304225606.work.030-kees@kernel.org Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit da0bb972fc7f16fa6910ff207f5a716974928084 Author: Atish Patra Date: Mon Mar 3 14:53:06 2025 -0800 RISC-V: KVM: Disable the kernel perf counter during configure [ Upstream commit bbb622488749478955485765ddff9d56be4a7e4b ] The perf event should be marked disabled during the creation as it is not ready to be scheduled until there is SBI PMU start call or config matching is called with auto start. Otherwise, event add/start gets called during perf_event_create_kernel_counter function. It will be enabled and scheduled to run via perf_event_enable during either the above mentioned scenario. Fixes: 0cb74b65d2e5 ("RISC-V: KVM: Implement perf support without sampling") Reviewed-by: Andrew Jones Signed-off-by: Atish Patra Link: https://lore.kernel.org/r/20250303-kvm_pmu_improve-v2-1-41d177e45929@rivosinc.com Signed-off-by: Anup Patel Signed-off-by: Sasha Levin commit 59f637a90ed29ba074e1e6df3f32f00b025948de Author: Aaron Kling Date: Wed Feb 26 12:51:59 2025 -0600 cpufreq: tegra194: Allow building for Tegra234 [ Upstream commit 4a1e3bf61fc78ad100018adb573355303915dca3 ] Support was added for Tegra234 in the referenced commit, but the Kconfig was not updated to allow building for the arch. Fixes: 273bc890a2a8 ("cpufreq: tegra194: Add support for Tegra234") Signed-off-by: Aaron Kling Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 7db68f9d09e6303c4335b65130d954fefe43c504 Author: Rafael J. Wysocki Date: Thu Feb 27 11:53:50 2025 +0100 PM: sleep: Adjust check before setting power.must_resume [ Upstream commit eeb87d17aceab7803a5a5bcb6cf2817b745157cf ] The check before setting power.must_resume in device_suspend_noirq() does not take power.child_count into account, but it should do that, so use pm_runtime_need_not_resume() in it for this purpose and adjust the comment next to it accordingly. Fixes: 107d47b2b95e ("PM: sleep: core: Simplify the SMART_SUSPEND flag handling") Signed-off-by: Rafael J. Wysocki Reviewed-by: Ulf Hansson Link: https://patch.msgid.link/3353728.44csPzL39Z@rjwysocki.net Signed-off-by: Sasha Levin commit 4ba8398555046de01c30a7726d1c64dcf76e4b38 Author: Peter Zijlstra Date: Mon Nov 4 14:39:10 2024 +0100 lockdep/mm: Fix might_fault() lockdep check of current->mm->mmap_lock [ Upstream commit a1b65f3f7c6f7f0a08a7dba8be458c6415236487 ] Turns out that this commit, about 10 years ago: 9ec23531fd48 ("sched/preempt, mm/fault: Trigger might_sleep() in might_fault() with disabled pagefaults") ... accidentally (and unnessecarily) put the lockdep part of __might_fault() under CONFIG_DEBUG_ATOMIC_SLEEP=y. This is potentially notable because large distributions such as Ubuntu are running with !CONFIG_DEBUG_ATOMIC_SLEEP. Restore the debug check. [ mingo: Update changelog. ] Fixes: 9ec23531fd48 ("sched/preempt, mm/fault: Trigger might_sleep() in might_fault() with disabled pagefaults") Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Cc: Linus Torvalds Cc: Andrew Morton Link: https://lore.kernel.org/r/20241104135517.536628371@infradead.org Signed-off-by: Sasha Levin commit 85bf8a5a3e63ba725239d726f9d5e35f579cfc1c Author: Kevin Loughlin Date: Fri Nov 22 20:23:22 2024 +0000 x86/sev: Add missing RIP_REL_REF() invocations during sme_enable() [ Upstream commit 72dafb567760320f2de7447cd6e979bf9d4e5d17 ] The following commit: 1c811d403afd ("x86/sev: Fix position dependent variable references in startup code") introduced RIP_REL_REF() to force RIP-relative accesses to global variables, as needed to prevent crashes during early SEV/SME startup code. For completeness, RIP_REL_REF() should be used with additional variables during sme_enable(): https://lore.kernel.org/all/CAMj1kXHnA0fJu6zh634=fbJswp59kSRAbhW+ubDGj1+NYwZJ-Q@mail.gmail.com/ Access these vars with RIP_REL_REF() to prevent problem reoccurence. Fixes: 1c811d403afd ("x86/sev: Fix position dependent variable references in startup code") Signed-off-by: Kevin Loughlin Signed-off-by: Ingo Molnar Reviewed-by: Ard Biesheuvel Reviewed-by: Tom Lendacky Cc: Dave Hansen Link: https://lore.kernel.org/r/20241122202322.977678-1-kevinloughlin@google.com Signed-off-by: Sasha Levin commit eb8b61378c41492f1deed7cc7b68fdd5c453bb86 Author: Arnd Bergmann Date: Wed Feb 26 22:37:14 2025 +0100 x86/platform: Only allow CONFIG_EISA for 32-bit [ Upstream commit 976ba8da2f3c2f1e997f4f620da83ae65c0e3728 ] The CONFIG_EISA menu was cleaned up in 2018, but this inadvertently brought the option back on 64-bit machines: ISA remains guarded by a CONFIG_X86_32 check, but EISA no longer depends on ISA. The last Intel machines ith EISA support used a 82375EB PCI/EISA bridge from 1993 that could be paired with the 440FX chipset on early Pentium-II CPUs, long before the first x86-64 products. Fixes: 6630a8e50105 ("eisa: consolidate EISA Kconfig entry in drivers/eisa") Signed-off-by: Arnd Bergmann Signed-off-by: Ingo Molnar Cc: Linus Torvalds Link: https://lore.kernel.org/r/20250226213714.4040853-11-arnd@kernel.org Signed-off-by: Sasha Levin commit 30389684dc8b23c98c8ab7d48a90c89a8837567c Author: Michael Jeanson Date: Tue Feb 25 15:24:46 2025 -0500 rseq: Update kernel fields in lockstep with CONFIG_DEBUG_RSEQ=y [ Upstream commit 79e10dad1ce3feac7937bedf911d92f486a9e76a ] With CONFIG_DEBUG_RSEQ=y, an in-kernel copy of the read-only fields is kept synchronized with the user-space fields. Ensure the updates are done in lockstep in case we error out on a write to user-space. Fixes: 7d5265ffcd8b ("rseq: Validate read-only fields under DEBUG_RSEQ config") Signed-off-by: Michael Jeanson Signed-off-by: Ingo Molnar Reviewed-by: Mathieu Desnoyers Link: https://lore.kernel.org/r/20250225202500.731245-1-mjeanson@efficios.com Signed-off-by: Sasha Levin commit e20390ad6bab09973a8fafbe3e8c0d3cafba2658 Author: Benjamin Berg Date: Wed Feb 26 14:31:36 2025 +0100 x86/fpu: Avoid copying dynamic FP state from init_task in arch_dup_task_struct() [ Upstream commit 5d3b81d4d8520efe888536b6906dc10fd1a228a8 ] The init_task instance of struct task_struct is statically allocated and may not contain the full FP state for userspace. As such, limit the copy to the valid area of both init_task and 'dst' and ensure all memory is initialized. Note that the FP state is only needed for userspace, and as such it is entirely reasonable for init_task to not contain parts of it. Fixes: 5aaeb5c01c5b ("x86/fpu, sched: Introduce CONFIG_ARCH_WANTS_DYNAMIC_TASK_STRUCT and use it on x86") Signed-off-by: Benjamin Berg Signed-off-by: Ingo Molnar Cc: Andy Lutomirski Cc: H. Peter Anvin Cc: Oleg Nesterov Link: https://lore.kernel.org/r/20250226133136.816901-1-benjamin@sipsolutions.net ---- v2: - Fix code if arch_task_struct_size < sizeof(init_task) by using memcpy_and_pad. Signed-off-by: Sasha Levin commit b99c1c63d88c75a4dc5487c3696cda38697b8d35 Author: Dhananjay Ugwekar Date: Wed Feb 5 11:25:21 2025 +0000 cpufreq/amd-pstate: Add missing NULL ptr check in amd_pstate_update [ Upstream commit 426db24d4db2e4f0d6720aeb7795eafcb9e82640 ] Check if policy is NULL before dereferencing it in amd_pstate_update. Fixes: e8f555daacd3 ("cpufreq/amd-pstate: fix setting policy current frequency value") Signed-off-by: Dhananjay Ugwekar Reviewed-by: Mario Limonciello Reviewed-by: Gautham R. Shenoy Link: https://lore.kernel.org/r/20250205112523.201101-11-dhananjay.ugwekar@amd.com Signed-off-by: Mario Limonciello Signed-off-by: Sasha Levin commit 1c4dbe5e1dc8090a61e985dd8701831dbdd261dc Author: Dhananjay Ugwekar Date: Wed Feb 5 11:25:17 2025 +0000 cpufreq/amd-pstate: Convert all perf values to u8 [ Upstream commit 555bbe67a622b297405e246d1868dbda3284bde8 ] All perf values are always within 0-255 range, hence convert their datatype to u8 everywhere. Signed-off-by: Dhananjay Ugwekar Reviewed-by: Mario Limonciello Reviewed-by: Gautham R. Shenoy Link: https://lore.kernel.org/r/20250205112523.201101-7-dhananjay.ugwekar@amd.com Signed-off-by: Mario Limonciello Stable-dep-of: 426db24d4db2 ("cpufreq/amd-pstate: Add missing NULL ptr check in amd_pstate_update") Signed-off-by: Sasha Levin commit 83767dbe6f93916ceead3bee54cf5eddd9b085f9 Author: Dhananjay Ugwekar Date: Wed Feb 5 11:25:16 2025 +0000 cpufreq/amd-pstate: Pass min/max_limit_perf as min/max_perf to amd_pstate_update [ Upstream commit e9869c836b2a460c48e2d69ae79d786303dbffda ] Currently, amd_pstate_update_freq passes the hardware perf limits as min/max_perf to amd_pstate_update, which eventually gets programmed into the min/max_perf fields of the CPPC_REQ register. Instead pass the effective perf limits i.e. min/max_limit_perf values to amd_pstate_update as min/max_perf. Signed-off-by: Dhananjay Ugwekar Reviewed-by: Mario Limonciello Reviewed-by: Gautham R. Shenoy Link: https://lore.kernel.org/r/20250205112523.201101-6-dhananjay.ugwekar@amd.com Signed-off-by: Mario Limonciello Stable-dep-of: 426db24d4db2 ("cpufreq/amd-pstate: Add missing NULL ptr check in amd_pstate_update") Signed-off-by: Sasha Levin commit 95a3068fb2f6203655b065aaa9f1f29f2bffddb0 Author: Dhananjay Ugwekar Date: Wed Feb 5 11:25:14 2025 +0000 cpufreq/amd-pstate: Modify the min_perf calculation in adjust_perf callback [ Upstream commit 6ceb877d5cecd5417d63239bf833a1cd5f8f271c ] Instead of setting a fixed floor at lowest_nonlinear_perf, use the min_limit_perf value, so that it gives the user the freedom to lower the floor further. There are two minimum frequency/perf limits that we need to consider in the adjust_perf callback. One provided by schedutil i.e. the sg_cpu->bw_min value passed in _min_perf arg, another is the effective value of min_freq_qos request that is updated in cpudata->min_limit_perf. Modify the code to use the bigger of these two values. Signed-off-by: Dhananjay Ugwekar Reviewed-by: Mario Limonciello Reviewed-by: Gautham R. Shenoy Link: https://lore.kernel.org/r/20250205112523.201101-4-dhananjay.ugwekar@amd.com Signed-off-by: Mario Limonciello Stable-dep-of: 426db24d4db2 ("cpufreq/amd-pstate: Add missing NULL ptr check in amd_pstate_update") Signed-off-by: Sasha Levin commit abf2a0a0d348eb69209f6f8419ac34736d3b426d Author: Stanislav Spassov Date: Tue Feb 18 14:10:45 2025 +0000 x86/fpu: Fix guest FPU state buffer allocation size [ Upstream commit 1937e18cc3cf27e2b3ef70e8c161437051ab7608 ] Ongoing work on an optimization to batch-preallocate vCPU state buffers for KVM revealed a mismatch between the allocation sizes used in fpu_alloc_guest_fpstate() and fpstate_realloc(). While the former allocates a buffer sized to fit the default set of XSAVE features in UABI form (as per fpu_user_cfg), the latter uses its ksize argument derived (for the requested set of features) in the same way as the sizes found in fpu_kernel_cfg, i.e. using the compacted in-kernel representation. The correct size to use for guest FPU state should indeed be the kernel one as seen in fpstate_realloc(). The original issue likely went unnoticed through a combination of UABI size typically being larger than or equal to kernel size, and/or both amounting to the same number of allocated 4K pages. Fixes: 69f6ed1d14c6 ("x86/fpu: Provide infrastructure for KVM FPU cleanup") Signed-off-by: Stanislav Spassov Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20250218141045.85201-1-stanspas@amazon.de Signed-off-by: Sasha Levin commit 7c342513ed30323b85f46d7d1cdb4946f08fea94 Author: Thomas Weißschuh Date: Tue Feb 4 13:05:33 2025 +0100 x86/vdso: Fix latent bug in vclock_pages calculation [ Upstream commit 3ef32d90cdaa0cfa6c4ffd18f8d646a658163e3d ] The vclock pages are *after* the non-vclock pages. Currently there are both two vclock and two non-vclock pages so the existing logic works by accident. As soon as the number of pages changes it will break however. This will be the case with the introduction of the generic vDSO data storage. Use a macro to keep the calculation understandable and in sync between the linker script and mapping code. Fixes: e93d2521b27f ("x86/vdso: Split virtual clock pages into dedicated mapping") Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/20250204-vdso-store-rng-v3-1-13a4669dfc8c@linutronix.de Signed-off-by: Sasha Levin commit 8ccd606de3f6cfc47d4a705b999ce5de5ea59010 Author: Qiuxu Zhuo Date: Fri Feb 14 08:27:28 2025 +0800 EDAC/{skx_common,i10nm}: Fix some missing error reports on Emerald Rapids [ Upstream commit d9207cf7760f5f5599e9ff7eb0fedf56821a1d59 ] When doing error injection to some memory DIMMs on certain Intel Emerald Rapids servers, the i10nm_edac missed error reports for some memory DIMMs. Certain BIOS configurations may hide some memory controllers, and the i10nm_edac doesn't enumerate these hidden memory controllers. However, the ADXL decodes memory errors using memory controller physical indices even if there are hidden memory controllers. Therefore, the memory controller physical indices reported by the ADXL may mismatch the logical indices enumerated by the i10nm_edac, resulting in missed error reports for some memory DIMMs. Fix this issue by creating a mapping table from memory controller physical indices (used by the ADXL) to logical indices (used by the i10nm_edac) and using it to convert the physical indices to the logical indices during the error handling process. Fixes: c545f5e41225 ("EDAC/i10nm: Skip the absent memory controllers") Reported-by: Kevin Chang Tested-by: Kevin Chang Reported-by: Thomas Chen Tested-by: Thomas Chen Signed-off-by: Qiuxu Zhuo Signed-off-by: Tony Luck Link: https://lore.kernel.org/r/20250214002728.6287-1-qiuxu.zhuo@intel.com Signed-off-by: Sasha Levin commit 59e255db43b6513c3584b23429154663543d688f Author: Qiuxu Zhuo Date: Wed Feb 12 16:33:54 2025 +0800 EDAC/igen6: Fix the flood of invalid error reports [ Upstream commit 267e5b1d267539d9a927dc04aab6f15aca57da92 ] The ECC_ERROR_LOG register of certain SoCs may contain the invalid value ~0, which results in a flood of invalid error reports in polling mode. Fix the flood of invalid error reports by skipping the invalid ECC error log value ~0. Fixes: e14232afa944 ("EDAC/igen6: Add polling support") Reported-by: Ramses Closes: https://lore.kernel.org/all/OISL8Rv--F-9@well-founded.dev/ Tested-by: Ramses Reported-by: John Closes: https://lore.kernel.org/all/p5YcxOE6M3Ncxpn2-Ia_wCt61EM4LwIiN3LroQvT_-G2jMrFDSOW5k2A9D8UUzD2toGpQBN1eI0sL5dSKnkO8iteZegLoQEj-DwQaMhGx4A=@proton.me/ Tested-by: John Signed-off-by: Qiuxu Zhuo Signed-off-by: Tony Luck Link: https://lore.kernel.org/r/20250212083354.31919-1-qiuxu.zhuo@intel.com Signed-off-by: Sasha Levin commit 42e37ff839b639f2a3f01bfd65e8ce125de99c5c Author: Jie Zhan Date: Thu Feb 13 11:55:10 2025 +0800 cpufreq: governor: Fix negative 'idle_time' handling in dbs_update() [ Upstream commit 3698dd6b139dc37b35a9ad83d9330c1f99666c02 ] We observed an issue that the CPU frequency can't raise up with a 100% CPU load when NOHZ is off and the 'conservative' governor is selected. 'idle_time' can be negative if it's obtained from get_cpu_idle_time_jiffy() when NOHZ is off. This was found and explained in commit 9485e4ca0b48 ("cpufreq: governor: Fix handling of special cases in dbs_update()"). However, commit 7592019634f8 ("cpufreq: governors: Fix long idle detection logic in load calculation") introduced a comparison between 'idle_time' and 'samling_rate' to detect a long idle interval. While 'idle_time' is converted to int before comparison, it's actually promoted to unsigned again when compared with an unsigned 'sampling_rate'. Hence, this leads to wrong idle interval detection when it's in fact 100% busy and sets policy_dbs->idle_periods to a very large value. 'conservative' adjusts the frequency to minimum because of the large 'idle_periods', such that the frequency can't raise up. 'Ondemand' doesn't use policy_dbs->idle_periods so it fortunately avoids the issue. Correct negative 'idle_time' to 0 before any use of it in dbs_update(). Fixes: 7592019634f8 ("cpufreq: governors: Fix long idle detection logic in load calculation") Signed-off-by: Jie Zhan Reviewed-by: Chen Yu Link: https://patch.msgid.link/20250213035510.2402076-1-zhanjie9@hisilicon.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 61c16eaaaf5026ca4596f045ee5b60c93de1754f Author: Tianchen Ding Date: Tue Feb 11 14:36:59 2025 +0800 sched/eevdf: Force propagating min_slice of cfs_rq when {en,de}queue tasks [ Upstream commit 563bc2161b94571ea425bbe2cf69fd38e24cdedf ] When a task is enqueued and its parent cgroup se is already on_rq, this parent cgroup se will not be enqueued again, and hence the root->min_slice leaves unchanged. The same issue happens when a task is dequeued and its parent cgroup se has other runnable entities, and the parent cgroup se will not be dequeued. Force propagating min_slice when se doesn't need to be enqueued or dequeued. Ensure the se hierarchy always get the latest min_slice. Fixes: aef6987d8954 ("sched/eevdf: Propagate min_slice up the cgroup hierarchy") Signed-off-by: Tianchen Ding Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20250211063659.7180-1-dtcccc@linux.alibaba.com Signed-off-by: Sasha Levin commit 6a017ba3138a772879f5b7155bbd290d34063713 Author: zihan zhou <15645113830zzh@gmail.com> Date: Sat Feb 8 16:08:52 2025 +0800 sched: Cancel the slice protection of the idle entity [ Upstream commit f553741ac8c0e467a3b873e305f34b902e50b86d ] A wakeup non-idle entity should preempt idle entity at any time, but because of the slice protection of the idle entity, the non-idle entity has to wait, so just cancel it. This patch is aimed at minimizing the impact of SCHED_IDLE on SCHED_NORMAL. For example, a task with SCHED_IDLE policy that sleeps for 1s and then runs for 3 ms, running cyclictest on the same cpu, has a maximum latency of 3 ms, which is caused by the slice protection of the idle entity. It is unreasonable. With this patch, the cyclictest latency under the same conditions is basically the same on the cpu with idle processes and on empty cpu. [peterz: add helpers] Fixes: 63304558ba5d ("sched/eevdf: Curb wakeup-preemption") Signed-off-by: zihan zhou <15645113830zzh@gmail.com> Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Vincent Guittot Tested-by: Vincent Guittot Link: https://lkml.kernel.org/r/20250208080850.16300-1-15645113830zzh@gmail.com Signed-off-by: Sasha Levin commit 3e1ca06c4da72513163f28e24a580ceda6553473 Author: Konstantin Andreev Date: Sun Jan 26 17:07:27 2025 +0300 smack: ipv4/ipv6: tcp/dccp/sctp: fix incorrect child socket label [ Upstream commit 6cce0cc3861337b3ad8d4ac131d6e47efa0954ec ] Since inception [1], SMACK initializes ipv* child socket security for connection-oriented communications (tcp/sctp/dccp) during accept() syscall, in the security_sock_graft() hook: | void smack_sock_graft(struct sock *sk, ...) | { | // only ipv4 and ipv6 are eligible here | // ... | ssp = sk->sk_security; // socket security | ssp->smk_in = skp; // process label: smk_of_current() | ssp->smk_out = skp; // process label: smk_of_current() | } This approach is incorrect for two reasons: A) initialization occurs too late for child socket security: The child socket is created by the kernel once the handshake completes (e.g., for tcp: after receiving ack for syn+ack). Data can legitimately start arriving to the child socket immediately, long before the application calls accept() on the socket. Those data are (currently — were) processed by SMACK using incorrect child socket security attributes. B) Incoming connection requests are handled using the listening socket's security, hence, the child socket must inherit the listening socket's security attributes. smack_sock_graft() initilizes the child socket's security with a process label, as is done for a new socket() But ... the process label is not necessarily the same as the listening socket label. A privileged application may legitimately set other in/out labels for a listening socket. When this happens, SMACK processes incoming packets using incorrect socket security attributes. In [2] Michael Lontke noticed (A) and fixed it in [3] by adding socket initialization into security_sk_clone_security() hook like | void smack_sk_clone_security(struct sock *oldsk, struct sock *newsk) | { | *(struct socket_smack *)newsk->sk_security = | *(struct socket_smack *)oldsk->sk_security; | } This initializes the child socket security with the parent (listening) socket security at the appropriate time. I was forced to revisit this old story because smack_sock_graft() was left in place by [3] and continues overwriting the child socket's labels with the process label, and there might be a reason for this, so I undertook a study. If the process label differs from the listening socket's labels, the following occurs for ipv4: assigning the smk_out is not accompanied by netlbl_sock_setattr, so the outgoing packet's cipso label does not change. So, the only effect of this assignment for interhost communications is a divergence between the program-visible “out” socket label and the cipso network label. For intrahost communications this label, however, becomes visible via secmark netfilter marking, and is checked for access rights by the client, receiving side. Assigning the smk_in affects both interhost and intrahost communications: the server begins to check access rights against an wrong label. Access check against wrong label (smk_in or smk_out), unsurprisingly fails, breaking the connection. The above affects protocols that calls security_sock_graft() during accept(), namely: {tcp,dccp,sctp}/{ipv4,ipv6} One extra security_sock_graft() caller, crypto/af_alg.c`af_alg_accept is not affected, because smack_sock_graft() does nothing for PF_ALG. To reproduce, assign non-default in/out labels to a listening socket, setup rules between these labels and client label, attempt to connect and send some data. Ipv6 specific: ipv6 packets do not convey SMACK labels. To reproduce the issue in interhost communications set opposite labels in /smack/ipv6host on both hosts. Ipv6 intrahost communications do not require tricking, because SMACK labels are conveyed via secmark netfilter marking. So, currently smack_sock_graft() is not useful, but harmful, therefore, I have removed it. This fixes the issue for {tcp,dccp}/{ipv4,ipv6}, but not sctp/{ipv4,ipv6}. Although this change is necessary for sctp+smack to function correctly, it is not sufficient because: sctp/ipv4 does not call security_sk_clone() and sctp/ipv6 ignores SMACK completely. These are separate issues, belong to other subsystem, and should be addressed separately. [1] 2008-02-04, Fixes: e114e473771c ("Smack: Simplified Mandatory Access Control Kernel") [2] Michael Lontke, 2022-08-31, SMACK LSM checks wrong object label during ingress network traffic Link: https://lore.kernel.org/linux-security-module/6324997ce4fc092c5020a4add075257f9c5f6442.camel@elektrobit.com/ [3] 2022-08-31, michael.lontke, commit 4ca165fc6c49 ("SMACK: Add sk_clone_security LSM hook") Signed-off-by: Konstantin Andreev Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin commit c32dfad48f0bba47fe808af0588719738b7c8655 Author: Konstantin Andreev Date: Fri Jan 17 19:36:42 2025 +0300 smack: dont compile ipv6 code unless ipv6 is configured [ Upstream commit bfcf4004bcbce2cb674b4e8dbd31ce0891766bac ] I want to be sure that ipv6-specific code is not compiled in kernel binaries if ipv6 is not configured. [1] was getting rid of "unused variable" warning, but, with that, it also mandated compilation of a handful ipv6- specific functions in ipv4-only kernel configurations: smk_ipv6_localhost, smack_ipv6host_label, smk_ipv6_check. Their compiled bodies are likely to be removed by compiler from the resulting binary, but, to be on the safe side, I remove them from the compiler view. [1] Fixes: 00720f0e7f28 ("smack: avoid unused 'sip' variable warning") Signed-off-by: Konstantin Andreev Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin commit 4e4346494654f71a91042f1567dac3744d53864d Author: Oleg Nesterov Date: Tue Jan 28 16:03:07 2025 +0100 seccomp: fix the __secure_computing() stub for !HAVE_ARCH_SECCOMP_FILTER [ Upstream commit b37778bec82ba82058912ca069881397197cd3d5 ] Depending on CONFIG_HAVE_ARCH_SECCOMP_FILTER, __secure_computing(NULL) will crash or not. This is not consistent/safe, especially considering that after the previous change __secure_computing(sd) is always called with sd == NULL. Fortunately, if CONFIG_HAVE_ARCH_SECCOMP_FILTER=n, __secure_computing() has no callers, these architectures use secure_computing_strict(). Yet it make sense make __secure_computing(NULL) safe in this case. Note also that with this change we can unexport secure_computing_strict() and change the current callers to use __secure_computing(NULL). Fixes: 8cf8dfceebda ("seccomp: Stub for !HAVE_ARCH_SECCOMP_FILTER") Signed-off-by: Oleg Nesterov Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20250128150307.GA15325@redhat.com Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 11769835a5da88572f0d5c26e9de803f7932e305 Author: zuoqian Date: Sat Jan 25 08:49:49 2025 +0000 cpufreq: scpi: compare kHz instead of Hz [ Upstream commit 4742da9774a416908ef8e3916164192c15c0e2d1 ] The CPU rate from clk_get_rate() may not be divisible by 1000 (e.g., 133333333). But the rate calculated from frequency(kHz) is always divisible by 1000 (e.g., 133333000). Comparing the rate causes a warning during CPU scaling: "cpufreq: __target_index: Failed to change cpu frequency: -5". When we choose to compare kHz here, the issue does not occur. Fixes: 343a8d17fa8d ("cpufreq: scpi: remove arm_big_little dependency") Signed-off-by: zuoqian Reviewed-by: Dan Carpenter Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 4f8f80a768bcfe36deb68ec3cae97655af762e33 Author: Geert Uytterhoeven Date: Mon Jan 20 16:40:22 2025 +0100 m68k: sun3: Fix DEBUG_MMU_EMU build [ Upstream commit 723be3c6ab31b320afe0075e2eb9b8dd41f3b6d1 ] With DEBUG_MMU_EMU enabled: arch/m68k/sun3/mmu_emu.c: In function ‘mmu_emu_handle_fault’: arch/m68k/sun3/mmu_emu.c:420:38: error: implicit declaration of function ‘get_fs’; did you mean ‘sget_fc’? [-Werror=implicit-function-declaration] 420 | pr_info("seg:%ld crp:%p ->", get_fs().seg, crp); | ^~~~~~ [...] arch/m68k/sun3/mmu_emu.c:420:46: error: request for member ‘seg’ in something not a structure or union 420 | pr_info("seg:%ld crp:%p ->", get_fs().seg, crp); | ^ Fix this by reintroducing and using a helper to retrieve the current value of the DFC register. While at it, replace "%p" by "%px", as there is no point in printing obfuscated pointers during debugging. Fixes: 9fde0348640252c7 ("m68k: Remove set_fs()") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/b1d12a1d24b4aea9f98d905383ba932b2dc382e6.1737387419.git.geert@linux-m68k.org Signed-off-by: Sasha Levin commit ede1c5f489083a98d78f01761278953f1d9106ee Author: Thorsten Blum Date: Fri Jan 17 13:06:05 2025 +0100 m68k: sun3: Use str_read_write() helper in mmu_emu_handle_fault() [ Upstream commit 751b3d8d886e73ecc24a5426adba228ef7eb39e8 ] Remove hard-coded strings by using the str_read_write() helper. Signed-off-by: Thorsten Blum Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/20250117120605.126941-2-thorsten.blum@linux.dev Signed-off-by: Geert Uytterhoeven Stable-dep-of: 723be3c6ab31 ("m68k: sun3: Fix DEBUG_MMU_EMU build") Signed-off-by: Sasha Levin commit d89e42b4b58bfc470736d34c3240b11e86276ee6 Author: Mike Rapoport (Microsoft) Date: Sun Jan 26 09:47:25 2025 +0200 x86/mm/pat: cpa-test: fix length for CPA_ARRAY test [ Upstream commit 33ea120582a638b2f2e380a50686c2b1d7cce795 ] The CPA_ARRAY test always uses len[1] as numpages argument to change_page_attr_set() although the addresses array is different each iteration of the test loop. Replace len[1] with len[i] to have numpages matching the addresses array. Fixes: ecc729f1f471 ("x86/mm/cpa: Add ARRAY and PAGES_ARRAY selftests") Signed-off-by: "Mike Rapoport (Microsoft)" Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20250126074733.1384926-2-rppt@kernel.org Signed-off-by: Sasha Levin commit 205028ebba838938d3b264dda1d0708fa7fe1ade Author: Eric Sandeen Date: Thu Feb 27 11:41:08 2025 -0600 watch_queue: fix pipe accounting mismatch [ Upstream commit f13abc1e8e1a3b7455511c4e122750127f6bc9b0 ] Currently, watch_queue_set_size() modifies the pipe buffers charged to user->pipe_bufs without updating the pipe->nr_accounted on the pipe itself, due to the if (!pipe_has_watch_queue()) test in pipe_resize_ring(). This means that when the pipe is ultimately freed, we decrement user->pipe_bufs by something other than what than we had charged to it, potentially leading to an underflow. This in turn can cause subsequent too_many_pipe_buffers_soft() tests to fail with -EPERM. To remedy this, explicitly account for the pipe usage in watch_queue_set_size() to match the number set via account_pipe_buffers() (It's unclear why watch_queue_set_size() does not update nr_accounted; it may be due to intentional overprovisioning in watch_queue_set_size()?) Fixes: e95aada4cb93d ("pipe: wakeup wr_wait after setting max_usage") Signed-off-by: Eric Sandeen Link: https://lore.kernel.org/r/206682a8-0604-49e5-8224-fdbe0c12b460@redhat.com Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 1d0782a68a32838c69bd679f101d297775dd044a Author: Christian Brauner Date: Mon Feb 10 13:38:59 2025 +0100 fs: support O_PATH fds with FSCONFIG_SET_FD [ Upstream commit 0ff053b98a0f039e52c2bd8d0cb38f2831edfaf5 ] Let FSCONFIG_SET_FD handle O_PATH file descriptors. This is particularly useful in the context of overlayfs where layers can be specified via file descriptors instead of paths. But userspace must currently use non-O_PATH file desriptors which is often pointless especially if the file descriptors have been created via open_tree(OPEN_TREE_CLONE). Link: https://lore.kernel.org/r/20250210-work-overlayfs-v2-1-ed2a949b674b@kernel.org Fixes: a08557d19ef41 ("ovl: specify layers via file descriptors") Reviewed-by: Amir Goldstein Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin