* Re: [PATCH 2/3] rv/rtapp/sleep: Update nanosleep rule
From: Nam Cao @ 2026-05-25 11:38 UTC (permalink / raw)
To: Gabriele Monaco; +Cc: Steven Rostedt, linux-kernel, linux-trace-kernel
In-Reply-To: <376235e7f56f4d7fe21c68b39e12bacb9d3e3d19.camel@redhat.com>
Gabriele Monaco <gmonaco@redhat.com> writes:
> Was it intentional to remove this too? It seems to me now it's cleared
> only for existing user threads.
>
> Aren't we sure new kthreads aren't stopping?
...
> You missed removing a couple of these in the next branch, the monitor
> doesn't build.
These are just mistakes from me, sorry about that. Not sure what I was
smoking while sending these patches..
Nam
^ permalink raw reply
* Re: [PATCH 3/3] rv/rtapp: Add wakeup monitor
From: Nam Cao @ 2026-05-25 11:45 UTC (permalink / raw)
To: Gabriele Monaco; +Cc: Steven Rostedt, linux-kernel, linux-trace-kernel
In-Reply-To: <fb0c1a36b4e773c65591bde2ef31c48711d30163.camel@redhat.com>
Gabriele Monaco <gmonaco@redhat.com> writes:
> Looks neat, so the idea here is that we are looking at the same events
> sleep would react for, just from a different perspective, so it does
> make sense to run them both together.
>
> You may want to set
>
> depends on RV_PER_TASK_MONITORS >= 3
>
> in rtapp/Kconfig. Though if we plan to add more per-task monitors we may
> need to find a better solution.
Yeah, perhaps some sort of list instead of the current fixed-length array.
>> diff --git a/tools/verification/models/rtapp/wakeup.ltl
>> b/tools/verification/models/rtapp/wakeup.ltl
>> new file mode 100644
>> index 000000000000..a5d63ca0811a
>> --- /dev/null
>> +++ b/tools/verification/models/rtapp/wakeup.ltl
>> @@ -0,0 +1,5 @@
>> +RULE = always (((RT and USER_THREAD) imply
>> + (not (WOKEN_BY_LOWER_PRIO or WOKEN_BY_SOFTIRQ)) or
>> ALLOWLIST))
>> +
>> +ALLOWLIST = BLOCK_ON_RT_MUTEX
>> + or FUTEX_LOCK_PI
>
> So here the events and atoms are similar to the ones in sleep, but since
> we fail on the waking event, we are going to see it from the perspective
> of the waker task, right?
>
> But are those really equivalent? Why do we do RT and USER_THREAD here
> while there is a much more nuanced set of conditions in sleep?
>
> If I understand it correctly, sleep can monitor some kernel threads but
> this monitor does not, is there a reason for that? Are we just not
> interested in the waker for kernel threads?
Urgh, initially I had a patch which drops kernel threads in the sleep
monitor, but finally I decided to drop that patch. This is the leftover
of that.
You are right that we should be consistent and consider kernel threads
here as well.
> I'm not sure if there is any better terminology, but "waking" task makes
> me think of the task that is about to be woken, though it can mean also
> that task that is waking another (what you probably mean here).
>
> What about using the waker/wakee terminology?
waker/wakee would be clearer.
> I see the kernel (events/sched.h) uses waking as well, but it says
> waking context (which a bit clearer to me than waking task).
> May be worth running it through an LLM which can produce more
> English-native unambiguous wording, or maybe I'm just flipping..
>
> Also please document it in Documentation/trace/rv/monitor_rtapp.rst
Right, thanks for the reminder.
Nam
^ permalink raw reply
* Re: [PATCH mm-unstable v17 11/14] mm/khugepaged: Introduce mTHP collapse support
From: Nico Pache @ 2026-05-25 13:08 UTC (permalink / raw)
To: Wei Yang
Cc: linux-doc, linux-kernel, linux-mm, linux-trace-kernel, aarcange,
akpm, anshuman.khandual, apopple, baohua, baolin.wang, byungchul,
catalin.marinas, cl, corbet, dave.hansen, david, dev.jain, gourry,
hannes, hughd, jack, jackmanb, jannh, jglisse, joshua.hahnjy, kas,
lance.yang, liam, ljs, mathieu.desnoyers, matthew.brost, mhiramat,
mhocko, peterx, pfalcato, rakie.kim, raquini, rdunlap, rientjes,
rostedt, rppt, ryan.roberts, shivankg, sunnanyong, surenb,
thomas.hellstrom, tiwai, usamaarif642, vbabka, vishal.moola,
wangkefeng.wang, will, willy, yang, ying.huang, ziy, zokeefe
In-Reply-To: <20260521015510.k4p22m365q2wqkro@master>
On Wed, May 20, 2026 at 7:55 PM Wei Yang <richard.weiyang@gmail.com> wrote:
>
> On Wed, May 20, 2026 at 06:05:31AM -0600, Nico Pache wrote:
> >On Tue, May 12, 2026 at 9:44 AM Wei Yang <richard.weiyang@gmail.com> wrote:
> >>
> >> On Mon, May 11, 2026 at 12:58:11PM -0600, Nico Pache wrote:
> >> >Enable khugepaged to collapse to mTHP orders. This patch implements the
> >> >main scanning logic using a bitmap to track occupied pages and a stack
> >> >structure that allows us to find optimal collapse sizes.
> >> >
> >> >Previous to this patch, PMD collapse had 3 main phases, a light weight
> >> >scanning phase (mmap_read_lock) that determines a potential PMD
> >> >collapse, an alloc phase (mmap unlocked), then finally heavier collapse
> >> >phase (mmap_write_lock).
> >> >
> >> >To enabled mTHP collapse we make the following changes:
> >> >
> >> >During PMD scan phase, track occupied pages in a bitmap. When mTHP
> >> >orders are enabled, we remove the restriction of max_ptes_none during the
> >> >scan phase to avoid missing potential mTHP collapse candidates. Once we
> >> >have scanned the full PMD range and updated the bitmap to track occupied
> >> >pages, we use the bitmap to find the optimal mTHP size.
> >> >
> >> >Implement collapse_scan_bitmap() to perform binary recursion on the bitmap
> >> >and determine the best eligible order for the collapse. A stack structure
> >> >is used instead of traditional recursion to manage the search. This also
> >> >prevents a traditional recursive approach when the kernel stack struct is
> >> >limited. The algorithm recursively splits the bitmap into smaller chunks to
> >> >find the highest order mTHPs that satisfy the collapse criteria. We start
> >> >by attempting the PMD order, then moved on the consecutively lower orders
> >> >(mTHP collapse). The stack maintains a pair of variables (offset, order),
> >> >indicating the number of PTEs from the start of the PMD, and the order of
> >> >the potential collapse candidate.
> >> >
> >> >The algorithm for consuming the bitmap works as such:
> >> > 1) push (0, HPAGE_PMD_ORDER) onto the stack
> >> > 2) pop the stack
> >> > 3) check if the number of set bits in that (offset,order) pair
> >> > statisfy the max_ptes_none threshold for that order
> >> > 4) if yes, attempt collapse
> >> > 5) if no (or collapse fails), push two new stack items representing
> >> > the left and right halves of the current bitmap range, at the
> >> > next lower order
> >> > 6) repeat at step (2) until stack is empty.
> >> >
> >> >Below is a diagram representing the algorithm and stack items:
> >> >
> >> > offset mid_offset
> >> > | |
> >> > | |
> >> > v v
> >> > ____________________________________
> >> > | PTE Page Table |
> >> > --------------------------------------
> >> > <-------><------->
> >> > order-1 order-1
> >> >
> >> >mTHP collapses reject regions containing swapped out or shared pages.
> >> >This is because adding new entries can lead to new none pages, and these
> >> >may lead to constant promotion into a higher order mTHP. A similar
> >> >issue can occur with "max_ptes_none > HPAGE_PMD_NR/2" due to a collapse
> >> >introducing at least 2x the number of pages, and on a future scan will
> >> >satisfy the promotion condition once again. This issue is prevented via
> >> >the collapse_max_ptes_none() function which imposes the max_ptes_none
> >> >restrictions above.
> >> >
> >> >We currently only support mTHP collapse for max_ptes_none values of 0
> >> >and HPAGE_PMD_NR - 1. resulting in the following behavior:
> >> >
> >> > - max_ptes_none=0: Never introduce new empty pages during collapse
> >> > - max_ptes_none=HPAGE_PMD_NR-1: Always try collapse to the highest
> >> > available mTHP order
> >> >
> >> >Any other max_ptes_none value will emit a warning and skip mTHP collapse
> >> >attempts. There should be no behavior change for PMD collapse.
> >> >
> >> >Once we determine what mTHP sizes fits best in that PMD range a collapse
> >> >is attempted. A minimum collapse order of 2 is used as this is the lowest
> >> >order supported by anon memory as defined by THP_ORDERS_ALL_ANON.
> >> >
> >> >Currently madv_collapse is not supported and will only attempt PMD
> >> >collapse.
> >> >
> >> >We can also remove the check for is_khugepaged inside the PMD scan as
> >> >the collapse_max_ptes_none() function handles this logic now.
> >> >
> >> >Signed-off-by: Nico Pache <npache@redhat.com>
> >>
> >> [...]
> >>
> >> >+static int mthp_collapse(struct mm_struct *mm, unsigned long address,
> >> >+ int referenced, int unmapped, struct collapse_control *cc,
> >> >+ unsigned long enabled_orders)
> >> >+{
> >> >+ unsigned int nr_occupied_ptes, nr_ptes;
> >> >+ int max_ptes_none, collapsed = 0, stack_size = 0;
> >> >+ unsigned long collapse_address;
> >> >+ struct mthp_range range;
> >> >+ u16 offset;
> >> >+ u8 order;
> >> >+
> >> >+ collapse_mthp_stack_push(cc, &stack_size, 0, HPAGE_PMD_ORDER);
> >> >+
> >> >+ while (stack_size) {
> >> >+ range = collapse_mthp_stack_pop(cc, &stack_size);
> >> >+ order = range.order;
> >> >+ offset = range.offset;
> >> >+ nr_ptes = 1UL << order;
> >> >+
> >> >+ if (!test_bit(order, &enabled_orders))
> >> >+ goto next_order;
> >> >+
> >> >+ max_ptes_none = collapse_max_ptes_none(cc, NULL, order);
> >>
> >> I am thinking whether there is a behavioral change for userfaultfd_armed(vma).
> >>
> >> collapse_single_pmd()
> >> collapse_scan_pmd
> >> max_ptes_none = collapse_max_ptes_none(cc, vma)
> >> max_ptes_none = KHUGEPAGED_MAX_PTES_LIMIT --- (1)
> >> mthp_collapse
> >> max_ptes_none = collapse_max_ptes_none(cc, NULL) --- (2)
> >> collapse_huge_page(mm)
> >> hugepage_vma_revalidate(&vma)
> >> __collapse_huge_page_isolate(vma)
> >> max_ptes_none = collapse_max_ptes_none(cc, vma)
> >>
> >> Before mthp_collapse() introduced, userfaultfd_armed(vma) is skipped if there
> >> is any pte_none_or_zero() in collapse_scan_pmd().
> >>
> >> But now, max_ptes_none could be set to KHUGEPAGED_MAX_PTES_LIMIT at (1), so
> >> that we can scan all the pte to get the bitmap. This means
> >> userfaultfd_armed(vma) could continue even with pte_none_or_zero().
> >>
> >> Then in mthp_collapse(), collapse_max_ptes_none() at (2) ignores
> >> userfaultfd_armed(vma), which means it will continue to collapse a
> >> userfaultfd_armed(vma) when there is pte_none_or_zero().
> >>
> >> The good news is we will stop at __collapse_huge_page_isolate(), where we
> >> get collapse_max_ptes_none() with vma. But we already did a lot of work.
> >
> >Good catch!
> >
> >As you stated we eventually ensure we respect the uffd checks. So
> >there are no correctness issues, just the potential for wasted cycles.
> >
> >At (1) we only do this if mTHPs are enabled. If that is the case, the
> >only waste that can arise is at the PMD order, as that order respects
> >the max_ptes_none value.
> >
> >I think one approach is to gate (1) with the uffd check as well. That
> >way, if mTHPs are enabled and its uffd-armed, max_ptes_none will stay
> >at 0, and we bail early on the scan early if any none_ptes are hit.
> >
> >But then we lose the ability to collapse to mTHPs that are uffd-armed,
> >where the PMD has none/zero-ptes and the mTHP fully has 0
> >non-none/zero-ptes.
> >
> >ie) assume a PMD is 16 x's [xxxxxxxx00000000]
> >where x is a populated pte and 0 is not
> >If we guard this scan (1), then we will never check if its possible to
> >collapse to the smaller orders.
> >
> >Let me know if you see a flaw in my logic, I think it's best to keep it as is?
> >
>
> Yes, gate it at (1) is not a proper place.
>
> I am thinking whether we could pass vma to (2)? So that we could respect
> uffd-armed?
Ok, sorry I never replied but i did implement it at (2). Sashiko
brought up a good point that this can result in a UAF; I verified
that. I'm going to send a fixup to the v18 to undo the change.
I added this to my todo list, and will look into optimizing/finding a
solution for this in a future series. The good thing is, as you stated
earlier, this can result in some wasted work, but it is not logically
incorrect overall.
Cheers,
-- Nico
>
> >>
> >> Not sure if I missed something.
> >>
> >> >+
> >> >+ if (max_ptes_none < 0)
> >> >+ return collapsed;
> >> >+
> >> >+ nr_occupied_ptes = collapse_mthp_count_present(cc, offset,
> >> >+ nr_ptes);
> >> >+
> >> >+ if (nr_occupied_ptes >= nr_ptes - max_ptes_none) {
> >> >+ int ret;
> >> >+
> >> >+ collapse_address = address + offset * PAGE_SIZE;
> >> >+ ret = collapse_huge_page(mm, collapse_address, referenced,
> >> >+ unmapped, cc, order);
> >> >+ if (ret == SCAN_SUCCEED) {
> >> >+ collapsed += nr_ptes;
> >> >+ continue;
> >> >+ }
> >> >+ }
> >> >+
> >> >+next_order:
> >> >+ if (order > KHUGEPAGED_MIN_MTHP_ORDER) {
> >> >+ const u8 next_order = order - 1;
> >> >+ const u16 mid_offset = offset + (nr_ptes / 2);
> >> >+
> >> >+ collapse_mthp_stack_push(cc, &stack_size, mid_offset,
> >> >+ next_order);
> >> >+ collapse_mthp_stack_push(cc, &stack_size, offset,
> >> >+ next_order);
> >> >+ }
> >> >+ }
> >> >+ return collapsed;
> >> >+}
> >> >+
> >> > static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> >> > struct vm_area_struct *vma, unsigned long start_addr,
> >> > bool *lock_dropped, struct collapse_control *cc)
> >> > {
> >> >- const int max_ptes_none = collapse_max_ptes_none(cc, vma, HPAGE_PMD_ORDER);
> >> >+ int max_ptes_none = collapse_max_ptes_none(cc, vma, HPAGE_PMD_ORDER);
> >> > const unsigned int max_ptes_shared = collapse_max_ptes_shared(cc, HPAGE_PMD_ORDER);
> >> > const unsigned int max_ptes_swap = collapse_max_ptes_swap(cc, HPAGE_PMD_ORDER);
> >> >+ enum tva_type tva_flags = cc->is_khugepaged ? TVA_KHUGEPAGED : TVA_FORCED_COLLAPSE;
> >> > pmd_t *pmd;
> >> >- pte_t *pte, *_pte;
> >> >- int none_or_zero = 0, shared = 0, referenced = 0;
> >> >+ pte_t *pte, *_pte, pteval;
> >> >+ int i;
> >> >+ int none_or_zero = 0, shared = 0, nr_collapsed = 0, referenced = 0;
> >> > enum scan_result result = SCAN_FAIL;
> >> > struct page *page = NULL;
> >> > struct folio *folio = NULL;
> >> > unsigned long addr;
> >> >+ unsigned long enabled_orders;
> >> > spinlock_t *ptl;
> >> > int node = NUMA_NO_NODE, unmapped = 0;
> >> >
> >> >@@ -1429,8 +1579,19 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> >> > goto out;
> >> > }
> >> >
> >> >+ bitmap_zero(cc->mthp_bitmap, MAX_PTRS_PER_PTE);
> >> > memset(cc->node_load, 0, sizeof(cc->node_load));
> >> > nodes_clear(cc->alloc_nmask);
> >> >+
> >> >+ enabled_orders = collapse_allowable_orders(vma, vma->vm_flags, tva_flags);
> >>
> >> Would it be 0 at this point?
> >
> >If your question relates to the issue you brought up above, then yes,
> >max_ptes_none would be 0 if it's uffd-armed. We must recheck the
> >uffd-armed status before modifying it to 511.
> >
> >>
> >> >+
> >> >+ /*
> >> >+ * If PMD is the only enabled order, enforce max_ptes_none, otherwise
> >> >+ * scan all pages to populate the bitmap for mTHP collapse.
> >> >+ */
> >> >+ if (enabled_orders != BIT(HPAGE_PMD_ORDER))
> >> >+ max_ptes_none = KHUGEPAGED_MAX_PTES_LIMIT;
> >> >+
> >> > pte = pte_offset_map_lock(mm, pmd, start_addr, &ptl);
> >> > if (!pte) {
> >> > cc->progress++;
> >> >@@ -1438,11 +1599,13 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> >> > goto out;
> >> > }
> >> >
> >> >- for (addr = start_addr, _pte = pte; _pte < pte + HPAGE_PMD_NR;
> >> >- _pte++, addr += PAGE_SIZE) {
> >> >+ for (i = 0; i < HPAGE_PMD_NR; i++) {
> >> >+ _pte = pte + i;
> >> >+ addr = start_addr + i * PAGE_SIZE;
> >> >+ pteval = ptep_get(_pte);
> >> >+
> >> > cc->progress++;
> >> >
> >> >- pte_t pteval = ptep_get(_pte);
> >> > if (pte_none_or_zero(pteval)) {
> >> > if (++none_or_zero > max_ptes_none) {
> >> > result = SCAN_EXCEED_NONE_PTE;
> >> >@@ -1522,6 +1685,8 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> >> > }
> >> > }
> >> >
> >> >+ /* Set bit for occupied pages */
> >> >+ __set_bit(i, cc->mthp_bitmap);
> >> > /*
> >> > * Record which node the original page is from and save this
> >> > * information to cc->node_load[].
> >> >@@ -1580,10 +1745,11 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> >> > if (result == SCAN_SUCCEED) {
> >> > /* collapse_huge_page expects the lock to be dropped before calling */
> >> > mmap_read_unlock(mm);
> >> >- result = collapse_huge_page(mm, start_addr, referenced,
> >> >- unmapped, cc, HPAGE_PMD_ORDER);
> >> >+ nr_collapsed = mthp_collapse(mm, start_addr, referenced, unmapped,
> >> >+ cc, enabled_orders);
> >> > /* collapse_huge_page will return with the mmap_lock released */
> >>
> >> collapse_huge_page will return with mmap_lock released, but mthp_collapse()
> >> may not?
> >
> >We are now releasing the lock before calling mthp_collapse, which
> >subsequently calls collapse_huge_page. Even if `collapse_huge_page` is
> >never called-- say, because enabled_orders is 0 (which should not
> >happen) and all collapse orders are skipped (never calling
> >collapse_huge_page)-- we still return here with the lock dropped.
> >
> >I think this is sound. Let me know if you think differently.
> >
>
> You are right. I missed the lock is released in previous patch.
>
> >Cheers :)
> >-- Nico
> >
> >>
> >> > *lock_dropped = true;
> >> >+ result = nr_collapsed ? SCAN_SUCCEED : SCAN_FAIL;
> >> > }
> >> > out:
> >> > trace_mm_khugepaged_scan_pmd(mm, folio, referenced,
> >> >--
> >> >2.54.0
> >>
> >> --
> >> Wei Yang
> >> Help you, Help me
> >>
>
> --
> Wei Yang
> Help you, Help me
>
^ permalink raw reply
* [PATCH] rethook: Use tsk->on_cpu to check task execution state
From: Tengda Wu @ 2026-05-25 13:22 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu
Cc: Mathieu Desnoyers, Alexei Starovoitov, linux-trace-kernel,
linux-kernel, Tengda Wu
When a task calls schedule() to yield the CPU, its state remains
TASK_RUNNING, but its stack is frozen and safe to walk.
Replace task_is_running(tsk) with tsk->on_cpu to avoid overly
conservative rejections.
Fixes: 54ecbe6f1ed5 ("rethook: Add a generic return hook")
Signed-off-by: Tengda Wu <wutengda@huaweicloud.com>
---
kernel/trace/rethook.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/rethook.c b/kernel/trace/rethook.c
index 5a8bdf88999a..bd5e5f455e85 100644
--- a/kernel/trace/rethook.c
+++ b/kernel/trace/rethook.c
@@ -250,7 +250,7 @@ unsigned long rethook_find_ret_addr(struct task_struct *tsk, unsigned long frame
if (WARN_ON_ONCE(!cur))
return 0;
- if (tsk != current && task_is_running(tsk))
+ if (tsk != current && tsk->on_cpu)
return 0;
do {
--
2.34.1
^ permalink raw reply related
* Re: [PATCH mm-unstable v18 11/14] mm/khugepaged: Introduce mTHP collapse support
From: Nico Pache @ 2026-05-25 14:15 UTC (permalink / raw)
To: linux-doc, linux-kernel, linux-mm, linux-trace-kernel, akpm
Cc: aarcange, anshuman.khandual, apopple, baohua, baolin.wang,
byungchul, catalin.marinas, cl, corbet, dave.hansen, david,
dev.jain, gourry, hannes, hughd, jack, jackmanb, jannh, jglisse,
joshua.hahnjy, kas, lance.yang, liam, ljs, mathieu.desnoyers,
matthew.brost, mhiramat, mhocko, peterx, pfalcato, rakie.kim,
raquini, rdunlap, richard.weiyang, rientjes, rostedt, rppt,
ryan.roberts, shivankg, sunnanyong, surenb, thomas.hellstrom,
tiwai, usamaarif642, vbabka, vishal.moola, wangkefeng.wang, will,
willy, yang, ying.huang, ziy, zokeefe
In-Reply-To: <20260522150009.121603-12-npache@redhat.com>
On 5/22/26 9:00 AM, Nico Pache wrote:
> Enable khugepaged to collapse to mTHP orders. This patch implements the
> main scanning logic using a bitmap to track occupied pages and a stack
> structure that allows us to find optimal collapse sizes.
>
> Previous to this patch, PMD collapse had 3 main phases, a light weight
> scanning phase (mmap_read_lock) that determines a potential PMD
> collapse, an alloc phase (mmap unlocked), then finally heavier collapse
> phase (mmap_write_lock).
>
> To enabled mTHP collapse we make the following changes:
>
> During PMD scan phase, track occupied pages in a bitmap. When mTHP
> orders are enabled, we remove the restriction of max_ptes_none during the
> scan phase to avoid missing potential mTHP collapse candidates. Once we
> have scanned the full PMD range and updated the bitmap to track occupied
> pages, we use the bitmap to find the optimal mTHP size.
>
> Implement collapse_scan_bitmap() to perform binary recursion on the bitmap
> and determine the best eligible order for the collapse. A stack structure
> is used instead of traditional recursion to manage the search. This also
> prevents a traditional recursive approach when the kernel stack struct is
> limited. The algorithm recursively splits the bitmap into smaller chunks to
> find the highest order mTHPs that satisfy the collapse criteria. We start
> by attempting the PMD order, then moved on the consecutively lower orders
> (mTHP collapse). The stack maintains a pair of variables (offset, order),
> indicating the number of PTEs from the start of the PMD, and the order of
> the potential collapse candidate.
>
> The algorithm for consuming the bitmap works as such:
> 1) push (0, HPAGE_PMD_ORDER) onto the stack
> 2) pop the stack
> 3) check if the number of set bits in that (offset,order) pair
> statisfy the max_ptes_none threshold for that order
> 4) if yes, attempt collapse
> 5) if no (or collapse fails), push two new stack items representing
> the left and right halves of the current bitmap range, at the
> next lower order
> 6) repeat at step (2) until stack is empty.
>
> Below is a diagram representing the algorithm and stack items:
>
> offset mid_offset
> | |
> | |
> v v
> ____________________________________
> | PTE Page Table |
> --------------------------------------
> <-------><------->
> order-1 order-1
>
> mTHP collapses reject regions containing swapped out or shared pages.
> This is because adding new entries can lead to new none pages, and these
> may lead to constant promotion into a higher order mTHP. A similar
> issue can occur with "max_ptes_none > HPAGE_PMD_NR/2" due to a collapse
> introducing at least 2x the number of pages, and on a future scan will
> satisfy the promotion condition once again. This issue is prevented via
> the collapse_max_ptes_none() function which imposes the max_ptes_none
> restrictions above.
>
> We currently only support mTHP collapse for max_ptes_none values of 0
> and HPAGE_PMD_NR - 1. resulting in the following behavior:
>
> - max_ptes_none=0: Never introduce new empty pages during collapse
> - max_ptes_none=HPAGE_PMD_NR-1: Always try collapse to the highest
> available mTHP order
>
> Any other max_ptes_none value will emit a warning and default mTHP
> collapse to max_ptes_none=0. There should be no behavior change for PMD
> collapse.
>
> Once we determine what mTHP sizes fits best in that PMD range a collapse
> is attempted. A minimum collapse order of 2 is used as this is the lowest
> order supported by anon memory as defined by THP_ORDERS_ALL_ANON.
>
> Currently madv_collapse is not supported and will only attempt PMD
> collapse.
>
> We can also remove the check for is_khugepaged inside the PMD scan as
> the collapse_max_ptes_none() function handles this logic now.
>
> Signed-off-by: Nico Pache <npache@redhat.com>
> ---
> mm/khugepaged.c | 181 +++++++++++++++++++++++++++++++++++++++++++++---
> 1 file changed, 172 insertions(+), 9 deletions(-)
>
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index 64ceebc9d8a7..d3d7db8be26c 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -99,6 +99,30 @@ static DEFINE_READ_MOSTLY_HASHTABLE(mm_slots_hash, MM_SLOTS_HASH_BITS);
>
> static struct kmem_cache *mm_slot_cache __ro_after_init;
>
> +#define KHUGEPAGED_MIN_MTHP_ORDER 2
> +/*
> + * mthp_collapse() does an iterative DFS over a binary tree, from
> + * HPAGE_PMD_ORDER down to KHUGEPAGED_MIN_MTHP_ORDER. The max stack
> + * size needed for a DFS on a binary tree is height + 1, where
> + * height = HPAGE_PMD_ORDER - KHUGEPAGED_MIN_MTHP_ORDER.
> + *
> + * ilog2 is used in place of HPAGE_PMD_ORDER because some architectures
> + * (e.g. ppc64le) do not define HPAGE_PMD_ORDER until after build time.
> + */
> +#define MTHP_STACK_SIZE (ilog2(MAX_PTRS_PER_PTE) - KHUGEPAGED_MIN_MTHP_ORDER + 1)
> +
> +/*
> + * Defines a range of PTE entries in a PTE page table which are being
> + * considered for mTHP collapse.
> + *
> + * @offset: the offset of the first PTE entry in a PMD range.
> + * @order: the order of the PTE entries being considered for collapse.
> + */
> +struct mthp_range {
> + u16 offset;
> + u8 order;
> +};
> +
> struct collapse_control {
> bool is_khugepaged;
>
> @@ -110,6 +134,12 @@ struct collapse_control {
>
> /* nodemask for allocation fallback */
> nodemask_t alloc_nmask;
> +
> + /* Each bit represents a single occupied (!none/zero) page. */
> + DECLARE_BITMAP(mthp_bitmap, MAX_PTRS_PER_PTE);
> + /* A mask of the current range being considered for mTHP collapse. */
> + DECLARE_BITMAP(mthp_bitmap_mask, MAX_PTRS_PER_PTE);
> + struct mthp_range mthp_bitmap_stack[MTHP_STACK_SIZE];
> };
>
> /**
> @@ -1411,20 +1441,137 @@ static enum scan_result collapse_huge_page(struct mm_struct *mm, unsigned long s
> return result;
> }
>
> +static void collapse_mthp_stack_push(struct collapse_control *cc, int *stack_size,
> + u16 offset, u8 order)
> +{
> + const int size = *stack_size;
> + struct mthp_range *stack = &cc->mthp_bitmap_stack[size];
> +
> + VM_WARN_ON_ONCE(size >= MTHP_STACK_SIZE);
> + stack->order = order;
> + stack->offset = offset;
> + (*stack_size)++;
> +}
> +
> +static struct mthp_range collapse_mthp_stack_pop(struct collapse_control *cc,
> + int *stack_size)
> +{
> + const int size = *stack_size;
> +
> + VM_WARN_ON_ONCE(size <= 0);
> + (*stack_size)--;
> + return cc->mthp_bitmap_stack[size - 1];
> +}
> +
> +static unsigned int collapse_mthp_count_present(struct collapse_control *cc,
> + u16 offset, unsigned int nr_ptes)
> +{
> + bitmap_zero(cc->mthp_bitmap_mask, MAX_PTRS_PER_PTE);
> + bitmap_set(cc->mthp_bitmap_mask, offset, nr_ptes);
> + return bitmap_weight_and(cc->mthp_bitmap, cc->mthp_bitmap_mask, MAX_PTRS_PER_PTE);
> +}
> +
> +/*
> + * mthp_collapse() consumes the bitmap that is generated during
> + * collapse_scan_pmd() to determine what regions and mTHP orders fit best.
> + *
> + * Each bit in cc->mthp_bitmap represents a single occupied (!none/zero) page.
> + * A stack structure cc->mthp_bitmap_stack is used to check different regions
> + * of the bitmap for collapse eligibility. The stack maintains a pair of
> + * variables (offset, order), indicating the number of PTEs from the start of
> + * the PMD, and the order of the potential collapse candidate respectively. We
> + * start at the PMD order and check if it is eligible for collapse; if not, we
> + * add two entries to the stack at a lower order to represent the left and right
> + * halves of the PTE page table we are examining.
> + *
> + * offset mid_offset
> + * | |
> + * | |
> + * v v
> + * --------------------------------------
> + * | cc->mthp_bitmap |
> + * --------------------------------------
> + * <-------><------->
> + * order-1 order-1
> + *
> + * For each of these, we determine how many PTE entries are occupied in the
> + * range of PTE entries we propose to collapse, then we compare this to a
> + * threshold number of PTE entries which would need to be occupied for a
> + * collapse to be permitted at that order (accounting for max_ptes_none).
> + *
> + * If a collapse is permitted, we attempt to collapse the PTE range into a
> + * mTHP.
> + */
> +static int mthp_collapse(struct mm_struct *mm, struct vm_area_struct *vma,
> + unsigned long address, int referenced, int unmapped,
> + struct collapse_control *cc, unsigned long enabled_orders)
> +{
> + unsigned int nr_occupied_ptes, nr_ptes, max_ptes_none;
> + int collapsed = 0, stack_size = 0;
> + unsigned long collapse_address;
> + struct mthp_range range;
> + u16 offset;
> + u8 order;
> +
> + collapse_mthp_stack_push(cc, &stack_size, 0, HPAGE_PMD_ORDER);
> +
> + while (stack_size) {
> + range = collapse_mthp_stack_pop(cc, &stack_size);
> + order = range.order;
> + offset = range.offset;
> + nr_ptes = 1UL << order;
> +
> + if (!test_bit(order, &enabled_orders))
> + goto next_order;
> +
> + max_ptes_none = collapse_max_ptes_none(cc, vma, order);
> +
> + nr_occupied_ptes = collapse_mthp_count_present(cc, offset,
> + nr_ptes);
> +
> + if (nr_occupied_ptes >= nr_ptes - max_ptes_none) {
> + int ret;
> +
> + collapse_address = address + offset * PAGE_SIZE;
> + ret = collapse_huge_page(mm, collapse_address, referenced,
> + unmapped, cc, order);
> + if (ret == SCAN_SUCCEED) {
> + collapsed += nr_ptes;
> + continue;
> + }
> + }
> +
> +next_order:
> + if ((BIT(order) - 1) & enabled_orders) {
> + const u8 next_order = order - 1;
> + const u16 mid_offset = offset + (nr_ptes / 2);
> +
> + collapse_mthp_stack_push(cc, &stack_size, mid_offset,
> + next_order);
> + collapse_mthp_stack_push(cc, &stack_size, offset,
> + next_order);
> + }
> + }
> + return collapsed;
> +}
Hi Andrew,
Can you please append the following fixup that reverts one of the
changes requested in V17. The issue with the change is described
below.
commit 1e099144dfcdd28e3b3b50b32535798db53866aa
Author: Nico Pache <npache@redhat.com>
Date: Mon May 25 07:38:59 2026 -0600
fixup: fix potential use-after-free of vma in mthp_collapse()
Between V17 and v18, one reviewer (Wei) brought up that we are not
doing
the uffd-armed check until deep in the collapse operation. While not
functionally incorrect, it can lead to unnecessary work.
We optimized this by passing the vma variable to mthp_collapse()
and using
the collapse_max_ptes_none() function to check the state of uffd-armed
preventing the wasted work later in the collapse.
mthp_collapse() is called after mmap_read_unlock(), so the vma pointer
can become stale. Remove the vma parameter and pass NULL to
collapse_max_ptes_none() instead.
Signed-off-by: Nico Pache <npache@redhat.com>
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index d3d7db8be26c..a901db5c9201 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -1502,9 +1502,9 @@ static unsigned int
collapse_mthp_count_present(struct collapse_control *cc,
* If a collapse is permitted, we attempt to collapse the PTE range into a
* mTHP.
*/
-static int mthp_collapse(struct mm_struct *mm, struct vm_area_struct *vma,
- unsigned long address, int referenced, int unmapped,
- struct collapse_control *cc, unsigned long enabled_orders)
+static int mthp_collapse(struct mm_struct *mm, unsigned long address,
+ int referenced, int unmapped, struct collapse_control *cc,
+ unsigned long enabled_orders)
{
unsigned int nr_occupied_ptes, nr_ptes, max_ptes_none;
int collapsed = 0, stack_size = 0;
@@ -1524,7 +1524,7 @@ static int mthp_collapse(struct mm_struct *mm,
struct vm_area_struct *vma,
if (!test_bit(order, &enabled_orders))
goto next_order;
- max_ptes_none = collapse_max_ptes_none(cc, vma, order);
+ max_ptes_none = collapse_max_ptes_none(cc, NULL, order);
nr_occupied_ptes = collapse_mthp_count_present(cc, offset,
nr_ptes);
@@ -1749,7 +1749,7 @@ static enum scan_result collapse_scan_pmd(struct
mm_struct *mm,
if (result == SCAN_SUCCEED) {
/* collapse_huge_page expects the lock to be dropped before
calling */
mmap_read_unlock(mm);
- nr_collapsed = mthp_collapse(mm, vma, start_addr, referenced,
+ nr_collapsed = mthp_collapse(mm, start_addr, referenced,
unmapped, cc, enabled_orders);
/* mmap_lock was released above, set lock_dropped */
*lock_dropped = true;
> +
> static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> struct vm_area_struct *vma, unsigned long start_addr,
> bool *lock_dropped, struct collapse_control *cc)
> {
> - const unsigned int max_ptes_none = collapse_max_ptes_none(cc, vma, HPAGE_PMD_ORDER);
> const unsigned int max_ptes_shared = collapse_max_ptes_shared(cc, HPAGE_PMD_ORDER);
> const unsigned int max_ptes_swap = collapse_max_ptes_swap(cc, HPAGE_PMD_ORDER);
> + unsigned int max_ptes_none = collapse_max_ptes_none(cc, vma, HPAGE_PMD_ORDER);
> + enum tva_type tva_flags = cc->is_khugepaged ? TVA_KHUGEPAGED : TVA_FORCED_COLLAPSE;
> pmd_t *pmd;
> - pte_t *pte, *_pte;
> - int none_or_zero = 0, shared = 0, referenced = 0;
> + pte_t *pte, *_pte, pteval;
> + int i;
> + int none_or_zero = 0, shared = 0, nr_collapsed = 0, referenced = 0;
> enum scan_result result = SCAN_FAIL;
> struct page *page = NULL;
> struct folio *folio = NULL;
> unsigned long addr;
> + unsigned long enabled_orders;
> spinlock_t *ptl;
> int node = NUMA_NO_NODE, unmapped = 0;
>
> @@ -1436,8 +1583,19 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> goto out;
> }
>
> + bitmap_zero(cc->mthp_bitmap, MAX_PTRS_PER_PTE);
> memset(cc->node_load, 0, sizeof(cc->node_load));
> nodes_clear(cc->alloc_nmask);
> +
> + enabled_orders = collapse_allowable_orders(vma, vma->vm_flags, tva_flags);
> +
> + /*
> + * If PMD is the only enabled order, enforce max_ptes_none, otherwise
> + * scan all pages to populate the bitmap for mTHP collapse.
> + */
> + if (enabled_orders != BIT(HPAGE_PMD_ORDER))
> + max_ptes_none = KHUGEPAGED_MAX_PTES_LIMIT;
> +
> pte = pte_offset_map_lock(mm, pmd, start_addr, &ptl);
> if (!pte) {
> cc->progress++;
> @@ -1445,11 +1603,13 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> goto out;
> }
>
> - for (addr = start_addr, _pte = pte; _pte < pte + HPAGE_PMD_NR;
> - _pte++, addr += PAGE_SIZE) {
> + for (i = 0; i < HPAGE_PMD_NR; i++) {
> + _pte = pte + i;
> + addr = start_addr + i * PAGE_SIZE;
> + pteval = ptep_get(_pte);
> +
> cc->progress++;
>
> - pte_t pteval = ptep_get(_pte);
> if (pte_none_or_zero(pteval)) {
> if (++none_or_zero > max_ptes_none) {
> result = SCAN_EXCEED_NONE_PTE;
> @@ -1529,6 +1689,8 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> }
> }
>
> + /* Set bit for occupied pages */
> + __set_bit(i, cc->mthp_bitmap);
> /*
> * Record which node the original page is from and save this
> * information to cc->node_load[].
> @@ -1587,10 +1749,11 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> if (result == SCAN_SUCCEED) {
> /* collapse_huge_page expects the lock to be dropped before calling */
> mmap_read_unlock(mm);
> - result = collapse_huge_page(mm, start_addr, referenced,
> - unmapped, cc, HPAGE_PMD_ORDER);
> - /* collapse_huge_page will return with the mmap_lock released */
> + nr_collapsed = mthp_collapse(mm, vma, start_addr, referenced,
> + unmapped, cc, enabled_orders);
> + /* mmap_lock was released above, set lock_dropped */
> *lock_dropped = true;
> + result = nr_collapsed ? SCAN_SUCCEED : SCAN_FAIL;
> }
> out:
> trace_mm_khugepaged_scan_pmd(mm, folio, referenced,
^ permalink raw reply related
* Re: [PATCH v6] tracing/eprobes: Allow use of BTF names to dereference pointers
From: Masami Hiramatsu @ 2026-05-25 14:55 UTC (permalink / raw)
To: Steven Rostedt
Cc: LKML, Linux trace kernel, Masami Hiramatsu, Mathieu Desnoyers,
Mark Rutland, Peter Zijlstra, Namhyung Kim, Takaya Saeki,
Douglas Raillard, Tom Zanussi, Andrew Morton, Thomas Gleixner,
Ian Rogers, Jiri Olsa
In-Reply-To: <20260521225033.56458336@fedora>
On Thu, 21 May 2026 22:50:33 -0400
Steven Rostedt <rostedt@kernel.org> wrote:
> +static int handle_typecast(char *arg, struct fetch_insn **pcode,
> + struct fetch_insn *end,
> + struct traceprobe_parse_context *ctx)
> +{
> + char *tmp;
> + int ret;
> +
> + /* Currently this only works for eprobes */
> + if (!(ctx->flags & TPARG_FL_TEVENT)) {
> + trace_probe_log_err(ctx->offset, TYPECAST_NOT_EVENT);
> + return -EINVAL;
> + }
> +
> + tmp = strchr(arg, ')');
> + if (!tmp) {
> + trace_probe_log_err(ctx->offset + strlen(arg),
> + DEREF_OPEN_BRACE);
> + return -EINVAL;
> + }
> + *tmp = '\0';
> + ret = query_btf_struct(arg + 1, ctx);
> + *tmp = ')';
BTW, is there any reason to recover this? The @arg is copied
string, see traceprobe_parse_probe_arg_body().
Thanks,
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCHv3 11/12] selftests/bpf: Add tests for uprobe nop10 red zone clobbering
From: Jiri Olsa @ 2026-05-25 15:44 UTC (permalink / raw)
To: bot+bpf-ci
Cc: oleg, peterz, mingo, mhiramat, andrii, bpf, linux-trace-kernel,
ast, daniel, martin.lau, eddyz87, yonghong.song, clm,
ihor.solodrai
In-Reply-To: <7773c27d0070aa7544a5a7596aceb8abacb4fbdb20a3aab998f05c39de4f20dc@mail.kernel.org>
On Thu, May 21, 2026 at 01:26:07PM +0000, bot+bpf-ci@kernel.org wrote:
> > diff --git a/tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c b/tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c
> > index 969f4deba9fd..efff0c515184 100644
> > --- a/tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c
> > +++ b/tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c
>
> [ ... ]
>
> > diff --git a/tools/testing/selftests/bpf/prog_tests/usdt.c b/tools/testing/selftests/bpf/prog_tests/usdt.c
> > index fda3a298ccfc..8004c9568ffa 100644
> > --- a/tools/testing/selftests/bpf/prog_tests/usdt.c
> > +++ b/tools/testing/selftests/bpf/prog_tests/usdt.c
>
> [ ... ]
>
> > diff --git a/tools/testing/selftests/bpf/progs/test_usdt.c b/tools/testing/selftests/bpf/progs/test_usdt.c
> > index f00cb52874e0..0ee78fb050a1 100644
> > --- a/tools/testing/selftests/bpf/progs/test_usdt.c
> > +++ b/tools/testing/selftests/bpf/progs/test_usdt.c
>
> [ ... ]
>
> > diff --git a/tools/testing/selftests/bpf/usdt_2.c b/tools/testing/selftests/bpf/usdt_2.c
> > index b359b389f6c0..5e38f8605b02 100644
> > --- a/tools/testing/selftests/bpf/usdt_2.c
> > +++ b/tools/testing/selftests/bpf/usdt_2.c
> > @@ -13,4 +13,17 @@ void usdt_2(void)
> > USDT(optimized_attach, usdt_2);
> > }
> >
> > +static volatile unsigned long usdt_red_zone_arg1 = 0xDEADBEEF;
> > +static volatile unsigned long usdt_red_zone_arg2 = 0xCAFEBABE;
> > +static volatile unsigned long usdt_red_zone_arg3 = 0xFEEDFACE;
> > +
> > +void __attribute__((noinline)) usdt_red_zone_trigger(void)
> > +{
> > + unsigned long a1 = usdt_red_zone_arg1;
> > + unsigned long a2 = usdt_red_zone_arg2;
> > + unsigned long a3 = usdt_red_zone_arg3;
> > +
> > + USDT(optimized_attach, usdt_red_zone, a1, a2, a3);
> > +}
>
> Following up on a review comment from sashiko-bot: is this test reliable
> across different compiler versions?
Andrii replied this one in the original post:
https://lore.kernel.org/bpf/CAEf4BzZ-nASpoF+-vLYZ1D8eWRVd5JWAuhrwx8XZNrX7ZPY5_Q@mail.gmail.com/
jirka
>
> The x86-64 USDT macro uses the "nor" inline assembly constraint, which allows
> the compiler to allocate these operands to CPU registers. Because there is no
> register pressure in usdt_red_zone_trigger(), modern compilers might allocate
> the local variables a1, a2, and a3 directly to registers rather than the
> stack's red zone.
>
> If the operands are placed in registers, the uprobe CALL optimization
> clobbering [rsp-8] will not corrupt them. This could cause the test to pass
> even on buggy kernels, creating a false positive.
>
> The author acknowledged this concern but kept the test as-is, noting that
> selftests compile with -O0 and there's also an assembly-based test.
>
> Would it be safer to explicitly force these operands into the red zone using
> inline assembly constraints, rather than depending on the compiler's register
> allocator?
>
> Reference:
> https://lore.kernel.org/bpf/20260509021238.AE98FC2BCB0@smtp.kernel.org/
>
>
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
>
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/26227520868
^ permalink raw reply
* Re: [PATCHv3 08/12] selftests/bpf: Change uprobe syscall tests to use nop10
From: Jiri Olsa @ 2026-05-25 15:44 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Oleg Nesterov, Peter Zijlstra, Ingo Molnar, Masami Hiramatsu,
Andrii Nakryiko, bpf, linux-trace-kernel
In-Reply-To: <CAEf4BzZn0NvNwuPdh10z+MAdw-9K6CgZ0XnAL0J4XRpQHhFv2w@mail.gmail.com>
On Fri, May 22, 2026 at 11:57:04AM -0700, Andrii Nakryiko wrote:
> On Thu, May 21, 2026 at 5:45 AM Jiri Olsa <jolsa@kernel.org> wrote:
> >
> > Optimized uprobes are now on top of 10-bytes nop instructions,
> > reflect that in existing tests.
> >
> > Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> > ---
> > .../selftests/bpf/benchs/bench_trigger.c | 2 +-
> > .../selftests/bpf/prog_tests/uprobe_syscall.c | 28 ++++++++++---------
> > tools/testing/selftests/bpf/prog_tests/usdt.c | 25 ++++++++++-------
> > tools/testing/selftests/bpf/usdt_2.c | 2 +-
> > 4 files changed, 32 insertions(+), 25 deletions(-)
> >
> > diff --git a/tools/testing/selftests/bpf/benchs/bench_trigger.c b/tools/testing/selftests/bpf/benchs/bench_trigger.c
> > index 2f22ec61667b..a60b8173cdc4 100644
> > --- a/tools/testing/selftests/bpf/benchs/bench_trigger.c
> > +++ b/tools/testing/selftests/bpf/benchs/bench_trigger.c
> > @@ -398,7 +398,7 @@ static void *uprobe_producer_ret(void *input)
> > #ifdef __x86_64__
> > __nocf_check __weak void uprobe_target_nop5(void)
>
> heh, nop5 -> nop_a_lot ;)
>
>
> > {
> > - asm volatile (".byte 0x0f, 0x1f, 0x44, 0x00, 0x00");
> > + asm volatile (".byte 0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00");
> > }
> >
>
> [...]
>
> > @@ -420,7 +421,8 @@ static void *check_attach(struct uprobe_syscall_executed *skel, trigger_t trigge
> > ASSERT_EQ(skel->bss->executed, executed, "executed");
> >
> > /* .. and check the trampoline is as expected. */
> > - call = (struct __arch_relative_insn *) addr;
> > + ASSERT_OK(memcmp(addr, lea_rsp, 5), "lea_rsp");
> > + call = (struct __arch_relative_insn *)(addr + 5);
> > tramp = (void *) (call + 1) + call->raddr;
> > ASSERT_EQ(call->op, 0xe8, "call");
> > ASSERT_OK(find_uprobes_trampoline(tramp), "uprobes_trampoline");
> > @@ -432,7 +434,7 @@ static void check_detach(void *addr, void *tramp)
> > {
> > /* [uprobes_trampoline] stays after detach */
> > ASSERT_OK(find_uprobes_trampoline(tramp), "uprobes_trampoline");
> > - ASSERT_OK(memcmp(addr, nop5, 5), "nop5");
> > + ASSERT_OK(memcmp(addr, jmp2B, 2), "jmp2B");
>
> yeah, not jump anymore?
mixed up the selftest change.. I had it fixed already,
new version will have both fixes ;-)
thanks,
jirka
>
> > }
> >
> > static void check(struct uprobe_syscall_executed *skel, struct bpf_link *link,
>
> [...]
^ permalink raw reply
* [PATCH] tracing: Disable KCOV instrumentation for trace_irqsoff.o
From: Karl Mehltretter @ 2026-05-25 17:04 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu
Cc: Mathieu Desnoyers, Dmitry Vyukov, Andrey Konovalov, Marco Elver,
kasan-dev, linux-trace-kernel, linux-kernel, Karl Mehltretter
When KCOV runs its boot selftest with whole-kernel instrumentation
enabled, it sets current->kcov_mode to KCOV_MODE_TRACE_PC without
installing a coverage area. Any instrumented code accepted as task-context
coverage in that window dereferences current->kcov_area and crashes.
On ARMv5 Versatile PB with CONFIG_KCOV_SELFTEST=y,
CONFIG_KCOV_INSTRUMENT_ALL=y and CONFIG_IRQSOFF_TRACER=y, boot hits a
NULL pointer fault during the selftest:
kcov: running self test
Internal error: Oops: 5 [#1] ARM
PC is at __sanitizer_cov_trace_pc+0x4c/0x90
Kernel panic - not syncing: Fatal exception
A diagnostic run showed the unwanted coverage comes from the IRQs-off
tracer callbacks reached from ARM IRQ entry before hardirq context is
visible to KCOV:
__sanitizer_cov_trace_pc from tracer_hardirqs_off+0x18/0x1cc
tracer_hardirqs_off from trace_hardirqs_off+0x34/0x54
trace_hardirqs_off from __irq_svc+0x58/0xb0
__irq_svc from kcov_init+0x7c/0xdc
and similarly through tracer_hardirqs_on().
trace_preemptirq.o is already excluded because this tracing path can run
from early interrupt code and produce coverage unrelated to syscall
inputs. Exclude trace_irqsoff.o as well, instead of requiring users to
turn off CONFIG_KCOV_INSTRUMENT_ALL=y, which is the default whole-kernel
KCOV mode.
With the exclusion in place, the same ARMv5 Versatile PB QEMU test boots
through the KCOV selftest and reaches userspace.
Tested on ARMv5 Versatile PB QEMU with CONFIG_KCOV_SELFTEST=y,
CONFIG_KCOV_INSTRUMENT_ALL=y and CONFIG_IRQSOFF_TRACER=y.
Assisted-by: Codex:gpt-5
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
---
kernel/trace/Makefile | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile
index 8d3d96e847d8..f934ff586bd4 100644
--- a/kernel/trace/Makefile
+++ b/kernel/trace/Makefile
@@ -48,9 +48,10 @@ ifdef CONFIG_GCOV_PROFILE_FTRACE
GCOV_PROFILE := y
endif
-# Functions in this file could be invoked from early interrupt
-# code and produce random code coverage.
+# Functions in these files can run from IRQ entry before hardirq context
+# is visible to KCOV, and produce coverage unrelated to syscall inputs.
KCOV_INSTRUMENT_trace_preemptirq.o := n
+KCOV_INSTRUMENT_trace_irqsoff.o := n
CFLAGS_bpf_trace.o := -I$(src)
--
2.39.5 (Apple Git-154)
^ permalink raw reply related
* Re: [PATCH mm-unstable v18 11/14] mm/khugepaged: Introduce mTHP collapse support
From: Andrew Morton @ 2026-05-25 19:10 UTC (permalink / raw)
To: Nico Pache
Cc: linux-doc, linux-kernel, linux-mm, linux-trace-kernel, aarcange,
anshuman.khandual, apopple, baohua, baolin.wang, byungchul,
catalin.marinas, cl, corbet, dave.hansen, david, dev.jain, gourry,
hannes, hughd, jack, jackmanb, jannh, jglisse, joshua.hahnjy, kas,
lance.yang, liam, ljs, mathieu.desnoyers, matthew.brost, mhiramat,
mhocko, peterx, pfalcato, rakie.kim, raquini, rdunlap,
richard.weiyang, rientjes, rostedt, rppt, ryan.roberts, shivankg,
sunnanyong, surenb, thomas.hellstrom, tiwai, usamaarif642, vbabka,
vishal.moola, wangkefeng.wang, will, willy, yang, ying.huang, ziy,
zokeefe
In-Reply-To: <2b2cda8c-358a-4a5c-989c-ae42593ef2ea@redhat.com>
On Mon, 25 May 2026 08:15:53 -0600 Nico Pache <npache@redhat.com> wrote:
> Can you please append the following fixup that reverts one of the
> changes requested in V17. The issue with the change is described
> below.
OK. fyi, what I received was badly mangled: wordwrapping, tabs messed
up, etc.
Here's my reconstruction:
Author: Nico Pache <npache@redhat.com>
Subject: fix potential use-after-free of vma in mthp_collapse()
Date: Mon May 25 07:38:59 2026 -0600
Between V17 and v18, one reviewer (Wei) brought up that we are not doing
the uffd-armed check until deep in the collapse operation. While not
functionally incorrect, it can lead to unnecessary work.
We optimized this by passing the vma variable to mthp_collapse() and using
the collapse_max_ptes_none() function to check the state of uffd-armed
preventing the wasted work later in the collapse.
mthp_collapse() is called after mmap_read_unlock(), so the vma pointer can
become stale. Remove the vma parameter and pass NULL to
collapse_max_ptes_none() instead.
Link: https://lore.kernel.org/2b2cda8c-358a-4a5c-989c-ae42593ef2ea@redhat.com
Signed-off-by: Nico Pache <npache@redhat.com>
...
mm/khugepaged.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/mm/khugepaged.c~mm-khugepaged-introduce-mthp-collapse-support-fix
+++ a/mm/khugepaged.c
@@ -1502,9 +1502,9 @@ static unsigned int collapse_mthp_count_
* If a collapse is permitted, we attempt to collapse the PTE range into a
* mTHP.
*/
-static int mthp_collapse(struct mm_struct *mm, struct vm_area_struct *vma,
- unsigned long address, int referenced, int unmapped,
- struct collapse_control *cc, unsigned long enabled_orders)
+static int mthp_collapse(struct mm_struct *mm, unsigned long address,
+ int referenced, int unmapped, struct collapse_control *cc,
+ unsigned long enabled_orders)
{
unsigned int nr_occupied_ptes, nr_ptes, max_ptes_none;
int collapsed = 0, stack_size = 0;
@@ -1524,7 +1524,7 @@ static int mthp_collapse(struct mm_struc
if (!test_bit(order, &enabled_orders))
goto next_order;
- max_ptes_none = collapse_max_ptes_none(cc, vma, order);
+ max_ptes_none = collapse_max_ptes_none(cc, NULL, order);
nr_occupied_ptes = collapse_mthp_count_present(cc, offset,
nr_ptes);
@@ -1749,7 +1749,7 @@ out_unmap:
if (result == SCAN_SUCCEED) {
/* collapse_huge_page expects the lock to be dropped before calling */
mmap_read_unlock(mm);
- nr_collapsed = mthp_collapse(mm, vma, start_addr, referenced,
+ nr_collapsed = mthp_collapse(mm, start_addr, referenced,
unmapped, cc, enabled_orders);
/* mmap_lock was released above, set lock_dropped */
*lock_dropped = true;
_
^ permalink raw reply
* Re: [PATCHv5 bpf-next 06/28] bpf: Move trampoline image setup into bpf_trampoline_ops callbacks
From: Jiri Olsa @ 2026-05-25 20:05 UTC (permalink / raw)
To: Jiri Olsa
Cc: bot+bpf-ci, ast, daniel, andrii, bpf, linux-trace-kernel, kafai,
eddyz87, songliubraving, yhs, menglong8.dong, rostedt, martin.lau,
yonghong.song, clm, ihor.solodrai
In-Reply-To: <aec7d0Z70WKqC1b4@krava>
On Tue, Apr 21, 2026 at 10:55:19AM +0200, Jiri Olsa wrote:
> On Fri, Apr 17, 2026 at 08:10:25PM +0000, bot+bpf-ci@kernel.org wrote:
> > > There's slight functional change for the unregister path, where we
> > > currently free the image unconditionally even if the detach fails.
> > > The new code keeps the image in place, possibly preventing the crash.
> >
> > This appears to be fixing a bug where the image was freed even when detach
> > failed. The bug was introduced in commit e21aa341785c ("bpf: Fix fexit
> > trampoline.") which unconditionally freed the trampoline image.
actually the paragraph above is not accurate, we'd not prevent the crash with
this change.. that needs separate fix
jirka
> >
> > Should this commit include a Fixes tag? The suggested tag would be:
> >
> > Fixes: e21aa341785c ("bpf: Fix fexit trampoline.")
>
> right, I think I'll send separate fix for current code,
> to have this fixed earlier
>
> jirka
>
> >
> >
> > ---
> > AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> > See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
> >
> > CI run summary: https://github.com/kernel-patches/bpf/actions/runs/24583317711
>
^ permalink raw reply
* Re: [PATCH v6] tracing/eprobes: Allow use of BTF names to dereference pointers
From: Masami Hiramatsu @ 2026-05-26 0:09 UTC (permalink / raw)
To: Steven Rostedt
Cc: LKML, Linux trace kernel, Masami Hiramatsu, Mathieu Desnoyers,
Mark Rutland, Peter Zijlstra, Namhyung Kim, Takaya Saeki,
Douglas Raillard, Tom Zanussi, Andrew Morton, Thomas Gleixner,
Ian Rogers, Jiri Olsa
In-Reply-To: <20260521225033.56458336@fedora>
On Thu, 21 May 2026 22:50:33 -0400
Steven Rostedt <rostedt@kernel.org> wrote:
> @@ -640,7 +673,7 @@ static int parse_btf_arg(char *varname,
> int i, is_ptr, ret;
> u32 tid;
>
> - if (WARN_ON_ONCE(!ctx->funcname))
> + if (WARN_ON_ONCE(!ctx->funcname && !(ctx->flags & TPARG_FL_TEVENT)))
> return -EINVAL;
>
> is_ptr = split_next_field(varname, &field, ctx);
> @@ -653,6 +686,20 @@ static int parse_btf_arg(char *varname,
> return -EOPNOTSUPP;
> }
>
> + if (ctx->flags & TPARG_FL_TEVENT) {
> + int ret;
nit: parse_btf_arg already declared @ret. So we don't need this.
Thanks,
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH] rethook: Use tsk->on_cpu to check task execution state
From: Masami Hiramatsu @ 2026-05-26 3:37 UTC (permalink / raw)
To: Tengda Wu
Cc: Steven Rostedt, Mathieu Desnoyers, Alexei Starovoitov,
linux-trace-kernel, linux-kernel
In-Reply-To: <20260525132253.1889726-1-wutengda@huaweicloud.com>
On Mon, 25 May 2026 21:22:53 +0800
Tengda Wu <wutengda@huaweicloud.com> wrote:
> When a task calls schedule() to yield the CPU, its state remains
> TASK_RUNNING, but its stack is frozen and safe to walk.
>
> Replace task_is_running(tsk) with tsk->on_cpu to avoid overly
> conservative rejections.
Please see the Sashiko's comment.
https://sashiko.dev/#/patchset/20260525132253.1889726-1-wutengda%40huaweicloud.com
When calling Unwind on a task other than the current, IMHO, it is
the responsibility of the caller of this function to ensure that the
stack trace of that task is safe.
We also should not use tsk->on_cpu, but should use task_on_cpu(tsk).
BTW, should task_on_cpu() use READ_ONCE() etc?
wait_task_inactive() seems a bit fragile.
Thanks,
>
> Fixes: 54ecbe6f1ed5 ("rethook: Add a generic return hook")
> Signed-off-by: Tengda Wu <wutengda@huaweicloud.com>
> ---
> kernel/trace/rethook.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/trace/rethook.c b/kernel/trace/rethook.c
> index 5a8bdf88999a..bd5e5f455e85 100644
> --- a/kernel/trace/rethook.c
> +++ b/kernel/trace/rethook.c
> @@ -250,7 +250,7 @@ unsigned long rethook_find_ret_addr(struct task_struct *tsk, unsigned long frame
> if (WARN_ON_ONCE(!cur))
> return 0;
>
> - if (tsk != current && task_is_running(tsk))
> + if (tsk != current && tsk->on_cpu)
> return 0;
>
> do {
> --
> 2.34.1
>
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCHv2] trace: allocate fields with elt struct
From: Masami Hiramatsu @ 2026-05-26 4:43 UTC (permalink / raw)
To: Rosen Penev, Steven Rostedt
Cc: linux-trace-kernel, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, open list:TRACING
In-Reply-To: <20260522212627.12406-1-rosenp@gmail.com>
Hi,
Sashiko made 2 comments.
https://sashiko.dev/#/patchset/20260522212627.12406-1-rosenp%40gmail.com
On Fri, 22 May 2026 14:26:27 -0700
Rosen Penev <rosenp@gmail.com> wrote:
> > diff --git a/kernel/trace/tracing_map.c b/kernel/trace/tracing_map.c
> > index 0dd7927df22ac..196a7b0be99df 100644
> > --- a/kernel/trace/tracing_map.c
> > +++ b/kernel/trace/tracing_map.c
> [ ... ]
> > @@ -125,32 +125,32 @@ u64 tracing_map_read_var_once(struct tracing_map_elt *elt, unsigned int i)
> [ ... ]
> > #define DEFINE_TRACING_MAP_CMP_FN(type) \
> > -static int tracing_map_cmp_##type(void *val_a, void *val_b) \
> > +static int tracing_map_cmp_##type(const void *val_a, const void *val_b) \
> > { \
> > - type a = (type)(*(u64 *)val_a); \
> > - type b = (type)(*(u64 *)val_b); \
> > + type a = (type)(*(const u64 *)val_a); \
> > + type b = (type)(*(const u64 *)val_b); \
> > \
> > return (a > b) ? 1 : ((a < b) ? -1 : 0); \
> > }
> This is a pre-existing issue, but does unconditionally reading 8 bytes
> via the u64 cast cause unaligned access exceptions on architectures that
> do not support them?
> Additionally, for fields near the end of the dynamically allocated elt->key
> buffer, can this trigger KASAN slab-out-of-bounds reads?
> Also, on big-endian architectures, reading a smaller integer as a 64-bit
> value and casting it down extracts the least-significant bytes rather than
> the correct field value. Could this result in completely incorrect sorting
> for small types?
Steve, it seems this comes from your commit 106f41f5a302 ("tracing: Have
the histogram compare functions convert to u64 first").
I think neither of them is a problem, but could you check it?
> > diff --git a/kernel/trace/tracing_map.h b/kernel/trace/tracing_map.h
> > index 99c37eeebc161..ed64136782d80 100644
> > --- a/kernel/trace/tracing_map.h
> > +++ b/kernel/trace/tracing_map.h
> [ ... ]
> > @@ -137,11 +137,11 @@ struct tracing_map_field {
> >
> > struct tracing_map_elt {
> > struct tracing_map *map;
> > - struct tracing_map_field *fields;
> > atomic64_t *vars;
> > bool *var_set;
> > void *key;
> > void *private_data;
> > + struct tracing_map_field fields[];
> > };
>
> Is it safe to add a flexible array member to struct tracing_map_elt when it
> is embedded by value in the middle of struct track_data?
> kernel/trace/trace_events_hist.c:struct track_data {
> ...
> struct tracing_map_elt elt;
> ...
> struct action_data *action_data;
> struct hist_trigger_data *hist_data;
> };
> Embedding a struct with a flexible array member in the middle of another
> struct violates C standard constraints. Does this trigger compiler
> warnings (such as -Wflex-array-member-not-at-end on modern compilers) or
> break bounds computations for FORTIFY_SOURCE?
Yeah, from this reason, this is is not acceptable.
To fix this issue, we need to refactor the trace_events_hist.c,
because track_data only uses tracing_map_elt as a placeholder
of private_data.
Thank you,
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH v21 8/9] ring-buffer: Show persistent buffer dropped events in trace file
From: Masami Hiramatsu @ 2026-05-26 5:06 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-kernel, linux-trace-kernel, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, Andrew Morton, Ian Rogers
In-Reply-To: <20260522171052.006276604@kernel.org>
On Fri, 22 May 2026 13:09:05 -0400
Steven Rostedt <rostedt@kernel.org> wrote:
> @@ -7187,6 +7190,8 @@ int ring_buffer_read_page(struct trace_buffer *buffer,
> local_set(&reader->entries, 0);
> reader->read = 0;
> data_page->data = dpage;
> + if (!missed_events && rb_data_page_commit(dpage) & RB_MISSED_EVENTS)
> + missed_events = -1;
>
> /*
> * Use the real_end for the data size,
> @@ -7204,10 +7209,12 @@ int ring_buffer_read_page(struct trace_buffer *buffer,
> * Set a flag in the commit field if we lost events
> */
> if (missed_events) {
> - /* If there is room at the end of the page to save the
> + /*
> + * If there is room at the end of the page to save the
> * missed events, then record it there.
> */
> - if (buffer->subbuf_size - commit >= sizeof(missed_events)) {
> + if (missed_events > 0 &&
> + buffer->subbuf_size - commit >= sizeof(missed_events)) {
> memcpy(&dpage->data[commit], &missed_events,
> sizeof(missed_events));
> local_add(RB_MISSED_STORED, &dpage->commit);
After this line, we "add" RB_MISSED_EVENTS instead of set.
In this case, does it clear the RB_MISSED_EVENTS bit because
it already sets RB_MISSED_EVENTS.
commit += sizeof(missed_events);
}
local_add(RB_MISSED_EVENTS, &bpage->commit);
^^^ here.
Thanks,
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 2/2] serial: qcom-geni: Add tracepoints for Qualcomm GENI serial driver
From: Praveen Talari @ 2026-05-26 5:06 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers, Jiri Slaby,
Konrad Dybcio, linux-kernel, linux-trace-kernel, linux-arm-msm,
linux-serial, Mukesh Kumar Savaliya, Aniket Randive,
chandana.chiluveru, jyothi.seerapu
In-Reply-To: <2026052258-scrooge-friction-fe21@gregkh>
Hi
On 22-05-2026 15:17, Greg Kroah-Hartman wrote:
> On Mon, May 18, 2026 at 11:26:56PM +0530, Praveen Talari wrote:
>> Add tracing to the Qualcomm GENI serial driver to improve runtime
>> observability.
>>
>> Trace hooks are added at key points including termios and clock
>> configuration, manual control get/set, interrupt handling, and data
>> TX/RX paths.
>>
>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>> Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
>> ---
>> v2->v3:
>> - Updated commit text(removed example as it was available on cover
>> letter).
>> ---
>> drivers/tty/serial/qcom_geni_serial.c | 27 +++++++++++++++++++++++----
>> 1 file changed, 23 insertions(+), 4 deletions(-)
> This patch did not apply to my tree :(
Do you mean these patches are not applied cleanly?If yes, i will push on
linux-next tip.
Thanks,
Praveen Talari
^ permalink raw reply
* Re: [PATCH v21 0/9] ring-buffer: Making persistent ring buffers robust
From: Masami Hiramatsu @ 2026-05-26 5:17 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-kernel, linux-trace-kernel, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, Andrew Morton, Ian Rogers
In-Reply-To: <20260522170857.263969486@kernel.org>
On Fri, 22 May 2026 13:08:57 -0400
Steven Rostedt <rostedt@kernel.org> wrote:
> This is to make the persistent ring buffer more robust when sub-buffers
> are detected to be corrupted. Instead of invalidating the entire buffer,
> just invalidate the individual sub-buffers.
>
> I started with Masami's patches and modified some from Sashiko reviews.
> I added a few patches to display the dropped events when the persistent
> ring buffers validation checks found sub-buffers were dropped due to being
> corrupted data.
It seems that Sashiko still marks it "Incompleted".
Maybe we need base-commit: tag in this cover mail?
I also guess that this series does not use "In-Reply-To:" but
only uses "References:" tag in the mail header. I guess
Sashiko's mail header parser missed it.
Thanks,
>
> Changes since v20: https://lore.kernel.org/all/20260520184938.749337513@kernel.org/
>
> - squashed the fix for max_loops in rb_iter_peek()
>
> - Still process reader page if head page fails validation (Sashiko)
>
> - Removed left over printk() (Masami Hiramatsu)
>
>
> Masami Hiramatsu (Google) (6):
> ring-buffer: Skip invalid sub-buffers when validating persistent ring buffer
> ring-buffer: Skip invalid sub-buffers when rewinding persistent ring buffer
> ring-buffer: Add persistent ring buffer invalid-page inject test
> ring-buffer: Show commit numbers in buffer_meta file
> ring-buffer: Cleanup persistent ring buffer validation
> ring-buffer: Cleanup buffer_data_page related code
>
> Steven Rostedt (3):
> ring-buffer: Have dropped subbuffers be persistent across reboots
> ring-buffer: Show persistent buffer dropped events in trace file
> ring-buffer: Show persistent buffer dropped events in trace_pipe file
>
> ----
> include/linux/ring_buffer.h | 1 +
> kernel/trace/Kconfig | 34 +++
> kernel/trace/ring_buffer.c | 543 +++++++++++++++++++++++++++++---------------
> kernel/trace/trace.c | 4 +
> 4 files changed, 402 insertions(+), 180 deletions(-)
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH v21 9/9] ring-buffer: Show persistent buffer dropped events in trace_pipe file
From: Masami Hiramatsu @ 2026-05-26 6:06 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-kernel, linux-trace-kernel, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, Andrew Morton, Ian Rogers
In-Reply-To: <20260522171052.156419479@kernel.org>
On Fri, 22 May 2026 13:09:06 -0400
Steven Rostedt <rostedt@kernel.org> wrote:
> From: Steven Rostedt <rostedt@goodmis.org>
>
> When the persistent ring buffer is validated on boot up, if a subbuffer is
> deemed invalid, it resets the buffer and continues. Have the code preserve
> the RB_MISSED_EVENTS flag in the commit portion of the subbuffer header
> and pass that back so that the trace_pipe file can show the missed events
> like the trace file does.
>
> For example:
>
> <...>-1242 [005] d.... 4429.120116: page_fault_user: address=0x7ffaebb6e728 ip=0x7ffaeb9d4960 error_code=0x7
> <...>-1242 [005] ..... 4429.120124: mm_page_alloc: page=00000000055254f3 pfn=0x1373bd order=0 migratetype=1 gfp_flags=GFP_HIGHUSER_MOVABLE|__GFP_COMP
> <...>-1242 [005] d..2. 4429.120132: tlb_flush: pages:1 reason:local MM shootdown (3)
> CPU:5 [LOST EVENTS]
> <...>-1242 [005] d.... 4429.120661: page_fault_user: address=0x55ba7c2d0944 ip=0x55ba7c20cd02 error_code=0x7
> <...>-1242 [005] ..... 4429.120669: mm_page_alloc: page=0000000005a02500 pfn=0x12b6e4 order=0 migratetype=1 gfp_flags=GFP_HIGHUSER_MOVABLE|__GFP_COMP
> <...>-1242 [005] d..2. 4429.120680: tlb_flush: pages:1 reason:local MM shootdown (3)
>
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> ---
> Changes since v20: https://patch.msgid.link/20260520185018.470465795@kernel.org
>
Looks good to me.
Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Thanks,
> - Removed left over printk() (Masami Hiramatsu)
>
> kernel/trace/ring_buffer.c | 56 +++++++++++++++++++++++---------------
> 1 file changed, 34 insertions(+), 22 deletions(-)
>
> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> index 988915f035c7..910f6b3adf74 100644
> --- a/kernel/trace/ring_buffer.c
> +++ b/kernel/trace/ring_buffer.c
> @@ -5801,6 +5801,7 @@ __rb_get_reader_page(struct ring_buffer_per_cpu *cpu_buffer)
> struct buffer_page *reader = NULL;
> unsigned long overwrite;
> unsigned long flags;
> + int missed_events = 0;
> int nr_loops = 0;
> bool ret;
>
> @@ -5901,6 +5902,9 @@ __rb_get_reader_page(struct ring_buffer_per_cpu *cpu_buffer)
> if (!ret)
> goto spin;
>
> + if (rb_page_commit(reader) & RB_MISSED_EVENTS)
> + missed_events = -1;
> +
> if (cpu_buffer->ring_meta)
> rb_update_meta_reader(cpu_buffer, reader);
>
> @@ -5965,6 +5969,8 @@ __rb_get_reader_page(struct ring_buffer_per_cpu *cpu_buffer)
> */
> smp_rmb();
>
> + if (!cpu_buffer->lost_events)
> + cpu_buffer->lost_events = missed_events;
>
> return reader;
> }
> @@ -7066,6 +7072,7 @@ int ring_buffer_read_page(struct trace_buffer *buffer,
> struct buffer_page *reader;
> long missed_events;
> unsigned int commit;
> + unsigned int size;
> unsigned int read;
> u64 save_timestamp;
> bool force_memcpy;
> @@ -7101,7 +7108,8 @@ int ring_buffer_read_page(struct trace_buffer *buffer,
> event = rb_reader_event(cpu_buffer);
>
> read = reader->read;
> - commit = rb_page_size(reader);
> + commit = rb_page_commit(reader);
> + size = rb_page_size(reader);
>
> /* Check if any events were dropped */
> missed_events = cpu_buffer->lost_events;
> @@ -7115,13 +7123,14 @@ int ring_buffer_read_page(struct trace_buffer *buffer,
> * we must copy the data from the page to the buffer.
> * Otherwise, we can simply swap the page with the one passed in.
> */
> - if (read || (len < (commit - read)) ||
> + if (read || (len < (size - read)) ||
> cpu_buffer->reader_page == cpu_buffer->commit_page ||
> force_memcpy) {
> struct buffer_data_page *rpage = cpu_buffer->reader_page->page;
> unsigned int rpos = read;
> unsigned int pos = 0;
> - unsigned int size;
> + unsigned int event_size;
> + unsigned int flags = 0;
>
> /*
> * If a full page is expected, this can still be returned
> @@ -7130,19 +7139,22 @@ int ring_buffer_read_page(struct trace_buffer *buffer,
> * the reader page.
> */
> if (full &&
> - (!read || (len < (commit - read)) ||
> + (!read || (len < (size - read)) ||
> cpu_buffer->reader_page == cpu_buffer->commit_page))
> return -1;
>
> - if (len > (commit - read))
> - len = (commit - read);
> + if (len > (size - read))
> + len = (size - read);
>
> /* Always keep the time extend and data together */
> - size = rb_event_ts_length(event);
> + event_size = rb_event_ts_length(event);
>
> - if (len < size)
> + if (len < event_size)
> return -1;
>
> + if (commit & RB_MISSED_EVENTS)
> + flags = RB_MISSED_EVENTS;
> +
> /* save the current timestamp, since the user will need it */
> save_timestamp = cpu_buffer->read_stamp;
>
> @@ -7154,25 +7166,25 @@ int ring_buffer_read_page(struct trace_buffer *buffer,
> * one or two events.
> * We have already ensured there's enough space if this
> * is a time extend. */
> - size = rb_event_length(event);
> - memcpy(dpage->data + pos, rpage->data + rpos, size);
> + event_size = rb_event_length(event);
> + memcpy(dpage->data + pos, rpage->data + rpos, event_size);
>
> - len -= size;
> + len -= event_size;
>
> rb_advance_reader(cpu_buffer);
> rpos = reader->read;
> - pos += size;
> + pos += event_size;
>
> - if (rpos >= commit)
> + if (rpos >= event_size)
> break;
>
> event = rb_reader_event(cpu_buffer);
> /* Always keep the time extend and data together */
> - size = rb_event_ts_length(event);
> - } while (len >= size);
> + event_size = rb_event_ts_length(event);
> + } while (len >= event_size);
>
> /* update dpage */
> - local_set(&dpage->commit, pos);
> + local_set(&dpage->commit, pos | flags);
> dpage->time_stamp = save_timestamp;
>
> /* we copied everything to the beginning */
> @@ -7204,7 +7216,7 @@ int ring_buffer_read_page(struct trace_buffer *buffer,
>
> cpu_buffer->lost_events = 0;
>
> - commit = rb_data_page_commit(dpage);
> + size = rb_data_page_size(dpage);
> /*
> * Set a flag in the commit field if we lost events
> */
> @@ -7214,11 +7226,11 @@ int ring_buffer_read_page(struct trace_buffer *buffer,
> * missed events, then record it there.
> */
> if (missed_events > 0 &&
> - buffer->subbuf_size - commit >= sizeof(missed_events)) {
> - memcpy(&dpage->data[commit], &missed_events,
> + buffer->subbuf_size - size >= sizeof(missed_events)) {
> + memcpy(&dpage->data[size], &missed_events,
> sizeof(missed_events));
> local_add(RB_MISSED_STORED, &dpage->commit);
> - commit += sizeof(missed_events);
> + size += sizeof(missed_events);
> }
> local_add(RB_MISSED_EVENTS, &dpage->commit);
> }
> @@ -7226,8 +7238,8 @@ int ring_buffer_read_page(struct trace_buffer *buffer,
> /*
> * This page may be off to user land. Zero it out here.
> */
> - if (commit < buffer->subbuf_size)
> - memset(&dpage->data[commit], 0, buffer->subbuf_size - commit);
> + if (size < buffer->subbuf_size)
> + memset(&dpage->data[size], 0, buffer->subbuf_size - size);
>
> return read;
> }
> --
> 2.53.0
>
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH] tracing: Disable KCOV instrumentation for trace_irqsoff.o
From: Masami Hiramatsu @ 2026-05-26 6:07 UTC (permalink / raw)
To: Karl Mehltretter
Cc: Steven Rostedt, Mathieu Desnoyers, Dmitry Vyukov,
Andrey Konovalov, Marco Elver, kasan-dev, linux-trace-kernel,
linux-kernel
In-Reply-To: <20260525170428.67211-1-kmehltretter@gmail.com>
On Mon, 25 May 2026 19:04:28 +0200
Karl Mehltretter <kmehltretter@gmail.com> wrote:
> When KCOV runs its boot selftest with whole-kernel instrumentation
> enabled, it sets current->kcov_mode to KCOV_MODE_TRACE_PC without
> installing a coverage area. Any instrumented code accepted as task-context
> coverage in that window dereferences current->kcov_area and crashes.
>
> On ARMv5 Versatile PB with CONFIG_KCOV_SELFTEST=y,
> CONFIG_KCOV_INSTRUMENT_ALL=y and CONFIG_IRQSOFF_TRACER=y, boot hits a
> NULL pointer fault during the selftest:
>
> kcov: running self test
> Internal error: Oops: 5 [#1] ARM
> PC is at __sanitizer_cov_trace_pc+0x4c/0x90
> Kernel panic - not syncing: Fatal exception
>
> A diagnostic run showed the unwanted coverage comes from the IRQs-off
> tracer callbacks reached from ARM IRQ entry before hardirq context is
> visible to KCOV:
>
> __sanitizer_cov_trace_pc from tracer_hardirqs_off+0x18/0x1cc
> tracer_hardirqs_off from trace_hardirqs_off+0x34/0x54
> trace_hardirqs_off from __irq_svc+0x58/0xb0
> __irq_svc from kcov_init+0x7c/0xdc
>
> and similarly through tracer_hardirqs_on().
>
> trace_preemptirq.o is already excluded because this tracing path can run
> from early interrupt code and produce coverage unrelated to syscall
> inputs. Exclude trace_irqsoff.o as well, instead of requiring users to
> turn off CONFIG_KCOV_INSTRUMENT_ALL=y, which is the default whole-kernel
> KCOV mode.
>
> With the exclusion in place, the same ARMv5 Versatile PB QEMU test boots
> through the KCOV selftest and reaches userspace.
>
> Tested on ARMv5 Versatile PB QEMU with CONFIG_KCOV_SELFTEST=y,
> CONFIG_KCOV_INSTRUMENT_ALL=y and CONFIG_IRQSOFF_TRACER=y.
Thanks for reporting. This looks good to me for a mitigation.
BTW, I could not reproduce the bug with above configs.
Is this only for arm32?
>
> Assisted-by: Codex:gpt-5
> Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
> ---
> kernel/trace/Makefile | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile
> index 8d3d96e847d8..f934ff586bd4 100644
> --- a/kernel/trace/Makefile
> +++ b/kernel/trace/Makefile
> @@ -48,9 +48,10 @@ ifdef CONFIG_GCOV_PROFILE_FTRACE
> GCOV_PROFILE := y
> endif
>
> -# Functions in this file could be invoked from early interrupt
> -# code and produce random code coverage.
> +# Functions in these files can run from IRQ entry before hardirq context
> +# is visible to KCOV, and produce coverage unrelated to syscall inputs.
> KCOV_INSTRUMENT_trace_preemptirq.o := n
> +KCOV_INSTRUMENT_trace_irqsoff.o := n
>
> CFLAGS_bpf_trace.o := -I$(src)
>
> --
> 2.39.5 (Apple Git-154)
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH mm-unstable v18 11/14] mm/khugepaged: Introduce mTHP collapse support
From: Wei Yang @ 2026-05-26 6:57 UTC (permalink / raw)
To: Nico Pache, Andrew Morton
Cc: linux-doc, linux-kernel, linux-mm, linux-trace-kernel, aarcange,
anshuman.khandual, apopple, baohua, baolin.wang, byungchul,
catalin.marinas, cl, corbet, dave.hansen, david, dev.jain, gourry,
hannes, hughd, jack, jackmanb, jannh, jglisse, joshua.hahnjy, kas,
lance.yang, liam, ljs, mathieu.desnoyers, matthew.brost, mhiramat,
mhocko, peterx, pfalcato, rakie.kim, raquini, rdunlap,
richard.weiyang, rientjes, rostedt, rppt, ryan.roberts, shivankg,
sunnanyong, surenb, thomas.hellstrom, tiwai, usamaarif642, vbabka,
vishal.moola, wangkefeng.wang, will, willy, yang, ying.huang, ziy,
zokeefe
In-Reply-To: <20260525121041.2f2508a4f627c338cddd837a@linux-foundation.org>
On Mon, May 25, 2026 at 12:10:41PM -0700, Andrew Morton wrote:
>On Mon, 25 May 2026 08:15:53 -0600 Nico Pache <npache@redhat.com> wrote:
>
>> Can you please append the following fixup that reverts one of the
>> changes requested in V17. The issue with the change is described
>> below.
>
>OK. fyi, what I received was badly mangled: wordwrapping, tabs messed
>up, etc.
>
>Here's my reconstruction:
>
Hi, Nico
I tried to reply your mail, but found it has some encoding problem, so reply
here.
>
>Author: Nico Pache <npache@redhat.com>
>Subject: fix potential use-after-free of vma in mthp_collapse()
>Date: Mon May 25 07:38:59 2026 -0600
>
>Between V17 and v18, one reviewer (Wei) brought up that we are not doing
>the uffd-armed check until deep in the collapse operation. While not
>functionally incorrect, it can lead to unnecessary work.
So we decide to tolerate the behavioral change?
>
>We optimized this by passing the vma variable to mthp_collapse() and using
>the collapse_max_ptes_none() function to check the state of uffd-armed
>preventing the wasted work later in the collapse.
>
>mthp_collapse() is called after mmap_read_unlock(), so the vma pointer can
>become stale. Remove the vma parameter and pass NULL to
>collapse_max_ptes_none() instead.
>
>Link: https://lore.kernel.org/2b2cda8c-358a-4a5c-989c-ae42593ef2ea@redhat.com
>Signed-off-by: Nico Pache <npache@redhat.com>
>...
>
> mm/khugepaged.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
>--- a/mm/khugepaged.c~mm-khugepaged-introduce-mthp-collapse-support-fix
>+++ a/mm/khugepaged.c
>@@ -1502,9 +1502,9 @@ static unsigned int collapse_mthp_count_
> * If a collapse is permitted, we attempt to collapse the PTE range into a
> * mTHP.
> */
>-static int mthp_collapse(struct mm_struct *mm, struct vm_area_struct *vma,
>- unsigned long address, int referenced, int unmapped,
>- struct collapse_control *cc, unsigned long enabled_orders)
>+static int mthp_collapse(struct mm_struct *mm, unsigned long address,
>+ int referenced, int unmapped, struct collapse_control *cc,
>+ unsigned long enabled_orders)
> {
> unsigned int nr_occupied_ptes, nr_ptes, max_ptes_none;
> int collapsed = 0, stack_size = 0;
>@@ -1524,7 +1524,7 @@ static int mthp_collapse(struct mm_struc
> if (!test_bit(order, &enabled_orders))
> goto next_order;
>
>- max_ptes_none = collapse_max_ptes_none(cc, vma, order);
>+ max_ptes_none = collapse_max_ptes_none(cc, NULL, order);
>
> nr_occupied_ptes = collapse_mthp_count_present(cc, offset,
> nr_ptes);
>@@ -1749,7 +1749,7 @@ out_unmap:
> if (result == SCAN_SUCCEED) {
> /* collapse_huge_page expects the lock to be dropped before calling */
> mmap_read_unlock(mm);
>- nr_collapsed = mthp_collapse(mm, vma, start_addr, referenced,
>+ nr_collapsed = mthp_collapse(mm, start_addr, referenced,
> unmapped, cc, enabled_orders);
> /* mmap_lock was released above, set lock_dropped */
> *lock_dropped = true;
>_
--
Wei Yang
Help you, Help me
^ permalink raw reply
* Re: [PATCH mm-hotfixes-unstable v18 00/14] khugepaged: add mTHP collapse support
From: Lorenzo Stoakes @ 2026-05-26 8:14 UTC (permalink / raw)
To: Nico Pache
Cc: linux-doc, akpm, linux-kernel, linux-mm, linux-trace-kernel,
aarcange, anshuman.khandual, apopple, baohua, baolin.wang,
byungchul, catalin.marinas, cl, corbet, dave.hansen, david,
dev.jain, gourry, hannes, hughd, jack, jackmanb, jannh, jglisse,
joshua.hahnjy, kas, lance.yang, liam, mathieu.desnoyers,
matthew.brost, mhiramat, mhocko, peterx, pfalcato, rakie.kim,
raquini, rdunlap, richard.weiyang, rientjes, rostedt, rppt,
ryan.roberts, shivankg, sunnanyong, surenb, thomas.hellstrom,
tiwai, usamaarif642, vbabka, vishal.moola, wangkefeng.wang, will,
willy, yang, ying.huang, ziy, zokeefe
In-Reply-To: <ahCFIDuyrvEfB9jv@lucifer>
Nico,
While I stand by the below, and we very well might wish to delay this until
the next cycle, I will try to take some time to go through this myself as
soon as I am able.
If David's happy with it for this cycle, and I don't find anything too
crazy, then it's not impossible we could still move forward with it now.
My only aim here is to avoid rushing something in that might have
unexpected changes or issues in it, given how late in the cycle we are :)
Cheers, Lorenzo
On Fri, May 22, 2026 at 06:12:59PM +0100, Lorenzo Stoakes wrote:
> On Fri, May 22, 2026 at 10:31:41AM -0600, Nico Pache wrote:
> > On Fri, May 22, 2026 at 10:20 AM Lorenzo Stoakes <ljs@kernel.org> wrote:
> > > There's some kind of confusion here.
> > >
> > > This series isn't suited for 7.2.
> > >
> > > Sorry but Zi's series, unless it depends on functionality here, will have
> > > to be rebased.
> > >
> > > People have been at conferences, people have been on leave, I've had to
> > > pace myself for health reasons and it seems there's been more than simply
> > > review comment-based changes happening here.
> > >
> > > (Again I strongly encourage, at this stage, to ONLY be making changes based
> > > on review, not adding ANYTHING else or changing ANYTHING else to avoid
> > > delays :)
> >
> > All the changes are based on review points. Very small changes in this
> > version; the largest being the one that you specifically argeed too.
>
> 16->17
>
> Documentation/admin-guide/mm/transhuge.rst | 24 +++++-------------
> include/linux/khugepaged.h | 7 ++---
> include/trace/events/huge_memory.h | 3 ++-
> mm/huge_memory.c | 2 +-
> mm/khugepaged.c | 168 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------------------------------------------------
> mm/vma.c | 6 ++---
> tools/testing/vma/include/stubs.h | 3 ++-
> 7 files changed, 103 insertions(+), 110 deletions(-)
>
> 17->18
>
> Documentation/admin-guide/mm/transhuge.rst | 5 +++--
> include/trace/events/huge_memory.h | 3 +--
> mm/khugepaged.c | 121 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----------------------------------------------------------
> 3 files changed, 66 insertions(+), 63 deletions(-)
>
> These are not small 'very small changes'.
>
> We're nearly at rc-5, and this is a major, invasive, dangerous change that
> we have to get right.
>
> You've also made changes unrelated to review, repeatedly, throughout this
> process, which as I've told you, is causing delays.
>
> You've also throughout the review of this series done stuff like make MAJOR
> changes to things and _kept review tags_.
>
> You're forcing us to use git range-diff etc. to forensically check that the
> series is what is claimed.
>
> Dude I mean you switched to using // comment style which is not used in mm
> anywhere for instance? Don't do things like that and complain about
> delays. Honestly.
>
> Also, again, LSF happened. Other confeerences happened. Bandwidth is
> reduced.
>
> So again, I'm sorry, but you've been hit with some bad luck here.
>
> I really wanted this in for 7.2, and I feel bad that we couldn't make it,
> but you're also doing thing that's making it difficult for us.
>
> I've spent double-digits hours on your series, and I've also had work
> pushed out becasue of that leading me to work evenings and weekends as a
> result.
>
> And I'm not even going to get any credit for it :))
>
> So while I sypmathise, really, please have empathy and realise it goes both
> ways, please.
>
> I'm not being mean for the sake of it, I'm pushing back because I feel this
> is not at a stage where I'd feel confident in this being merged at this
> time.
>
> And it's very much a regret, as I _really_ wanted us to have it in this
> time. But life and circumstances and the issues mentioned above have
> intervened, sadly.
>
> >
> > >
> > > Also - shouldn't mm-unstable already have mm-hotfixes-unstable in it?
> > >
> > > I think in mm-next we will have an stable branch, that everything is
> > > based on, where things go once review is complete and things are mergeable.
> > >
> > > And a separate hotfixes branch based on Linus's tree.
> > >
> > > That would avoid issues like this :)
> >
> > Im sorry im new to this, but I really dont think this tiny error, and
> > something that I'd confirmed with Andrew beforehand deserves NAKing
> > and defering it. Ive worked through my PTO to clean up some of these
> > review nits just to get it in 7.2. I even through this through my
> > rounds of testing today before resending.
>
> The issue wasn't the error (though it wasn't tiny...!), it's the state of
> review. There was fresh review comments from a few days ago, and there's
> big diffs between revisions.
>
> You've also made unrelated changes as you have done throughout the series.
>
> As I said above, I'm sorry that you spent time in your PTO on this, but we
> cannot rush this in when things are not clearly ready yet, and I am not
> confident in this being ready at this stage.
>
> >
> > >
> > > >
> > > > The intent wasn't that this is a hotfix, just that this was the
> > > > closest base before the v17 that is already in the tree.
> > >
> > > The convention is that [PATCH ... <branch>] indicates the target of the
> > > changes. Putting the hotfixes branch there implies it's a hotfix.
> >
> > Sorry I thought the <branch> was what base you used.
>
> I mean, sure there's clearly confusion here as you sent [PATCH 7.2 v16 ...]
> (against an unreleased kernel version) then a branch specifier then the
> hotfixes one...
>
> Anyway sure, it's fine, I've made vastly more dumb mistakes than that
> myself, nobody minds, but it's concerning as by convention [PATCH
> ... <mm->hotfixes<whatever>] generally is taken to mean 'please rush this
> to hotfixes!' :)
>
> So be careful with that please!
>
> >
> > >
> > > So please be careful with that in future :)
> >
> > Yes will do for sure.
>
> Thanks!
>
> >
> > >
> > > >
> > > > Sorry for the confusion, hopefully Andrew can still apply it to the
> > > > correct tree.
> > >
> > > I'm not even sure what's best for that at this stage given we have
> > > conflicts and this has to be delayed until 7.3.
> > >
> > > I wonder if given that we should not have this in mm-unstable at all and
> > > just wait it out until the next cycle begins? Review can happen
> > > concurrently.
> >
> > I still dont see why this has to be deferred, I was working with
> > Andrew to prevent merge headaches.
>
> I've explained the why above, and David and I co-maintain THP so I feel
> that ultimately given the blood, sweat and tears we've put into THP review
> we ought to have some input on this :)
>
> Thanks, Lorenzo
^ permalink raw reply
* Re: [PATCHv3 04/12] uprobes/x86: Move optimized uprobe from nop5 to nop10
From: Peter Zijlstra @ 2026-05-26 9:19 UTC (permalink / raw)
To: Jiri Olsa
Cc: Andrii Nakryiko, Oleg Nesterov, Ingo Molnar, Masami Hiramatsu,
Andrii Nakryiko, bpf, linux-trace-kernel
In-Reply-To: <ahDIVTM5WfVqiYE6@krava>
On Fri, May 22, 2026 at 11:19:17PM +0200, Jiri Olsa wrote:
> On Fri, May 22, 2026 at 11:50:44AM -0700, Andrii Nakryiko wrote:
> > On Thu, May 21, 2026 at 5:44 AM Jiri Olsa <jolsa@kernel.org> wrote:
> > >
> > > Andrii reported an issue with optimized uprobes [1] that can clobber
> > > redzone area with call instruction storing return address on stack
> > > where user code may keep temporary data without adjusting rsp.
> > >
> > > Fixing this by moving the optimized uprobes on top of 10-bytes nop
> > > instruction, so we can squeeze another instruction to escape the
> > > redzone area before doing the call, like:
> > >
> > > lea -0x80(%rsp), %rsp
> > > call tramp
> > >
> > > Note the lea instruction is used to adjust the rsp register without
> > > changing the flags.
> > >
> > > We use nop10 and following transofrmation to optimized instructions
> > > above and back as suggested by Peterz [2].
> > >
> > > Optimize path (int3_update_optimize):
> > >
> > > 1) Initial state after set_swbp() installed the uprobe:
> > > cc 2e 0f 1f 84 00 00 00 00 00
> > >
> > > From offset 0 this is INT3 followed by the tail of the original
> > > 10-byte NOP.
> > >
> > > 2) Trap the call slot before rewriting the NOP tail:
> > > cc 2e 0f 1f 84 [cc] 00 00 00 00
> > >
> > > From offset 0 this traps on the uprobe INT3. A thread reaching
> > > offset 5 traps on the temporary INT3 instead of seeing a partially
> > > patched call.
> > >
> > > 3) Rewrite the LEA tail and call displacement, keeping both INT3 bytes:
> > > cc [8d 64 24 80] cc [d0 d1 d2 d3]
> > >
> > > From offset 0 and offset 5 this still traps. The bytes between
> > > them are not executable entry points while both traps are in place.
> > >
> > > 4) Restore the call opcode at offset 5:
> > > cc 8d 64 24 80 [e8] d0 d1 d2 d3
> > >
> > > From offset 0 this still traps. From offset 5 the instruction is
> > > the final CALL to the uprobe trampoline.
> > >
> >
> > I'm sorry if I'm slow, but I don't understand why we need that second
> > cc at offset 5? Isn't original nop10 processed by CPU as single
> > instruction? So it will either be at ip of nop10, or at ip+10, no? If
> > we trap at ip and in int3 handler +10 from there while we are
> > installing lea+call, why do we need cc on byte 5?
> >
> > I.e., I don't understand how CPU can end up being at ip+5 until we
> > finalize lea+call sequence? Can it?
>
> hum, so I though it's for the case when you do unoptimize+optimize,
> then you can have cpu executing the previous lea and hitting the int3
> on +5 offset.. but as pointed by Peter (and you) the call instruction
> never changes, so now I'm not sure why we need it
So I missed you did the second INT3 in my initial reading.
That second INT3 is absolutely required *IF* the CALL can ever change.
However Andrii pointed out that once the CALL is written, it will always
be the same CALL -- there is but the one trampoline, it doesn't move.
Therefore, the second INT3 is not strictly required.
Does this clarify?
^ permalink raw reply
* [PATCH] tracing: Fix field_var_str allocation errno
From: Yu Peng @ 2026-05-26 9:50 UTC (permalink / raw)
To: Steven Rostedt
Cc: Masami Hiramatsu, Mathieu Desnoyers, Tom Zanussi,
linux-trace-kernel, linux-kernel, Yu Peng
hist_trigger_elt_data_alloc() returns -EINVAL when the field_var_str
kcalloc() fails. Return -ENOMEM instead, matching the other allocation
failures in the function.
Fixes: c910db943d35 ("tracing: Dynamically allocate the per-elt hist_elt_data array")
Signed-off-by: Yu Peng <pengyu@kylinos.cn>
---
kernel/trace/trace_events_hist.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
index eb2c2bc8bc3d..17fe13e12a4f 100644
--- a/kernel/trace/trace_events_hist.c
+++ b/kernel/trace/trace_events_hist.c
@@ -1680,7 +1680,7 @@ static int hist_trigger_elt_data_alloc(struct tracing_map_elt *elt)
elt_data->field_var_str = kcalloc(n_str, sizeof(char *), GFP_KERNEL);
if (!elt_data->field_var_str) {
hist_elt_data_free(elt_data);
- return -EINVAL;
+ return -ENOMEM;
}
elt_data->n_field_var_str = n_str;
--
2.43.0
^ permalink raw reply related
* [PATCH] tracing: Use kstrdup_const() for constant hist field type
From: Yu Peng @ 2026-05-26 9:51 UTC (permalink / raw)
To: Steven Rostedt
Cc: Masami Hiramatsu, Mathieu Desnoyers, linux-trace-kernel,
linux-kernel, Yu Peng
The HIST_FIELD_FL_CONST path duplicates the literal "u64" type with
kstrdup(), then releases it through kfree_const().
Use kstrdup_const() instead, avoiding the allocation for a .rodata string
while keeping the matching free helper.
Signed-off-by: Yu Peng <pengyu@kylinos.cn>
---
kernel/trace/trace_events_hist.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
index eb2c2bc8bc3d..6ffe9f4720a0 100644
--- a/kernel/trace/trace_events_hist.c
+++ b/kernel/trace/trace_events_hist.c
@@ -1992,7 +1992,7 @@ static struct hist_field *create_hist_field(struct hist_trigger_data *hist_data,
if (flags & HIST_FIELD_FL_CONST) {
hist_field->fn_num = HIST_FIELD_FN_CONST;
hist_field->size = sizeof(u64);
- hist_field->type = kstrdup("u64", GFP_KERNEL);
+ hist_field->type = kstrdup_const("u64", GFP_KERNEL);
if (!hist_field->type)
goto free;
goto out;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH bpf-next v2 2/3] tracing: Expose tracepoint BTF ids via tracefs
From: Mykyta Yatsenko @ 2026-05-26 10:07 UTC (permalink / raw)
To: bpf, rostedt
Cc: Mykyta Yatsenko, linux-trace-kernel, Andrii Nakryiko,
Alexei Starovoitov
In-Reply-To: <20260518-generic_tracepoint-v2-2-b755a5cf67bb@meta.com>
Hi Steven,
Gentle ping on this patch from the series.
Since this part touches tracing, I’d appreciate your thoughts on the
tracing changes whenever you have a chance.
Thanks,
Mykyta
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox