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

Re: stable 6.6: commit "sched/cpufreq: Rework schedutil governor performance estimation' causes a regression

by Christian Loehle

On 11/21/25 15:37, Yu-Che Cheng wrote: > Hi Vincent, > > On Fri, Nov 21, 2025 at 10:00 PM Vincent Guittot <vincent.guittot(a)linaro.org> > wrote: >> >> On Fri, 21 Nov 2025 at 04:55, Sergey Senozhatsky >> <senozhatsky(a)chromium.org> wrote: >>> >>> Hi Christian, >>> >>> On (25/11/20 10:15), Christian Loehle wrote: >>>> On 11/20/25 04:45, Sergey Senozhatsky wrote: >>>>> Hi, >>>>> >>>>> We are observing a performance regression on one of our arm64 > boards. >>>>> We tracked it down to the linux-6.6.y commit ada8d7fa0ad4 > ("sched/cpufreq: >> >> You mentioned that you tracked down to linux-6.6.y but which kernel >> are you using ? >> > > We're using ChromeOS 6.6 kernel, which is currently on top of linux-v6.6.99. > But we've tested that the performance regression still happens on exactly > the same scheduler codes (`kernel/sched`) as upstream v6.6.99, compared to > those on v6.6.88. > >>>>> Rework schedutil governor performance estimation"). >>>>> >>>>> UI speedometer benchmark: >>>>> w/commit: 395 +/-38 >>>>> w/o commit: 439 +/-14 >>>>> >>>> >>>> Hi Sergey, >>>> Would be nice to get some details. What board? >>> >>> It's an MT8196 chromebook. >>> >>>> What do the OPPs look like? >>> >>> How do I find that out? >> >> In /sys/kernel/debug/opp/cpu*/ >> or >> /sys/devices/system/cpu/cpufreq/policy*/scaling_available_frequencies >> with related_cpus >> > > The energy model on the device is: > > CPU0-3: > +------------+------------+ > | freq (khz) | power (uw) | > +============+============+ > | 339000 | 34362 | > | 400000 | 42099 | > | 500000 | 52907 | > | 600000 | 63795 | > | 700000 | 74747 | > | 800000 | 88445 | > | 900000 | 101444 | > | 1000000 | 120377 | > | 1100000 | 136859 | > | 1200000 | 154162 | > | 1300000 | 174843 | > | 1400000 | 196833 | > | 1500000 | 217052 | > | 1600000 | 247844 | > | 1700000 | 281464 | > | 1800000 | 321764 | > | 1900000 | 352114 | > | 2000000 | 383791 | > | 2100000 | 421809 | > | 2200000 | 461767 | > | 2300000 | 503648 | > | 2400000 | 540731 | > +------------+------------+ > > CPU4-6: > +------------+------------+ > | freq (khz) | power (uw) | > +============+============+ > | 622000 | 131738 | > | 700000 | 147102 | > | 800000 | 172219 | > | 900000 | 205455 | > | 1000000 | 233632 | > | 1100000 | 254313 | > | 1200000 | 288843 | > | 1300000 | 330863 | > | 1400000 | 358947 | > | 1500000 | 400589 | > | 1600000 | 444247 | > | 1700000 | 497941 | > | 1800000 | 539959 | > | 1900000 | 584011 | > | 2000000 | 657172 | > | 2100000 | 746489 | > | 2200000 | 822854 | > | 2300000 | 904913 | > | 2400000 | 1006581 | > | 2500000 | 1115458 | > | 2600000 | 1205167 | > | 2700000 | 1330751 | > | 2800000 | 1450661 | > | 2900000 | 1596740 | > | 3000000 | 1736568 | > | 3100000 | 1887001 | > | 3200000 | 2048877 | > | 3300000 | 2201141 | > +------------+------------+ > > CPU7: > > +------------+------------+ > | freq (khz) | power (uw) | > +============+============+ > | 798000 | 320028 | > | 900000 | 330714 | > | 1000000 | 358108 | > | 1100000 | 384730 | > | 1200000 | 410669 | > | 1300000 | 438355 | > | 1400000 | 469865 | > | 1500000 | 502740 | > | 1600000 | 531645 | > | 1700000 | 560380 | > | 1800000 | 588902 | > | 1900000 | 617278 | > | 2000000 | 645584 | > | 2100000 | 698653 | > | 2200000 | 744179 | > | 2300000 | 810471 | > | 2400000 | 895816 | > | 2500000 | 985234 | > | 2600000 | 1097802 | > | 2700000 | 1201162 | > | 2800000 | 1332076 | > | 2900000 | 1439847 | > | 3000000 | 1575917 | > | 3100000 | 1741987 | > | 3200000 | 1877346 | > | 3300000 | 2161512 | > | 3400000 | 2437879 | > | 3500000 | 2933742 | > | 3600000 | 3322959 | > | 3626000 | 3486345 | > +------------+------------+ > >>> >>>> Does this system use uclamp during the benchmark? How? >>> >>> How do I find that out? >> >> it can be set per cgroup >> /sys/fs/cgroup/system.slice/<name>/cpu.uclam.min|max >> or per task with sched_setattr() >> >> You most probably use it because it's the main reason for ada8d7fa0ad4 >> to remove wrong overestimate of OPP >> > > For the speedometer case, yes, we set the uclamp.min to 20 for the whole > browser and UI (chrome). > There's no system-wide uclamp settings though. (From Sergey's traces) Per-cluster time‑weighted average frequency base => revert: little (cpu0–3, max 2.4 GHz): 0.746 GHz => 1.132 GHz (+51.6%) mid (cpu4–6, max 3.3 GHz): 1.043 GHz => 1.303 GHz (+24.9%) big (cpu7, max 3.626 GHz): 2.563 GHz => 3.116 GHz (+21.6%) And in particular time spent at OPPs (base => revert): Big core at upper 10%: 29.6% => 61.5% little cluster at 339 MHz: 50.1% => 1.0% Interesting that a uclamp.min of 20 (which shouldn't really have much affect on big CPU at all, with or without headroom AFAICS?) makes such a big difference here? > > But we also found other performance regressions in an Android guest VM, > where there's no uclamp for the VM and vCPU processes from the host side. > Particularly, the RAR extraction throughput reduces about 20% in the RAR > app (from RARLAB). > Although it's hard to tell if this is some sort of a side-effect of the UI > regression as the UI is also running at the same time. > I'd be inclined to say that is because of the vastly different DVFS from the UI workload, yes.

3 days, 21 hours

4
6
0 0

🚀 Spaceboard 2.0: Like Coffee but for Your Browser!

by Aleksandar

Hello, Are you ready to send your productivity soaring, fuelled by none other than Spaceboard 2.0? Buckle up, because this ride is taking us straight to the planet of Achievement (it's right next to Planet Procrastination, which we’re leaving far behind). Brace Yourself for Awesomeness: 🤖 AI-Powered Assistant – Our Robot Friends Are Here! We brought more than 90 AI models to the party. Yes, 90! Use them wisely or use them wildly; either way, they’re here to serve (and maybe dance a little jig). 📚 Smart Collections – Organize or Chaos-‘nize! Think of it as your personal organization ninja, ready to karate-chop your digital mess into a zen-like order. 📅 Advanced Task Management – Because To-Do Lists Deserve Better It's more than just a list – it's a life coach that fits in your browser. Automatic deadline tracking and Google Calendar integration might mean you’ve finally found your planner soulmate. 🎨 Chrome Sidepanel – Cool Features On-the-Go Who needs to jump tabs when Spaceboard’s right there? Consider this your personal assistant, minus the coffee runs (AI is still working on that). 🌤 Weather & Location Services – Because Knowing Is Half the Battle Avoid surprising rain showers with real-time forecasts. We promise it will not predict catnados – yet. 🔍 Universal Search – Find All the Things! It’s like having a GPS for your brain! From bookmarks to hidden chocolates at the back of your mind – find it all instantly. 🎯 Subscription Plans – More Choices than a Dessert Menu Explorer Plan for beginners, Visionary Plan for Jedis. Pick your path to ultimate productivity enlightenment. So, What Are You Waiting For? Zoom over to spaceboard.ai [https://emailmarketingsrb.inboxingproserver.com/index.php/campaigns/qw394ew…] and update your extension today. Go ahead, transform your browser into a bustling hub of energy and excitement! Questions, comments, or philosophical musings? We're here to chat, brainstorm, or just swap dad jokes. Catch you at the productivity summit! Cheers, The Spaceboard Crew 🙌 Unsubscribe here [https://emailmarketingsrb.inboxingproserver.com/index.php/campaigns/qw394ew…]

3 days, 21 hours

1
0
0 0

[PATCH net v3] atm/fore200e: Fix possible data race in fore200e_open()

by Gui-Dong Han

Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)vger.kernel.org Signed-off-by: Gui-Dong Han <hanguidong02(a)gmail.com> Reviewed-by: Simon Horman <horms(a)kernel.org> --- v3: * Expanded the commit message to describe the specific call paths causing the race, as suggested by Jakub Kicinski and Paolo Abeni. v2: * Added a description of the data race hazard in fore200e_open(), as suggested by Jakub Kicinski and Simon Horman. --- drivers/atm/fore200e.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c index 4fea1149e003..f62e38571440 100644 --- a/drivers/atm/fore200e.c +++ b/drivers/atm/fore200e.c @@ -1374,7 +1374,9 @@ fore200e_open(struct atm_vcc *vcc) vcc->dev_data = NULL; + mutex_lock(&fore200e->rate_mtx); fore200e->available_cell_rate += vcc->qos.txtp.max_pcr; + mutex_unlock(&fore200e->rate_mtx); kfree(fore200e_vcc); return -EINVAL; -- 2.34.1

3 days, 21 hours

2
1
0 0

[PATCH net v6 0/5] net: dsa: microchip: Fix resource releases in error path

by Bastien Curutchet (Schneider Electric)

Hi all, I worked on adding PTP support for the KSZ8463. While doing so, I ran into a few bugs in the resource release process that occur when things go wrong arount IRQ initialization. This small series fixes those bugs. The next series, which will add the PTP support, depend on this one. Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet(a)bootlin.com> --- Changes in v6: - PATCH 4: Jump in the middle of the release loop instead of partially freeing resource before jumping at the beginning of the release loop. - PATCH 5: Add Andrew's Reviewed-By. - Link to v5: https://lore.kernel.org/r/20251118-ksz-fix-v5-0-8e9c7f56618d@bootlin.com Changes in v5: - All: Add Cc Tag. - PATCH 3: Use dsa_switch_for_each_user_port_continue_reverse() to only iterate over initialized ports. - PATCH 4: Also clean PTP IRQs on port initialization failures - Link to v4: https://lore.kernel.org/r/20251117-ksz-fix-v4-0-13e1da58a492@bootlin.com Changes in v4: - PATCH 1 & 2: Add Andrew's Reviewed-By. - PATCH 3: Ensure ksz_irq is initialized outside of ksz_irq_free() - Add PATCH 4 - PATCH 5: Fix symetry issues in ksz_ptp_msg_irq_{setup/free}() - Link to v3: https://lore.kernel.org/r/20251114-ksz-fix-v3-0-acbb3b9cc32f@bootlin.com Changes in v3: - PATCH 1 and 3: Fix Fixes tags - PATCH 3: Move the irq_dispose_mapping() behind the check that verifies that the domain is initialized - Link to v2: https://lore.kernel.org/r/20251106-ksz-fix-v2-0-07188f608873@bootlin.com Changes in v2: - Add Fixes tag. - Split PATCH 1 in two patches as it needed two different Fixes tags - Add details in commit logs - Link to v1: https://lore.kernel.org/r/20251031-ksz-fix-v1-0-7e46de999ed1@bootlin.com --- Bastien Curutchet (Schneider Electric) (5): net: dsa: microchip: common: Fix checks on irq_find_mapping() net: dsa: microchip: ptp: Fix checks on irq_find_mapping() net: dsa: microchip: Don't free uninitialized ksz_irq net: dsa: microchip: Free previously initialized ports on init failures net: dsa: microchip: Fix symetry in ksz_ptp_msg_irq_{setup/free}() drivers/net/dsa/microchip/ksz_common.c | 31 +++++++++++++++---------------- drivers/net/dsa/microchip/ksz_ptp.c | 22 +++++++++------------- 2 files changed, 24 insertions(+), 29 deletions(-) --- base-commit: 09652e543e809c2369dca142fee5d9b05be9bdc7 change-id: 20251031-ksz-fix-db345df7635f Best regards, -- Bastien Curutchet (Schneider Electric) <bastien.curutchet(a)bootlin.com>

3 days, 21 hours

2
6
0 0

[PATCH] 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 Supress 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 Supress EOI Broad 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 two flags to allow userspace to choose exactly how to solve the immediate issue, and in the long term to allow userspace to control the virtual CPU model that is exposed to the guest (KVM should never have enabled supported for Supress EOI Broadcast without a userspace opt-in). 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 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> --- Documentation/virt/kvm/api.rst | 14 ++++++++++++-- arch/x86/include/asm/kvm_host.h | 2 ++ arch/x86/include/uapi/asm/kvm.h | 6 ++++-- arch/x86/kvm/lapic.c | 13 +++++++++++++ arch/x86/kvm/x86.c | 12 +++++++++--- 5 files changed, 40 insertions(+), 7 deletions(-) diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 57061fa29e6a..4141d2bd8156 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_API_DISABLE_IGNORE_SUPPRESS_EOI_BROADCAST_QUIRK (1ULL << 2) + #define KVM_X2APIC_API_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,14 @@ 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_API_DISABLE_IGNORE_SUPPRESS_EOI_BROADCAST_QUIRK overrides +KVM's quirky behavior of not actually suppressing EOI broadcasts for split IRQ +chips when support for Suppress EOI Broadcasts is advertised to the guest. + +Setting KVM_X2APIC_API_DISABLE_SUPPRESS_EOI_BROADCAST disables support for +Suppress EOI Broadcasts entirely, i.e. instructs KVM to NOT advertise support +to the guest and thus disallow enabling EOI broadcast suppression in SPIV. + 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..f6fdc0842c05 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1480,6 +1480,8 @@ struct kvm_arch { bool x2apic_format; bool x2apic_broadcast_quirk_disabled; + bool disable_ignore_suppress_eoi_broadcast_quirk; + bool x2apic_disable_suppress_eoi_broadcast; 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..82d49696118f 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 (1ULL << 0) +#define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK (1ULL << 1) +#define KVM_X2APIC_API_DISABLE_IGNORE_SUPPRESS_EOI_BROADCAST_QUIRK (1ULL << 2) +#define KVM_X2APIC_API_DISABLE_SUPPRESS_EOI_BROADCAST (1ULL << 3) struct kvm_hyperv_eventfd { __u32 conn_id; diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 0ae7f913d782..cf8a2162872b 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -562,6 +562,7 @@ void kvm_apic_set_version(struct kvm_vcpu *vcpu) * IOAPIC. */ if (guest_cpu_cap_has(vcpu, X86_FEATURE_X2APIC) && + !vcpu->kvm->arch.x2apic_disable_suppress_eoi_broadcast && !ioapic_in_kernel(vcpu->kvm)) v |= APIC_LVR_DIRECTED_EOI; kvm_lapic_set_reg(apic, APIC_LVR, v); @@ -1517,6 +1518,18 @@ 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 disabled KVM's quirk (KVM advertised support for + * Suppress EOI Broadcasts without actually suppressing EOIs). + */ + if ((kvm_lapic_get_reg(apic, APIC_SPIV) & APIC_SPIV_DIRECTED_EOI) && + apic->vcpu->kvm->arch.disable_ignore_suppress_eoi_broadcast_quirk) + 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..e1b6fe783615 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_API_DISABLE_IGNORE_SUPPRESS_EOI_BROADCAST_QUIRK | \ + KVM_X2APIC_API_DISABLE_SUPPRESS_EOI_BROADCAST) static void update_cr8_intercept(struct kvm_vcpu *vcpu); static void process_nmi(struct kvm_vcpu *vcpu); @@ -6782,7 +6785,10 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm, 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_API_DISABLE_IGNORE_SUPPRESS_EOI_BROADCAST_QUIRK) + kvm->arch.disable_ignore_suppress_eoi_broadcast_quirk = true; + if (cap->args[0] & KVM_X2APIC_API_DISABLE_SUPPRESS_EOI_BROADCAST) + kvm->arch.x2apic_disable_suppress_eoi_broadcast = true; r = 0; break; case KVM_CAP_X86_DISABLE_EXITS: -- 2.39.3

4 days

1
0
0 0

[PATCH] LoongArch: Add new PCI ID for pci_fixup_vgadev()

by Huacai Chen

Loongson-2K3000 has a new PCI ID (0x7a46) for its display controller, Add it for pci_fixup_vgadev() since we prefer a discrete graphics card as default boot device if present. Cc: stable(a)vger.kernel.org Signed-off-by: Tianrui Zhao <zhaotianrui(a)loongson.cn> Signed-off-by: Huacai Chen <chenhuacai(a)loongson.cn> --- arch/loongarch/pci/pci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/loongarch/pci/pci.c b/arch/loongarch/pci/pci.c index d9fc5d520b37..d923295ab8c6 100644 --- a/arch/loongarch/pci/pci.c +++ b/arch/loongarch/pci/pci.c @@ -14,6 +14,7 @@ #define PCI_DEVICE_ID_LOONGSON_HOST 0x7a00 #define PCI_DEVICE_ID_LOONGSON_DC1 0x7a06 #define PCI_DEVICE_ID_LOONGSON_DC2 0x7a36 +#define PCI_DEVICE_ID_LOONGSON_DC3 0x7a46 int raw_pci_read(unsigned int domain, unsigned int bus, unsigned int devfn, int reg, int len, u32 *val) @@ -97,3 +98,4 @@ static void pci_fixup_vgadev(struct pci_dev *pdev) } DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LOONGSON, PCI_DEVICE_ID_LOONGSON_DC1, pci_fixup_vgadev); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LOONGSON, PCI_DEVICE_ID_LOONGSON_DC2, pci_fixup_vgadev); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LOONGSON, PCI_DEVICE_ID_LOONGSON_DC3, pci_fixup_vgadev); -- 2.47.3

4 days

1
0
0 0

[PATCH v1] phy: fsl-imx8mq-usb: fix typec orientation switch when built as module

by Franz Schnyder

From: Franz Schnyder <franz.schnyder(a)toradex.com> Currently, the PHY only registers the typec orientation switch when it is built in. If the typec driver is built as a module, the switch registration is skipped due to the preprocessor condition, causing orientation detection to fail. This patch replaces the preprocessor condition so that the orientation switch is correctly registered for both built-in and module builds. Fixes: b58f0f86fd61 ("phy: fsl-imx8mq-usb: add tca function driver for imx95") Cc: stable(a)vger.kernel.org Signed-off-by: Franz Schnyder <franz.schnyder(a)toradex.com> --- drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c index b94f242420fc..d498a6b7234b 100644 --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c @@ -124,7 +124,7 @@ struct imx8mq_usb_phy { static void tca_blk_orientation_set(struct tca_blk *tca, enum typec_orientation orientation); -#ifdef CONFIG_TYPEC +#if IS_ENABLED(CONFIG_TYPEC) static int tca_blk_typec_switch_set(struct typec_switch_dev *sw, enum typec_orientation orientation) -- 2.43.0

4 days, 1 hour

4
4
0 0

[PATCH] [SCSI] hptiop: Add inbound queue offset bounds check in iop_get_config_itl

by Guangshuo Li

In the driver code for the MV‑based queue variant (struct hpt_iopmu_mv of the hptiop driver), the field "inbound_head" is read from the hardware register and used as an index into the array "inbound_q[MVIOP_QUEUE_LEN]". For example: u32 inbound_head = readl(&hba->u.mv.mu->inbound_head); /* ... */ memcpy_toio(&hba->u.mv.mu->inbound_q[inbound_head], &p, 8); The code then increments head and wraps it to zero when it equals MVIOP_QUEUE_LEN. However, the driver does *not* check that the initial value of "inbound_head" is strictly less than "MVIOP_QUEUE_LEN". If the hardware (or attacker‑controlled firmware/hardware device) writes a malicious value into the inbound_head register (which could be ≥ MVIOP_QUEUE_LEN), then subsequent "memcpy_toio" will write past the end of "inbound_q", leading to an out‑of‑bounds write condition. Since inbound_q is allocated with exactly MVIOP_QUEUE_LEN entries (see: __le64 inbound_q[MVIOP_QUEUE_LEN]; /* MVIOP_QUEUE_LEN == 512 */ ), indexing at e.g. "inbound_head == 512" or greater results in undefined memory access and potential corruption of adjacent fields or memory regions. This issue is particularly concerning in scenarios where an attacker has control or influence over the hardware/firmware on the adapter card (for example a malicious or compromised controller), because they could deliberately set "inbound_head" to a value outside the expected [0, MVIOP_QUEUE_LEN‑1] range, thus forcing the driver to write arbitrary data beyond the queue bounds. To mitigate this issue, we add a check to validate the value of "inbound_head" before it is used as an index. If "inbound_head" is found to be out of bounds (≥ MVIOP_QUEUE_LEN), the head will be reset to 0, and "head" will be set to 1 to ensure that a valid entry is written to the queue. The resetting of "inbound_head" to 0 ensures that the queue processing can continue safely and predictably, while the adjustment of "head = 1" ensures that the next valid index is used for subsequent writes. This prevents any out-of-bounds writes and ensures that the queue continues to operate safely even if the hardware is compromised. Fixes: 00f5970193e22 ("[SCSI] hptiop: add more adapter models and other fixes") Cc: stable(a)vger.kernel.org Signed-off-by: Guangshuo Li <lgs201920130244(a)gmail.com> --- drivers/scsi/hptiop.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/scsi/hptiop.c b/drivers/scsi/hptiop.c index c01370893a81..a1a3840e6ea8 100644 --- a/drivers/scsi/hptiop.c +++ b/drivers/scsi/hptiop.c @@ -166,6 +166,14 @@ static void mv_inbound_write(u64 p, struct hptiop_hba *hba) if (head == MVIOP_QUEUE_LEN) head = 0; + if (inbound_head >= MVIOP_QUEUE_LEN) { + dev_err(&hba->pdev->dev, + "hptiop: inbound_head out of range (%u)\n", + inbound_head); + inbound_head = 0; + head = 1; + } + memcpy_toio(&hba->u.mv.mu->inbound_q[inbound_head], &p, 8); writel(head, &hba->u.mv.mu->inbound_head); writel(MVIOP_MU_INBOUND_INT_POSTQUEUE, -- 2.43.0

4 days, 2 hours

2
1
0 0

[PATCH V1 5.4.y 0/2] Fix bad pmd due to race between change_prot_numa() and THP migration

by Harry Yoo

# TL;DR previous discussion: https://lore.kernel.org/linux-mm/20250921232709.1608699-1-harry.yoo@oracle.… A "bad pmd" error occurs due to race condition between change_prot_numa() and THP migration. The mainline kernel does not have this bug as commit 670ddd8cdc fixes the race condition. 6.1.y, 5.15.y, 5.10.y, 5.4.y are affected by this bug. Fixing this in -stable kernels is tricky because pte_map_offset_lock() has different semantics in pre-6.5 and post-6.5 kernels. I am trying to backport the same mechanism we have in the mainline kernel. # Testing I verified that the bug described below is not reproduced anymore (on a downstream kernel) after applying this patch series. It used to trigger in few days of intensive numa balancing testing, but it survived 2 weeks with this applied. # Bug Description It was reported that a bad pmd is seen when automatic NUMA balancing is marking page table entries as prot_numa: [2437548.196018] mm/pgtable-generic.c:50: bad pmd 00000000af22fc02(dffffffe71fbfe02) [2437548.235022] Call Trace: [2437548.238234] <TASK> [2437548.241060] dump_stack_lvl+0x46/0x61 [2437548.245689] panic+0x106/0x2e5 [2437548.249497] pmd_clear_bad+0x3c/0x3c [2437548.253967] change_pmd_range.isra.0+0x34d/0x3a7 [2437548.259537] change_p4d_range+0x156/0x20e [2437548.264392] change_protection_range+0x116/0x1a9 [2437548.269976] change_prot_numa+0x15/0x37 [2437548.274774] task_numa_work+0x1b8/0x302 [2437548.279512] task_work_run+0x62/0x95 [2437548.283882] exit_to_user_mode_loop+0x1a4/0x1a9 [2437548.289277] exit_to_user_mode_prepare+0xf4/0xfc [2437548.294751] ? sysvec_apic_timer_interrupt+0x34/0x81 [2437548.300677] irqentry_exit_to_user_mode+0x5/0x25 [2437548.306153] asm_sysvec_apic_timer_interrupt+0x16/0x1b This is due to a race condition between change_prot_numa() and THP migration because the kernel doesn't check is_swap_pmd() and pmd_trans_huge() atomically: change_prot_numa() THP migration ====================================================================== - change_pmd_range() -> is_swap_pmd() returns false, meaning it's not a PMD migration entry. - do_huge_pmd_numa_page() -> migrate_misplaced_page() sets migration entries for the THP. - change_pmd_range() -> pmd_none_or_clear_bad_unless_trans_huge() -> pmd_none() and pmd_trans_huge() returns false - pmd_none_or_clear_bad_unless_trans_huge() -> pmd_bad() returns true for the migration entry! The upstream commit 670ddd8cdcbd ("mm/mprotect: delete pmd_none_or_clear_bad_unless_trans_huge()") closes this race condition by checking is_swap_pmd() and pmd_trans_huge() atomically. # Backporting note commit a79390f5d6a7 ("mm/mprotect: use long for page accountings and retval") is backported to return an error code (negative value) in change_pte_range(). Unlike the mainline, pte_offset_map_lock() does not check if the pmd entry is a migration entry or a hugepage; acquires PTL unconditionally instead of returning failure. Therefore, it is necessary to keep the !is_swap_pmd() && !pmd_trans_huge() && !pmd_devmap() checks in change_pmd_range() before acquiring the PTL. After acquiring the lock, open-code the semantics of pte_offset_map_lock() in the mainline kernel; change_pte_range() fails if the pmd value has changed. This requires adding pmd_old parameter (pmd_t value that is read before calling the function) to change_pte_range(). Hugh Dickins (1): mm/mprotect: delete pmd_none_or_clear_bad_unless_trans_huge() Peter Xu (1): mm/mprotect: use long for page accountings and retval include/linux/hugetlb.h | 4 +- include/linux/mm.h | 2 +- mm/hugetlb.c | 4 +- mm/mempolicy.c | 2 +- mm/mprotect.c | 124 +++++++++++++++++----------------------- 5 files changed, 60 insertions(+), 76 deletions(-) -- 2.43.0

4 days, 4 hours

1
2
0 0

[PATCH V1 5.10.y 0/2] Fix bad pmd due to race between change_prot_numa() and THP migration

by Harry Yoo

# TL;DR previous discussion: https://lore.kernel.org/linux-mm/20250921232709.1608699-1-harry.yoo@oracle.… A "bad pmd" error occurs due to race condition between change_prot_numa() and THP migration. The mainline kernel does not have this bug as commit 670ddd8cdc fixes the race condition. 6.1.y, 5.15.y, 5.10.y, 5.4.y are affected by this bug. Fixing this in -stable kernels is tricky because pte_map_offset_lock() has different semantics in pre-6.5 and post-6.5 kernels. I am trying to backport the same mechanism we have in the mainline kernel. # Testing I verified that the bug described below is not reproduced anymore (on a downstream kernel) after applying this patch series. It used to trigger in few days of intensive numa balancing testing, but it survived 2 weeks with this applied. # Bug Description It was reported that a bad pmd is seen when automatic NUMA balancing is marking page table entries as prot_numa: [2437548.196018] mm/pgtable-generic.c:50: bad pmd 00000000af22fc02(dffffffe71fbfe02) [2437548.235022] Call Trace: [2437548.238234] <TASK> [2437548.241060] dump_stack_lvl+0x46/0x61 [2437548.245689] panic+0x106/0x2e5 [2437548.249497] pmd_clear_bad+0x3c/0x3c [2437548.253967] change_pmd_range.isra.0+0x34d/0x3a7 [2437548.259537] change_p4d_range+0x156/0x20e [2437548.264392] change_protection_range+0x116/0x1a9 [2437548.269976] change_prot_numa+0x15/0x37 [2437548.274774] task_numa_work+0x1b8/0x302 [2437548.279512] task_work_run+0x62/0x95 [2437548.283882] exit_to_user_mode_loop+0x1a4/0x1a9 [2437548.289277] exit_to_user_mode_prepare+0xf4/0xfc [2437548.294751] ? sysvec_apic_timer_interrupt+0x34/0x81 [2437548.300677] irqentry_exit_to_user_mode+0x5/0x25 [2437548.306153] asm_sysvec_apic_timer_interrupt+0x16/0x1b This is due to a race condition between change_prot_numa() and THP migration because the kernel doesn't check is_swap_pmd() and pmd_trans_huge() atomically: change_prot_numa() THP migration ====================================================================== - change_pmd_range() -> is_swap_pmd() returns false, meaning it's not a PMD migration entry. - do_huge_pmd_numa_page() -> migrate_misplaced_page() sets migration entries for the THP. - change_pmd_range() -> pmd_none_or_clear_bad_unless_trans_huge() -> pmd_none() and pmd_trans_huge() returns false - pmd_none_or_clear_bad_unless_trans_huge() -> pmd_bad() returns true for the migration entry! The upstream commit 670ddd8cdcbd ("mm/mprotect: delete pmd_none_or_clear_bad_unless_trans_huge()") closes this race condition by checking is_swap_pmd() and pmd_trans_huge() atomically. # Backporting note commit a79390f5d6a7 ("mm/mprotect: use long for page accountings and retval") is backported to return an error code (negative value) in change_pte_range(). Unlike the mainline, pte_offset_map_lock() does not check if the pmd entry is a migration entry or a hugepage; acquires PTL unconditionally instead of returning failure. Therefore, it is necessary to keep the !is_swap_pmd() && !pmd_trans_huge() && !pmd_devmap() checks in change_pmd_range() before acquiring the PTL. After acquiring the lock, open-code the semantics of pte_offset_map_lock() in the mainline kernel; change_pte_range() fails if the pmd value has changed. This requires adding pmd_old parameter (pmd_t value that is read before calling the function) to change_pte_range(). Hugh Dickins (1): mm/mprotect: delete pmd_none_or_clear_bad_unless_trans_huge() Peter Xu (1): mm/mprotect: use long for page accountings and retval include/linux/hugetlb.h | 4 +- include/linux/mm.h | 2 +- mm/hugetlb.c | 4 +- mm/mempolicy.c | 2 +- mm/mprotect.c | 107 ++++++++++++++++++++++------------------ 5 files changed, 64 insertions(+), 55 deletions(-) -- 2.43.0

4 days, 4 hours

1
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror