* [PATCH] tracing/probes: Point the error offset correctly for eprobe argument error
From: Masami Hiramatsu (Google) @ 2026-05-25 2:21 UTC (permalink / raw)
To: Steven Rostedt, Shuah Khan
Cc: Masami Hiramatsu, Mathieu Desnoyers, linux-kernel,
linux-trace-kernel, linux-kselftest
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Fix to point the error offset correctly for eprobe argument error.
In the cleanup commit 1b8b0cd754cd ("tracing/probes: Move event parameter
fetching code to common parser"), due to incorrect backward compatibility
aimed at conforming to the test specifications, the error location was set
to 0 when a non-existent formal parameter was specified for Eprobe.
However, this should be corrected in both the test and the implementation
to point correct error position.
Fixes: 1b8b0cd754cd ("tracing/probes: Move event parameter fetching code to common parser")
Cc: stable@vger.kernel.org
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
---
kernel/trace/trace_probe.c | 2 --
.../test.d/dynevent/eprobes_syntax_errors.tc | 2 +-
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
index 39f040c863e8..695310571b08 100644
--- a/kernel/trace/trace_probe.c
+++ b/kernel/trace/trace_probe.c
@@ -957,8 +957,6 @@ static int parse_probe_vars(char *orig_arg, const struct fetch_type *t,
code->op = FETCH_OP_COMM;
return 0;
}
- /* backward compatibility */
- ctx->offset = 0;
goto inval;
}
diff --git a/tools/testing/selftests/ftrace/test.d/dynevent/eprobes_syntax_errors.tc b/tools/testing/selftests/ftrace/test.d/dynevent/eprobes_syntax_errors.tc
index 4f5e8c665156..2a680c086047 100644
--- a/tools/testing/selftests/ftrace/test.d/dynevent/eprobes_syntax_errors.tc
+++ b/tools/testing/selftests/ftrace/test.d/dynevent/eprobes_syntax_errors.tc
@@ -20,7 +20,7 @@ check_error 'e:foo/^123456789012345678901234567890123456789012345678901234567890
check_error 'e:foo/^bar.1 syscalls/sys_enter_openat' # BAD_EVENT_NAME
check_error 'e:foo/bar syscalls/sys_enter_openat arg=^dfd' # BAD_FETCH_ARG
-check_error 'e:foo/bar syscalls/sys_enter_openat ^arg=$foo' # BAD_ATTACH_ARG
+check_error 'e:foo/bar syscalls/sys_enter_openat arg=^$foo' # BAD_ATTACH_ARG
if grep -q '<attached-group>\.<attached-event>.*\[if <filter>\]' README; then
check_error 'e:foo/bar syscalls/sys_enter_openat if ^' # NO_EP_FILTER
^ permalink raw reply related
* Re: [PATCH v3 2/2] spi: qcom-geni: Add trace events for Qualcomm GENI SPI driver
From: Mukesh Savaliya @ 2026-05-25 5:17 UTC (permalink / raw)
To: Konrad Dybcio, Praveen Talari, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Mark Brown
Cc: linux-kernel, linux-trace-kernel, linux-arm-msm, linux-spi,
aniket.randive, chandana.chiluveru, jyothi.seerapu
In-Reply-To: <5c59952f-72c5-4aee-a1a6-4b11b0a542c3@oss.qualcomm.com>
On 5/19/2026 5:04 PM, Konrad Dybcio wrote:
> On 5/19/26 12:59 PM, Mukesh Savaliya wrote:
>> Hi Praveen, one question below.
>>
>> On 5/18/2026 10:30 PM, Praveen Talari wrote:
>>> Add tracepoints to the Qualcomm GENI (Generic Interface) SPI driver.
>>> These trace events enable runtime debugging and performance analysis
>>> of SPI operations.
>>>
>>> The trace events capture SPI clock configuration, setup parameters,
>>> transfer details, interrupt status.
>> Don't you need trace logs around PM operations ? ie. runtime and system PM ?
>
> The PM core provides a couple, are those enough?
>
Understood, should be enough. Thanks !
> Konrad
^ permalink raw reply
* Re: [PATCH v2] perf/ftrace: Fix WARNING in __unregister_ftrace_function
From: Masami Hiramatsu @ 2026-05-25 5:39 UTC (permalink / raw)
To: Rik van Riel
Cc: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers, linux-kernel,
linux-trace-kernel, kernel-team, sashiko-bot, sashiko-reviews
In-Reply-To: <8f8d0cd380f40b84557304d110f38ecefc994a35.camel@surriel.com>
On Fri, 22 May 2026 16:39:41 -0400
Rik van Riel <riel@surriel.com> wrote:
> On Wed, 2026-05-20 at 16:41 -0400, Steven Rostedt wrote:
> >
> > Rik,
> >
> > Can you reply to Sashiko here?
> >
> > The below comes from Sashiko:
> > https://sashiko.dev/?list=org.kernel.vger.linux-trace-kernel#/patchset/20260513161916.04151502%40fangorn
> >
> > Thanks,
> >
> > -- Steve
> >
> >
> > > commit f90ac36f39b79a19c015522bb1caf7ef903caf02
> > > Author: Rik van Riel <riel@surriel.com>
> > > perf/ftrace: Fix WARNING in __unregister_ftrace_function
> > > This commit attempts to fix a WARN_ON triggered during
> > > perf_event_alloc() error
> > > cleanup by checking FTRACE_OPS_FL_ENABLED before unregistering the
> > > ftrace
> > > function. The warning occurs because the ftrace_ops registration
> > > failed or was
> > > torn down by perf_try_init_event() earlier, but the event->destroy
> > > callback is
> > > executed again during the error path.
> > > > diff --git a/kernel/trace/trace_event_perf.c
> > > > b/kernel/trace/trace_event_perf.c
> > > > index 61e3a2620fa3c..8d64f17135e8f 100644
> > > > --- a/kernel/trace/trace_event_perf.c
> > > > +++ b/kernel/trace/trace_event_perf.c
> > > > @@ -495,7 +495,11 @@ static int
> > > > perf_ftrace_function_register(struct perf_event *event)
> > > > static int perf_ftrace_function_unregister(struct perf_event
> > > > *event)
> > > > {
> > > > struct ftrace_ops *ops = &event->ftrace_ops;
> > > > - int ret = unregister_ftrace_function(ops);
> > > > + int ret = 0;
> > > > +
> > > > + if (ops->flags & FTRACE_OPS_FL_ENABLED)
> > > > + ret = unregister_ftrace_function(ops);
> > > > +
> > > > ftrace_free_filter(ops);
> >
> > > Does calling ftrace_free_filter() unconditionally here mask a
> > > double-teardown
> > > regression while leaving the underlying double-free active?
>
> I don't see how calling ftrace_free_filter() twice would
> call issues, given that it sets the ->*_hash values to
> EMPTY_HASH:
>
> void ftrace_free_filter(struct ftrace_ops *ops)
> {
> ftrace_ops_init(ops);
> if (WARN_ON(ops->flags & FTRACE_OPS_FL_ENABLED))
> return;
> free_ftrace_hash(ops->func_hash->filter_hash);
> free_ftrace_hash(ops->func_hash->notrace_hash);
> ops->func_hash->filter_hash = EMPTY_HASH;
> ops->func_hash->notrace_hash = EMPTY_HASH;
> }
>
> void free_ftrace_hash(struct ftrace_hash *hash)
> {
> if (!hash || hash == EMPTY_HASH)
> return;
> ..
>
Yeah, confirmed.
>
> > > In perf_try_init_event(), if a PMU event_init() succeeds but a
> > > subsequent
> > > capability check fails, it explicitly calls event->destroy(event)
> > > to roll back:
> > > kernel/events/core.c:perf_try_init_event() {
> > > ...
> > > if (ret && event->destroy)
> > > event->destroy(event);
> > > ...
> > > }
>
> The error handling there all seems to "goto err_destroy"
>
> err_destroy:
> if (event->destroy) {
> event->destroy(event);
> event->destroy = NULL;
> }
>
>
> > > However, it does not set event->destroy to NULL.
>
> ... but it does?
>
> I am not sure what code Sashiko is looking at,
> but it does not look like the code I just pulled.
Indeed.
>
> Is there a different tree I should be looking at
> than upstream Linus?
You can see the baseline info if you expand the collapsed triangle.
Anyway, it said:
linux-trace/HEAD (70575e77839f4c5337ce2653b39b86bb365a870e)
So that is linux-trace/master.
commit 70575e77839f4c5337ce2653b39b86bb365a870e (linux-trace/master)
Merge: 7bc6e90d7aa4 a43ae8057cc1
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Fri Sep 30 09:41:34 2022 -0700
Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost
Hmm, this is too old. And linux-trace/master is not used anymore.
Reported to Sashiko.
https://github.com/sashiko-dev/sashiko/issues/218
Thank you,
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [RFC PATCH v2 0/3] trace: stack trace deduplication for ftrace ring buffer
From: Masami Hiramatsu @ 2026-05-25 6:58 UTC (permalink / raw)
To: Li Pengfei
Cc: linux-trace-kernel, rostedt, mhiramat, linux-kernel, cmllamas,
zhangbo56, lipengfei28, lkp
In-Reply-To: <20260522104017.1668638-1-lipengfei28@xiaomi.com>
Hi Pengfei,
On Fri, 22 May 2026 18:40:14 +0800
Li Pengfei <ljdlns1987@gmail.com> wrote:
> From: Pengfei Li <lipengfei28@xiaomi.com>
>
> Hi Steven, all,
>
> This is v2 of the ftrace stackmap series. It addresses the Sashiko
> review at [1] and incorporates the kernel test robot's toctree fix.
>
> The series adds stack trace deduplication to ftrace. When the
> stacktrace option is enabled, the ring buffer stores a 4-byte
> stack_id instead of a full kernel stack trace, while the full
> stacks are exported via tracefs.
Sashiko still made some comments on the series. Please review it.
https://sashiko.dev/#/patchset/20260522104017.1668638-1-lipengfei28%40xiaomi.com
And reply to the comment on this thread, so that we can discuss it
here.
Thanks,
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [RFC PATCH v2 0/3] trace: stack trace deduplication for ftrace ring buffer
From: Li Pengfei @ 2026-05-25 7:39 UTC (permalink / raw)
To: mhiramat
Cc: linux-trace-kernel, rostedt, linux-kernel, cmllamas, zhangbo56,
lipengfei28, lkp
In-Reply-To: <20260525155841.b15adcd50d25485aab287043@kernel.org>
Hi Masami,
I went through the Sashiko comments on v2 [1]. Per-finding response
below; v3 will incorporate the fixes.
[1] https://sashiko.dev/#/patchset/20260522104017.1668638-1-lipengfei28%40xiaomi.com
Patch 1/3:
- memset() torn reads against lockless readers: agreed, the
reset path is not well serialized against tracefs readers.
Will tighten slow-path synchronization in v3.
- seq_next() not advancing *pos on EOF: agreed, will fix in v3.
- atomic_read(&resetting) without acquire: agreed, will switch
to atomic_read_acquire() in v3.
- Plain reads of entry->key: agreed, will use READ_ONCE() in v3.
- atomic64_inc() in NMI-safe hot path on 32-bit GENERIC_ATOMIC64:
agreed, will move the counters off the hot path (local_t /
per-CPU) in v3.
Patch 2/3:
- TRACE_STACK_ID not in trace_valid_entry(): agreed, will add in v3.
- "NULL from kzalloc" comment: wording bug, will correct in v3.
- Reset memset synchronization: same fix as patch 1, finding 1.
Patch 3/3:
- Selftest missing 'function:tracer' in '# requires:': agreed,
will add in v3.
- Selftest wiping the ring buffer via 'echo nop > current_tracer'
before reading trace: agreed, will reorder in v3.
I'll send v3 once the changes are tested.
Pengfei
^ permalink raw reply
* Re: [PATCH] tracing: Replace BUG_ON with lockdep_assert_held in uprobe_buffer functions
From: Masami Hiramatsu @ 2026-05-25 7:42 UTC (permalink / raw)
To: Steven Rostedt
Cc: Yash Suthar, mhiramat, mathieu.desnoyers, linux-kernel,
linux-trace-kernel, skhan
In-Reply-To: <20260521181601.77ce38e6@gandalf.local.home>
On Thu, 21 May 2026 18:16:01 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:
> On Fri, 22 May 2026 00:58:46 +0530
> Yash Suthar <yashsuthar983@gmail.com> wrote:
>
> > Replace BUG_ON(!mutex_is_locked(&event_mutex)) with
> > lockdep_assert_held(&event_mutex) in uprobe_buffer_enable() and
> > uprobe_buffer_disable().
> >
> > BUG_ON() will crash the kernel. mutex_is_locked() only checks
> > if any task holds lock,but not the caller task. lockdep_assert_held()
> > also check current task for lock and no crash on true condition.
> >
> > Signed-off-by: Yash Suthar <yashsuthar983@gmail.com>
>
> This looks good to me.
>
> Acked-by: Steven Rostedt <rostedt@goodmis.org>
>
> Masami, do you want to take this?
Yeah, let me pick this.
Thanks!
>
> -- Steve
>
> > ---
> > kernel/trace/trace_uprobe.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
> > index 2cabf8a23ec5..aee0960d0cf7 100644
> > --- a/kernel/trace/trace_uprobe.c
> > +++ b/kernel/trace/trace_uprobe.c
> > @@ -912,7 +912,7 @@ static int uprobe_buffer_enable(void)
> > {
> > int ret = 0;
> >
> > - BUG_ON(!mutex_is_locked(&event_mutex));
> > + lockdep_assert_held(&event_mutex);
> >
> > if (uprobe_buffer_refcnt++ == 0) {
> > ret = uprobe_buffer_init();
> > @@ -927,7 +927,7 @@ static void uprobe_buffer_disable(void)
> > {
> > int cpu;
> >
> > - BUG_ON(!mutex_is_locked(&event_mutex));
> > + lockdep_assert_held(&event_mutex);
> >
> > if (--uprobe_buffer_refcnt == 0) {
> > for_each_possible_cpu(cpu)
>
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH 07/13] rv: Simply hybrid automata monitors's clock variables
From: Gabriele Monaco @ 2026-05-25 8:03 UTC (permalink / raw)
To: Nam Cao
Cc: Steven Rostedt, Wander Lairson Costa, linux-trace-kernel,
linux-kernel
In-Reply-To: <a779af6dc89721179e0dbab08623e42aa0191275.1777962130.git.namcao@linutronix.de>
On Tue, 2026-05-05 at 08:59 +0200, Nam Cao wrote:
> -static inline bool ha_check_invariant_ns(struct ha_monitor *ha_mon,
> - enum envs env, u64 time_ns)
> +static inline bool ha_check_invariant_ns(struct ha_monitor *ha_mon, enum envs
> env,
> + u64 time_ns, u64 expire_ns)
> {
> - return READ_ONCE(ha_mon->env_store[env]) >= time_ns;
> + return time_ns - READ_ONCE(ha_mon->env_store[env]) <= expire_ns;
> }
This function had the silent assumption that invalid/uninitialised
values (max u64) pass the check.
This is no longer working (see nomiss) but could be restored by doing:
READ_ONCE(ha_mon->env_store[env]) >= time_ns - expire_ns
But.. Yeah, that's a weak assumption. We should probably refactor the
thing to use ha_reset_env() in ha_monitor_reset_all_stored(), then
variables are never going to be uninitialised. It needs a bit of
tinkering but it's definitely better than now.
I'll try and add that to my fixes series.
And I should add some nomiss and stall selftest..
> -static inline bool ha_check_invariant_jiffy(struct ha_monitor *ha_mon,
> - enum envs env, u64 time_ns)
> +static inline bool ha_check_invariant_jiffy(struct ha_monitor *ha_mon, enum
> envs env,
> + u64 time_ns, u64 expire_jiffy)
> {
> - return time_after64(READ_ONCE(ha_mon->env_store[env]),
> get_jiffies_64());
> -
> + return time_after64(READ_ONCE(ha_mon->env_store[env]) + expire_jiffy,
> get_jiffies_64());
> }
I'd prefer if this was consistent with the above as in (now - env <=
expire) or (env >= now - env), whichever you prefer but let's keep it
equivalent.
Or do you have a reason to rearrange it here?
Thanks,
Gabriele
^ permalink raw reply
* 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
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