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

[PATCH] intel_idle: fix ACPI _CST matching for newer Xeon platforms

by Weilin Tong

From: Artem Bityutskiy <artem.bityutskiy(a)linux.intel.com> ANBZ: #11599 commit 4c411cca33cf1c21946b710b2eb59aca9f646703 upstream. Background ~~~~~~~~~~ The driver uses 'use_acpi = true' in C-state custom table for all Xeon platforms. The meaning of this flag is as follows. 1. If a C-state from the custom table is defined in ACPI _CST (matched by the mwait hint), then enable this C-state. 2. Otherwise, disable this C-state, unless the C-sate definition in the custom table has the 'CPUIDLE_FLAG_ALWAYS_ENABLE' flag set, in which case enabled it. The goal is to honor BIOS C6 settings - If BIOS disables C6, disable it by default in the OS too (but it can be enabled via sysfs). This works well on Xeons that expose only one flavor of C6. This are all Xeons except for the newest Granite Rapids (GNR) and Sierra Forest (SRF). The problem ~~~~~~~~~~~ GNR and SRF have 2 flavors of C6: C6/C6P on GNR, C6S/C6SP on SRF. The the "P" flavor allows for the package C6, while the "non-P" flavor allows only for core/module C6. As far as this patch is concerned, both GNR and SRF platforms are handled the same way. Therefore, further discussion is focused on GNR, but it applies to SRF as well. On Intel Xeon platforms, BIOS exposes only 2 ACPI C-states: C1 and C2. Well, depending on BIOS settings, C2 may be named as C3. But there still will be only 2 states - C1 and C3. But this is a non-essential detail, so further discussion is focused on the ACPI C1 and C2 case. On pre-GNR/SRF Xeon platforms, ACPI C1 is mapped to C1 or C1E, and ACPI C2 is mapped to C6. The 'use_acpi' flag works just fine: * If ACPI C2 enabled, enable C6. * Otherwise, disable C6. However, on GNR there are 2 flavors of C6, so BIOS maps ACPI C2 to either C6 or C6P, depending on the user settings. As a result, due to the 'use_acpi' flag, 'intel_idle' disables least one of the C6 flavors. BIOS | OS | Verdict ----------------------------------------------------|--------- ACPI C2 disabled | C6 disabled, C6P disabled | OK ACPI C2 mapped to C6 | C6 enabled, C6P disabled | Not OK ACPI C2 mapped to C6P | C6 disabled, C6P enabled | Not OK The goal of 'use_acpi' is to honor BIOS ACPI C2 disabled case, which works fine. But if ACPI C2 is enabled, the goal is to enable all flavors of C6, not just one of the flavors. This was overlooked when enabling GNR/SRF platforms. In other words, before GNR/SRF, the ACPI C2 status was binary - enabled or disabled. But it is not binary on GNR/SRF, however the goal is to continue treat it as binary. The fix ~~~~~~~ Notice, that current algorithm matches ACPI and custom table C-states by the mwait hint. However, mwait hint consists of the 'state' and 'sub-state' parts, and all C6 flavors have the same state value of 0x20, but different sub-state values. Introduce new C-state table flag - CPUIDLE_FLAG_PARTIAL_HINT_MATCH and add it to both C6 flavors of the GNR/SRF platforms. When matching ACPI _CST and custom table C-states, match only the start part if the C-state has CPUIDLE_FLAG_PARTIAL_HINT_MATCH, other wise match both state and sub-state parts (as before). With this fix, GNR C-states enabled/disabled status looks like this. BIOS | OS ---------------------------------------------------- ACPI C2 disabled | C6 disabled, C6P disabled ACPI C2 mapped to C6 | C6 enabled, C6P enabled ACPI C2 mapped to C6P | C6 enabled, C6P enabled Possible alternative ~~~~~~~~~~~~~~~~~~~~ The alternative would be to remove 'use_acpi' flag for GNR and SRF. This would be a simpler solution, but it would violate the principle of least surprise - users of Xeon platforms are used to the fact that intel_idle honors C6 enabled/disabled flag. It is more consistent user experience if GNR/SRF continue doing so. How tested ~~~~~~~~~~ Tested on GNR and SRF platform with all the 3 BIOS configurations: ACPI C2 disabled, mapped to C6/C6S, mapped to C6P/C6SP. Tested on Ice lake Xeon and Sapphire Rapids Xeon platforms with ACPI C2 enabled and disabled, just to verify that the patch does not break older Xeons. Intel-SIG: Intel-SIG: commit 4c411cca33cf intel_idle: fix ACPI _CST matching for newer Xeon platforms. Backport intel_idle GNR and SRF fix Fixes: 92813fd5b156 ("intel_idle: add Sierra Forest SoC support") Fixes: 370406bf5738 ("intel_idle: add Granite Rapids Xeon support") Cc: 6.8+ <stable(a)vger.kernel.org> # 6.8+ Signed-off-by: Artem Bityutskiy <artem.bityutskiy(a)linux.intel.com> Link: https://patch.msgid.link/20240913165143.4140073-1-dedekind1@gmail.com [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> [ Yingbao Jia: amend commit log ] Signed-off-by: Yingbao Jia <yingbao.jia(a)intel.com> Reviewed-by: Artie Ding <artie.ding(a)linux.alibaba.com> Link: https://gitee.com/anolis/cloud-kernel/pulls/4057 --- drivers/idle/intel_idle.c | 37 +++++++++++++++++++++++++++++-------- 1 file changed, 29 insertions(+), 8 deletions(-) diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c index 3f216160f19c..783545ff98af 100644 --- a/drivers/idle/intel_idle.c +++ b/drivers/idle/intel_idle.c @@ -120,6 +120,12 @@ static unsigned int mwait_substates __initdata; */ #define CPUIDLE_FLAG_INIT_XSTATE BIT(17) +/* + * Ignore the sub-state when matching mwait hints between the ACPI _CST and + * custom tables. + */ +#define CPUIDLE_FLAG_PARTIAL_HINT_MATCH BIT(18) + /* * MWAIT takes an 8-bit "hint" in EAX "suggesting" * the C-state (top nibble) and sub-state (bottom nibble) @@ -880,7 +886,8 @@ static struct cpuidle_state gnr_cstates[] __initdata = { .name = "C6", .desc = "MWAIT 0x20", .flags = MWAIT2flg(0x20) | CPUIDLE_FLAG_TLB_FLUSHED | - CPUIDLE_FLAG_INIT_XSTATE, + CPUIDLE_FLAG_INIT_XSTATE | + CPUIDLE_FLAG_PARTIAL_HINT_MATCH, .exit_latency = 170, .target_residency = 650, .enter = &intel_idle, @@ -889,7 +896,8 @@ static struct cpuidle_state gnr_cstates[] __initdata = { .name = "C6P", .desc = "MWAIT 0x21", .flags = MWAIT2flg(0x21) | CPUIDLE_FLAG_TLB_FLUSHED | - CPUIDLE_FLAG_INIT_XSTATE, + CPUIDLE_FLAG_INIT_XSTATE | + CPUIDLE_FLAG_PARTIAL_HINT_MATCH, .exit_latency = 210, .target_residency = 1000, .enter = &intel_idle, @@ -1162,7 +1170,8 @@ static struct cpuidle_state srf_cstates[] __initdata = { { .name = "C6S", .desc = "MWAIT 0x22", - .flags = MWAIT2flg(0x22) | CPUIDLE_FLAG_TLB_FLUSHED, + .flags = MWAIT2flg(0x22) | CPUIDLE_FLAG_TLB_FLUSHED | + CPUIDLE_FLAG_PARTIAL_HINT_MATCH, .exit_latency = 270, .target_residency = 700, .enter = &intel_idle, @@ -1170,7 +1179,8 @@ static struct cpuidle_state srf_cstates[] __initdata = { { .name = "C6SP", .desc = "MWAIT 0x23", - .flags = MWAIT2flg(0x23) | CPUIDLE_FLAG_TLB_FLUSHED, + .flags = MWAIT2flg(0x23) | CPUIDLE_FLAG_TLB_FLUSHED | + CPUIDLE_FLAG_PARTIAL_HINT_MATCH, .exit_latency = 310, .target_residency = 900, .enter = &intel_idle, @@ -1519,7 +1529,7 @@ static void __init intel_idle_init_cstates_acpi(struct cpuidle_driver *drv) } } -static bool __init intel_idle_off_by_default(u32 mwait_hint) +static bool __init intel_idle_off_by_default(unsigned int flags, u32 mwait_hint) { int cstate, limit; @@ -1536,7 +1546,15 @@ static bool __init intel_idle_off_by_default(u32 mwait_hint) * the interesting states are ACPI_CSTATE_FFH. */ for (cstate = 1; cstate < limit; cstate++) { - if (acpi_state_table.states[cstate].address == mwait_hint) + u32 acpi_hint = acpi_state_table.states[cstate].address; + u32 table_hint = mwait_hint; + + if (flags & CPUIDLE_FLAG_PARTIAL_HINT_MATCH) { + acpi_hint &= ~MWAIT_SUBSTATE_MASK; + table_hint &= ~MWAIT_SUBSTATE_MASK; + } + + if (acpi_hint == table_hint) return false; } return true; @@ -1546,7 +1564,10 @@ static bool __init intel_idle_off_by_default(u32 mwait_hint) static inline bool intel_idle_acpi_cst_extract(void) { return false; } static inline void intel_idle_init_cstates_acpi(struct cpuidle_driver *drv) { } -static inline bool intel_idle_off_by_default(u32 mwait_hint) { return false; } +static inline bool intel_idle_off_by_default(unsigned int flags, u32 mwait_hint) +{ + return false; +} #endif /* !CONFIG_ACPI_PROCESSOR_CSTATE */ /** @@ -1833,7 +1854,7 @@ static void __init intel_idle_init_cstates_icpu(struct cpuidle_driver *drv) if ((disabled_states_mask & BIT(drv->state_count)) || ((icpu->use_acpi || force_use_acpi) && - intel_idle_off_by_default(mwait_hint) && + intel_idle_off_by_default(state->flags, mwait_hint) && !(state->flags & CPUIDLE_FLAG_ALWAYS_ENABLE))) state->flags |= CPUIDLE_FLAG_OFF; -- 2.43.5

1 day, 19 hours

1
0
0 0

FAILED: patch "[PATCH] x86/cpu/hygon: Add missing resctrl_cpu_detect() in bsp_init" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x d8df126349dad855cdfedd6bbf315bad2e901c2f # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025082518-attest-grit-8063@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From d8df126349dad855cdfedd6bbf315bad2e901c2f Mon Sep 17 00:00:00 2001 From: Tianxiang Peng <txpeng(a)tencent.com> Date: Mon, 23 Jun 2025 17:31:53 +0800 Subject: [PATCH] x86/cpu/hygon: Add missing resctrl_cpu_detect() in bsp_init helper Since 923f3a2b48bd ("x86/resctrl: Query LLC monitoring properties once during boot") resctrl_cpu_detect() has been moved from common CPU initialization code to the vendor-specific BSP init helper, while Hygon didn't put that call in their code. This triggers a division by zero fault during early booting stage on our machines with X86_FEATURE_CQM* supported, where get_rdt_mon_resources() tries to calculate mon_l3_config with uninitialized boot_cpu_data.x86_cache_occ_scale. Add the missing resctrl_cpu_detect() in the Hygon BSP init helper. [ bp: Massage commit message. ] Fixes: 923f3a2b48bd ("x86/resctrl: Query LLC monitoring properties once during boot") Signed-off-by: Tianxiang Peng <txpeng(a)tencent.com> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Reviewed-by: Hui Li <caelli(a)tencent.com> Cc: <stable(a)kernel.org> Link: https://lore.kernel.org/20250623093153.3016937-1-txpeng@tencent.com diff --git a/arch/x86/kernel/cpu/hygon.c b/arch/x86/kernel/cpu/hygon.c index 2154f12766fb..1fda6c3a2b65 100644 --- a/arch/x86/kernel/cpu/hygon.c +++ b/arch/x86/kernel/cpu/hygon.c @@ -16,6 +16,7 @@ #include <asm/spec-ctrl.h> #include <asm/delay.h> #include <asm/msr.h> +#include <asm/resctrl.h> #include "cpu.h" @@ -117,6 +118,8 @@ static void bsp_init_hygon(struct cpuinfo_x86 *c) x86_amd_ls_cfg_ssbd_mask = 1ULL << 10; } } + + resctrl_cpu_detect(c); } static void early_init_hygon(struct cpuinfo_x86 *c)

1 day, 20 hours

2
1
0 0

[PATCH v4 1/4] x86/cpu/topology: Use initial APIC ID from XTOPOLOGY leaf on AMD/HYGON

by K Prateek Nayak

Prior to the topology parsing rewrite and the switchover to the new parsing logic for AMD processors in commit c749ce393b8f ("x86/cpu: Use common topology code for AMD"), the "initial_apicid" on these platforms was: - First initialized to the LocalApicId from CPUID leaf 0x1 EBX[31:24]. - Then overwritten by the ExtendedLocalApicId in CPUID leaf 0xb EDX[31:0] on processors that supported topoext. With the new parsing flow introduced in commit f7fb3b2dd92c ("x86/cpu: Provide an AMD/HYGON specific topology parser"), parse_8000_001e() now unconditionally overwrites the "initial_apicid" already parsed during cpu_parse_topology_ext(). Although this has not been a problem on baremetal platforms, on virtualized AMD guests that feature more than 255 cores, QEMU 0's out the CPUID leaf 0x8000001e on CPUs with "CoreID" > 255 to prevent collision of these IDs in EBX[7:0] which can only represent a maximum of 255 cores [1]. This results in the following FW_BUG being logged when booting a guest with more than 255 cores: [Firmware Bug]: CPU 512: APIC ID mismatch. CPUID: 0x0000 APIC: 0x0200 AMD64 Architecture Programmer's Manual Volume 2: System Programming Pub. 24593 Rev. 3.42 [2] Section 16.12 "x2APIC_ID" mentions the Extended Enumeration leaf 0x8000001e (which was later superseded by the extended leaf 0x80000026) provides the full x2APIC ID under all circumstances unlike the one reported by CPUID leaf 0x8000001e EAX which depends on the mode in which APIC is configured. Rely on the APIC ID parsed during cpu_parse_topology_ext() from CPUID leaf 0x80000026 or 0xb and only use the APIC ID from leaf 0x8000001e if cpu_parse_topology_ext() failed (has_topoext is false). On platforms that support the 0xb leaf (Zen2 or later, AMD guests on QEMU) or the extended leaf 0x80000026 (Zen4 or later), the "initial_apicid" is now set to the value parsed from EDX[31:0]. On older AMD/Hygon platforms that does not support the 0xb leaf but supports the TOPOEXT extension (Fam 0x15, 0x16, 0x17[Zen1], and Hygon), the current behavior is retained where "initial_apicid" is set using the 0x8000001e leaf. Cc: stable(a)vger.kernel.org Link: https://github.com/qemu/qemu/commit/35ac5dfbcaa4b [1] Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537 [2] Debugged-by: Naveen N Rao (AMD) <naveen(a)kernel.org> Debugged-by: Sairaj Kodilkar <sarunkod(a)amd.com> Fixes: c749ce393b8f ("x86/cpu: Use common topology code for AMD") Suggested-by: Thomas Gleixner <tglx(a)linutronix.de> Tested-by: Naveen N Rao (AMD) <naveen(a)kernel.org> Signed-off-by: K Prateek Nayak <kprateek.nayak(a)amd.com> --- Changelog v3..v4: o Refreshed the diff based on Thomas' suggestion. The tags have been retained since there are no functional changes - only comments around the code has changed. o Quoted relevant section of APM justifying the changes. o Moved this patch up ahead. o Cc'd stable. --- arch/x86/kernel/cpu/topology_amd.c | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/arch/x86/kernel/cpu/topology_amd.c b/arch/x86/kernel/cpu/topology_amd.c index 843b1655ab45..827dd0dbb6e9 100644 --- a/arch/x86/kernel/cpu/topology_amd.c +++ b/arch/x86/kernel/cpu/topology_amd.c @@ -81,20 +81,25 @@ static bool parse_8000_001e(struct topo_scan *tscan, bool has_topoext) cpuid_leaf(0x8000001e, &leaf); - tscan->c->topo.initial_apicid = leaf.ext_apic_id; - /* - * If leaf 0xb is available, then the domain shifts are set - * already and nothing to do here. Only valid for family >= 0x17. + * If leaf 0xb/0x26 is available, then the APIC ID and the domain + * shifts are set already. */ - if (!has_topoext && tscan->c->x86 >= 0x17) { + if (!has_topoext) { + tscan->c->topo.initial_apicid = leaf.ext_apic_id; + /* - * Leaf 0x80000008 set the CORE domain shift already. - * Update the SMT domain, but do not propagate it. + * Leaf 0x8000008 sets the CORE domain shift but not the + * SMT domain shift. On CPUs with family >= 0x17, there + * might be hyperthreads. */ - unsigned int nthreads = leaf.core_nthreads + 1; + if (tscan->c->x86 >= 0x17) { + /* Update the SMT domain, but do not propagate it. */ + unsigned int nthreads = leaf.core_nthreads + 1; - topology_update_dom(tscan, TOPO_SMT_DOMAIN, get_count_order(nthreads), nthreads); + topology_update_dom(tscan, TOPO_SMT_DOMAIN, + get_count_order(nthreads), nthreads); + } } store_node(tscan, leaf.nnodes_per_socket + 1, leaf.node_id); -- 2.34.1

1 day, 20 hours

1
1
0 0

FAILED: patch "[PATCH] x86/cpu/hygon: Add missing resctrl_cpu_detect() in bsp_init" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y git checkout FETCH_HEAD git cherry-pick -x d8df126349dad855cdfedd6bbf315bad2e901c2f # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025082516-casually-shaping-7c9a@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From d8df126349dad855cdfedd6bbf315bad2e901c2f Mon Sep 17 00:00:00 2001 From: Tianxiang Peng <txpeng(a)tencent.com> Date: Mon, 23 Jun 2025 17:31:53 +0800 Subject: [PATCH] x86/cpu/hygon: Add missing resctrl_cpu_detect() in bsp_init helper Since 923f3a2b48bd ("x86/resctrl: Query LLC monitoring properties once during boot") resctrl_cpu_detect() has been moved from common CPU initialization code to the vendor-specific BSP init helper, while Hygon didn't put that call in their code. This triggers a division by zero fault during early booting stage on our machines with X86_FEATURE_CQM* supported, where get_rdt_mon_resources() tries to calculate mon_l3_config with uninitialized boot_cpu_data.x86_cache_occ_scale. Add the missing resctrl_cpu_detect() in the Hygon BSP init helper. [ bp: Massage commit message. ] Fixes: 923f3a2b48bd ("x86/resctrl: Query LLC monitoring properties once during boot") Signed-off-by: Tianxiang Peng <txpeng(a)tencent.com> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Reviewed-by: Hui Li <caelli(a)tencent.com> Cc: <stable(a)kernel.org> Link: https://lore.kernel.org/20250623093153.3016937-1-txpeng@tencent.com diff --git a/arch/x86/kernel/cpu/hygon.c b/arch/x86/kernel/cpu/hygon.c index 2154f12766fb..1fda6c3a2b65 100644 --- a/arch/x86/kernel/cpu/hygon.c +++ b/arch/x86/kernel/cpu/hygon.c @@ -16,6 +16,7 @@ #include <asm/spec-ctrl.h> #include <asm/delay.h> #include <asm/msr.h> +#include <asm/resctrl.h> #include "cpu.h" @@ -117,6 +118,8 @@ static void bsp_init_hygon(struct cpuinfo_x86 *c) x86_amd_ls_cfg_ssbd_mask = 1ULL << 10; } } + + resctrl_cpu_detect(c); } static void early_init_hygon(struct cpuinfo_x86 *c)

1 day, 20 hours

2
1
0 0

[PATCH v2] wifi: mwifiex: use kcalloc to apply for chan_stats

by Qianfeng Rong

Use kcalloc to allocate 'adapter->chan_stats' memory (max 900 bytes) instead of vmalloc for efficiency and zero-initialize it for security per Dan Carpenter's suggestion. Cc: stable(a)vger.kernel.org Fixes: bf35443314ac ("mwifiex: channel statistics support for mwifiex") Suggested-by: Dan Carpenter <dan.carpenter(a)linaro.org> Signed-off-by: Qianfeng Rong <rongqianfeng(a)vivo.com> --- v2: Change vmalloc_array/vfree to kcalloc/kfree. --- drivers/net/wireless/marvell/mwifiex/cfg80211.c | 5 +++-- drivers/net/wireless/marvell/mwifiex/main.c | 4 ++-- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c index 3498743d5ec0..4c8c7a5fdf23 100644 --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c @@ -4673,8 +4673,9 @@ int mwifiex_init_channel_scan_gap(struct mwifiex_adapter *adapter) * additional active scan request for hidden SSIDs on passive channels. */ adapter->num_in_chan_stats = 2 * (n_channels_bg + n_channels_a); - adapter->chan_stats = vmalloc(array_size(sizeof(*adapter->chan_stats), - adapter->num_in_chan_stats)); + adapter->chan_stats = kcalloc(adapter->num_in_chan_stats, + sizeof(*adapter->chan_stats), + GFP_KERNEL); if (!adapter->chan_stats) return -ENOMEM; diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c index 7b50a88a18e5..1ec069bc8ea1 100644 --- a/drivers/net/wireless/marvell/mwifiex/main.c +++ b/drivers/net/wireless/marvell/mwifiex/main.c @@ -642,7 +642,7 @@ static int _mwifiex_fw_dpc(const struct firmware *firmware, void *context) goto done; err_add_intf: - vfree(adapter->chan_stats); + kfree(adapter->chan_stats); err_init_chan_scan: wiphy_unregister(adapter->wiphy); wiphy_free(adapter->wiphy); @@ -1485,7 +1485,7 @@ static void mwifiex_uninit_sw(struct mwifiex_adapter *adapter) wiphy_free(adapter->wiphy); adapter->wiphy = NULL; - vfree(adapter->chan_stats); + kfree(adapter->chan_stats); mwifiex_free_cmd_buffers(adapter); } -- 2.34.1

1 day, 20 hours

4
5
0 0

[PATCH v4 2/4] x86/cpu/topology: Always try cpu_parse_topology_ext() on AMD/Hygon

by K Prateek Nayak

Support for parsing the topology on AMD/Hygon processors using CPUID leaf 0xb was added in commit 3986a0a805e6 ("x86/CPU/AMD: Derive CPU topology from CPUID function 0xB when available"). In an effort to keep all the topology parsing bits in one place, this commit also introduced a pseudo dependency on the TOPOEXT feature to parse the CPUID leaf 0xb. TOPOEXT feature (CPUID 0x80000001 ECX[22]) advertises the support for Cache Properties leaf 0x8000001d and the CPUID leaf 0x8000001e EAX for "Extended APIC ID" however support for 0xb was introduced alongside the x2APIC support not only on AMD [1], but also historically on x86 [2]. Similar to 0xb, the support for extended CPU topology leaf 0x80000026 too does not depend on the TOPOEXT feature. The support for these leaves is expected to be confirmed by ensuring "leaf <= {extended_}cpuid_level" and then parsing the level 0 of the respective leaf to confirm EBX[15:0] (LogProcAtThisLevel) is non-zero as stated in the definition of "CPUID_Fn0000000B_EAX_x00 [Extended Topology Enumeration] (Core::X86::Cpuid::ExtTopEnumEax0)" in Processor Programming Reference (PPR) for AMD Family 19h Model 01h Rev B1 Vol1 [3] Sec. 2.1.15.1 "CPUID Instruction Functions". This has not been a problem on baremetal platforms since support for TOPOEXT (Fam 0x15 and later) predates the support for CPUID leaf 0xb (Fam 0x17[Zen2] and later), however, for AMD guests on QEMU, "x2apic" feature can be enabled independent of the "topoext" feature where QEMU expects topology and the initial APICID to be parsed using the CPUID leaf 0xb (especially when number of cores > 255) which is populated independent of the "topoext" feature flag. Unconditionally call cpu_parse_topology_ext() on AMD and Hygon processors to first parse the topology using the XTOPOLOGY leaves (0x80000026 / 0xb) before using the TOPOEXT leaf (0x8000001e). Cc: stable(a)vger.kernel.org # Only v6.9 and above Link: https://lore.kernel.org/lkml/1529686927-7665-1-git-send-email-suravee.suthi… [1] Link: https://lore.kernel.org/lkml/20080818181435.523309000@linux-os.sc.intel.com/ [2] Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537 [3] Suggested-by: Naveen N Rao (AMD) <naveen(a)kernel.org> Fixes: 3986a0a805e6 ("x86/CPU/AMD: Derive CPU topology from CPUID function 0xB when available") Signed-off-by: K Prateek Nayak <kprateek.nayak(a)amd.com> --- Changelog v3..v4: o Quoted relevant section of the PPR justifying the changes. o Moved this patch up ahead. o Cc'd stable and made a note that backports should target v6.9 and above since this depends on the x86 topology rewrite. --- arch/x86/kernel/cpu/topology_amd.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/cpu/topology_amd.c b/arch/x86/kernel/cpu/topology_amd.c index 827dd0dbb6e9..4e3134a5550c 100644 --- a/arch/x86/kernel/cpu/topology_amd.c +++ b/arch/x86/kernel/cpu/topology_amd.c @@ -175,18 +175,14 @@ static void topoext_fixup(struct topo_scan *tscan) static void parse_topology_amd(struct topo_scan *tscan) { - bool has_topoext = false; - /* - * If the extended topology leaf 0x8000_001e is available - * try to get SMT, CORE, TILE, and DIE shifts from extended + * Try to get SMT, CORE, TILE, and DIE shifts from extended * CPUID leaf 0x8000_0026 on supported processors first. If * extended CPUID leaf 0x8000_0026 is not supported, try to * get SMT and CORE shift from leaf 0xb first, then try to * get the CORE shift from leaf 0x8000_0008. */ - if (cpu_feature_enabled(X86_FEATURE_TOPOEXT)) - has_topoext = cpu_parse_topology_ext(tscan); + bool has_topoext = cpu_parse_topology_ext(tscan); if (cpu_feature_enabled(X86_FEATURE_AMD_HTR_CORES)) tscan->c->topo.cpu_type = cpuid_ebx(0x80000026); -- 2.34.1

1 day, 20 hours

1
0
0 0

[REGRESSION][STABLE] ext4: too many credits wanted / file system issue in v6.16.1

by Christian Heusel

Hello everyone, the systemd CI has [recently noticed][0] an issue within the ext4 file system after the Arch Linux kernel was upgraded to 6.16.1. The issue is exclusive to the stable tree and does not occur on 6.16 and not on 6.17-rc2. I have also tested 6.16.2-rc1 and it still contains the bug. I was able to bisect the issue between 6.16 and 6.16.1 to the following commit: b9c561f3f29c2 ("ext4: fix insufficient credits calculation in ext4_meta_trans_blocks()") The issue can be reproduced by running the tests from [TEST-58-REPART.sh][1] by running the [systemd integration tests][2]. But if there are any suggestions I can also test myself as the initial setup for the integration tests is a bit involved. It is not yet clear to me whether this has real-world impact besides the test, but the systemd devs said that it's not a particularily demanding workflow, so I guess it is expected to work and could cause issues on other systems too. Also does anybody have an idea which backport could be missing? Cheers, Chris [0]: https://github.com/systemd/systemd/actions/runs/17053272497/job/48345703316… [1]: https://github.com/systemd/systemd/blob/main/test/units/TEST-58-REPART.sh [2]: https://github.com/systemd/systemd/blob/main/test/integration-tests/README.… --- #regzbot introduced: b9c561f3f29c2 #regzbot title: [STABLE] ext4: too many credits wanted / file system issue in v6.16.1 #regzbot link: https://github.com/systemd/systemd/actions/runs/17053272497/job/48345703316… --- git bisect start # status: waiting for both good and bad commits # good: [038d61fd642278bab63ee8ef722c50d10ab01e8f] Linux 6.16 git bisect good 038d61fd642278bab63ee8ef722c50d10ab01e8f # status: waiting for bad commit, 1 good commit known # bad: [3e0969c9a8c57ff3c6139c084673ebedfc1cf14f] Linux 6.16.1 git bisect bad 3e0969c9a8c57ff3c6139c084673ebedfc1cf14f # good: [288f1562e3f6af6d9b461eba49e75c84afa1b92c] media: v4l2-ctrls: Fix H264 SEPARATE_COLOUR_PLANE check git bisect good 288f1562e3f6af6d9b461eba49e75c84afa1b92c # bad: [f427460a1586c2e0865f9326b71ed6e5a0f404f2] f2fs: turn off one_time when forcibly set to foreground GC git bisect bad f427460a1586c2e0865f9326b71ed6e5a0f404f2 # bad: [5f57327f41a5bbb85ea382bc389126dd7b8f2d7b] scsi: elx: efct: Fix dma_unmap_sg() nents value git bisect bad 5f57327f41a5bbb85ea382bc389126dd7b8f2d7b # good: [9143c604415328d5dcd4d37b8adab8417afcdd21] leds: pca955x: Avoid potential overflow when filling default_label (take 2) git bisect good 9143c604415328d5dcd4d37b8adab8417afcdd21 # good: [9c4f20b7ac700e4b4377f85e36165a4f6ca85995] RDMA/hns: Fix accessing uninitialized resources git bisect good 9c4f20b7ac700e4b4377f85e36165a4f6ca85995 # good: [0b21d1962bec2e660c22c4c4231430f97163dcf8] perf tests bp_account: Fix leaked file descriptor git bisect good 0b21d1962bec2e660c22c4c4231430f97163dcf8 # good: [3dbe96d5481acd40d6090f174d2be8433d88716d] clk: thead: th1520-ap: Correctly refer the parent of osc_12m git bisect good 3dbe96d5481acd40d6090f174d2be8433d88716d # bad: [c6714f30ef88096a8da9fcafb6034dc4e9aa467d] clk: sunxi-ng: v3s: Fix de clock definition git bisect bad c6714f30ef88096a8da9fcafb6034dc4e9aa467d # bad: [b9c561f3f29c2d6e1c1d3ffc202910bef250b7d8] ext4: fix insufficient credits calculation in ext4_meta_trans_blocks() git bisect bad b9c561f3f29c2d6e1c1d3ffc202910bef250b7d8 # first bad commit: [b9c561f3f29c2d6e1c1d3ffc202910bef250b7d8] ext4: fix insufficient credits calculation in ext4_meta_trans_blocks()

1 day, 20 hours

3
3
0 0

PCI: dwc: Ensure that dw_pcie_wait_for_link() waits 100 ms after link up

by Marek Vasut

Please backport the following commit into Linux v5.4 and newer stable releases: 80dc18a0cba8dea42614f021b20a04354b213d86 The backport will likely depend on macro rename commit: 817f989700fddefa56e5e443e7d138018ca6709d This part of commit description clarifies why this is a fix: " As per PCIe r6.0, sec 6.6.1, a Downstream Port that supports Link speeds greater than 5.0 GT/s, software must wait a minimum of 100 ms after Link training completes before sending a Configuration Request. " In practice, this makes detection of PCIe Gen3 and Gen4 SSDs reliable on Renesas R-Car V4H SoC. Without this commit, the SSDs sporadically do not get detected, or sometimes they link up in Gen1 mode. This fixes commit 886bc5ceb5cc ("PCI: designware: Add generic dw_pcie_wait_for_link()") which is in v4.5-rc1-4-g886bc5ceb5cc3 , so I think this fix should be backported to all currently maintained stable releases, i.e. v5.4+ . Thank you -- Best regards, Marek Vasut

1 day, 20 hours

2
1
0 0

[REGRESSION] stable-rc/linux-5.10.y: (build) ‘struct platform_driver’ has no member named ‘remove_new’; did you...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.10.y: --- ‘struct platform_driver’ has no member named ‘remove_new’; did you mean ‘remove’? in drivers/usb/musb/omap2430.o (drivers/usb/musb/omap2430.c) [logspec:kbuild,kbuild.compiler.error] --- - dashboard: https://d.kernelci.org/i/maestro:67bf95f2502a816345830c2bfb96f4a8950ce208 - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: 10b6e479487675365bd106d20fb7dbeec6fb4f60 Log excerpt: ===================================================== drivers/usb/musb/omap2430.c:514:10: error: ‘struct platform_driver’ has no member named ‘remove_new’; did you mean ‘remove’? 514 | .remove_new = omap2430_remove, | ^~~~~~~~~~ | remove drivers/usb/musb/omap2430.c:514:27: error: initialization of ‘int (*)(struct platform_device *)’ from incompatible pointer type ‘void (*)(struct platform_device *)’ [-Werror=incompatible-pointer-types] 514 | .remove_new = omap2430_remove, | ^~~~~~~~~~~~~~~ drivers/usb/musb/omap2430.c:514:27: note: (near initialization for ‘omap2430_driver.remove’) cc1: some warnings being treated as errors ===================================================== # Builds where the incident occurred: ## multi_v7_defconfig on (arm): - compiler: gcc-12 - dashboard: https://d.kernelci.org/build/maestro:68aadff1233e484a3fad599c #kernelci issue maestro:67bf95f2502a816345830c2bfb96f4a8950ce208 Reported-by: kernelci.org bot <bot(a)kernelci.org> -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

1 day, 20 hours

2
1
0 0

Linux 6.16.3

by Greg Kroah-Hartman

I'm announcing the release of the 6.16.3 kernel. All users of the 6.16 kernel series that use the ext4 filesystem should upgrade. The updated 6.16.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-6.16.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h ------------ Makefile | 2 fs/ext4/ext4.h | 2 fs/ext4/extents.c | 6 fs/ext4/inline.c | 6 fs/ext4/inode.c | 323 +++++++++++++++++++++++++++----------------- fs/ext4/move_extent.c | 3 fs/ext4/xattr.c | 2 include/trace/events/ext4.h | 47 +++++- 8 files changed, 250 insertions(+), 141 deletions(-) Greg Kroah-Hartman (1): Linux 6.16.3 Zhang Yi (9): ext4: process folios writeback in bytes ext4: move the calculation of wbc->nr_to_write to mpage_folio_done() ext4: fix stale data if it bail out of the extents mapping loop ext4: refactor the block allocation process of ext4_page_mkwrite() ext4: restart handle if credits are insufficient during allocating blocks ext4: enhance tracepoints during the folios writeback ext4: correct the reserved credits for extent conversion ext4: reserved credits for one extent during the folio writeback ext4: replace ext4_writepage_trans_blocks()

1 day, 20 hours

4
8
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror