- Linux-stable-mirror - lists.linaro.org

[PATCH] rust: maple_tree: rcu_read_lock() in destructor to silence lockdep

by Alice Ryhl

When running the Rust maple tree kunit tests with lockdep, you may trigger a warning that looks like this: lib/maple_tree.c:780 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 no locks held by kunit_try_catch/344. stack backtrace: CPU: 3 UID: 0 PID: 344 Comm: kunit_try_catch Tainted: G N 6.19.0-rc1+ #2 NONE Tainted: [N]=TEST Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x71/0x90 lockdep_rcu_suspicious+0x150/0x190 mas_start+0x104/0x150 mas_find+0x179/0x240 _RINvNtCs5QSdWC790r4_4core3ptr13drop_in_placeINtNtCs1cdwasc6FUb_6kernel10maple_tree9MapleTreeINtNtNtBL_5alloc4kbox3BoxlNtNtB1x_9allocator7KmallocEEECsgxAQYCfdR72_25doctests_kernel_generated+0xaf/0x130 rust_doctest_kernel_maple_tree_rs_0+0x600/0x6b0 ? lock_release+0xeb/0x2a0 ? kunit_try_catch_run+0x210/0x210 kunit_try_run_case+0x74/0x160 ? kunit_try_catch_run+0x210/0x210 kunit_generic_run_threadfn_adapter+0x12/0x30 kthread+0x21c/0x230 ? __do_trace_sched_kthread_stop_ret+0x40/0x40 ret_from_fork+0x16c/0x270 ? __do_trace_sched_kthread_stop_ret+0x40/0x40 ret_from_fork_asm+0x11/0x20 </TASK> This is because the destructor of maple tree calls mas_find() without taking rcu_read_lock() or the spinlock. Doing that is actually ok in this case since the destructor has exclusive access to the entire maple tree, but it triggers a lockdep warning. To fix that, take the rcu read lock. In the future, it's possible that memory reclaim could gain a feature where it reallocates entries in maple trees even if no user-code is touching it. If that feature is added, then this use of rcu read lock would become load-bearing, so I did not make it conditional on lockdep. We have to repeatedly take and release rcu because the destructor of T might perform operations that sleep. Reported-by: Andreas Hindborg <a.hindborg(a)kernel.org> Closes: https://rust-for-linux.zulipchat.com/#narrow/channel/x/topic/x/near/5642151… Fixes: da939ef4c494 ("rust: maple_tree: add MapleTree") Cc: stable(a)vger.kernel.org Signed-off-by: Alice Ryhl <aliceryhl(a)google.com> --- Intended for the same tree as any other maple tree patch. (I believe that's Andrew Morton's tree.) --- rust/kernel/maple_tree.rs | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/rust/kernel/maple_tree.rs b/rust/kernel/maple_tree.rs index e72eec56bf5772ada09239f47748cd649212d8b0..265d6396a78a17886c8b5a3ebe7ba39ccc354add 100644 --- a/rust/kernel/maple_tree.rs +++ b/rust/kernel/maple_tree.rs @@ -265,7 +265,16 @@ unsafe fn free_all_entries(self: Pin<&mut Self>) { loop { // This uses the raw accessor because we're destroying pointers without removing them // from the maple tree, which is only valid because this is the destructor. - let ptr = ma_state.mas_find_raw(usize::MAX); + // + // Take the rcu lock because mas_find_raw() requires that you hold either the spinlock + // or the rcu read lock. This is only really required if memory reclaim might + // reallocate entries in the tree, as we otherwise have exclusive access. That feature + // doesn't exist yet, so for now, taking the rcu lock only serves the purpose of + // silencing lockdep. + let ptr = { + let _rcu = kernel::sync::rcu::Guard::new(); + ma_state.mas_find_raw(usize::MAX) + }; if ptr.is_null() { break; } --- base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8 change-id: 20251217-maple-drop-rcu-dfe72fb5f49e Best regards, -- Alice Ryhl <aliceryhl(a)google.com>

1 day, 9 hours

4
4
0 0

[PATCH] riva/fbdev: fix divide error in nv3_arb()

by Guangshuo Li

A userspace program can trigger the RIVA NV3 arbitration code by calling the FBIOPUT_VSCREENINFO ioctl on /dev/fb*. When doing so, the driver recomputes FIFO arbitration parameters in nv3_arb(), using state->mclk_khz (derived from the PRAMDAC MCLK PLL) as a divisor without validating it first. In a normal setup, state->mclk_khz is provided by the real hardware and is non-zero. However, an attacker can construct a malicious or misconfigured device (e.g. a crafted/emulated PCI device) that exposes a bogus PLL configuration, causing state->mclk_khz to become zero. Once nv3_get_param() calls nv3_arb(), the division by state->mclk_khz in the gns calculation causes a divide error and crashes the kernel. Fix this by checking whether state->mclk_khz is zero and bailing out before doing the division. The following log reveals it: rivafb: setting virtual Y resolution to 2184 divide error: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 PID: 2187 Comm: syz-executor.0 Not tainted 5.18.0-rc1+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 RIP: 0010:nv3_arb drivers/video/fbdev/riva/riva_hw.c:439 [inline] RIP: 0010:nv3_get_param+0x3ab/0x13b0 drivers/video/fbdev/riva/riva_hw.c:546 Code: c1 e8 03 42 0f b6 14 38 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 b7 0e 00 00 41 8b 46 18 01 d8 69 c0 40 42 0f 00 99 <41> f7 fc 48 63 c8 4c 89 e8 48 c1 e8 03 42 0f b6 14 38 4c 89 e8 83 RSP: 0018:ffff888013b2f318 EFLAGS: 00010206 RAX: 0000000001d905c0 RBX: 0000000000000016 RCX: 0000000000040000 RDX: 0000000000000000 RSI: 0000000000000080 RDI: ffff888013b2f6f0 RBP: 0000000000000002 R08: ffffffff82226288 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000 R13: ffff888013b2f4d8 R14: ffff888013b2f6d8 R15: dffffc0000000000 Call Trace: nv3CalcArbitration.constprop.0+0x255/0x460 drivers/video/fbdev/riva/riva_hw.c:603 nv3UpdateArbitrationSettings drivers/video/fbdev/riva/riva_hw.c:637 [inline] CalcStateExt+0x447/0x1b90 drivers/video/fbdev/riva/riva_hw.c:1246 riva_load_video_mode+0x8a9/0xea0 drivers/video/fbdev/riva/fbdev.c:779 rivafb_set_par+0xc0/0x5f0 drivers/video/fbdev/riva/fbdev.c:1196 fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1033 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1109 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1188 __x64_sys_ioctl+0x122/0x190 fs/ioctl.c:856 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)vger.kernel.org Signed-off-by: Guangshuo Li <lgs201920130244(a)gmail.com> --- drivers/video/fbdev/riva/riva_hw.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/video/fbdev/riva/riva_hw.c b/drivers/video/fbdev/riva/riva_hw.c index 8b829b720064..d70c6c4d28e8 100644 --- a/drivers/video/fbdev/riva/riva_hw.c +++ b/drivers/video/fbdev/riva/riva_hw.c @@ -436,6 +436,9 @@ static char nv3_arb(nv3_fifo_info * res_info, nv3_sim_state * state, nv3_arb_in vmisses = 2; eburst_size = state->memory_width * 1; mburst_size = 32; + if (!state->mclk_khz) + return (0); + gns = 1000000 * (gmisses*state->mem_page_miss + state->mem_latency)/state->mclk_khz; ainfo->by_gfacc = gns*ainfo->gdrain_rate/1000000; ainfo->wcmocc = 0; -- 2.43.0

1 day, 9 hours

3
3
0 0

[PATCH v2 1/2] usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe()

by Duoming Zhou

The gaokun_ucsi_probe() uses ucsi_create() to allocate a UCSI instance. The ucsi_create() validates whether ops->poll_cci is defined, and if not, it directly returns -EINVAL. However, the gaokun_ucsi_ops structure does not define the poll_cci, causing ucsi_create() always fail with -EINVAL. This issue can be observed in the kernel log with the following error: ucsi_huawei_gaokun.ucsi huawei_gaokun_ec.ucsi.0: probe with driver ucsi_huawei_gaokun.ucsi failed with error -22 Fix the issue by adding the missing poll_cci callback to gaokun_ucsi_ops. Fixes: 00327d7f2c8c ("usb: typec: ucsi: add Huawei Matebook E Go ucsi driver") Cc: stable(a)vger.kernel.org Signed-off-by: Duoming Zhou <duoming(a)zju.edu.cn> --- Changes in v2: - Add cc: stable. - Correct spelling mistake. drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c b/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c index 7b5222081bb..8401ab414bd 100644 --- a/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c +++ b/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c @@ -196,6 +196,7 @@ static void gaokun_ucsi_connector_status(struct ucsi_connector *con) const struct ucsi_operations gaokun_ucsi_ops = { .read_version = gaokun_ucsi_read_version, .read_cci = gaokun_ucsi_read_cci, + .poll_cci = gaokun_ucsi_read_cci, .read_message_in = gaokun_ucsi_read_message_in, .sync_control = ucsi_sync_control_common, .async_control = gaokun_ucsi_async_control, -- 2.34.1

1 day, 9 hours

3
2
0 0

[PATCH stable/6.16-5.15] md: add check_new_feature module parameter

by linan666＠huaweicloud.com

From: Li Nan <linan122(a)huawei.com> commit 9c47127a807da3e36ce80f7c83a1134a291fc021 upstream. Raid checks if pad3 is zero when loading superblock from disk. Arrays created with new features may fail to assemble on old kernels as pad3 is used. Add module parameter check_new_feature to bypass this check. Link: https://lore.kernel.org/linux-raid/20251103125757.1405796-5-linan666@huawei… Signed-off-by: Li Nan <linan122(a)huawei.com> Reviewed-by: Xiao Ni <xni(a)redhat.com> Signed-off-by: Yu Kuai <yukuai(a)fnnas.com> [ Conflict in md.c, because of a difference in the context, introduced by commit 25db5f284fb8 ("md: add legacy_async_del_gendisk mode"), which is not in this version. The same lines can still be added at the same place. ] Signed-off-by: Li Nan <linan122(a)huawei.com> --- drivers/md/md.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/md/md.c b/drivers/md/md.c index 0f41573fa9f5..4bcbd2ed439e 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -339,6 +339,7 @@ static int start_readonly; * so all the races disappear. */ static bool create_on_open = true; +static bool check_new_feature = true; /* * We have a system wide 'event count' that is incremented @@ -1735,9 +1736,13 @@ static int super_1_load(struct md_rdev *rdev, struct md_rdev *refdev, int minor_ } if (sb->pad0 || sb->pad3[0] || - memcmp(sb->pad3, sb->pad3+1, sizeof(sb->pad3) - sizeof(sb->pad3[1]))) - /* Some padding is non-zero, might be a new feature */ - return -EINVAL; + memcmp(sb->pad3, sb->pad3+1, sizeof(sb->pad3) - sizeof(sb->pad3[1]))) { + pr_warn("Some padding is non-zero on %pg, might be a new feature\n", + rdev->bdev); + if (check_new_feature) + return -EINVAL; + pr_warn("check_new_feature is disabled, data corruption possible\n"); + } rdev->preferred_minor = 0xffff; rdev->data_offset = le64_to_cpu(sb->data_offset); @@ -10422,6 +10427,7 @@ module_param_call(start_ro, set_ro, get_ro, NULL, S_IRUSR|S_IWUSR); module_param(start_dirty_degraded, int, S_IRUGO|S_IWUSR); module_param_call(new_array, add_named_array, NULL, NULL, S_IWUSR); module_param(create_on_open, bool, S_IRUSR|S_IWUSR); +module_param(check_new_feature, bool, 0600); MODULE_LICENSE("GPL"); MODULE_DESCRIPTION("MD RAID framework"); -- 2.39.2

1 day, 9 hours

1
0
0 0

[PATCH v2 0/2] nfc: llcp: fix double put/unlock on LLCP_CLOSED in recv handlers

by Qianchang Zhao

This series fixes a refcount/locking imbalance in NFC LLCP receive handlers when the socket is already in LLCP_CLOSED. nfc_llcp_recv_disc() used to perform release_sock()/nfc_llcp_sock_put() in the CLOSED branch but did not exit, and then performed the same cleanup again on the common exit path. Drop the redundant CLOSED-branch cleanup so the common exit path runs it exactly once, while keeping the existing DM_DISC reply behavior. nfc_llcp_recv_hdlc() performed the CLOSED cleanup but then continued processing and later cleaned up again on the common exit path. Return immediately after the CLOSED cleanup. Changes in v2: - Drop Reported-by tags - Add missing Fixes tags Build-tested with: make M=net/nfc (no NFC HW available for runtime testing). Qianchang Zhao (2): nfc: llcp: avoid double release/put on LLCP_CLOSED in nfc_llcp_recv_disc() nfc: llcp: stop processing on LLCP_CLOSED in nfc_llcp_recv_hdlc() net/nfc/llcp_core.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) -- 2.34.1

1 day, 9 hours

2
3
0 0

[PATCH v2 0/8] ASoC: SOF: ipoc4: Support for generic bytes controls

by Peter Ujfalusi

Hi, Changes since v1: - correct SHAs for fixes tags - add Cc stable tag We support bytes control type for set and get, but these are module specific controls and there is no way to handle notifications from them in a generic way. Each control have module specific param_id and this param_id is only valid in the module's scope, other modules might use the same id for different functions for example. This series will add a new generic control type, similar to the existing ones for ENUM and SWITCH, which can be used to create bytes controls which can send notifications from firmware on change. The new param_id is 202 and the sof_ipc4_control_msg_payload is updated to describe bytes payload also. On set, the payload must include the sof_ipc4_control_msg_payload struct with the control's ID and data size, followed by the data. On get, the kernel needs to send the sof_ipc4_control_msg_payload struct along with the LARGE_CONFIG_GET message as payload with the ID of the control that needs to be retrieved. The raw data is received back without additional header. A notification might contain data, in this case the num_elems reflects the size in bytes, or without data. If no data is received then the control is marked as dirty and on read the kernel will refresh the data from firmware. The series includes mandatory fixes for existing code and adds support for sending payload with LARGE_CONFIG_GET when the param_id is either generic ENUM, SWITCH or BYTES control. Regards, Peter --- Peter Ujfalusi (8): ASoC: SOF: ipc4-control: If there is no data do not send bytes update ASoC: SOF: ipc4-topology: Correct the allocation size for bytes controls ASoC: SOF: ipc4-control: Use the correct size for scontrol->ipc_control_data ASoC: SOF: ipc4-control: Keep the payload size up to date ASoC: SOF: ipc4-topology: Set initial param_id for bytes control type ASoC: SOF: ipc4: Support for sending payload along with LARGE_CONFIG_GET ASoC: SOF: ipc4: Add definition for generic bytes control ASoC: SOF: ipc4-control: Add support for generic bytes control sound/soc/sof/ipc4-control.c | 197 ++++++++++++++++++++++++++++++---- sound/soc/sof/ipc4-topology.c | 36 +++++-- sound/soc/sof/ipc4-topology.h | 9 +- sound/soc/sof/ipc4.c | 45 +++++++- 4 files changed, 252 insertions(+), 35 deletions(-) -- 2.52.0

1 day, 10 hours

3
11
0 0

[PATCH v4] KVM: x86: Add x2APIC "features" to control EOI broadcast suppression

by Khushit Shah

Add two flags for KVM_CAP_X2APIC_API to allow userspace to control support for Suppress EOI Broadcasts, which KVM completely mishandles. When x2APIC support was first added, KVM incorrectly advertised and "enabled" Suppress EOI Broadcast, without fully supporting the I/O APIC side of the equation, i.e. without adding directed EOI to KVM's in-kernel I/O APIC. That flaw was carried over to split IRQCHIP support, i.e. KVM advertised support for Suppress EOI Broadcasts irrespective of whether or not the userspace I/O APIC implementation supported directed EOIs. Even worse, KVM didn't actually suppress EOI broadcasts, i.e. userspace VMMs without support for directed EOI came to rely on the "spurious" broadcasts. KVM "fixed" the in-kernel I/O APIC implementation by completely disabling support for Suppress EOI Broadcasts in commit 0bcc3fb95b97 ("KVM: lapic: stop advertising DIRECTED_EOI when in-kernel IOAPIC is in use"), but didn't do anything to remedy userspace I/O APIC implementations. KVM's bogus handling of Suppress EOI Broadcast is problematic when the guest relies on interrupts being masked in the I/O APIC until well after the initial local APIC EOI. E.g. Windows with Credential Guard enabled handles interrupts in the following order: 1. Interrupt for L2 arrives. 2. L1 APIC EOIs the interrupt. 3. L1 resumes L2 and injects the interrupt. 4. L2 EOIs after servicing. 5. L1 performs the I/O APIC EOI. Because KVM EOIs the I/O APIC at step #2, the guest can get an interrupt storm, e.g. if the IRQ line is still asserted and userspace reacts to the EOI by re-injecting the IRQ, because the guest doesn't de-assert the line until step #4, and doesn't expect the interrupt to be re-enabled until step #5. Unfortunately, simply "fixing" the bug isn't an option, as KVM has no way of knowing if the userspace I/O APIC supports directed EOIs, i.e. suppressing EOI broadcasts would result in interrupts being stuck masked in the userspace I/O APIC due to step #5 being ignored by userspace. And fully disabling support for Suppress EOI Broadcast is also undesirable, as picking up the fix would require a guest reboot, *and* more importantly would change the virtual CPU model exposed to the guest without any buy-in from userspace. Add KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST and KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST flags to allow userspace to explicitly enable or disable support for Suppress EOI Broadcasts while using split IRQCHIP mode. This gives userspace control over the virtual CPU model exposed to the guest, as KVM should never have enabled support for Suppress EOI Broadcast without a userspace opt-in. Not setting either flag will result in legacy quirky behavior for backward compatibility. Note, Suppress EOI Broadcasts is defined only in Intel's SDM, not in AMD's APM. But the bit is writable on some AMD CPUs, e.g. Turin, and KVM's ABI is to support Directed EOI (KVM's name) irrespective of guest CPU vendor. Fixes: 7543a635aa09 ("KVM: x86: Add KVM exit for IOAPIC EOIs") Closes: https://lore.kernel.org/kvm/7D497EF1-607D-4D37-98E7-DAF95F099342@nutanix.com Cc: stable(a)vger.kernel.org Suggested-by: David Woodhouse <dwmw2(a)infradead.org> Co-developed-by: Sean Christopherson <seanjc(a)google.com> Signed-off-by: Sean Christopherson <seanjc(a)google.com> Signed-off-by: Khushit Shah <khushit.shah(a)nutanix.com> --- v4: - Add KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST and KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST flags to allow userspace to explicitly enable or disable support for Suppress EOI Broadcasts while using split IRQCHIP mode. After the inclusion of David Woodhouse's patch to support IOAPIC version 0x20, we can tweak the uAPI to support kernel IRQCHIP mode as well. Testing: - Setting both the flags fails with EINVAL. - Setting flags in kernel IRQCHIP mode fails with EINVAL. - Setting flags in split IRQCHIP mode succeeds and both the flags work as expected. --- Documentation/virt/kvm/api.rst | 27 ++++++++++++++++++++-- arch/x86/include/asm/kvm_host.h | 7 ++++++ arch/x86/include/uapi/asm/kvm.h | 6 +++-- arch/x86/kvm/lapic.c | 40 +++++++++++++++++++++++++++++++++ arch/x86/kvm/x86.c | 19 +++++++++++++--- 5 files changed, 92 insertions(+), 7 deletions(-) diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 57061fa29e6a..b26528e0fec1 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -7800,8 +7800,10 @@ Will return -EBUSY if a VCPU has already been created. Valid feature flags in args[0] are:: - #define KVM_X2APIC_API_USE_32BIT_IDS (1ULL << 0) - #define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK (1ULL << 1) + #define KVM_X2APIC_API_USE_32BIT_IDS (1ULL << 0) + #define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK (1ULL << 1) + #define KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST (1ULL << 2) + #define KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST (1ULL << 3) Enabling KVM_X2APIC_API_USE_32BIT_IDS changes the behavior of KVM_SET_GSI_ROUTING, KVM_SIGNAL_MSI, KVM_SET_LAPIC, and KVM_GET_LAPIC, @@ -7814,6 +7816,27 @@ as a broadcast even in x2APIC mode in order to support physical x2APIC without interrupt remapping. This is undesirable in logical mode, where 0xff represents CPUs 0-7 in cluster 0. +Setting KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST instructs KVM to enable +Suppress EOI Broadcasts. KVM will advertise support for Suppress EOI Broadcast +to the guest and suppress LAPIC EOI broadcasts when the guest sets the +Suppress EOI Broadcast bit in the SPIV register. + +Setting KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST disables support for +Suppress EOI Broadcasts entirely, i.e. instructs KVM to NOT advertise support +to the guest. + +Modern VMMs should either enable KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST or +KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST. If not, legacy quirky behavior will +be used by KVM, which is to advertise support for Suppress EOI Broadcasts but +not actually suppressing EOI broadcasts. + +Currently, both KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST and +KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST must only be set when in split IRQCHIP +mode. Otherwise, the ioctl will fail with an EINVAL error. + +Setting both KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST and +KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST will fail with an EINVAL error. + 7.8 KVM_CAP_S390_USER_INSTR0 ---------------------------- diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index 48598d017d6f..4a6d94dc7a2a 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1229,6 +1229,12 @@ enum kvm_irqchip_mode { KVM_IRQCHIP_SPLIT, /* created with KVM_CAP_SPLIT_IRQCHIP */ }; +enum kvm_suppress_eoi_broadcast_mode { + KVM_SUPPRESS_EOI_BROADCAST_QUIRKED, /* Legacy behavior */ + KVM_SUPPRESS_EOI_BROADCAST_ENABLED, /* Enable Suppress EOI broadcast */ + KVM_SUPPRESS_EOI_BROADCAST_DISABLED /* Disable Suppress EOI broadcast */ +}; + struct kvm_x86_msr_filter { u8 count; bool default_allow:1; @@ -1480,6 +1486,7 @@ struct kvm_arch { bool x2apic_format; bool x2apic_broadcast_quirk_disabled; + enum kvm_suppress_eoi_broadcast_mode suppress_eoi_broadcast_mode; bool has_mapped_host_mmio; bool guest_can_read_msr_platform_info; diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h index d420c9c066d4..d30241429fa8 100644 --- a/arch/x86/include/uapi/asm/kvm.h +++ b/arch/x86/include/uapi/asm/kvm.h @@ -913,8 +913,10 @@ struct kvm_sev_snp_launch_finish { __u64 pad1[4]; }; -#define KVM_X2APIC_API_USE_32BIT_IDS (1ULL << 0) -#define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK (1ULL << 1) +#define KVM_X2APIC_API_USE_32BIT_IDS (_BITULL(0)) +#define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK (_BITULL(1)) +#define KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST (_BITULL(2)) +#define KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST (_BITULL(3)) struct kvm_hyperv_eventfd { __u32 conn_id; diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 0ae7f913d782..1ef0bd3eff1e 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -105,6 +105,34 @@ bool kvm_apic_pending_eoi(struct kvm_vcpu *vcpu, int vector) apic_test_vector(vector, apic->regs + APIC_IRR); } +static inline bool kvm_lapic_advertise_suppress_eoi_broadcast(struct kvm *kvm) +{ + /* + * Advertise Suppress EOI broadcast support to the guest unless the VMM + * explicitly disabled it. + * + * Historically, KVM advertised this capability even though it did not + * actually suppress EOIs. + */ + return kvm->arch.suppress_eoi_broadcast_mode != + KVM_SUPPRESS_EOI_BROADCAST_DISABLED; +} + +static inline bool kvm_lapic_ignore_suppress_eoi_broadcast(struct kvm *kvm) +{ + /* + * Returns true if KVM should ignore the suppress EOI broadcast bit set by + * the guest and broadcast EOIs anyway. + * + * Only returns false when the VMM explicitly enabled Suppress EOI + * broadcast. If disabled by VMM, the bit should be ignored as it is not + * supported. Legacy behavior was to ignore the bit and broadcast EOIs + * anyway. + */ + return kvm->arch.suppress_eoi_broadcast_mode != + KVM_SUPPRESS_EOI_BROADCAST_ENABLED; +} + __read_mostly DEFINE_STATIC_KEY_FALSE(kvm_has_noapic_vcpu); EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_has_noapic_vcpu); @@ -562,6 +590,7 @@ void kvm_apic_set_version(struct kvm_vcpu *vcpu) * IOAPIC. */ if (guest_cpu_cap_has(vcpu, X86_FEATURE_X2APIC) && + kvm_lapic_advertise_suppress_eoi_broadcast(vcpu->kvm) && !ioapic_in_kernel(vcpu->kvm)) v |= APIC_LVR_DIRECTED_EOI; kvm_lapic_set_reg(apic, APIC_LVR, v); @@ -1517,6 +1546,17 @@ static void kvm_ioapic_send_eoi(struct kvm_lapic *apic, int vector) /* Request a KVM exit to inform the userspace IOAPIC. */ if (irqchip_split(apic->vcpu->kvm)) { + /* + * Don't exit to userspace if the guest has enabled Directed + * EOI, a.k.a. Suppress EOI Broadcasts, in which case the local + * APIC doesn't broadcast EOIs (the guest must EOI the target + * I/O APIC(s) directly). Ignore the suppression if userspace + * has NOT explicitly enabled Suppress EOI broadcast. + */ + if ((kvm_lapic_get_reg(apic, APIC_SPIV) & APIC_SPIV_DIRECTED_EOI) && + !kvm_lapic_ignore_suppress_eoi_broadcast(apic->vcpu->kvm)) + return; + apic->vcpu->arch.pending_ioapic_eoi = vector; kvm_make_request(KVM_REQ_IOAPIC_EOI_EXIT, apic->vcpu); return; diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index c9c2aa6f4705..81b40fdb5f5f 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -121,8 +121,11 @@ static u64 __read_mostly efer_reserved_bits = ~((u64)EFER_SCE); #define KVM_CAP_PMU_VALID_MASK KVM_PMU_CAP_DISABLE -#define KVM_X2APIC_API_VALID_FLAGS (KVM_X2APIC_API_USE_32BIT_IDS | \ - KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK) +#define KVM_X2APIC_API_VALID_FLAGS \ + (KVM_X2APIC_API_USE_32BIT_IDS | \ + KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK | \ + KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST | \ + KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST) static void update_cr8_intercept(struct kvm_vcpu *vcpu); static void process_nmi(struct kvm_vcpu *vcpu); @@ -6777,12 +6780,22 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm, r = -EINVAL; if (cap->args[0] & ~KVM_X2APIC_API_VALID_FLAGS) break; + if ((cap->args[0] & KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST) && + (cap->args[0] & KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST)) + break; + if (!irqchip_split(kvm) && + ((cap->args[0] & KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST) || + (cap->args[0] & KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST))) + break; if (cap->args[0] & KVM_X2APIC_API_USE_32BIT_IDS) kvm->arch.x2apic_format = true; if (cap->args[0] & KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK) kvm->arch.x2apic_broadcast_quirk_disabled = true; - + if (cap->args[0] & KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST) + kvm->arch.suppress_eoi_broadcast_mode = KVM_SUPPRESS_EOI_BROADCAST_ENABLED; + if (cap->args[0] & KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST) + kvm->arch.suppress_eoi_broadcast_mode = KVM_SUPPRESS_EOI_BROADCAST_DISABLED; r = 0; break; case KVM_CAP_X86_DISABLE_EXITS: -- 2.39.3

1 day, 10 hours

4
13
0 0

ARMv7 Linux + Rust doesn't boot when compiling with only LLVM=1

by Rudraksha Gupta

Hello all, I have the following problem: https://gitlab.postmarketos.org/postmarketOS/pmbootstrap/-/issues/2635 In short, what is happening is the following: - The kernel boots and outputs via UART when I build the kernel with the following: make LLVM=1 ARCH="$arm" CC="${CC:-gcc}" - The kernel doesn't boot and there is no output via UART when I build the kernel with the following: make LLVM=1 ARCH="$arm" The only difference being: CC="${CC:-gcc}". Is this expected? I think this was present in the Linux kernel ever since Rust was enabled for ARMv7, and I never encountered it because postmarketOS was originally building the first way. Thanks, Rudraksha

1 day, 12 hours

4
8
0 0

[PATCH 5.10.y v2 0/2] Backport 2 commits to fix a KASAN ext4 splat

by David Nyström

Backport commit:5701875f9609 ("ext4: fix out-of-bound read in ext4_xattr_inode_dec_ref_all()" to linux 5.10 branch. The fix depends on commit:69f3a3039b0d ("ext4: introduce ITAIL helper") In order to make a clean backport on stable kernel, backport 2 commits. It has a single merge conflict where static inline int, which changed to static int. Signed-off-by: David Nyström <david.nystrom(a)est.tech> --- Changes in v2: - Resend identical patchset with correct "Upstream commit" denotation. - Link to v1: https://patch.msgid.link/20251216-ext4_splat-v1-0-b76fd8748f44@est.tech --- Ye Bin (2): ext4: introduce ITAIL helper ext4: fix out-of-bound read in ext4_xattr_inode_dec_ref_all() fs/ext4/inode.c | 5 +++++ fs/ext4/xattr.c | 32 ++++---------------------------- fs/ext4/xattr.h | 10 ++++++++++ 3 files changed, 19 insertions(+), 28 deletions(-) --- base-commit: f964b940099f9982d723d4c77988d4b0dda9c165 change-id: 20251215-ext4_splat-f59c1acd9e88 Best regards, -- David Nyström <david.nystrom(a)est.tech>

1 day, 12 hours

1
2
0 0

[PATCH v2,stable/linux-6.6.y] fbdev: Fix out-of-bounds issue in sys_fillrect()

by Gu Bowen

There was an out-of-bounds issue found by syzkaller test on v6.6. BUG: unable to handle page fault for address: ffffc90000c3f000 PGD 100000067 P4D 100000067 PUD 100c80067 PMD 10ac1c067 PTE 0 Oops: 0002 [#1] PREEMPT SMP KASAN PTI CPU: 3 PID: 6521 Comm: syz.3.1365 Not tainted 6.6.0+ #82 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010:memset64 arch/x86/include/asm/string_64.h:58 [inline] RIP: 0010:memset_l include/linux/string.h:168 [inline] RIP: 0010:bitfill_aligned drivers/video/fbdev/core/sysfillrect.c:53 [inline] RIP: 0010:bitfill_aligned+0x144/0x1c0 drivers/video/fbdev/core/sysfillrect.c:25 Code: 23 04 24 48 31 d0 49 89 46 f8 44 89 e0 44 29 f8 29 c3 e8 9f 39 49 fe 89 d8 31 d2 4c 89 f7 41 f7 f4 48 89 c3 48 89 c1 48 89 e8 <f3> 48 ab 31 ff 4c 89 ee e8 df 2f 49 fe 4d 85 ed 0f 84 6b ff ff ff RSP: 0018:ffff888119ce7418 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000180 RCX: 0000000000000180 RDX: 0000000000000000 RSI: ffffc90003873000 RDI: ffffc90000c3f000 RBP: 0000000000000000 R08: 0000000000006000 R09: 0000000000000040 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000040 R13: 0000000000000000 R14: ffffc90000c3f000 R15: 0000000000000000 FS: 00007f1704b926c0(0000) GS:ffff8881f5980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc90000c3f000 CR3: 00000001230d0002 CR4: 0000000000770ee0 DR0: 0000000000000000 DR1: 000000000000e000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: <TASK> sys_fillrect+0x429/0x830 drivers/video/fbdev/core/sysfillrect.c:281 drm_fbdev_generic_defio_fillrect+0x27/0x140 drivers/gpu/drm/drm_fbdev_generic.c:37 bit_clear+0x183/0x220 drivers/video/fbdev/core/bitblit.c:73 __fbcon_clear+0x5ea/0x670 drivers/video/fbdev/core/fbcon.c:1281 fbcon_scroll+0x41e/0x560 drivers/video/fbdev/core/fbcon.c:1847 con_scroll+0x464/0x6a0 drivers/tty/vt/vt.c:577 lf+0x274/0x2d0 drivers/tty/vt/vt.c:1461 do_con_trol+0x5ea/0x3d80 drivers/tty/vt/vt.c:2149 do_con_write+0x780/0x10c0 drivers/tty/vt/vt.c:2905 con_write+0x28/0xc0 drivers/tty/vt/vt.c:3245 do_output_char+0x5de/0x850 drivers/tty/n_tty.c:433 process_output drivers/tty/n_tty.c:500 [inline] n_tty_write+0x442/0xb00 drivers/tty/n_tty.c:2406 iterate_tty_write+0x2b5/0x630 drivers/tty/tty_io.c:1017 file_tty_write.constprop.0+0x20c/0x3b0 drivers/tty/tty_io.c:1088 call_write_iter include/linux/fs.h:2085 [inline] do_iter_readv_writev+0x210/0x3c0 fs/read_write.c:737 do_iter_write+0x181/0x4e0 fs/read_write.c:862 vfs_writev+0x15b/0x4d0 fs/read_write.c:935 do_writev+0x136/0x370 fs/read_write.c:978 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 When the virtual console is rotated in the backend state, it can lead to inconsistencies between the size of the virtual console's size and its hook functions. In such cases, clearing the screen may result in out-of-bounds issue. This issue has already been fixed by commit eabb03293087 ("fbdev: Refactoring the fbcon packed pixel drawing routines") on v6.15-rc1, but it still exists in the stable version. It was unclear if there were other scenarios for this issue, and I tried to add pr_err in sys_fillrect. But as Helge pointed out[1], sys_fillrect is on the console printing code path and adding printing here might cause infinite loop. So let's just fix the known scenario. Fix it by moving set_blitting_type() to the visible area of the VC. Link: https://lore.kernel.org/all/aef7d5fd-2926-4c58-b720-4af58aa380d3@gmx.de/ [1] CC: stable(a)vger.kernel.org # for stable-6.6, fbdev had been refactored on 6.15-rc1 Fixes: 68648ed1f58d ("fbdev: add drawing functions for framebuffers in system RAM") Signed-off-by: Gu Bowen <gubowen5(a)huawei.com> --- drivers/video/fbdev/core/fbcon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c index 78a5b22c8d15..8139ac8a666f 100644 --- a/drivers/video/fbdev/core/fbcon.c +++ b/drivers/video/fbdev/core/fbcon.c @@ -2702,9 +2702,9 @@ static void fbcon_modechanged(struct fb_info *info) return; p = &fb_display[vc->vc_num]; - set_blitting_type(vc, info); if (con_is_visible(vc)) { + set_blitting_type(vc, info); var_to_display(p, &info->var, info); cols = FBCON_SWAP(ops->rotate, info->var.xres, info->var.yres); rows = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres); -- 2.43.0

1 day, 13 hours

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror