summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-10-28selftests/intel_pstate: check if cpupower is installedAlessandro Zanni
Running "make kselftest TARGETS=intel_pstate" results in the following errors: - ./run.sh: line 89: cpupower: command not found - ./run.sh: line 91: cpupower: command not found if the cpupower is not installed. Since the test depends on cpupower, this patch stops the test if the cpupower is not installed. Link: https://lore.kernel.org/all/cc01753c8dab0f33669a5a0fc162544078055bd1.1730141362.git.alessandro.zanni87@gmail.com/ Signed-off-by: Alessandro Zanni <alessandro.zanni87@gmail.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2024-10-28selftests/intel_pstate: fix operand expected errorAlessandro Zanni
Running "make kselftest TARGETS=intel_pstate" results in the following errors: - ./run.sh: line 90: / 1000: syntax error: operand expected (error token is "/ 1000") - ./run.sh: line 92: / 1000: syntax error: operand expected (error token is "/ 1000") This fix allows to have cross-platform compatibility when using arithmetic expression with command substitutions. Link: https://lore.kernel.org/r/f37df23888cd5ea6b3976f19d3e25796129dd090.1730141362.git.alessandro.zanni87@gmail.com Signed-off-by: Alessandro Zanni <alessandro.zanni87@gmail.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2024-10-28selftests/mount_setattr: fix idmap_mount_tree_invalid failed to runzhouyuhang
Test case idmap_mount_tree_invalid failed to run on the newer kernel with the following output: # RUN mount_setattr_idmapped.idmap_mount_tree_invalid ... # mount_setattr_test.c:1428:idmap_mount_tree_invalid:Expected sys_mount_setattr(open_tree_fd, "", AT_EMPTY_PATH, &attr, sizeof(attr)) (0) ! = 0 (0) # idmap_mount_tree_invalid: Test terminated by assertion This is because tmpfs is mounted at "/mnt/A", and tmpfs already contains the flag FS_ALLOW_IDMAP after the commit 7a80e5b8c6fa ("shmem: support idmapped mounts for tmpfs"). So calling sys_mount_setattr here returns 0 instead of -EINVAL as expected. Ramfs does not support idmap mounts, so we can use it here to test invalid mounts, which allows the test case to pass with the following output: # Starting 1 tests from 1 test cases. # RUN mount_setattr_idmapped.idmap_mount_tree_invalid ... # OK mount_setattr_idmapped.idmap_mount_tree_invalid ok 1 mount_setattr_idmapped.idmap_mount_tree_invalid # PASSED: 1 / 1 tests passed. Link: https://lore.kernel.org/all/20241028084132.3212598-1-zhouyuhang1010@163.com/ Signed-off-by: zhouyuhang <zhouyuhang@kylinos.cn> Reviewed-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2024-10-29Merge tag 'thunderbolt-for-v6.12-rc5' of ↵Greg Kroah-Hartman
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-linus Mika writes: thunderbolt: Fixes for v6.12-rc5 This includes following USB4/Thunderbolt fixes for v6.12-rc5: - Fix KASAN reported stack out-of-bounds read - Honor Time Management Unit (TMU) requirements in the domain when configuring TMU mode of a newly plugged router. Both have been in linux-next with no reported issues. * tag 'thunderbolt-for-v6.12-rc5' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt: thunderbolt: Honor TMU requirements in the domain when setting TMU mode thunderbolt: Fix KASAN reported stack out-of-bounds read in tb_retimer_scan()
2024-10-29Merge tag 'iio-fixes-for-6.12b' of ↵Greg Kroah-Hartman
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/jic23/iio into char-misc-next Jonathan writes: IIO: Fixes for 6.12, set 2 Usual mixed back of fixes for ancient bugs and some more recently introduced problems. gts-helper module - Memory leak fixes for this library code to handle complex gain cases. adi,ad7124 - Fix a divide by zero that can be triggered from userspace. adi,ad7380 - Various supply fixes. Includes some minor rework that simplifies the fix though increases the apparent scale of the change. adi,ad9832 - Avoid a potential divide by zero if clk_get_rate() returns 0. adi,ltc2642 - Fix wrong Kconfig regmap dependency. vishay,veml6030 - Fix a scaling problem with decimal part of processed channel. Note that only the illuminance channel is fixed as a larger series of cleanups not suitable for this point in the rc cycle removes the intensity channel anyway. * tag 'iio-fixes-for-6.12b' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/jic23/iio: iio: dac: Kconfig: Fix build error for ltc2664 iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr() staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg() docs: iio: ad7380: fix supply for ad7380-4 iio: adc: ad7380: fix supplies for ad7380-4 iio: adc: ad7380: add missing supplies iio: adc: ad7380: use devm_regulator_get_enable_read_voltage() dt-bindings: iio: adc: ad7380: fix ad7380-4 reference supply iio: light: veml6030: fix microlux value calculation iio: gts-helper: Fix memory leaks for the error path of iio_gts_build_avail_scale_table() iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table()
2024-10-29mei: use kvmalloc for read bufferAlexander Usyskin
Read buffer is allocated according to max message size, reported by the firmware and may reach 64K in systems with pxp client. Contiguous 64k allocation may fail under memory pressure. Read buffer is used as in-driver message storage and not required to be contiguous. Use kvmalloc to allow kernel to allocate non-contiguous memory. Fixes: 3030dc056459 ("mei: add wrapper for queuing control commands.") Cc: stable <stable@kernel.org> Reported-by: Rohit Agarwal <rohiagar@chromium.org> Closes: https://lore.kernel.org/all/20240813084542.2921300-1-rohiagar@chromium.org/ Tested-by: Brian Geffon <bgeffon@google.com> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Acked-by: Tomas Winkler <tomasw@gmail.com> Link: https://lore.kernel.org/r/20241015123157.2337026-1-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-10-29MAINTAINERS: add netup_unidvb maintainerAbylay Ospan
Adding/restoring maintainership for the following drivers: F: drivers/media/pci/netup_unidvb/* F: drivers/media/dvb-frontends/helene* F: drivers/media/dvb-frontends/horus3a* F: drivers/media/dvb-frontends/lnbh25* F: drivers/media/dvb-frontends/ascot2e* F: drivers/media/dvb-frontends/cxd2841er* Signed-off-by: Abylay Ospan <aospan@amazon.com> Link: https://lore.kernel.org/r/20241023163425.30492-1-aospan@amazon.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-10-28sock_map: fix a NULL pointer dereference in sock_map_link_update_prog()Cong Wang
The following race condition could trigger a NULL pointer dereference: sock_map_link_detach(): sock_map_link_update_prog(): mutex_lock(&sockmap_mutex); ... sockmap_link->map = NULL; mutex_unlock(&sockmap_mutex); mutex_lock(&sockmap_mutex); ... sock_map_prog_link_lookup(sockmap_link->map); mutex_unlock(&sockmap_mutex); <continue> Fix it by adding a NULL pointer check. In this specific case, it makes no sense to update a link which is being released. Reported-by: Ruan Bonan <bonan.ruan@u.nus.edu> Fixes: 699c23f02c65 ("bpf: Add bpf_link support for sk_msg and sk_skb progs") Cc: Yonghong Song <yonghong.song@linux.dev> Cc: John Fastabend <john.fastabend@gmail.com> Cc: Jakub Sitnicki <jakub@cloudflare.com> Signed-off-by: Cong Wang <cong.wang@bytedance.com> Link: https://lore.kernel.org/r/20241026185522.338562-1-xiyou.wangcong@gmail.com Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
2024-10-29Revert "driver core: Fix uevent_show() vs driver detach race"Greg Kroah-Hartman
This reverts commit 15fffc6a5624b13b428bb1c6e9088e32a55eb82c. This commit causes a regression, so revert it for now until it can come back in a way that works for everyone. Link: https://lore.kernel.org/all/172790598832.1168608.4519484276671503678.stgit@dwillia2-xfh.jf.intel.com/ Fixes: 15fffc6a5624 ("driver core: Fix uevent_show() vs driver detach race") Cc: stable <stable@kernel.org> Cc: Ashish Sangwan <a.sangwan@samsung.com> Cc: Namjae Jeon <namjae.jeon@samsung.com> Cc: Dirk Behme <dirk.behme@de.bosch.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Rafael J. Wysocki <rafael@kernel.org> Cc: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-10-28ASoC: dapm: fix bounds checker error in dapm_widget_list_createAleksei Vetrov
The widgets array in the snd_soc_dapm_widget_list has a __counted_by attribute attached to it, which points to the num_widgets variable. This attribute is used in bounds checking, and if it is not set before the array is filled, then the bounds sanitizer will issue a warning or a kernel panic if CONFIG_UBSAN_TRAP is set. This patch sets the size of the widgets list calculated with list_for_each as the initial value for num_widgets as it is used for allocating memory for the array. It is updated with the actual number of added elements after the array is filled. Signed-off-by: Aleksei Vetrov <vvvvvv@google.com> Fixes: 80e698e2df5b ("ASoC: soc-dapm: Annotate struct snd_soc_dapm_widget_list with __counted_by") Link: https://patch.msgid.link/20241028-soc-dapm-bounds-checker-fix-v1-1-262b0394e89e@google.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-10-28usb: add support for new USB device ID 0x17EF:0x3098 for the r8152 driverBenjamin Große
This patch adds support for another Lenovo Mini dock 0x17EF:0x3098 to the r8152 driver. The device has been tested on NixOS, hotplugging and sleep included. Signed-off-by: Benjamin Große <ste3ls@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20241020174128.160898-1-ste3ls@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-28macsec: Fix use-after-free while sending the offloading packetJianbo Liu
KASAN reports the following UAF. The metadata_dst, which is used to store the SCI value for macsec offload, is already freed by metadata_dst_free() in macsec_free_netdev(), while driver still use it for sending the packet. To fix this issue, dst_release() is used instead to release metadata_dst. So it is not freed instantly in macsec_free_netdev() if still referenced by skb. BUG: KASAN: slab-use-after-free in mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] Read of size 2 at addr ffff88813e42e038 by task kworker/7:2/714 [...] Workqueue: mld mld_ifc_work Call Trace: <TASK> dump_stack_lvl+0x51/0x60 print_report+0xc1/0x600 kasan_report+0xab/0xe0 mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] dev_hard_start_xmit+0x120/0x530 sch_direct_xmit+0x149/0x11e0 __qdisc_run+0x3ad/0x1730 __dev_queue_xmit+0x1196/0x2ed0 vlan_dev_hard_start_xmit+0x32e/0x510 [8021q] dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 macsec_start_xmit+0x13e9/0x2340 dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 ip6_finish_output2+0x923/0x1a70 ip6_finish_output+0x2d7/0x970 ip6_output+0x1ce/0x3a0 NF_HOOK.constprop.0+0x15f/0x190 mld_sendpack+0x59a/0xbd0 mld_ifc_work+0x48a/0xa80 process_one_work+0x5aa/0xe50 worker_thread+0x79c/0x1290 kthread+0x28f/0x350 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x11/0x20 </TASK> Allocated by task 3922: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x77/0x90 __kmalloc_noprof+0x188/0x400 metadata_dst_alloc+0x1f/0x4e0 macsec_newlink+0x914/0x1410 __rtnl_newlink+0xe08/0x15b0 rtnl_newlink+0x5f/0x90 rtnetlink_rcv_msg+0x667/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 4011: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x50 poison_slab_object+0x10c/0x190 __kasan_slab_free+0x11/0x30 kfree+0xe0/0x290 macsec_free_netdev+0x3f/0x140 netdev_run_todo+0x450/0xc70 rtnetlink_rcv_msg+0x66f/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Fixes: 0a28bfd4971f ("net/macsec: Add MACsec skb_metadata_dst Tx Data path support") Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Patrisious Haddad <phaddad@nvidia.com> Reviewed-by: Chris Mi <cmi@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> Link: https://patch.msgid.link/20241021100309.234125-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-28Merge branch 'mptcp-sched-fix-some-lock-issues'Jakub Kicinski
Matthieu Baerts says: ==================== mptcp: sched: fix some lock issues Two small fixes related to the MPTCP packets scheduler: - Patch 1: add missing rcu_read_(un)lock(). A fix for >= 6.6. And some modifications in the MPTCP selftests: - Patch 2: a small addition to the MPTCP selftests to cover more code. ==================== Link: https://patch.msgid.link/20241021-net-mptcp-sched-lock-v1-0-637759cf061c@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-28selftests: mptcp: list sysctl dataMatthieu Baerts (NGI0)
Listing all the values linked to the MPTCP sysctl knobs was not exercised in MPTCP test suite. Let's do that to avoid any regressions, but also to have a kernel with a debug kconfig verifying more assumptions. For the moment, we are not interested by the output, only to avoid crashes and warnings. Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20241021-net-mptcp-sched-lock-v1-3-637759cf061c@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-28mptcp: init: protect sched with rcu_read_lockMatthieu Baerts (NGI0)
Enabling CONFIG_PROVE_RCU_LIST with its dependence CONFIG_RCU_EXPERT creates this splat when an MPTCP socket is created: ============================= WARNING: suspicious RCU usage 6.12.0-rc2+ #11 Not tainted ----------------------------- net/mptcp/sched.c:44 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 no locks held by mptcp_connect/176. stack backtrace: CPU: 0 UID: 0 PID: 176 Comm: mptcp_connect Not tainted 6.12.0-rc2+ #11 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) mptcp_sched_find (net/mptcp/sched.c:44 (discriminator 7)) mptcp_init_sock (net/mptcp/protocol.c:2867 (discriminator 1)) ? sock_init_data_uid (arch/x86/include/asm/atomic.h:28) inet_create.part.0.constprop.0 (net/ipv4/af_inet.c:386) ? __sock_create (include/linux/rcupdate.h:347 (discriminator 1)) __sock_create (net/socket.c:1576) __sys_socket (net/socket.c:1671) ? __pfx___sys_socket (net/socket.c:1712) ? do_user_addr_fault (arch/x86/mm/fault.c:1419 (discriminator 1)) __x64_sys_socket (net/socket.c:1728) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) That's because when the socket is initialised, rcu_read_lock() is not used despite the explicit comment written above the declaration of mptcp_sched_find() in sched.c. Adding the missing lock/unlock avoids the warning. Fixes: 1730b2b2c5a5 ("mptcp: add sched in mptcp_sock") Cc: stable@vger.kernel.org Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/523 Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20241021-net-mptcp-sched-lock-v1-1-637759cf061c@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-28docs: networking: packet_mmap: replace dead links with archive.org linksLevi Zim
The original link returns 404 now. This commit replaces the dead google site link with archive.org link. Signed-off-by: Levi Zim <rsworktech@outlook.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20241021-packet_mmap_fix_link-v1-1-dffae4a174c0@outlook.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-29tpm: Lazily flush the auth sessionJarkko Sakkinen
Move the allocation of chip->auth to tpm2_start_auth_session() so that this field can be used as flag to tell whether auth session is active or not. Instead of flushing and reloading the auth session for every transaction separately, keep the session open unless /dev/tpm0 is used. Reported-by: Pengyu Ma <mapengyu@gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219229 Cc: stable@vger.kernel.org # v6.10+ Fixes: 7ca110f2679b ("tpm: Address !chip->auth in tpm_buf_append_hmac_session*()") Tested-by: Pengyu Ma <mapengyu@gmail.com> Tested-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2024-10-28drm/amdgpu/smu13: fix profile reportingAlex Deucher
The following 3 commits landed in parallel: commit d7d2688bf4ea ("drm/amd/pm: update workload mask after the setting") commit 7a1613e47e65 ("drm/amdgpu/smu13: always apply the powersave optimization") commit 7c210ca5a2d7 ("drm/amdgpu: handle default profile on on devices without fullscreen 3D") While everything is set correctly, this caused the profile to be reported incorrectly because both the powersave and fullscreen3d bits were set in the mask and when the driver prints the profile, it looks for the first bit set. Fixes: d7d2688bf4ea ("drm/amd/pm: update workload mask after the setting") Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit ecfe9b237687a55d596fff0650ccc8cc455edd3f) Cc: stable@vger.kernel.org
2024-10-28Merge tag 'spi-fix-v6.12-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi fixes from Mark Brown: "A small collection of driver specific fixes for SPI, there's nothing particularly remarkable about any of them" * tag 'spi-fix-v6.12-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: spi-fsl-dspi: Fix crash when not using GPIO chip select spi: geni-qcom: Fix boot warning related to pm_runtime and devres spi: mtk-snfi: fix kerneldoc for mtk_snand_is_page_ops() spi: stm32: fix missing device mode capability in stm32mp25
2024-10-28drm/amd/pm: Vangogh: Fix kernel memory out of bounds writeTvrtko Ursulin
KASAN reports that the GPU metrics table allocated in vangogh_tables_init() is not large enough for the memset done in smu_cmn_init_soft_gpu_metrics(). Condensed report follows: [ 33.861314] BUG: KASAN: slab-out-of-bounds in smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu] [ 33.861799] Write of size 168 at addr ffff888129f59500 by task mangoapp/1067 ... [ 33.861808] CPU: 6 UID: 1000 PID: 1067 Comm: mangoapp Tainted: G W 6.12.0-rc4 #356 1a56f59a8b5182eeaf67eb7cb8b13594dd23b544 [ 33.861816] Tainted: [W]=WARN [ 33.861818] Hardware name: Valve Galileo/Galileo, BIOS F7G0107 12/01/2023 [ 33.861822] Call Trace: [ 33.861826] <TASK> [ 33.861829] dump_stack_lvl+0x66/0x90 [ 33.861838] print_report+0xce/0x620 [ 33.861853] kasan_report+0xda/0x110 [ 33.862794] kasan_check_range+0xfd/0x1a0 [ 33.862799] __asan_memset+0x23/0x40 [ 33.862803] smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.863306] vangogh_get_gpu_metrics_v2_4+0x123/0xad0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.864257] vangogh_common_get_gpu_metrics+0xb0c/0xbc0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.865682] amdgpu_dpm_get_gpu_metrics+0xcc/0x110 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.866160] amdgpu_get_gpu_metrics+0x154/0x2d0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.867135] dev_attr_show+0x43/0xc0 [ 33.867147] sysfs_kf_seq_show+0x1f1/0x3b0 [ 33.867155] seq_read_iter+0x3f8/0x1140 [ 33.867173] vfs_read+0x76c/0xc50 [ 33.867198] ksys_read+0xfb/0x1d0 [ 33.867214] do_syscall_64+0x90/0x160 ... [ 33.867353] Allocated by task 378 on cpu 7 at 22.794876s: [ 33.867358] kasan_save_stack+0x33/0x50 [ 33.867364] kasan_save_track+0x17/0x60 [ 33.867367] __kasan_kmalloc+0x87/0x90 [ 33.867371] vangogh_init_smc_tables+0x3f9/0x840 [amdgpu] [ 33.867835] smu_sw_init+0xa32/0x1850 [amdgpu] [ 33.868299] amdgpu_device_init+0x467b/0x8d90 [amdgpu] [ 33.868733] amdgpu_driver_load_kms+0x19/0xf0 [amdgpu] [ 33.869167] amdgpu_pci_probe+0x2d6/0xcd0 [amdgpu] [ 33.869608] local_pci_probe+0xda/0x180 [ 33.869614] pci_device_probe+0x43f/0x6b0 Empirically we can confirm that the former allocates 152 bytes for the table, while the latter memsets the 168 large block. Root cause appears that when GPU metrics tables for v2_4 parts were added it was not considered to enlarge the table to fit. The fix in this patch is rather "brute force" and perhaps later should be done in a smarter way, by extracting and consolidating the part version to size logic to a common helper, instead of brute forcing the largest possible allocation. Nevertheless, for now this works and fixes the out of bounds write. v2: * Drop impossible v3_0 case. (Mario) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Fixes: 41cec40bc9ba ("drm/amd/pm: Vangogh: Add new gpu_metrics_v2_4 to acquire gpu_metrics") Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Evan Quan <evan.quan@amd.com> Cc: Wenyou Yang <WenYou.Yang@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20241025145639.19124-1-tursulin@igalia.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 0880f58f9609f0200483a49429af0f050d281703) Cc: stable@vger.kernel.org # v6.6+
2024-10-28Revert "drm/amd/display: update DML2 policy ↵Ovidiu Bunea
EnhancedPrefetchScheduleAccelerationFinal DCN35" This reverts commit 9dad21f910fc ("drm/amd/display: update DML2 policy EnhancedPrefetchScheduleAccelerationFinal DCN35") [why & how] The offending commit exposes a hang with lid close/open behavior. Both issues seem to be related to ODM 2:1 mode switching, so there is another issue generic to that sequence that needs to be investigated. Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Ovidiu Bunea <Ovidiu.Bunea@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 68bf95317ebf2cfa7105251e4279e951daceefb7) Cc: stable@vger.kernel.org
2024-10-28cpufreq/amd-pstate: Align offline flow of shared memory and MSR based systemsDhananjay Ugwekar
Set min_perf to lowest_perf for shared memory systems, similar to the MSR based systems. Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Link: https://lore.kernel.org/r/20241023102108.5980-5-Dhananjay.Ugwekar@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28cpufreq/amd-pstate: Call cppc_set_epp_perf in the reenable functionDhananjay Ugwekar
The EPP value being set in perf_ctrls.energy_perf is not being propagated to the shared memory, fix that. Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Perry Yuan <perry.yuan@amd.com> Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Link: https://lore.kernel.org/r/20241023102108.5980-4-Dhananjay.Ugwekar@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28cpufreq/amd-pstate: Do not attempt to clear MSR_AMD_CPPC_ENABLEDhananjay Ugwekar
MSR_AMD_CPPC_ENABLE is a write once register, i.e. attempting to clear it is futile, it will not take effect. Hence, return if disable (0) argument is passed to the msr_cppc_enable() Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Link: https://lore.kernel.org/r/20241023102108.5980-3-Dhananjay.Ugwekar@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28cpufreq/amd-pstate: Rename functions that enable CPPCDhananjay Ugwekar
Explicitly rename functions that enable CPPC as *_cppc_*. Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Perry Yuan <perry.yuan@amd.com> Link: https://lore.kernel.org/r/20241023102108.5980-2-Dhananjay.Ugwekar@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28cpufreq/amd-pstate-ut: Add fix for min freq unit testMario Limonciello
commit 642aff3964b0f ("cpufreq/amd-pstate: Set the initial min_freq to lowest_nonlinear_freq") changed the initial minimum frequency to lowest nonlinear frequency, but the unit tests weren't updated and now fail. Update them to match this same change. Fixes: 642aff3964b0f ("cpufreq/amd-pstate: Set the initial min_freq to lowest_nonlinear_freq") Link: https://lore.kernel.org/r/20241017173439.4924-1-mario.limonciello@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28amd-pstate: Switch to amd-pstate by default on some Server platformsSwapnil Sapkal
Currently the default cpufreq driver for all the AMD EPYC servers is acpi-cpufreq. Going forward, switch to amd-pstate as the default driver on the AMD EPYC server platforms with CPU family 0x1A or higher. The default mode will be active mode. Testing shows that amd-pstate with active mode and performance governor provides comparable or better performance per-watt against acpi-cpufreq + performance governor. Likewise, amd-pstate with active mode and powersave governor with the energy_performance_preference=power (EPP=255) provides comparable or better performance per-watt against acpi-cpufreq + schedutil governor for a wide range of workloads. Users can still revert to using acpi-cpufreq driver on these platforms with the "amd_pstate=disable" kernel commandline parameter. Signed-off-by: Swapnil Sapkal <swapnil.sapkal@amd.com> Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20241021101836.9047-3-gautham.shenoy@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28amd-pstate: Set min_perf to nominal_perf for active mode performance govGautham R. Shenoy
The amd-pstate driver sets CPPC_REQ.min_perf to CPPC_REQ.max_perf when in active mode with performance governor. Typically CPPC_REQ.max_perf is set to CPPC.highest_perf. This causes frequency throttling on power-limited platforms which causes performance regressions on certain classes of workloads. Hence, set the CPPC_REQ.min_perf to the CPPC.nominal_perf or CPPC_REQ.max_perf, whichever is lower of the two. Fixes: ffa5096a7c33 ("cpufreq: amd-pstate: implement Pstate EPP support for the AMD processors") Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20241021101836.9047-2-gautham.shenoy@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28cpufreq/amd-pstate: Remove the redundant amd_pstate_set_driver() callDhananjay Ugwekar
amd_pstate_set_driver() is called twice, once in amd_pstate_init() and once as part of amd_pstate_register_driver(). Move around code and eliminate the redundancy. Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20241017100528.300143-5-Dhananjay.Ugwekar@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28cpufreq/amd-pstate: Remove the switch case in amd_pstate_init()Dhananjay Ugwekar
Replace the switch case with a more readable if condition. Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20241017100528.300143-4-Dhananjay.Ugwekar@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28cpufreq/amd-pstate: Call amd_pstate_set_driver() in amd_pstate_register_driver()Dhananjay Ugwekar
Replace a similar chunk of code in amd_pstate_register_driver() with amd_pstate_set_driver() call. Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20241017100528.300143-3-Dhananjay.Ugwekar@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28cpufreq/amd-pstate: Call amd_pstate_register() in amd_pstate_init()Dhananjay Ugwekar
Replace a similar chunk of code in amd_pstate_init() with amd_pstate_register() call. Suggested-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20241017100528.300143-2-Dhananjay.Ugwekar@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28cpufreq/amd-pstate: Set the initial min_freq to lowest_nonlinear_freqDhananjay Ugwekar
According to the AMD architectural programmer's manual volume 2 [1], in section "17.6.4.1 CPPC_CAPABILITY_1" lowest_nonlinear_perf is described as "Reports the most energy efficient performance level (in terms of performance per watt). Above this threshold, lower performance levels generally result in increased energy efficiency. Reducing performance below this threshold does not result in total energy savings for a given computation, although it reduces instantaneous power consumption". So lowest_nonlinear_perf is the most power efficient performance level, and going below that would lead to a worse performance/watt. Also, setting the minimum frequency to lowest_nonlinear_freq (instead of lowest_freq) allows the CPU to idle at a higher frequency which leads to more time being spent in a deeper idle state (as trivial idle tasks are completed sooner). This has shown a power benefit in some systems, in other systems, power consumption has increased but so has the throughput/watt. Modify the initial policy_data->min set by cpufreq-core to lowest_nonlinear_freq, in the ->verify() callback. Also set the cpudata->req[0] to FREQ_QOS_MIN_DEFAULT_VALUE (i.e. 0), so that it also gets overriden by the check in verify function. Link: https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24593.pdf [1] Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20241017053927.25285-3-Dhananjay.Ugwekar@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28cpufreq/amd-pstate: Remove the redundant verify() functionDhananjay Ugwekar
Merge the two verify() callback functions and rename the cpufreq_policy_data argument for better readability. Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Link: https://lore.kernel.org/r/20241017053927.25285-2-Dhananjay.Ugwekar@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28cpufreq/amd-pstate: Drop needless EPP initializationMario Limonciello
The EPP value doesn't need to be cached to the CPPC request in amd_pstate_epp_update_limit() because it's passed as an argument at the end to amd_pstate_set_epp() and stored at that time. Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Reviewed-by: Perry Yuan <perry.yuan@amd.com> Tested-by: Dhananjay Ugwekar <dhananjay.ugwekar@amd.com> Link: https://lore.kernel.org/r/20241012174519.897-4-mario.limonciello@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28cpufreq/amd-pstate: Use amd_pstate_update_min_max_limit() for EPP limitsMario Limonciello
When the EPP updates are set the maximum capable frequency for the CPU is used to set the upper limit instead of that of the policy. Adjust amd_pstate_epp_update_limit() to reuse policy calculation code from amd_pstate_update_min_max_limit(). Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Reviewed-by: Perry Yuan <perry.yuan@amd.com> Tested-by: Dhananjay Ugwekar <dhananjay.ugwekar@amd.com> Link: https://lore.kernel.org/r/20241012174519.897-3-mario.limonciello@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28cpufreq/amd-pstate: Don't update CPPC request in amd_pstate_cpu_boost_update()Mario Limonciello
When boost is changed the CPPC value is changed in amd_pstate_cpu_boost_update() but then changed again when refresh_frequency_limits() and all it's callbacks occur. The first is a pointless write, so instead just update the limits for the policy and let the policy refresh anchor everything properly. Fixes: c8c68c38b56f ("cpufreq: amd-pstate: initialize core precision boost state") Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Reviewed-by: Perry Yuan <perry.yuan@amd.com> Tested-by: Dhananjay Ugwekar <dhananjay.ugwekar@amd.com> Link: https://lore.kernel.org/r/20241012174519.897-2-mario.limonciello@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28cpufreq/amd-pstate: Fix non kerneldoc commentMario Limonciello
The comment for amd_cppc_supported() isn't meant to be kernel doc. Fixes: cb817ec6673b7 ("cpufreq: amd-pstate: show CPPC debug message if CPPC is not supported") Link: https://lore.kernel.org/r/20240905162351.1345560-1-superm1@kernel.org Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28cpufreq/amd-pstate: Rename MSR and shared memory specific functionsDhananjay Ugwekar
Existing function names "cppc_*" and "pstate_*" for shared memory and MSR based systems are not intuitive enough, replace them with "shmem_*" and "msr_*" respectively. Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20240917091434.10685-1-Dhananjay.Ugwekar@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2024-10-28block: fix queue limits checks in blk_rq_map_user_bvec for realChristoph Hellwig
blk_rq_map_user_bvec currently only has ad-hoc checks for queue limits, and the last fix to it enabled valid NVMe I/O to pass, but also allowed invalid one for drivers that set a max_segment_size or seg_boundary limit. Fix it once for all by using the bio_split_rw_at helper from the I/O path that indicates if and where a bio would be have to be split to adhere to the queue limits, and it returns a positive value, turn that into -EREMOTEIO to retry using the copy path. Fixes: 2ff949441802 ("block: fix sanity checks in blk_rq_map_user_bvec") Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: John Garry <john.g.garry@oracle.com> Link: https://lore.kernel.org/r/20241028090840.446180-1-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2024-10-28drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIMMatthew Brost
drm_gpu_scheduler.submit_wq is used to submit jobs, jobs are in the path of dma-fences, and dma-fences are in the path of reclaim. Mark scheduler work queue with WQ_MEM_RECLAIM to ensure forward progress during reclaim; without WQ_MEM_RECLAIM, work queues cannot make forward progress during reclaim. v2: - Fixes tags (Philipp) - Reword commit message (Philipp) Cc: Luben Tuikov <ltuikov89@gmail.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Philipp Stanner <pstanner@redhat.com> Cc: stable@vger.kernel.org Fixes: 34f50cc6441b ("drm/sched: Use drm sched lockdep map for submit_wq") Fixes: a6149f039369 ("drm/sched: Convert drm scheduler to use a work queue rather than kthread") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Acked-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Philipp Stanner <pstanner@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241023235917.1836428-1-matthew.brost@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-10-28perf/marvell: Marvell PEM performance monitor supportGowthami Thiagarajan
PCI Express Interface PMU includes various performance counters to monitor the data that is transmitted over the PCIe link. The counters track various inbound and outbound transactions which includes separate counters for posted/non-posted/completion TLPs. Also, inbound and outbound memory read requests along with their latencies can also be monitored. Address Translation Services(ATS)events such as ATS Translation, ATS Page Request, ATS Invalidation along with their corresponding latencies are also supported. The performance counters are 64 bits wide. For instance, perf stat -e ib_tlp_pr <workload> tracks the inbound posted TLPs for the workload. Co-developed-by: Linu Cherian <lcherian@marvell.com> Signed-off-by: Linu Cherian <lcherian@marvell.com> Signed-off-by: Gowthami Thiagarajan <gthiagarajan@marvell.com> Link: https://lore.kernel.org/r/20241028055309.17893-1-gthiagarajan@marvell.com Signed-off-by: Will Deacon <will@kernel.org>
2024-10-28perf/arm_pmuv3: Add PMUv3.9 per counter EL0 access controlRob Herring (Arm)
Armv8.9/9.4 PMUv3.9 adds per counter EL0 access controls. Per counter access is enabled with the UEN bit in PMUSERENR_EL1 register. Individual counters are enabled/disabled in the PMUACR_EL1 register. When UEN is set, the CR/ER bits control EL0 write access and must be set to disable write access. With the access controls, the clearing of unused counters can be skipped. KVM also configures PMUSERENR_EL1 in order to trap to EL2. UEN does not need to be set for it since only PMUv3.5 is exposed to guests. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20241002184326.1105499-1-robh@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2024-10-28x86/sev: Convert shared memory back to private on kexecAshish Kalra
SNP guests allocate shared buffers to perform I/O. It is done by allocating pages normally from the buddy allocator and converting them to shared with set_memory_decrypted(). The second, kexec-ed, kernel has no idea what memory is converted this way. It only sees E820_TYPE_RAM. Accessing shared memory via private mapping will cause unrecoverable RMP page-faults. On kexec, walk direct mapping and convert all shared memory back to private. It makes all RAM private again and second kernel may use it normally. Additionally, for SNP guests, convert all bss decrypted section pages back to private. The conversion occurs in two steps: stopping new conversions and unsharing all memory. In the case of normal kexec, the stopping of conversions takes place while scheduling is still functioning. This allows for waiting until any ongoing conversions are finished. The second step is carried out when all CPUs except one are inactive and interrupts are disabled. This prevents any conflicts with code that may access shared memory. Co-developed-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://lore.kernel.org/r/05a8c15fb665dbb062b04a8cb3d592a63f235937.1722520012.git.ashish.kalra@amd.com
2024-10-28x86/mm: Refactor __set_clr_pte_enc()Ashish Kalra
Refactor __set_clr_pte_enc() and add two new helper functions to set/clear PTE C-bit from early SEV/SNP initialization code and later during shutdown/kexec especially when all CPUs are stopped and interrupts are disabled and set_memory_xx() interfaces can't be used. Co-developed-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://lore.kernel.org/r/5df4aa450447f28294d1c5a890e27b63ed4ded36.1722520012.git.ashish.kalra@amd.com
2024-10-28ASoC: Intel: sst: Fix used of uninitialized ctx to log an errorHans de Goede
Fix the new "LPE0F28" code path using the uninitialized ctx variable to log an error. Fixes: 6668610b4d8c ("ASoC: Intel: sst: Support LPE0F28 ACPI HID") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202410261106.EBx49ssy-lkp@intel.com/ Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patch.msgid.link/20241026143615.171821-1-hdegoede@redhat.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-10-28perf cap: Add __NR_capget to arch/x86 unistdIan Rogers
As there are duplicated kernel headers in tools/include libc can pick up the wrong definitions. This was causing the wrong system call for capget in perf. Reported-by: Adrian Hunter <adrian.hunter@intel.com> Fixes: e25ebda78e230283 ("perf cap: Tidy up and improve capability testing") Closes: https://lore.kernel.org/lkml/cc7d6bdf-1aeb-4179-9029-4baf50b59342@intel.com/ Signed-off-by: Ian Rogers <irogers@google.com> Tested-by: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://lore.kernel.org/r/20241026055448.312247-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2024-10-28srcu: Introduce srcu_gp_is_expedited() helper functionPaul E. McKenney
Even though the open-coded expressions usually fit on one line, this commit replaces them with a call to a new srcu_gp_is_expedited() helper function in order to improve readability. Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Andrii Nakryiko <andrii@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Kent Overstreet <kent.overstreet@linux.dev> Cc: <bpf@vger.kernel.org> Reviewed-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com> Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
2024-10-28srcu: Rename srcu_might_be_idle() to srcu_should_expedite()Paul E. McKenney
SRCU auto-expedites grace periods that follow a sufficiently long idle period, and the srcu_might_be_idle() function is used to make this decision. However, the upcoming light-weight SRCU readers will not do auto-expediting because doing so would cause the grace-period machinery to invoke synchronize_rcu_expedited() twice, with IPIs all around. However, software-engineering considerations force this determination to remain in srcu_might_be_idle(). This commit therefore changes the name of srcu_might_be_idle() to srcu_should_expedite(), thus moving from what it currently does to why it does it, this latter being more future-proof. Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Andrii Nakryiko <andrii@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Kent Overstreet <kent.overstreet@linux.dev> Cc: <bpf@vger.kernel.org> Reviewed-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com> Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
2024-10-28x86/boot: Skip video memory access in the decompressor for SEV-ES/SNPAshish Kalra
Accessing guest video memory/RAM in the decompressor causes guest termination as the boot stage2 #VC handler for SEV-ES/SNP systems does not support MMIO handling. This issue is observed during a SEV-ES/SNP guest kexec as kexec -c adds screen_info to the boot parameters passed to the second kernel, which causes console output to be dumped to both video and serial. As the decompressor output gets cleared really fast, it is preferable to get the console output only on serial, hence, skip accessing the video RAM during decompressor stage to prevent guest termination. Serial console output during decompressor stage works as boot stage2 #VC handler already supports handling port I/O. [ bp: Massage. ] Suggested-by: Borislav Petkov (AMD) <bp@alien8.de> Suggested-by: Thomas Lendacky <thomas.lendacky@amd.com> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://lore.kernel.org/r/8a55ea86524c686e575d273311acbe57ce8cee23.1722520012.git.ashish.kalra@amd.com
generated by cgit (git 2.34.1) at 2025-09-21 16:49:15 +0000