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

[PATCH] perf Documentation: Correct branch stack sampling call-stack option

by Dapeng Mi

The correct call-stack option for branch stack sampling should be "stack" instead of "call_stack". Correct it. $perf record -e instructions -j call_stack -- sleep 1 unknown branch filter call_stack, check man page Usage: perf record [<options>] [<command>] or: perf record [<options>] -- <command> [<options>] -j, --branch-filter <branch filter mask> branch stack filter modes Cc: stable(a)vger.kernel.org Fixes: 955f6def5590 ("perf record: Add remaining branch filters: "no_cycles", "no_flags" & "hw_index"") Signed-off-by: Dapeng Mi <dapeng1.mi(a)linux.intel.com> --- tools/perf/Documentation/perf-record.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/Documentation/perf-record.txt b/tools/perf/Documentation/perf-record.txt index e8b9aadbbfa5..3d19e77c9c53 100644 --- a/tools/perf/Documentation/perf-record.txt +++ b/tools/perf/Documentation/perf-record.txt @@ -454,7 +454,7 @@ following filters are defined: - no_tx: only when the target is not in a hardware transaction - abort_tx: only when the target is a hardware transaction abort - cond: conditional branches - - call_stack: save call stack + - stack: save call stack - no_flags: don't save branch flags e.g prediction, misprediction etc - no_cycles: don't save branch cycles - hw_index: save branch hardware index base-commit: cb015814f8b6eebcbb8e46e111d108892c5e6821 -- 2.34.1

2 days, 16 hours

1
0
0 0

[PATCH] perf/x86/intel: Add missing branch counters constraint apply

by Dapeng Mi

When running the command: 'perf record -e "{instructions,instructions:p}" -j any,counter sleep 1', a "shift-out-of-bounds" warning is reported on CWF. [ 5231.981423][ C17] UBSAN: shift-out-of-bounds in /kbuild/src/consumer/arch/x86/events/intel/lbr.c:970:15 [ 5231.981428][ C17] shift exponent 64 is too large for 64-bit type 'long long unsigned int' [ 5231.981436][ C17] CPU: 17 UID: 0 PID: 211871 Comm: sleep Tainted: G S W 6.18.0-2025-12-09-intel-next-48166-g6cf574943ba3 #1 PREEMPT(none) [ 5231.981445][ C17] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN [ 5231.981447][ C17] Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.IPC.3544.P98.2508260307 08/26/2025 [ 5231.981449][ C17] Call Trace: [ 5231.981453][ C17] <NMI> [ 5231.981455][ C17] dump_stack_lvl+0x4b/0x70 [ 5231.981463][ C17] ubsan_epilogue+0x5/0x2b [ 5231.981468][ C17] __ubsan_handle_shift_out_of_bounds.cold+0x61/0xe6 [ 5231.981472][ C17] ? __entry_text_end+0x158b/0x102259 [ 5231.981475][ C17] intel_pmu_lbr_counters_reorder.isra.0.cold+0x2a/0xa7 [ 5231.981480][ C17] ? __task_pid_nr_ns+0x134/0x2a0 [ 5231.981483][ C17] ? __pfx_intel_pmu_lbr_counters_reorder.isra.0+0x10/0x10 [ 5231.981486][ C17] ? __pfx_perf_output_sample+0x10/0x10 [ 5231.981489][ C17] ? arch_perf_update_userpage+0x293/0x310 [ 5231.981491][ C17] ? __pfx_arch_perf_update_userpage+0x10/0x10 [ 5231.981494][ C17] ? local_clock_noinstr+0xd/0x100 [ 5231.981498][ C17] ? calc_timer_values+0x2cb/0x860 [ 5231.981501][ C17] ? perf_event_update_userpage+0x399/0x5b0 [ 5231.981505][ C17] ? __pfx_perf_event_update_userpage+0x10/0x10 [ 5231.981508][ C17] ? local_clock_noinstr+0xd/0x100 [ 5231.981511][ C17] ? __perf_event_account_interrupt+0x11c/0x540 [ 5231.981514][ C17] intel_pmu_lbr_save_brstack+0xc0/0x4c0 [ 5231.981518][ C17] setup_arch_pebs_sample_data+0x114b/0x2400 [ 5231.981522][ C17] ? __pfx_x86_perf_event_set_period+0x10/0x10 [ 5231.981526][ C17] intel_pmu_drain_arch_pebs+0x64d/0xcc0 [ 5231.981530][ C17] ? __pfx_intel_pmu_drain_arch_pebs+0x10/0x10 [ 5231.981534][ C17] ? unwind_next_frame+0x11c5/0x1df0 [ 5231.981541][ C17] ? intel_pmu_drain_bts_buffer+0xbf/0x6e0 [ 5231.981545][ C17] ? __pfx_intel_pmu_drain_bts_buffer+0x10/0x10 [ 5231.981550][ C17] handle_pmi_common+0x5c5/0xcb0 [ 5231.981553][ C17] ? __pfx_handle_pmi_common+0x10/0x10 [ 5231.981556][ C17] ? intel_idle+0x64/0xb0 [ 5231.981560][ C17] ? intel_bts_interrupt+0xe5/0x4c0 [ 5231.981562][ C17] ? __pfx_intel_bts_interrupt+0x10/0x10 [ 5231.981565][ C17] ? intel_pmu_lbr_filter+0x27f/0x910 [ 5231.981568][ C17] intel_pmu_handle_irq+0x2ed/0x600 [ 5231.981571][ C17] perf_event_nmi_handler+0x219/0x280 [ 5231.981575][ C17] ? __pfx_perf_event_nmi_handler+0x10/0x10 [ 5231.981579][ C17] ? unwind_next_frame+0x11c5/0x1df0 [ 5231.981582][ C17] nmi_handle.part.0+0x11b/0x3a0 [ 5231.981585][ C17] ? unwind_next_frame+0x11c5/0x1df0 [ 5231.981588][ C17] default_do_nmi+0x6b/0x180 [ 5231.981591][ C17] fred_exc_nmi+0x3e/0x80 [ 5231.981594][ C17] asm_fred_entrypoint_kernel+0x41/0x60 [ 5231.981596][ C17] RIP: 0010:unwind_next_frame+0x11c5/0x1df0 ...... The warning occurs because the second "instructions:p" event, which involves branch counters sampling, is incorrectly programmed to fixed counter 0 instead of the general-purpose (GP) counters 0-3 that support branch counters sampling. Currently only GP counters 0~3 support branch counters sampling on CWF, any event involving branch counters sampling should be programed on GP counters 0~3. Since the counter index of fixed counter 0 is 32, it leads to the "src" value in below code is right shifted 64 bits and trigger the "shift-out-of-bounds" warning. cnt = (src >> (order[j] * LBR_INFO_BR_CNTR_BITS)) & LBR_INFO_BR_CNTR_MASK; The root cause is the loss of the branch counters constraint for the last event in the branch counters sampling event group. This results in the second "instructions:p" event being programmed on fixed counter 0 incorrectly instead of the appropriate GP counters 0~3. To address this, we apply the missing branch counters constraint for the last event in the group. Additionally, we introduce a new function, `intel_set_branch_counter_constr()`, to apply the branch counters constraint and avoid code duplication. Cc: stable(a)vger.kernel.org Reported-by: Xudong Hao <xudong.hao(a)intel.com> Fixes: 33744916196b ("perf/x86/intel: Support branch counters logging") Signed-off-by: Dapeng Mi <dapeng1.mi(a)linux.intel.com> --- arch/x86/events/intel/core.c | 30 ++++++++++++++++++++---------- 1 file changed, 20 insertions(+), 10 deletions(-) diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c index aad89c9d9514..7c6a0001c8e4 100644 --- a/arch/x86/events/intel/core.c +++ b/arch/x86/events/intel/core.c @@ -4364,6 +4364,19 @@ static inline void intel_pmu_set_acr_caused_constr(struct perf_event *event, event->hw.dyn_constraint &= hybrid(event->pmu, acr_cause_mask64); } +static inline int intel_set_branch_counter_constr(struct perf_event *event, + int *num) +{ + if (branch_sample_call_stack(event)) + return -EINVAL; + if (branch_sample_counters(event)) { + (*num)++; + event->hw.dyn_constraint &= x86_pmu.lbr_counters; + } + + return 0; +} + static int intel_pmu_hw_config(struct perf_event *event) { int ret = x86_pmu_hw_config(event); @@ -4434,21 +4447,18 @@ static int intel_pmu_hw_config(struct perf_event *event) * group, which requires the extra space to store the counters. */ leader = event->group_leader; - if (branch_sample_call_stack(leader)) + if (intel_set_branch_counter_constr(leader, &num)) return -EINVAL; - if (branch_sample_counters(leader)) { - num++; - leader->hw.dyn_constraint &= x86_pmu.lbr_counters; - } leader->hw.flags |= PERF_X86_EVENT_BRANCH_COUNTERS; for_each_sibling_event(sibling, leader) { - if (branch_sample_call_stack(sibling)) + if (intel_set_branch_counter_constr(sibling, &num)) + return -EINVAL; + } + + if (event != leader) { + if (intel_set_branch_counter_constr(event, &num)) return -EINVAL; - if (branch_sample_counters(sibling)) { - num++; - sibling->hw.dyn_constraint &= x86_pmu.lbr_counters; - } } if (num > fls(x86_pmu.lbr_counters)) base-commit: 9929dffce5ed7e2988e0274f4db98035508b16d9 -- 2.34.1

2 days, 16 hours

1
0
0 0

[PATCH] drm/i915/dg2: Update workaround 22013059131

by Jia Yao

Previous fix enabled LSC chicken bit FORCE_1_SUB_MESSAGE_PER_FRAGMENT. This caused side effects on 128EU SKUs. Updated solution limits SLM allocation to 96KB which is done at UMD to avoid these issues and ensure stable behavior. Bspec: 54833 Fixes: 645cc0b9d972 ("drm/i915/dg2: Add initial gt/ctx/engine workarounds") Signed-off-by: Jia Yao <jia.yao(a)intel.com> Cc: Alex Zuo <alex.zuo(a)intel.com> Cc: Shuicheng Lin <shuicheng.lin(a)intel.com> Cc: Xin Wang <x.wang(a)intel.com> Cc: stable(a)vger.kernel.org Cc: Matt Roper <matthew.d.roper(a)intel.com> --- drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c index ece88c612e27..abb47c65f43a 100644 --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c @@ -2866,10 +2866,6 @@ general_render_compute_wa_init(struct intel_engine_cs *engine, struct i915_wa_li MAXREQS_PER_BANK, REG_FIELD_PREP(MAXREQS_PER_BANK, 2)); - /* Wa_22013059131:dg2 */ - wa_mcr_write_or(wal, LSC_CHICKEN_BIT_0, - FORCE_1_SUB_MESSAGE_PER_FRAGMENT); - /* * Wa_22012654132 * -- 2.34.1

2 days, 17 hours

2
1
0 0

[PATCH AUTOSEL 6.18-6.17] ALSA: hda/realtek: Add support for ASUS UM3406GA

by Sasha Levin

From: Stefan Binding <sbinding(a)opensource.cirrus.com> [ Upstream commit 826c0b1ed09e5335abcae07292440ce72346e578 ] Laptops use 2 CS35L41 Amps with HDA, using External boost, with I2C Signed-off-by: Stefan Binding <sbinding(a)opensource.cirrus.com> Link: https://patch.msgid.link/20251205150614.49590-3-sbinding@opensource.cirrus.… Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: ## Commit Analysis: ALSA: hda/realtek: Add support for ASUS UM3406GA ### 1. COMMIT MESSAGE ANALYSIS The commit message is straightforward: it adds support for a specific ASUS laptop model (UM3406GA) that uses 2 CS35L41 amplifiers connected via I2C with external boost. The message describes the hardware configuration, which is standard for such device ID additions. No Fixes: or Cc: stable tags are present, but as noted, this is expected for commits requiring manual review. ### 2. CODE CHANGE ANALYSIS The entire change is a single line addition: ```c SND_PCI_QUIRK(0x1043, 0x1584, "ASUS UM3406GA ", ALC287_FIXUP_CS35L41_I2C_2), ``` This adds: - Vendor ID: 0x1043 (ASUS) - Device/Subsystem ID: 0x1584 (ASUS UM3406GA) - Fixup: `ALC287_FIXUP_CS35L41_I2C_2` (an **existing** fixup already used by many other ASUS models) Looking at the surrounding code, multiple other ASUS laptops use the same fixup: - ASUS PM3406CKA (0x1454) - ASUS G513PI/PU/PV (0x14e3) - ASUS G733PY/PZ/PZV/PYV (0x1503) - ASUS GV302XA/XJ/XQ/XU/XV/XI (0x1533) - ASUS UM3402YAR (0x1683) ### 3. CLASSIFICATION This is a **NEW DEVICE ID** addition - explicitly listed as an exception that IS appropriate for stable backporting. The driver infrastructure and fixup code already exist; this merely adds an ID to enable the existing fix for new hardware. ### 4. SCOPE AND RISK ASSESSMENT - **Lines changed**: 1 line - **Files touched**: 1 file - **Complexity**: Zero - table entry addition only - **Risk**: Extremely low - this cannot affect any other hardware - **No new code paths**: Uses pre-existing `ALC287_FIXUP_CS35L41_I2C_2` fixup ### 5. USER IMPACT - **Who is affected**: Owners of ASUS UM3406GA laptops - **Problem without fix**: Audio (specifically the CS35L41 amplifiers) won't function properly - **Severity**: Non-working audio is a significant user-facing issue for laptop users ### 6. STABILITY INDICATORS - Signed-off by Takashi Iwai (ALSA maintainer at SUSE) - Standard quirk addition pattern used extensively throughout this file - Follows exact same format as dozens of other ASUS quirk entries ### 7. DEPENDENCY CHECK - The fixup `ALC287_FIXUP_CS35L41_I2C_2` has been in the kernel for some time, supporting multiple other ASUS models - No other commits are required for this to work - This should apply cleanly to stable trees that have the CS35L41 support infrastructure ### CONCLUSION This commit is a textbook example of what should be backported to stable trees: 1. **Falls under explicit exception**: Adding device IDs to existing drivers is explicitly allowed 2. **Minimal change**: Single line, single table entry 3. **Zero regression risk**: Cannot affect any hardware except the targeted laptop 4. **Uses existing infrastructure**: The fixup is already well-tested on similar ASUS models 5. **Fixes real user problem**: Enables audio on a production laptop 6. **Obviously correct**: Identical pattern to surrounding entries The risk-benefit analysis strongly favors backporting: virtually zero risk with clear user benefit (working audio on a specific laptop model). **YES** sound/hda/codecs/realtek/alc269.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c index b45fcc9a3785e..008bf9d5148e1 100644 --- a/sound/hda/codecs/realtek/alc269.c +++ b/sound/hda/codecs/realtek/alc269.c @@ -6752,6 +6752,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A", ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A), SND_PCI_QUIRK(0x1043, 0x1533, "ASUS GV302XA/XJ/XQ/XU/XV/XI", ALC287_FIXUP_CS35L41_I2C_2), SND_PCI_QUIRK(0x1043, 0x1573, "ASUS GZ301VV/VQ/VU/VJ/VA/VC/VE/VVC/VQC/VUC/VJC/VEC/VCC", ALC285_FIXUP_ASUS_HEADSET_MIC), + SND_PCI_QUIRK(0x1043, 0x1584, "ASUS UM3406GA ", ALC287_FIXUP_CS35L41_I2C_2), SND_PCI_QUIRK(0x1043, 0x1652, "ASUS ROG Zephyrus Do 15 SE", ALC289_FIXUP_ASUS_ZEPHYRUS_DUAL_SPK), SND_PCI_QUIRK(0x1043, 0x1662, "ASUS GV301QH", ALC294_FIXUP_ASUS_DUAL_SPK), SND_PCI_QUIRK(0x1043, 0x1663, "ASUS GU603ZI/ZJ/ZQ/ZU/ZV", ALC285_FIXUP_ASUS_HEADSET_MIC), -- 2.51.0

2 days, 18 hours

2
10
0 0

+ mm-hugetlb-fix-excessive-ipi-broadcasts-when-unsharing-pmd-tables-using-mmu_gather.patch added to mm-new branch

by Andrew Morton

The patch titled Subject: mm/hugetlb: fix excessive IPI broadcasts when unsharing PMD tables using mmu_gather has been added to the -mm mm-new branch. Its filename is mm-hugetlb-fix-excessive-ipi-broadcasts-when-unsharing-pmd-tables-using-mmu_gather.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-new branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Note, mm-new is a provisional staging ground for work-in-progress patches, and acceptance into mm-new is a notification for others take notice and to finish up reviews. Please do not hesitate to respond to review feedback and post updated versions to replace or incrementally fixup patches in mm-new. Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: "David Hildenbrand (Red Hat)" <david(a)kernel.org> Subject: mm/hugetlb: fix excessive IPI broadcasts when unsharing PMD tables using mmu_gather Date: Fri, 12 Dec 2025 08:10:19 +0100 As reported, ever since commit 1013af4f585f ("mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race") we can end up in some situations where we perform so many IPI broadcasts when unsharing hugetlb PMD page tables that it severely regresses some workloads. In particular, when we fork()+exit(), or when we munmap() a large area backed by many shared PMD tables, we perform one IPI broadcast per unshared PMD table. There are two optimizations to be had: (1) When we process (unshare) multiple such PMD tables, such as during exit(), it is sufficient to send a single IPI broadcast (as long as we respect locking rules) instead of one per PMD table. Locking prevents that any of these PMD tables could get reuse before we drop the lock. (2) When we are not the last sharer (> 2 users including us), there is no need to send the IPI broadcast. The shared PMD tables cannot become exclusive (fully unshared) before an IPI will be broadcasted by the last sharer. Concurrent GUP-fast could walk into a PMD table just before we unshared it. It could then succeed in grabbing a page from the shared page table even after munmap() etc succeeded (and supressed an IPI). But there is not difference compared to GUP-fast just sleeping for a while after grabbing the page and re-enabling IRQs. Most importantly, GUP-fast will never walk into page tables that are no-longer shared, because the last sharer will issue an IPI broadcast. (if ever required, checking whether the PUD changed in GUP-fast after grabbing the page like we do in the PTE case could handle this) So let's rework PMD sharing TLB flushing + IPI sync to use the mmu_gather infrastructure so we can implement these optimizations and demystify the code at least a bit. Extend the mmu_gather infrastructure to be able to deal with our special hugetlb PMD table sharing implementation. We'll consolidate the handling for (full) unsharing of PMD tables in tlb_unshare_pmd_ptdesc() and tlb_flush_unshared_tables(), and track in "struct mmu_gather" whether we had (full) unsharing of PMD tables. Because locking is very special (concurrent unsharing+reuse must be prevented), we disallow deferring flushing to tlb_finish_mmu() and instead require an explicit earlier call to tlb_flush_unshared_tables(). From hugetlb code, we call huge_pmd_unshare_flush() where we make sure that the expected lock protecting us from concurrent unsharing+reuse is still held. Check with a VM_WARN_ON_ONCE() in tlb_finish_mmu() that tlb_flush_unshared_tables() was properly called earlier. Document it all properly. Notes about tlb_remove_table_sync_one() interaction with unsharing: There are two fairly tricky things: (1) tlb_remove_table_sync_one() is a NOP on architectures without CONFIG_MMU_GATHER_RCU_TABLE_FREE. Here, the assumption is that the previous TLB flush would send an IPI to all relevant CPUs. Careful: some architectures like x86 only send IPIs to all relevant CPUs when tlb->freed_tables is set. The relevant architectures should be selecting MMU_GATHER_RCU_TABLE_FREE, but x86 might not do that in stable kernels and it might have been problematic before this patch. Also, the arch flushing behavior (independent of IPIs) is different when tlb->freed_tables is set. Do we have to enlighten them to also take care of tlb->unshared_tables? So far we didn't care, so hopefully we are fine. Of course, we could be setting tlb->freed_tables as well, but that might then unnecessarily flush too much, because the semantics of tlb->freed_tables are a bit fuzzy. This patch changes nothing in this regard. (2) tlb_remove_table_sync_one() is not a NOP on architectures with CONFIG_MMU_GATHER_RCU_TABLE_FREE that actually don't need a sync. Take x86 as an example: in the common case (!pv, !X86_FEATURE_INVLPGB) we still issue IPIs during TLB flushes and don't actually need the second tlb_remove_table_sync_one(). This optimized can be implemented on top of this, by checking e.g., in tlb_remove_table_sync_one() whether we really need IPIs. But as described in (1), it really must honor tlb->freed_tables then to send IPIs to all relevant CPUs. Further note that the ptdesc_pmd_pts_dec() in huge_pmd_share() is not a concern, as we are holding the i_mmap_lock the whole time, preventing concurrent unsharing. That ptdesc_pmd_pts_dec() usage will be removed separately as a cleanup later. There are plenty more cleanups to be had, but they have to wait until this is fixed. Link: https://lkml.kernel.org/r/20251212071019.471146-5-david@kernel.org Fixes: 1013af4f585f ("mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race") Signed-off-by: David Hildenbrand (Red Hat) <david(a)kernel.org> Reported-by: Uschakow, Stanislav" <suschako(a)amazon.de> Closes: https://lore.kernel.org/all/4d3878531c76479d9f8ca9789dc6485d@amazon.de/ Tested-by: Laurence Oberman <loberman(a)redhat.com> Cc: "Aneesh Kumar K.V" <aneesh.kumar(a)kernel.org> Cc: Arnd Bergmann <arnd(a)arndb.de> Cc: Harry Yoo <harry.yoo(a)oracle.com> Cc: Jann Horn <jannh(a)google.com> Cc: Lance Yang <lance.yang(a)linux.dev> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Liu Shixin <liushixin2(a)huawei.com> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Muchun Song <muchun.song(a)linux.dev> Cc: Nadav Amit <nadav.amit(a)gmail.com> Cc: Nicholas Piggin <npiggin(a)gmail.com> Cc: Oscar Salvador <osalvador(a)suse.de> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Prakash Sangappa <prakash.sangappa(a)oracle.com> Cc: Rik van Riel <riel(a)surriel.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Will Deacon <will(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/asm-generic/tlb.h | 74 +++++++++++++++++++++- include/linux/hugetlb.h | 19 +++-- mm/hugetlb.c | 121 ++++++++++++++++++++---------------- mm/mmu_gather.c | 7 ++ mm/mprotect.c | 2 mm/rmap.c | 25 +++++-- 6 files changed, 179 insertions(+), 69 deletions(-) --- a/include/asm-generic/tlb.h~mm-hugetlb-fix-excessive-ipi-broadcasts-when-unsharing-pmd-tables-using-mmu_gather +++ a/include/asm-generic/tlb.h @@ -364,6 +364,20 @@ struct mmu_gather { unsigned int vma_huge : 1; unsigned int vma_pfn : 1; + /* + * Did we unshare (unmap) any shared page tables? For now only + * used for hugetlb PMD table sharing. + */ + unsigned int unshared_tables : 1; + + /* + * Did we unshare any page tables such that they are now exclusive + * and could get reused+modified by the new owner? When setting this + * flag, "unshared_tables" will be set as well. For now only used + * for hugetlb PMD table sharing. + */ + unsigned int fully_unshared_tables : 1; + unsigned int batch_count; #ifndef CONFIG_MMU_GATHER_NO_GATHER @@ -400,6 +414,7 @@ static inline void __tlb_reset_range(str tlb->cleared_pmds = 0; tlb->cleared_puds = 0; tlb->cleared_p4ds = 0; + tlb->unshared_tables = 0; /* * Do not reset mmu_gather::vma_* fields here, we do not * call into tlb_start_vma() again to set them if there is an @@ -484,7 +499,7 @@ static inline void tlb_flush_mmu_tlbonly * these bits. */ if (!(tlb->freed_tables || tlb->cleared_ptes || tlb->cleared_pmds || - tlb->cleared_puds || tlb->cleared_p4ds)) + tlb->cleared_puds || tlb->cleared_p4ds || tlb->unshared_tables)) return; tlb_flush(tlb); @@ -773,6 +788,63 @@ static inline bool huge_pmd_needs_flush( } #endif +#ifdef CONFIG_HUGETLB_PMD_PAGE_TABLE_SHARING +static inline void tlb_unshare_pmd_ptdesc(struct mmu_gather *tlb, struct ptdesc *pt, + unsigned long addr) +{ + /* + * The caller must make sure that concurrent unsharing + exclusive + * reuse is impossible until tlb_flush_unshared_tables() was called. + */ + VM_WARN_ON_ONCE(!ptdesc_pmd_is_shared(pt)); + ptdesc_pmd_pts_dec(pt); + + /* Clearing a PUD pointing at a PMD table with PMD leaves. */ + tlb_flush_pmd_range(tlb, addr & PUD_MASK, PUD_SIZE); + + /* + * If the page table is now exclusively owned, we fully unshared + * a page table. + */ + if (!ptdesc_pmd_is_shared(pt)) + tlb->fully_unshared_tables = true; + tlb->unshared_tables = true; +} + +static inline void tlb_flush_unshared_tables(struct mmu_gather *tlb) +{ + /* + * As soon as the caller drops locks to allow for reuse of + * previously-shared tables, these tables could get modified and + * even reused outside of hugetlb context, so we have to make sure that + * any page table walkers (incl. TLB, GUP-fast) are aware of that + * change. + * + * Even if we are not fully unsharing a PMD table, we must + * flush the TLB for the unsharer now. + */ + if (tlb->unshared_tables) + tlb_flush_mmu_tlbonly(tlb); + + /* + * Similarly, we must make sure that concurrent GUP-fast will not + * walk previously-shared page tables that are getting modified+reused + * elsewhere. So broadcast an IPI to wait for any concurrent GUP-fast. + * + * We only perform this when we are the last sharer of a page table, + * as the IPI will reach all CPUs: any GUP-fast. + * + * Note that on configs where tlb_remove_table_sync_one() is a NOP, + * the expectation is that the tlb_flush_mmu_tlbonly() would have issued + * required IPIs already for us. + */ + if (tlb->fully_unshared_tables) { + tlb_remove_table_sync_one(); + tlb->fully_unshared_tables = false; + } +} +#endif /* CONFIG_HUGETLB_PMD_PAGE_TABLE_SHARING */ + #endif /* CONFIG_MMU */ #endif /* _ASM_GENERIC__TLB_H */ --- a/include/linux/hugetlb.h~mm-hugetlb-fix-excessive-ipi-broadcasts-when-unsharing-pmd-tables-using-mmu_gather +++ a/include/linux/hugetlb.h @@ -240,8 +240,9 @@ pte_t *huge_pte_alloc(struct mm_struct * pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr, unsigned long sz); unsigned long hugetlb_mask_last_page(struct hstate *h); -int huge_pmd_unshare(struct mm_struct *mm, struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep); +int huge_pmd_unshare(struct mmu_gather *tlb, struct vm_area_struct *vma, + unsigned long addr, pte_t *ptep); +void huge_pmd_unshare_flush(struct mmu_gather *tlb, struct vm_area_struct *vma); void adjust_range_if_pmd_sharing_possible(struct vm_area_struct *vma, unsigned long *start, unsigned long *end); @@ -271,7 +272,7 @@ void hugetlb_vma_unlock_write(struct vm_ int hugetlb_vma_trylock_write(struct vm_area_struct *vma); void hugetlb_vma_assert_locked(struct vm_area_struct *vma); void hugetlb_vma_lock_release(struct kref *kref); -long hugetlb_change_protection(struct vm_area_struct *vma, +long hugetlb_change_protection(struct mmu_gather *tlb, struct vm_area_struct *vma, unsigned long address, unsigned long end, pgprot_t newprot, unsigned long cp_flags); void hugetlb_unshare_all_pmds(struct vm_area_struct *vma); @@ -300,13 +301,17 @@ static inline struct address_space *huge return NULL; } -static inline int huge_pmd_unshare(struct mm_struct *mm, - struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep) +static inline int huge_pmd_unshare(struct mmu_gather *tlb, + struct vm_area_struct *vma, unsigned long addr, pte_t *ptep) { return 0; } +static inline void huge_pmd_unshare_flush(struct mmu_gather *tlb, + struct vm_area_struct *vma) +{ +} + static inline void adjust_range_if_pmd_sharing_possible( struct vm_area_struct *vma, unsigned long *start, unsigned long *end) @@ -432,7 +437,7 @@ static inline void move_hugetlb_state(st { } -static inline long hugetlb_change_protection( +static inline long hugetlb_change_protection(struct mmu_gather *tlb, struct vm_area_struct *vma, unsigned long address, unsigned long end, pgprot_t newprot, unsigned long cp_flags) --- a/mm/hugetlb.c~mm-hugetlb-fix-excessive-ipi-broadcasts-when-unsharing-pmd-tables-using-mmu_gather +++ a/mm/hugetlb.c @@ -5096,8 +5096,9 @@ int move_hugetlb_page_tables(struct vm_a unsigned long last_addr_mask; pte_t *src_pte, *dst_pte; struct mmu_notifier_range range; - bool shared_pmd = false; + struct mmu_gather tlb; + tlb_gather_mmu(&tlb, vma->vm_mm); mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, mm, old_addr, old_end); adjust_range_if_pmd_sharing_possible(vma, &range.start, &range.end); @@ -5122,12 +5123,12 @@ int move_hugetlb_page_tables(struct vm_a if (huge_pte_none(huge_ptep_get(mm, old_addr, src_pte))) continue; - if (huge_pmd_unshare(mm, vma, old_addr, src_pte)) { - shared_pmd = true; + if (huge_pmd_unshare(&tlb, vma, old_addr, src_pte)) { old_addr |= last_addr_mask; new_addr |= last_addr_mask; continue; } + tlb_remove_huge_tlb_entry(h, &tlb, src_pte, old_addr); dst_pte = huge_pte_alloc(mm, new_vma, new_addr, sz); if (!dst_pte) @@ -5136,13 +5137,13 @@ int move_hugetlb_page_tables(struct vm_a move_huge_pte(vma, old_addr, new_addr, src_pte, dst_pte, sz); } - if (shared_pmd) - flush_hugetlb_tlb_range(vma, range.start, range.end); - else - flush_hugetlb_tlb_range(vma, old_end - len, old_end); + tlb_flush_mmu_tlbonly(&tlb); + huge_pmd_unshare_flush(&tlb, vma); + mmu_notifier_invalidate_range_end(&range); i_mmap_unlock_write(mapping); hugetlb_vma_unlock_write(vma); + tlb_finish_mmu(&tlb); return len + old_addr - old_end; } @@ -5161,7 +5162,6 @@ void __unmap_hugepage_range(struct mmu_g unsigned long sz = huge_page_size(h); bool adjust_reservation; unsigned long last_addr_mask; - bool force_flush = false; WARN_ON(!is_vm_hugetlb_page(vma)); BUG_ON(start & ~huge_page_mask(h)); @@ -5184,10 +5184,8 @@ void __unmap_hugepage_range(struct mmu_g } ptl = huge_pte_lock(h, mm, ptep); - if (huge_pmd_unshare(mm, vma, address, ptep)) { + if (huge_pmd_unshare(tlb, vma, address, ptep)) { spin_unlock(ptl); - tlb_flush_pmd_range(tlb, address & PUD_MASK, PUD_SIZE); - force_flush = true; address |= last_addr_mask; continue; } @@ -5303,14 +5301,7 @@ void __unmap_hugepage_range(struct mmu_g } tlb_end_vma(tlb, vma); - /* - * There is nothing protecting a previously-shared page table that we - * unshared through huge_pmd_unshare() from getting freed after we - * release i_mmap_rwsem, so flush the TLB now. If huge_pmd_unshare() - * succeeded, flush the range corresponding to the pud. - */ - if (force_flush) - tlb_flush_mmu_tlbonly(tlb); + huge_pmd_unshare_flush(tlb, vma); } void __hugetlb_zap_begin(struct vm_area_struct *vma, @@ -6399,7 +6390,7 @@ out_release_nounlock: } #endif /* CONFIG_USERFAULTFD */ -long hugetlb_change_protection(struct vm_area_struct *vma, +long hugetlb_change_protection(struct mmu_gather *tlb, struct vm_area_struct *vma, unsigned long address, unsigned long end, pgprot_t newprot, unsigned long cp_flags) { @@ -6409,7 +6400,6 @@ long hugetlb_change_protection(struct vm pte_t pte; struct hstate *h = hstate_vma(vma); long pages = 0, psize = huge_page_size(h); - bool shared_pmd = false; struct mmu_notifier_range range; unsigned long last_addr_mask; bool uffd_wp = cp_flags & MM_CP_UFFD_WP; @@ -6452,7 +6442,7 @@ long hugetlb_change_protection(struct vm } } ptl = huge_pte_lock(h, mm, ptep); - if (huge_pmd_unshare(mm, vma, address, ptep)) { + if (huge_pmd_unshare(tlb, vma, address, ptep)) { /* * When uffd-wp is enabled on the vma, unshare * shouldn't happen at all. Warn about it if it @@ -6461,7 +6451,6 @@ long hugetlb_change_protection(struct vm WARN_ON_ONCE(uffd_wp || uffd_wp_resolve); pages++; spin_unlock(ptl); - shared_pmd = true; address |= last_addr_mask; continue; } @@ -6522,22 +6511,16 @@ long hugetlb_change_protection(struct vm pte = huge_pte_clear_uffd_wp(pte); huge_ptep_modify_prot_commit(vma, address, ptep, old_pte, pte); pages++; + tlb_remove_huge_tlb_entry(h, tlb, ptep, address); } next: spin_unlock(ptl); cond_resched(); } - /* - * There is nothing protecting a previously-shared page table that we - * unshared through huge_pmd_unshare() from getting freed after we - * release i_mmap_rwsem, so flush the TLB now. If huge_pmd_unshare() - * succeeded, flush the range corresponding to the pud. - */ - if (shared_pmd) - flush_hugetlb_tlb_range(vma, range.start, range.end); - else - flush_hugetlb_tlb_range(vma, start, end); + + tlb_flush_mmu_tlbonly(tlb); + huge_pmd_unshare_flush(tlb, vma); /* * No need to call mmu_notifier_arch_invalidate_secondary_tlbs() we are * downgrading page table protection not changing it to point to a new @@ -6904,18 +6887,27 @@ out: return pte; } -/* - * unmap huge page backed by shared pte. +/** + * huge_pmd_unshare - Unmap a pmd table if it is shared by multiple users + * @tlb: the current mmu_gather. + * @vma: the vma covering the pmd table. + * @addr: the address we are trying to unshare. + * @ptep: pointer into the (pmd) page table. + * + * Called with the page table lock held, the i_mmap_rwsem held in write mode + * and the hugetlb vma lock held in write mode. * - * Called with page table lock held. + * Note: The caller must call huge_pmd_unshare_flush() before dropping the + * i_mmap_rwsem. * - * returns: 1 successfully unmapped a shared pte page - * 0 the underlying pte page is not shared, or it is the last user + * Returns: 1 if it was a shared PMD table and it got unmapped, or 0 if it + * was not a shared PMD table. */ -int huge_pmd_unshare(struct mm_struct *mm, struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep) +int huge_pmd_unshare(struct mmu_gather *tlb, struct vm_area_struct *vma, + unsigned long addr, pte_t *ptep) { unsigned long sz = huge_page_size(hstate_vma(vma)); + struct mm_struct *mm = vma->vm_mm; pgd_t *pgd = pgd_offset(mm, addr); p4d_t *p4d = p4d_offset(pgd, addr); pud_t *pud = pud_offset(p4d, addr); @@ -6927,18 +6919,36 @@ int huge_pmd_unshare(struct mm_struct *m i_mmap_assert_write_locked(vma->vm_file->f_mapping); hugetlb_vma_assert_locked(vma); pud_clear(pud); - /* - * Once our caller drops the rmap lock, some other process might be - * using this page table as a normal, non-hugetlb page table. - * Wait for pending gup_fast() in other threads to finish before letting - * that happen. - */ - tlb_remove_table_sync_one(); - ptdesc_pmd_pts_dec(virt_to_ptdesc(ptep)); + + tlb_unshare_pmd_ptdesc(tlb, virt_to_ptdesc(ptep), addr); + mm_dec_nr_pmds(mm); return 1; } +/* + * huge_pmd_unshare_flush - Complete a sequence of huge_pmd_unshare() calls + * @tlb: the current mmu_gather. + * @vma: the vma covering the pmd table. + * + * Perform necessary TLB flushes or IPI broadcasts to synchronize PMD table + * unsharing with concurrent page table walkers. + * + * This function must be called after a sequence of huge_pmd_unshare() + * calls while still holding the i_mmap_rwsem. + */ +void huge_pmd_unshare_flush(struct mmu_gather *tlb, struct vm_area_struct *vma) +{ + /* + * We must synchronize page table unsharing such that nobody will + * try reusing a previously-shared page table while it might still + * be in use by previous sharers (TLB, GUP_fast). + */ + i_mmap_assert_write_locked(vma->vm_file->f_mapping); + + tlb_flush_unshared_tables(tlb); +} + #else /* !CONFIG_HUGETLB_PMD_PAGE_TABLE_SHARING */ pte_t *huge_pmd_share(struct mm_struct *mm, struct vm_area_struct *vma, @@ -6947,12 +6957,16 @@ pte_t *huge_pmd_share(struct mm_struct * return NULL; } -int huge_pmd_unshare(struct mm_struct *mm, struct vm_area_struct *vma, - unsigned long addr, pte_t *ptep) +int huge_pmd_unshare(struct mmu_gather *tlb, struct vm_area_struct *vma, + unsigned long addr, pte_t *ptep) { return 0; } +void huge_pmd_unshare_flush(struct mmu_gather *tlb, struct vm_area_struct *vma) +{ +} + void adjust_range_if_pmd_sharing_possible(struct vm_area_struct *vma, unsigned long *start, unsigned long *end) { @@ -7219,6 +7233,7 @@ static void hugetlb_unshare_pmds(struct unsigned long sz = huge_page_size(h); struct mm_struct *mm = vma->vm_mm; struct mmu_notifier_range range; + struct mmu_gather tlb; unsigned long address; spinlock_t *ptl; pte_t *ptep; @@ -7229,6 +7244,7 @@ static void hugetlb_unshare_pmds(struct if (start >= end) return; + tlb_gather_mmu(&tlb, mm); flush_cache_range(vma, start, end); /* * No need to call adjust_range_if_pmd_sharing_possible(), because @@ -7248,10 +7264,10 @@ static void hugetlb_unshare_pmds(struct if (!ptep) continue; ptl = huge_pte_lock(h, mm, ptep); - huge_pmd_unshare(mm, vma, address, ptep); + huge_pmd_unshare(&tlb, vma, address, ptep); spin_unlock(ptl); } - flush_hugetlb_tlb_range(vma, start, end); + huge_pmd_unshare_flush(&tlb, vma); if (take_locks) { i_mmap_unlock_write(vma->vm_file->f_mapping); hugetlb_vma_unlock_write(vma); @@ -7261,6 +7277,7 @@ static void hugetlb_unshare_pmds(struct * Documentation/mm/mmu_notifier.rst. */ mmu_notifier_invalidate_range_end(&range); + tlb_finish_mmu(&tlb); } /* --- a/mm/mmu_gather.c~mm-hugetlb-fix-excessive-ipi-broadcasts-when-unsharing-pmd-tables-using-mmu_gather +++ a/mm/mmu_gather.c @@ -426,6 +426,7 @@ static void __tlb_gather_mmu(struct mmu_ #endif tlb->vma_pfn = 0; + tlb->fully_unshared_tables = 0; __tlb_reset_range(tlb); inc_tlb_flush_pending(tlb->mm); } @@ -469,6 +470,12 @@ void tlb_gather_mmu_fullmm(struct mmu_ga void tlb_finish_mmu(struct mmu_gather *tlb) { /* + * We expect an earlier huge_pmd_unshare_flush() call to sort this out, + * due to complicated locking requirements with page table unsharing. + */ + VM_WARN_ON_ONCE(tlb->fully_unshared_tables); + + /* * If there are parallel threads are doing PTE changes on same range * under non-exclusive lock (e.g., mmap_lock read-side) but defer TLB * flush by batching, one thread may end up seeing inconsistent PTEs --- a/mm/mprotect.c~mm-hugetlb-fix-excessive-ipi-broadcasts-when-unsharing-pmd-tables-using-mmu_gather +++ a/mm/mprotect.c @@ -652,7 +652,7 @@ long change_protection(struct mmu_gather #endif if (is_vm_hugetlb_page(vma)) - pages = hugetlb_change_protection(vma, start, end, newprot, + pages = hugetlb_change_protection(tlb, vma, start, end, newprot, cp_flags); else pages = change_protection_range(tlb, vma, start, end, newprot, --- a/mm/rmap.c~mm-hugetlb-fix-excessive-ipi-broadcasts-when-unsharing-pmd-tables-using-mmu_gather +++ a/mm/rmap.c @@ -76,7 +76,7 @@ #include <linux/mm_inline.h> #include <linux/oom.h> -#include <asm/tlbflush.h> +#include <asm/tlb.h> #define CREATE_TRACE_POINTS #include <trace/events/migrate.h> @@ -2008,13 +2008,17 @@ static bool try_to_unmap_one(struct foli * if unsuccessful. */ if (!anon) { + struct mmu_gather tlb; + VM_BUG_ON(!(flags & TTU_RMAP_LOCKED)); if (!hugetlb_vma_trylock_write(vma)) goto walk_abort; - if (huge_pmd_unshare(mm, vma, address, pvmw.pte)) { + + tlb_gather_mmu(&tlb, mm); + if (huge_pmd_unshare(&tlb, vma, address, pvmw.pte)) { hugetlb_vma_unlock_write(vma); - flush_tlb_range(vma, - range.start, range.end); + huge_pmd_unshare_flush(&tlb, vma); + tlb_finish_mmu(&tlb); /* * The PMD table was unmapped, * consequently unmapping the folio. @@ -2022,6 +2026,7 @@ static bool try_to_unmap_one(struct foli goto walk_done; } hugetlb_vma_unlock_write(vma); + tlb_finish_mmu(&tlb); } pteval = huge_ptep_clear_flush(vma, address, pvmw.pte); if (pte_dirty(pteval)) @@ -2398,17 +2403,20 @@ static bool try_to_migrate_one(struct fo * fail if unsuccessful. */ if (!anon) { + struct mmu_gather tlb; + VM_BUG_ON(!(flags & TTU_RMAP_LOCKED)); if (!hugetlb_vma_trylock_write(vma)) { page_vma_mapped_walk_done(&pvmw); ret = false; break; } - if (huge_pmd_unshare(mm, vma, address, pvmw.pte)) { - hugetlb_vma_unlock_write(vma); - flush_tlb_range(vma, - range.start, range.end); + tlb_gather_mmu(&tlb, mm); + if (huge_pmd_unshare(&tlb, vma, address, pvmw.pte)) { + hugetlb_vma_unlock_write(vma); + huge_pmd_unshare_flush(&tlb, vma); + tlb_finish_mmu(&tlb); /* * The PMD table was unmapped, * consequently unmapping the folio. @@ -2417,6 +2425,7 @@ static bool try_to_migrate_one(struct fo break; } hugetlb_vma_unlock_write(vma); + tlb_finish_mmu(&tlb); } /* Nuke the hugetlb page table entry */ pteval = huge_ptep_clear_flush(vma, address, pvmw.pte); _ Patches currently in -mm which might be from david(a)kernel.org are mm-hugetlb-fix-hugetlb_pmd_shared.patch mm-hugetlb-fix-two-comments-related-to-huge_pmd_unshare.patch mm-rmap-fix-two-comments-related-to-huge_pmd_unshare.patch mm-hugetlb-fix-excessive-ipi-broadcasts-when-unsharing-pmd-tables-using-mmu_gather.patch

2 days, 19 hours

1
0
0 0

+ mm-hugetlb-fix-hugetlb_pmd_shared.patch added to mm-new branch

by Andrew Morton

The patch titled Subject: mm/hugetlb: fix hugetlb_pmd_shared() has been added to the -mm mm-new branch. Its filename is mm-hugetlb-fix-hugetlb_pmd_shared.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-new branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Note, mm-new is a provisional staging ground for work-in-progress patches, and acceptance into mm-new is a notification for others take notice and to finish up reviews. Please do not hesitate to respond to review feedback and post updated versions to replace or incrementally fixup patches in mm-new. Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: "David Hildenbrand (Red Hat)" <david(a)kernel.org> Subject: mm/hugetlb: fix hugetlb_pmd_shared() Date: Fri, 12 Dec 2025 08:10:16 +0100 Patch series "mm/hugetlb: fixes for PMD table sharing (incl. using mmu_gather)", v2. One functional fix, one performance regression fix, and two related comment fixes. The goal of this patch set is to be backported to stable trees "fairly" easily. At least patch #1 and #4. Patch #1 fixes hugetlb_pmd_shared() not detecting any sharing Patch #2 + #3 are simple comment fixes that patch #4 interacts with. Patch #4 is a fix for the reported performance regression due to excessive IPI broadcasts during fork()+exit(). The last patch is all about TLB flushes, IPIs and mmu_gather. Read: complicated This patch (of 4): We switched from (wrongly) using the page count to an independent shared count. Now, shared page tables have a refcount of 1 (excluding speculative references) and instead use ptdesc->pt_share_count to identify sharing. We didn't convert hugetlb_pmd_shared(), so right now, we would never detect a shared PMD table as such, because sharing/unsharing no longer touches the refcount of a PMD table. Page migration, like mbind() or migrate_pages() would allow for migrating folios mapped into such shared PMD tables, even though the folios are not exclusive. In smaps we would account them as "private" although they are "shared", and we would be wrongly setting the PM_MMAP_EXCLUSIVE in the pagemap interface. Fix it by properly using ptdesc_pmd_is_shared() in hugetlb_pmd_shared(). Link: https://lkml.kernel.org/r/20251212071019.471146-1-david@kernel.org Link: https://lkml.kernel.org/r/20251212071019.471146-2-david@kernel.org Fixes: 59d9094df3d7 ("mm: hugetlb: independent PMD page table shared count") Signed-off-by: David Hildenbrand (Red Hat) <david(a)kernel.org> Reviewed-by: Rik van Riel <riel(a)surriel.com> Reviewed-by: Lance Yang <lance.yang(a)linux.dev> Tested-by: Lance Yang <lance.yang(a)linux.dev> Reviewed-by: Harry Yoo <harry.yoo(a)oracle.com> Tested-by: Laurence Oberman <loberman(a)redhat.com> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Acked-by: Oscar Salvador <osalvador(a)suse.de> Cc: Liu Shixin <liushixin2(a)huawei.com> Cc: "Aneesh Kumar K.V" <aneesh.kumar(a)kernel.org> Cc: Arnd Bergmann <arnd(a)arndb.de> Cc: Jann Horn <jannh(a)google.com> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Muchun Song <muchun.song(a)linux.dev> Cc: Nadav Amit <nadav.amit(a)gmail.com> Cc: Nicholas Piggin <npiggin(a)gmail.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Prakash Sangappa <prakash.sangappa(a)oracle.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Will Deacon <will(a)kernel.org> Cc: Uschakow, Stanislav" <suschako(a)amazon.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/hugetlb.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/include/linux/hugetlb.h~mm-hugetlb-fix-hugetlb_pmd_shared +++ a/include/linux/hugetlb.h @@ -1326,7 +1326,7 @@ static inline __init void hugetlb_cma_re #ifdef CONFIG_HUGETLB_PMD_PAGE_TABLE_SHARING static inline bool hugetlb_pmd_shared(pte_t *pte) { - return page_count(virt_to_page(pte)) > 1; + return ptdesc_pmd_is_shared(virt_to_ptdesc(pte)); } #else static inline bool hugetlb_pmd_shared(pte_t *pte) _ Patches currently in -mm which might be from david(a)kernel.org are mm-hugetlb-fix-hugetlb_pmd_shared.patch mm-hugetlb-fix-two-comments-related-to-huge_pmd_unshare.patch mm-rmap-fix-two-comments-related-to-huge_pmd_unshare.patch mm-hugetlb-fix-excessive-ipi-broadcasts-when-unsharing-pmd-tables-using-mmu_gather.patch

2 days, 19 hours

1
0
0 0

[PATCH 6.12.y 0/2] net: dst: Backport fix CVE-2025-40075

by Gyokhan Kochmarla

From: Gyokhan Kochmarla <gyokhan(a)amazon.com> This patch series backports two commits from mainline to fix CVE-2025-40075, a data race vulnerability in dst->dev access. The first patch introduces dst->dev_rcu and dst_dev_net_rcu() helper to provide proper RCU protection with lockdep support. The second patch uses the new helper in tcp_metrics to eliminate unsafe dst_dev() calls. These are clean cherry-picks from mainline commits: - caedcc5b6df1 ("net: dst: introduce dst->dev_rcu") - 50c127a69cd6 ("tcp_metrics: use dst_dev_net_rcu()") Eric Dumazet (2): net: dst: introduce dst->dev_rcu tcp_metrics: use dst_dev_net_rcu() include/net/dst.h | 16 +++++++++++----- net/core/dst.c | 2 +- net/ipv4/route.c | 4 ++-- net/ipv4/tcp_metrics.c | 6 +++--- 4 files changed, 17 insertions(+), 11 deletions(-) -- 2.47.3 Amazon Web Services Development Center Germany GmbH Tamara-Danz-Str. 13 10243 Berlin Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597

2 days, 19 hours

1
2
0 0

[PATCH stable 6.12.y 0/8] idpf: fix Tx timeout issues

by Tony Nguyen

This targets the 6.12-y branch and fixes stability issues in the flow scheduling Tx send/clean path that results in a Tx timeouts and can occasionally crash in certain environments. The majority of the patches come from the series "idpf: replace Tx flow scheduling buffer ring with buffer pool" [1] except for the first two patches which are included as they address additional situations that can result in Tx timeouts. There are two minor differences from the original patch (3&8), also noted in the respective patches, for size assertions due to differences in struct sizes between the original version and what is present here. Snippet from the cover letter of the referenced series: The existing guardrails in the Tx path were not sufficient to prevent the driver from reusing completion tags that were still in flight (held by the HW). This collision would cause the driver to erroneously clean the wrong packet thus leaving the descriptor ring in a bad state. The main point of this fix is to replace the flow scheduling buffer ring with a large pool/array of buffers. The completion tag then simply is the index into this array. The driver tracks the free tags and pulls the next free one from a refillq. The cleaning routines simply use the completion tag from the completion descriptor to index into the array to quickly find the buffers to clean. All of the code to support this is added first to ensure traffic still passes with each patch. The final patch then removes all of the obsolete stashing code. [1] https://lore.kernel.org/netdev/20250821180100.401955-1-anthony.l.nguyen@int… --- We do realize this request is larger than stable rules, however, one of our customers asked if this could be backported to this LTS kernel. We're hoping this can be accepted since these changes are isolated to this driver alone and have been tested by the customer and Intel validation. Joshua Hay (8): idpf: add support for SW triggered interrupts idpf: trigger SW interrupt when exiting wb_on_itr mode idpf: add support for Tx refillqs in flow scheduling mode idpf: improve when to set RE bit logic idpf: simplify and fix splitq Tx packet rollback error path idpf: replace flow scheduling buffer ring with buffer pool idpf: stop Tx if there are insufficient buffer resources idpf: remove obsolete stashing code drivers/net/ethernet/intel/idpf/idpf_dev.c | 3 + .../ethernet/intel/idpf/idpf_singleq_txrx.c | 61 +- drivers/net/ethernet/intel/idpf/idpf_txrx.c | 750 +++++++----------- drivers/net/ethernet/intel/idpf/idpf_txrx.h | 95 +-- drivers/net/ethernet/intel/idpf/idpf_vf_dev.c | 3 + 5 files changed, 390 insertions(+), 522 deletions(-) -- 2.47.1

2 days, 20 hours

1
8
0 0

[PATCH] KVM: SVM: Fix redundant updates of LBR MSR intercepts

by Yosry Ahmed

svm_update_lbrv() always updates LBR MSRs intercepts, even when they are already set correctly. This results in force_msr_bitmap_recalc always being set to true on every nested transition, essentially undoing the hyperv optimization in nested_svm_merge_msrpm(). Fix it by keeping track of whether LBR MSRs are intercepted or not and only doing the update if needed, similar to x2avic_msrs_intercepted. Avoid using svm_test_msr_bitmap_*() to check the status of the intercepts, as an arbitrary MSR will need to be chosen as a representative of all LBR MSRs, and this could theoretically break if some of the MSRs intercepts are handled differently from the rest. Also, using svm_test_msr_bitmap_*() makes backports difficult as it was only recently introduced with no direct alternatives in older kernels. Fixes: fbe5e5f030c2 ("KVM: nSVM: Always recalculate LBR MSR intercepts in svm_update_lbrv()") Cc: stable(a)vger.kernel.org Signed-off-by: Yosry Ahmed <yosry.ahmed(a)linux.dev> --- arch/x86/kvm/svm/svm.c | 9 ++++++++- arch/x86/kvm/svm/svm.h | 1 + 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 10c21e4c5406f..9d29b2e7e855d 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -705,7 +705,11 @@ void *svm_alloc_permissions_map(unsigned long size, gfp_t gfp_mask) static void svm_recalc_lbr_msr_intercepts(struct kvm_vcpu *vcpu) { - bool intercept = !(to_svm(vcpu)->vmcb->control.virt_ext & LBR_CTL_ENABLE_MASK); + struct vcpu_svm *svm = to_svm(vcpu); + bool intercept = !(svm->vmcb->control.virt_ext & LBR_CTL_ENABLE_MASK); + + if (intercept == svm->lbr_msrs_intercepted) + return; svm_set_intercept_for_msr(vcpu, MSR_IA32_LASTBRANCHFROMIP, MSR_TYPE_RW, intercept); svm_set_intercept_for_msr(vcpu, MSR_IA32_LASTBRANCHTOIP, MSR_TYPE_RW, intercept); @@ -714,6 +718,8 @@ static void svm_recalc_lbr_msr_intercepts(struct kvm_vcpu *vcpu) if (sev_es_guest(vcpu->kvm)) svm_set_intercept_for_msr(vcpu, MSR_IA32_DEBUGCTLMSR, MSR_TYPE_RW, intercept); + + svm->lbr_msrs_intercepted = intercept; } void svm_vcpu_free_msrpm(void *msrpm) @@ -1221,6 +1227,7 @@ static int svm_vcpu_create(struct kvm_vcpu *vcpu) } svm->x2avic_msrs_intercepted = true; + svm->lbr_msrs_intercepted = true; svm->vmcb01.ptr = page_address(vmcb01_page); svm->vmcb01.pa = __sme_set(page_to_pfn(vmcb01_page) << PAGE_SHIFT); diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h index c856d8e0f95e7..dd78e64023450 100644 --- a/arch/x86/kvm/svm/svm.h +++ b/arch/x86/kvm/svm/svm.h @@ -336,6 +336,7 @@ struct vcpu_svm { bool guest_state_loaded; bool x2avic_msrs_intercepted; + bool lbr_msrs_intercepted; /* Guest GIF value, used when vGIF is not enabled */ bool guest_gif; base-commit: 8a4821412cf2c1429fffa07c012dd150f2edf78c -- 2.51.2.1041.gc1ab5b90ca-goog

2 days, 21 hours

2
21
0 0

[PATCH RESEND] ARM: tegra: fix device leak on tegra ahb lookup

by Ma Ke

tegra_ahb_enable_smmu() utilizes driver_find_device_by_of_node() which internally calls driver_find_device() to locate the matching device. driver_find_device() increments the ref count of the found device by calling get_device(), but tegra_ahb_enable_smmu() fails to call put_device() to decrement the reference count before returning. This results in a reference count leak of the device, which may prevent the device from being properly released and cause a memory leak. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 89c788bab1f0 ("ARM: tegra: Add SMMU enabler in AHB") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/amba/tegra-ahb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/amba/tegra-ahb.c b/drivers/amba/tegra-ahb.c index f23c3ed01810..3ed5cef34806 100644 --- a/drivers/amba/tegra-ahb.c +++ b/drivers/amba/tegra-ahb.c @@ -148,6 +148,7 @@ int tegra_ahb_enable_smmu(struct device_node *dn) val = gizmo_readl(ahb, AHB_ARBITRATION_XBAR_CTRL); val |= AHB_ARBITRATION_XBAR_CTRL_SMMU_INIT_DONE; gizmo_writel(ahb, val, AHB_ARBITRATION_XBAR_CTRL); + put_device(dev); return 0; } EXPORT_SYMBOL(tegra_ahb_enable_smmu); -- 2.17.1

2 days, 21 hours

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror