* [RFC v2 0/3] arm64: kprobes: Fix single-step fault and reentry handling
From: Pu Hu @ 2026-07-09 14:22 UTC (permalink / raw)
To: mhiramat@kernel.org
Cc: ada.coupriediaz@arm.com, catalin.marinas@arm.com,
davem@davemloft.net, Hongyan Xia, Pu Hu, Jiazi Li,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
naveen@kernel.org, will@kernel.org, yang@os.amperecomputing.com
From: Pu Hu <hupu@transsion.com>
This series fixes two arm64 kprobes issues observed when running
simpleperf with preemptirq tracepoints and dwarf callchains while a
kprobe is active on a frequently executed kernel function.
The crash happens in the kprobe debug exception path. While a kprobe is
preparing or executing its XOL single-step instruction, perf/trace code
can run in the same window. That code may either take a fault of its own
or hit another kprobe.
Patch 1 fixes kprobe_fault_handler() so that it only handles a fault
taken in KPROBE_HIT_SS or KPROBE_REENTER state when the faulting PC
points at the current kprobe's XOL instruction. Simulated kprobes,
which have no XOL slot at all, are filtered out at function entry so
that the normal page fault handler (including fixup_exception) can
process any fault without interference.
Patch 2 allows a kprobe hit in KPROBE_HIT_SS to be handled as a
recoverable one-level reentry, instead of treating it as unrecoverable.
This is safe because the reentry save area has not yet been consumed at
that point. Only a hit while already in KPROBE_REENTER remains
unrecoverable.
Patch 3 extends struct prev_kprobe with a saved_irqflag field so that
the outer kprobe's original DAIF state is preserved across reentry.
Without this, a nested kprobe from Patch 2 would overwrite
kcb->saved_irqflag, and the outer kprobe would restore the wrong DAIF
mask on completion, potentially leaving interrupts permanently disabled.
This follows the same logic as the existing x86 fixes:
6381c24cd6d5 ("kprobes/x86: Fix page-fault handling logic")
6a5022a56ac3 ("kprobes/x86: Allow to handle reentered kprobe on single-stepping")
v1 -> v2:
- Patch 1: moved simulated kprobe check to function entry (per
maintainer review); removed redundant xol_insn NULL check from
the inner branch.
- Patch 2: unchanged.
- Patch 3: new in v2; fixes the IRQ flag save/restore gap that
Patch 2 exposes.
- Removed the selftest patch (old Patch 3) from this series.
- Fixed Signed-off-by to use full name (Pu Hu) instead of username
(hupu).
- Updated comments and commit messages across all patches.
Reproducer:
simpleperf record -p <pid> -f 10000 \
-e preemptirq:preempt_disable \
-e preemptirq:preempt_enable \
--duration 9 --call-graph dwarf \
-o /data/local/tmp/perf.data
Before this series, the crash reproduced frequently. With all three
patches applied, it was no longer reproduced in our testing.
Pu Hu (3):
arm64: kprobes: Only handle faults originating from XOL slot
arm64: kprobes: Allow reentering kprobes while single-stepping
arm64: kprobes: Save and restore saved_irqflag in prev_kprobe
arch/arm64/include/asm/kprobes.h | 6 ++++
arch/arm64/kernel/probes/kprobes.c | 45 +++++++++++++++++++++++++++++-
2 files changed, 50 insertions(+), 1 deletion(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH v1 06/11] rcu: Enable RCU callbacks to benefit from expedited grace periods
From: Frederic Weisbecker @ 2026-07-09 13:58 UTC (permalink / raw)
To: Puranjay Mohan
Cc: rcu, linux-kernel, linux-trace-kernel, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Masami Hiramatsu, Davidlohr Bueso,
Breno Leitao
In-Reply-To: <20260624132356.516959-7-puranjay@kernel.org>
Le Wed, Jun 24, 2026 at 06:23:48AM -0700, Puranjay Mohan a écrit :
> Currently, RCU callbacks only track normal grace-period sequence
> numbers. This means callbacks must wait for normal grace periods to
> complete even when expedited grace periods have already elapsed.
The changelog still misses the reason for this change. I had to read
the lwn article to understand that this matters under memory pressure
in order to release objects faster.
Thanks.
--
Frederic Weisbecker
SUSE Labs
^ permalink raw reply
* Re: [PATCH v1 05/11] rcu: Add RCU_GET_STATE_NOT_TRACKED for subsystems without expedited GPs
From: Frederic Weisbecker @ 2026-07-09 13:48 UTC (permalink / raw)
To: Puranjay Mohan
Cc: rcu, linux-kernel, linux-trace-kernel, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Masami Hiramatsu, Davidlohr Bueso,
Breno Leitao
In-Reply-To: <20260624132356.516959-6-puranjay@kernel.org>
Le Wed, Jun 24, 2026 at 06:23:47AM -0700, Puranjay Mohan a écrit :
> SRCU and Tasks RCU do not track expedited grace periods. When their
> callback state is checked via poll_state_synchronize_rcu_full(), the
> uninitialized or zeroed exp field could cause false-positive
> completion detection.
>
> This commit adds an RCU_GET_STATE_NOT_TRACKED sentinel value (0x2) that
> these subsystems can place into exp to indicate that expedited GP
> tracking is not applicable. The expedited sequence check in
> poll_state_synchronize_rcu_full() is guarded to skip entries marked with
> this sentinel.
>
> This is needed to allow rcu_segcblist_advance() and rcu_accelerate_cbs()
> to work with both normal and expedited grace periods via
> get_state_synchronize_rcu_full() and poll_state_synchronize_rcu_full().
>
> Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
> Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
--
Frederic Weisbecker
SUSE Labs
^ permalink raw reply
* Re: [PATCH v1 04/11] rcu/segcblist: Track segment grace periods with struct rcu_gp_seq
From: Frederic Weisbecker @ 2026-07-09 13:33 UTC (permalink / raw)
To: Puranjay Mohan
Cc: rcu, linux-kernel, linux-trace-kernel, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Masami Hiramatsu, Davidlohr Bueso,
Breno Leitao
In-Reply-To: <20260624132356.516959-5-puranjay@kernel.org>
Le Wed, Jun 24, 2026 at 06:23:46AM -0700, Puranjay Mohan a écrit :
> Change the type of the per-segment ->gp_seq[] array in struct
> rcu_segcblist from unsigned long to struct rcu_gp_seq. This prepares the
> callback tracking infrastructure to record both normal and expedited
> grace periods per segment.
>
> The rcu_segcblist_nextgp(), rcu_segcblist_advance(), and
> rcu_segcblist_accelerate() helpers now take a struct rcu_gp_seq * instead
> of an unsigned long, and all callers use the .norm field for comparisons
> and assignments. The SRCU and Tasks RCU wrappers construct a struct
> rcu_gp_seq with only .norm set and forward to the core helpers.
>
> No functional change: only the .norm field is used.
>
> Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
--
Frederic Weisbecker
SUSE Labs
^ permalink raw reply
* Re: [PATCH v1 03/11] rcu/segcblist: Factor out rcu_segcblist_advance_compact() helper
From: Frederic Weisbecker @ 2026-07-09 13:21 UTC (permalink / raw)
To: Puranjay Mohan
Cc: rcu, linux-kernel, linux-trace-kernel, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Masami Hiramatsu, Davidlohr Bueso,
Breno Leitao
In-Reply-To: <20260624132356.516959-4-puranjay@kernel.org>
Le Wed, Jun 24, 2026 at 06:23:45AM -0700, Puranjay Mohan a écrit :
> This commit extracts the tail-pointer cleanup and segment compaction
> logic from rcu_segcblist_advance() into a new static helper function,
> rcu_segcblist_advance_compact(). This shared logic will be reused by the
> upcoming srcu_segcblist_advance() standalone implementation, which
> cannot call the core rcu_segcblist_advance() because that function will
> use RCU-specific globals.
>
> No functional change.
>
> Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
> Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
--
Frederic Weisbecker
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2 4/4] mm/mlock: migrate folios out of CMA when mlocking a range
From: Sebastian Andrzej Siewior @ 2026-07-09 13:15 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Wandun Chen, vbabka, rostedt, mhiramat, Alexander.Krabler, hughd,
fvdl, linux-mm, linux-kernel, linux-trace-kernel, linux-rt-devel,
akpm, surenb, mhocko, jackmanb, hannes, ziy, ljs, riel, liam,
harry, jannh, lance.yang, mathieu.desnoyers, matthew.brost,
joshua.hahnjy, rakie.kim, byungchul, gourry, ying.huang, apopple,
pfalcato
In-Reply-To: <9b227263-56d9-41d5-ba8e-c969d8d68785@kernel.org>
On 2026-07-09 12:04:33 [+0200], David Hildenbrand (Arm) wrote:
> On 7/7/26 14:59, Wandun Chen wrote:
> > From: Wandun Chen <chenwandun@lixiang.com>
> >
> > The region covered by mlock[all] may contain CMA pages. cma_alloc installs
>
> What about ZONE_MOVABLE where memory is supposed to be migratable?
Would it be bad if the pages would not be movable anymore? Does this
effect just memory-hotplug or something else, too?
> Also, what about drivers that mmap() CMA memory to user space, and
> __mm_populate()->populate_vma_page_range() would actually try mlocking them, and
> they actually must remain on CMA areas?
It should be safe to skip those. They belong to device and they
shouldn't be affected by anything including getting swapped out.
Sebastian
^ permalink raw reply
* Re: [PATCH v2 4/4] mm/mlock: migrate folios out of CMA when mlocking a range
From: Wandun @ 2026-07-09 12:25 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: vbabka, david, rostedt, mhiramat, Alexander.Krabler, hughd, fvdl,
linux-mm, linux-kernel, linux-trace-kernel, linux-rt-devel, akpm,
surenb, mhocko, jackmanb, hannes, ziy, riel, liam, harry, jannh,
lance.yang, mathieu.desnoyers, matthew.brost, joshua.hahnjy,
rakie.kim, byungchul, gourry, ying.huang, apopple, pfalcato
In-Reply-To: <20260709091316.TFgtBZlE@linutronix.de>
On 7/9/26 17:13, Sebastian Andrzej Siewior wrote:
> On 2026-07-07 15:54:57 [+0100], Lorenzo Stoakes wrote:
>> On Tue, Jul 07, 2026 at 08:59:25PM +0800, Wandun Chen wrote:
>>> From: Wandun Chen <chenwandun@lixiang.com>
>>>
>>> The region covered by mlock[all] may contain CMA pages. cma_alloc installs
>>> migration entries in the page table, if a memory access occurs at this
>>> point, it must wait for the migration to complete, which may cause
>>> latency spikes on the RT kernels.
>>>
>>> Try to move the migration cost into the mlock[all] caller, which is
>>> typically a setup path. So reduce the chance of latency spikes on RT
>>> kernels by migrating the currently mapped CMA pages out of CMA region.
>>
>> 'reduce the chances of latency' so do you have any data to back this invasive
>> change or not?
>
> The application gets pages assigned which belong a CMA area. If the
> pages are in need by the CMA then those pages are replaced with other
> pages during a migration phase. Since there is no guarantee how long
> this will take and is also subject to general scheduling in the system
> it will be measurable and painful once hit.
>
>> And for RT, but nothing in here at all checks for RT? You're using this
>> compaction sysctl as an RT check somehow? That's gross.
>
> The man-page for mlock says that it guarantees to stay in RAM and/ or
> preventing to be moved to swap area. I would however argue that
> replacing physical pages in the background should fall under this since
> the application can't access them and is blocked while trying. The notes
> section (in the man-page) lists "real-time applications" and
> "deterministic timing". Therefore I think it makes sense to do this
> unconditionally for mlock areas regardless of the sysctl knob.
> Security related application probably only care that their memory does
> not hit the swap area and probably wouldn't mind 10ms delay.
Thanks for helping to explain, that helps a lot, Sebastian.
Wandun
>
>> This doesn't feel like the right solution.
>
> Sebastian
^ permalink raw reply
* Re: [PATCH v1] tracing/remotes: Fix leak in trace_remote_alloc_buffer() error path
From: Vincent Donnefort @ 2026-07-09 12:18 UTC (permalink / raw)
To: Steven Rostedt
Cc: mhiramat, mathieu.desnoyers, linux-trace-kernel, kernel-team,
linux-kernel, Sashiko
In-Reply-To: <20260708125906.746f1def@gandalf.local.home>
On Wed, Jul 08, 2026 at 12:59:06PM -0400, Steven Rostedt wrote:
> On Wed, 8 Jul 2026 14:32:01 +0100
> Vincent Donnefort <vdonnefort@google.com> wrote:
>
> > If page allocation fails in trace_remote_alloc_buffer(), desc->nr_cpus
> > is not yet incremented for the current CPU. As a consequence, on error,
> > half-allocated rb_desc will not be freed in trace_remote_free_buffer().
> >
> > Include the failing CPU in desc->nr_cpus before going to the error path.
> >
>
> Looks like Sashiko found other issues you may want to address:
>
> https://sashiko.dev/#/patchset/20260708133201.295072-1-vdonnefort%40google.com
Yeah I saw it, the dreaded "This isn't a bug introduced by this patch" ...
Let me send a follow-up. After looking at the other issue, I think I want to
slightly modify this one actually!
>
> -- Steve
>
> > Fixes: 96e43537af54 ("tracing: Introduce trace remotes")
> > Reported-by: Sashiko <sashiko-bot@kernel.org>
> > Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
> >
> > diff --git a/kernel/trace/trace_remote.c b/kernel/trace/trace_remote.c
> > index 2a6cc000ec98..62d3d431c309 100644
> > --- a/kernel/trace/trace_remote.c
> > +++ b/kernel/trace/trace_remote.c
> > @@ -1008,8 +1008,10 @@ int trace_remote_alloc_buffer(struct trace_buffer_desc *desc, size_t desc_size,
> >
> > for (id = 0; id < nr_pages; id++) {
> > rb_desc->page_va[id] = (unsigned long)__get_free_page(GFP_KERNEL);
> > - if (!rb_desc->page_va[id])
> > + if (!rb_desc->page_va[id]) {
> > + desc->nr_cpus++; /* Free this partially-allocated rb_desc */
> > goto err;
> > + }
> >
> > rb_desc->nr_page_va++;
> > }
> >
> > base-commit: 8cdeaa50eae8dad34885515f62559ee83e7e8dda
>
^ permalink raw reply
* Re: [PATCH] tracing: fprobe: Remove __packed from generic __fprobe_header
From: Markus Schneider-Pargmann @ 2026-07-09 12:06 UTC (permalink / raw)
To: Masami Hiramatsu, Markus Schneider-Pargmann
Cc: Steven Rostedt, Mathieu Desnoyers, Heiko Carstens, linux-kernel,
linux-trace-kernel
In-Reply-To: <20260622135659.ff84ef3b831a464b802d7c33@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2756 bytes --]
Hi Masami,
On Mon Jun 22, 2026 at 6:56 AM CEST, Masami Hiramatsu wrote:
> On Wed, 10 Jun 2026 11:20:24 +0200
> "Markus Schneider-Pargmann" <msp@baylibre.com> wrote:
>
>> Hi Masami,
>>
>> On Wed Jun 10, 2026 at 10:17 AM CEST, Masami Hiramatsu wrote:
>> > Hi Markus,
>> >
>> > Thanks for ping me.
>> >
>> > On Tue, 28 Apr 2026 10:30:29 +0200
>> > "Markus Schneider-Pargmann (The Capable Hub)" <msp@baylibre.com> wrote:
>> >
>> >> fp pointer and unsigned long have the same size on all relevant
>> >> architectures that build Linux. Furthermore this struct is only used in
>> >> architectures that do not set ARCH_DEFINE_ENCODE_FPROBE_HEADER which is
>> >> set only for 64bit architectures (apart from LoongArch).
>> >>
>> >> Both fields are aligned on these architectures so the struct with
>> >> __packed and without it are the same.
>> >>
>> >> Remove the __packed as it is unnecessary.
>> >>
>> >> Fixes: 4346ba160409 ("fprobe: Rewrite fprobe on function-graph tracer")
>> >
>> > NOTE: This is not a Fix, but just cleanup or minor update. Or, you have
>> > any problem with this __packed attribute?
>>
>> Thanks, yes it is not fixing a bug, I can remove this.
>>
>> >
>> > Unless there is no problem (or any concern), I would like to keep this
>> > as it is.
>>
>> There is currently no problem with __packed in the upstream kernel. I
>> just thought this would be a good cleanup to remove the unnecessary
>> attribute. I am working on CHERI architectures where pointers have
>> capabilities. __packed breaks these capability tags and therefore
>> doesn't work on CHERI. When looking into why this struct has a __packed
>> attribute I didn't see a reason, so I thought this would be a good patch
>> for upstream as well even though CHERI is not yet relevant for upstream
>> linux.
>
> Hi Markus,
>
> Ah, OK. CHERI makes pointers to non-long value. Are you sure
> removing __packed makes fprobe working with CHERI? If so,
> please describe it. Then I can pick it.
Sorry for the late response.
No, this patch alone doesn't make fprobe work with CHERI. __packed is
problematic for CHERI because it sets the alignment to 1 which forces
the compiler to do unaligned access operations even if the
struct/pointer is aligned. Unaligned operations do not keep the CHERI
capabilities. Without __packed the compiler knows everything is aligned
and can use aligned operations and keep the CHERI capabilities. CHERI
hardware does not support unaligned pointer capability access.
On its own it doesn't help CHERI, there are more patches that are more
CHERI specific that are needed for fprobe to work on CHERI. I just
thought it would be a great standalone patch for upstream.
Best
Markus
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 289 bytes --]
^ permalink raw reply
* Re: [PATCH v1 02/11] rcu/segcblist: Add SRCU and Tasks RCU wrapper functions
From: Frederic Weisbecker @ 2026-07-09 11:51 UTC (permalink / raw)
To: Puranjay Mohan
Cc: rcu, linux-kernel, linux-trace-kernel, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Masami Hiramatsu, Davidlohr Bueso,
Breno Leitao
In-Reply-To: <20260624132356.516959-3-puranjay@kernel.org>
Le Wed, Jun 24, 2026 at 06:23:44AM -0700, Puranjay Mohan a écrit :
> Add srcu_segcblist_advance() and srcu_segcblist_accelerate() wrappers
> that forward to the core rcu_segcblist_advance() and
> rcu_segcblist_accelerate() functions, and switch all SRCU (srcutree.c)
> and Tasks RCU (tasks.h) callers to use these wrappers.
>
> This isolates SRCU and Tasks RCU from upcoming changes to the core
> advance/accelerate functions, which will switch to struct
> rcu_gp_seq for dual normal/expedited GP tracking. Because SRCU and
> Tasks RCU use only normal GP sequences, their wrappers will maintain the
> existing unsigned long interface.
>
> No functional change.
>
> Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
> Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
--
Frederic Weisbecker
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2 2/4] mm/mlock: wait for migration to finish when mlocking a folio
From: Wandun @ 2026-07-09 11:50 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: vbabka, david, rostedt, mhiramat, Alexander.Krabler, hughd, fvdl,
bigeasy, linux-mm, linux-kernel, linux-trace-kernel,
linux-rt-devel, akpm, surenb, mhocko, jackmanb, hannes, ziy, riel,
liam, harry, jannh, lance.yang, mathieu.desnoyers, matthew.brost,
joshua.hahnjy, rakie.kim, byungchul, gourry, ying.huang, apopple,
pfalcato
In-Reply-To: <ak0C-DP_1ZrTVSLj@lucifer>
On 7/7/26 22:33, Lorenzo Stoakes wrote:
> On Tue, Jul 07, 2026 at 08:59:23PM +0800, Wandun Chen wrote:
>> From: Wandun Chen <chenwandun@lixiang.com>
>>
>> In RT kernels, sysctl_compact_unevictable_allowed is false by default,
>> when the mlock/mlockall system call try to lock all the present page,
>> the mlock_pte_range function skips non-present entries. If these
>> non-present entries are migration entries, and the migration is not
>> guaranteed to have completed before the mlock/mlockall, it may result
>> in a page fault on subsequent access, which then waits for the
>> migration to finish, causing spike latency in RT kernels.
>
> Is this really noticable and measurable?
Alexander Krabler reported a 1.1ms latency in [1]
https://lore.kernel.org/all/DU0PR01MB10385345F7153F334100981888259A@DU0PR01MB10385.eurprd01.prod.exchangelabs.com/
>
> I suppose not too many ranges should be mock
>
>>
>> Fix it by waiting for the migration to complete during the mlock/mlockall
>> syscall when sysctl_compact_unevictable_allowed is false.
>
> Probably better to reference the sysctl itself rather than an arbitrary varible
> name.
Got it.
>
>>
>> Fixes: 90d07210ab55 ("mm: mlock: use folios and a folio batch internally")
>
> Again I have no idea why you chose this as the fixes target, especially for
> this?
You're right, the Fixes tag was wrong.
Setting sysctl_compact_unevictable_allowed to zero was introduced in v5.7 by:
commit 6923aa0d8c62 ("mm/compaction: Disable compact_unevictable_allowed on RT")
Before this commit, mlocked page can be migrated, and dont need to wait for
migration complete.
After this commit, if don't wait for migration complete, this may result in
latency spikes.
(The batch mlock feature increases the probability of hitting migration entries.)
Will update Fixes tag in next version.
>
> But in any case, why is this separate from the previous commit? I sthis an
> entirely separate fix?
These two patches address two aspects of the same problem,
and I split them into separate patches mainly to make review easier.
Patch 1 mainly prevents pages to be migrated due to batch mlock;
patch 2 mainly ensures that pages undergoing migration have finished
migrating once the mlock system call completes.
>
>> Suggested-by: Vlastimil Babka <vbabka@suse.cz>
>> Signed-off-by: Wandun Chen <chenwandun@lixiang.com>
>> Link: https://lore.kernel.org/lkml/c8793c0f-7156-4cb7-9e6e-7909397e2fff@kernel.org/#t
>
> A nit but please strip that #t.
Got it.
>
>> ---
>> mm/mlock.c | 23 +++++++++++++++++++++--
>> 1 file changed, 21 insertions(+), 2 deletions(-)
>>
>> diff --git a/mm/mlock.c b/mm/mlock.c
>> index 97e49038d8d3..ac65de40b22b 100644
>> --- a/mm/mlock.c
>> +++ b/mm/mlock.c
>> @@ -25,6 +25,7 @@
>> #include <linux/memcontrol.h>
>> #include <linux/mm_inline.h>
>> #include <linux/secretmem.h>
>> +#include <linux/compaction.h>
>>
>> #include "internal.h"
>>
>> @@ -361,8 +362,17 @@ static int mlock_pte_range(pmd_t *pmd, unsigned long addr,
>>
>> ptl = pmd_trans_huge_lock(pmd, vma);
>> if (ptl) {
>> - if (!pmd_present(*pmd))
>> + if (!pmd_present(*pmd)) {
>> + if (unlikely((vma->vm_flags & VM_LOCKED) &&
>
> -> vma_test(vma, VMA_LOCKED_BIT)...
>
> What is the basis for your unlikely()? Don't use likely()/unlikely() just
> because it feels right. Leave them out unless you have actual profiling data to
> prove it.
>
> Remove it please.
Got it.
>
> But I'm also confused here - why are you checking for VMAs that already had
> VMA_LOCKED_BIT set when you are about to set it?
>
> Surely this shouldn't be predicated on VMA_LOCKED_BIT?
munlock also would call mlock_pte_range, if page is under undergoing migration,
munlock dont need to wait migration complete.
>
>
>> + !compaction_allow_unevictable() &&
>
> Why do we care about compaction here? Are we assuming the softleaf migration
> entry is present only for compaction reasons?
>
> So these migration entries could be there for any reason? Does it matter? Is it
> such a big deal, on mlock, to wait for migration entries? I think probably not.
>
> But then maybe some weird workload gets affected... hmm.
Indeed, there are workloads that are affected by this.
In RT kernels, RT processes typically use mlock to prevent their memory from
being swapped out, and sysctl_compact_unevictable_is set to default 0 in the
RT kernels, so mlocked memory won't be migrated and won't encounter migration
entries on access.
Using compaction_allow_unevictable here is mainly to check whether the system
is latency-sensitive. In RT kernels, sysctl_compact_unevictable_is set to 0 by
default.
If there is no waiting, the migration may won't have completed by the time of
the subsequent memory access, and then we would have to wait for migration
to finish in the page fault path. Since pmd_migration_entry_wait/migration_entry_wait
has no priority-propagation mechanism, if the process executing mlock is an
RT process, this can lead to priority inversion and latency spike occurs.
>
>> + softleaf_is_migration(softleaf_from_pmd(*pmd)))) {
>
> Use pmd_is_migration_entry()? :)
Got it.
>
> And technically you should use pmdp_get() I think? Maybe a situation where we
> don't care/need the READ_ONCE() though.
>
>> + spin_unlock(ptl);
>> + pmd_migration_entry_wait(vma->vm_mm, pmd);
>> + walk->action = ACTION_AGAIN;
>> + return 0;
>> + }
>
> This code is really disgusting, let's please not just copy/paste open-coded
> nested horror shows like this.
>
> A good rule of thumb is if you see a bunch of code 'poking out' like this and
> certainly if you copy/paste it or something very much like it, break it out into
> a function.
Got it, will do in next version.
>
> So:
>
> static bool wait_for_migration(const struct vm_area_struct *vma, softleaf_t entry)
> {
>>>>> As above I'm not sure should even be checking this?
> if (!vma_test(vma, VMA_LOCKED_BIT))
> return false;
>>>>> As above I'm not sure this makes sense?
> if (compaction_allowed_unevictable())
> return false;
>
> return softleaf_is_migration(entry);
> }
>
> Then call it like:
>
> if (ptl) {
> const pmd_t pmd = pmdp_get(pmd);
>
> if (!pmd_present(pmd)) {
> const softleaf_t entry = softleaf_from_pmd(pmd);
>
> if (!wait_for_migration(vma, entry))
> goto out;
>
> spin_unlock(ptl);
> pmd_migration_entry_wait(vma->vm_mm, pmd);
> walk->action = ACTION_AGAIN;
> return 0;
> }
> if (is_huge_zero_pmd(pmd))
> goto out;
>
> (etc. going *pmd -> pmd)
>
> But we could probably do even better than that, and assuming your dubious checks
> above aren't needed, we don't even need a helper then:
>
> if (ptl) {
> const pmd_t pmd = pmdp_get(pmd); // possibly just *pmd?
> const softleaf_t entry = softleaf_from_pmd(pmd);
>
> if (softleaf_is_migration(entry)) {
> /* Wait for migration entries. */
> spin_unlock(ptl);
> pmd_migration_entry_wait(vma->vm_mm, pmd);
> walk->action = ACTION_AGAIN;
> return 0;
> }
> if (!pmd_present(pmd))
> goto out;
> etc.
>
> And similar for the PTE stuff below.
>
> This works because softleaf_from_pmd() (and pte) will give you a 'none' softleaf
> if the entry is not a softlaf entry. So you can unconditionally call it on a
> PMD.
Got it.
>
>> goto out;
>> + }
>> if (is_huge_zero_pmd(*pmd))
>> goto out;
>> folio = pmd_folio(*pmd);
>> @@ -383,8 +393,17 @@ static int mlock_pte_range(pmd_t *pmd, unsigned long addr,
>>
>> for (pte = start_pte; addr != end; pte++, addr += PAGE_SIZE) {
>> ptent = ptep_get(pte);
>> - if (!pte_present(ptent))
>> + if (!pte_present(ptent)) {
>> + if (unlikely((vma->vm_flags & VM_LOCKED) &&
>> + !compaction_allow_unevictable() &&
>> + softleaf_is_migration(softleaf_from_pte(ptent)))) {
>> + pte_unmap_unlock(start_pte, ptl);
>> + migration_entry_wait(vma->vm_mm, pmd, addr);
>> + walk->action = ACTION_AGAIN;
>> + return 0;
>> + }
>> continue;
>> + }
>> folio = vm_normal_folio(vma, addr, ptent);
>> if (!folio || folio_is_zone_device(folio))
>> continue;
>> --
>> 2.43.0
>>
>
> Thanks, Lorenzo
Thanks again.
Wandun
^ permalink raw reply
* Re: [PATCH v1 01/11] rcu: Rename struct rcu_gp_oldstate to rcu_gp_seq
From: Frederic Weisbecker @ 2026-07-09 11:47 UTC (permalink / raw)
To: Puranjay Mohan
Cc: rcu, linux-kernel, linux-trace-kernel, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Masami Hiramatsu, Davidlohr Bueso,
Breno Leitao
In-Reply-To: <20260624132356.516959-2-puranjay@kernel.org>
Le Wed, Jun 24, 2026 at 06:23:43AM -0700, Puranjay Mohan a écrit :
> The polled grace-period state structure rcu_gp_oldstate holds a snapshot
> of the normal (and, on SMP, expedited) grace-period sequence numbers.
> Upcoming changes store this structure in the callback segment list, where
> the "oldstate" name reads poorly: there it represents the grace period a
> segment is waiting on and is also compared against the current
> grace-period state.
>
> Rename struct rcu_gp_oldstate to the more neutral struct rcu_gp_seq, and
> shorten its members rgos_norm and rgos_exp to norm and exp. Local
> variables and parameters of this type are renamed from rgosp/rgos to
> gsp/gs accordingly.
>
> While at it, provide a single definition of the structure in rcupdate.h
> rather than separate Tiny-RCU and Tree-RCU definitions, and give it the
> ->exp field unconditionally. Tiny RCU does not track expedited grace
> periods and leaves ->exp unused, but a single definition that always has
> ->exp lets the shared callback code in rcu_segcblist.c reference it
> without CONFIG_SMP guards, including on !SMP builds.
>
> No functional change.
>
> Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
--
Frederic Weisbecker
SUSE Labs
^ permalink raw reply
* Re: [PATCH v3 06/11] mm/cma: Allow dynamically creating CMA areas
From: David Hildenbrand (Arm) @ 2026-07-09 10:08 UTC (permalink / raw)
To: Marek Szyprowski, Thierry Reding, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Hunter,
Mikko Perttunen, Yury Norov, Rasmus Villemoes, Russell King,
Alexander Gordeev, Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, Andrew Morton,
Lorenzo Stoakes, Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Robin Murphy, Sumit Semwal,
Benjamin Gaignard, Brian Starkey, John Stultz, T.J. Mercier,
Christian König, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Catalin Marinas, Will Deacon
Cc: devicetree, linux-tegra, linux-kernel, dri-devel, linux-media,
linux-arm-kernel, linux-s390, linux-mm, iommu, linaro-mm-sig,
linux-trace-kernel
In-Reply-To: <83e5e74d-7106-4e14-9d10-56438372f6a3@samsung.com>
On 7/9/26 07:56, Marek Szyprowski wrote:
> On 08.07.2026 10:35, David Hildenbrand (Arm) wrote:
>> On 7/7/26 12:02, Marek Szyprowski wrote:
>>>
>>> Well, the technical reason for not creating cma regions dynamically at
>>> runtime is that on some architectures (like 32bit ARM) the early fixup
>>> for the region is needed to make it functional for DMA.
>> Can you point me at the code that does that? Thanks!
> Check dma_contiguous_early_fixup() and dma_contiguous_remap() in
> arch/arm/mm/dma-mapping.c. Those functions ensures that the CPU mappings for
> the CMA reserved region in linear map are remapped with 4k pages instead
> of the 1M sections, so later, it will be possible to alter the mappings and
> change them to coherent when needed (altering 1M sections is not possible,
> because each process has it's own level-1 array even for the kernel linear
> mapping).
>
Thanks!
>
>
> However, in the use case in this patchset the reserved region is only shared
> with buddy allocator by using the CMA infrastructure, not registered to the
> regular DMA-mapping API, so it would work fine.
Yes, exactly.
> I'm not convinced that this
> is the right API to use for this though.
If it's supposed to be special DMA memory, then indeed, it would be bypassing
the DMA layer.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH 19/30] mm: use linear_page_[index, delta]() consistently
From: Huang, Kai @ 2026-07-09 10:07 UTC (permalink / raw)
To: ljs@kernel.org, akpm@linux-foundation.org
Cc: david@kernel.org, kvm@vger.kernel.org,
tomi.valkeinen@ideasonboard.com, dri-devel@lists.freedesktop.org,
surenb@google.com, riel@surriel.com,
linux-perf-users@vger.kernel.org, pfalcato@suse.de,
x86@kernel.org, rppt@kernel.org, jannh@google.com,
mperttunen@nvidia.com, dave.hansen@linux.intel.com,
kasan-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org,
hughd@google.com, dinguyen@kernel.org, ray.huang@amd.com,
linux@armlinux.org.uk, lumag@kernel.org, tglx@kernel.org,
simona@ffwll.ch, maarten.lankhorst@linux.intel.com,
robin.clark@oss.qualcomm.com, nvdimm@lists.linux.dev,
tzimmermann@suse.de, willy@infradead.org,
linux-kernel@vger.kernel.org, patrik.r.jakobsson@gmail.com,
linux-parisc@vger.kernel.org, etnaviv@lists.freedesktop.org,
m.szyprowski@samsung.com, muchun.song@linux.dev,
abbotti@mev.co.uk, l.stach@pengutronix.de,
James.Bottomley@HansenPartnership.com, peterz@infradead.org,
christian.koenig@amd.com, mhiramat@kernel.org,
hsweeten@visionengravers.com, djbw@kernel.org,
iommu@lists.linux.dev, jarkko@kernel.org, osalvador@suse.de,
acme@kernel.org, deller@gmx.de, thierry.reding@kernel.org,
linux-arm-msm@vger.kernel.org, sj@kernel.org, pbonzini@redhat.com,
viro@zeniv.linux.org.uk, jonathanh@nvidia.com,
schuster.simon@siemens-energy.com, rostedt@goodmis.org,
mingo@redhat.com, linmiaohe@huawei.com, ankita@nvidia.com,
damon@lists.linux.dev, freedreno@lists.freedesktop.org,
brauner@kernel.org, linux-arm-kernel@lists.infradead.org,
bp@alien8.de, airlied@gmail.com, alex@shazbot.org,
liam@infradead.org, linux-tegra@vger.kernel.org, kees@kernel.org,
mripard@kernel.org, namhyung@kernel.org,
linux-sgx@vger.kernel.org, linux-fsdevel@vger.kernel.org,
oleg@redhat.com, harry@kernel.org, linux-mm@kvack.org
In-Reply-To: <bf56e2e98b512962a2fb88900d535a0e9e6769d8.1782735110.git.ljs@kernel.org>
On Mon, 2026-06-29 at 13:23 +0100, Lorenzo Stoakes wrote:
> diff --git a/arch/x86/kernel/cpu/sgx/virt.c b/arch/x86/kernel/cpu/sgx/virt.c
> index db6806c40483..6a1933ddc6fc 100644
> --- a/arch/x86/kernel/cpu/sgx/virt.c
> +++ b/arch/x86/kernel/cpu/sgx/virt.c
> @@ -9,6 +9,7 @@
> #include <linux/miscdevice.h>
> #include <linux/mm.h>
> #include <linux/mman.h>
> +#include <linux/pagemap.h>
> #include <linux/sched/mm.h>
> #include <linux/sched/signal.h>
> #include <linux/slab.h>
> @@ -41,7 +42,7 @@ static int __sgx_vepc_fault(struct sgx_vepc *vepc,
> WARN_ON(!mutex_is_locked(&vepc->lock));
>
> /* Calculate index of EPC page in virtual EPC's page_array */
> - index = vma->vm_pgoff + PFN_DOWN(addr - vma->vm_start);
> + index = linear_page_index(vma, addr);
For SGX:
Acked-by: Kai Huang <kai.huang@intel.com> # sgx
^ permalink raw reply
* Re: [PATCH v2 4/4] mm/mlock: migrate folios out of CMA when mlocking a range
From: David Hildenbrand (Arm) @ 2026-07-09 10:04 UTC (permalink / raw)
To: Wandun Chen, vbabka, rostedt, mhiramat, Alexander.Krabler, hughd,
fvdl, bigeasy, linux-mm, linux-kernel, linux-trace-kernel,
linux-rt-devel
Cc: akpm, surenb, mhocko, jackmanb, hannes, ziy, ljs, riel, liam,
harry, jannh, lance.yang, mathieu.desnoyers, matthew.brost,
joshua.hahnjy, rakie.kim, byungchul, gourry, ying.huang, apopple,
pfalcato
In-Reply-To: <20260707125925.3725177-5-chenwandun1@gmail.com>
On 7/7/26 14:59, Wandun Chen wrote:
> From: Wandun Chen <chenwandun@lixiang.com>
>
> The region covered by mlock[all] may contain CMA pages. cma_alloc installs
What about ZONE_MOVABLE where memory is supposed to be migratable?
Also, what about drivers that mmap() CMA memory to user space, and
__mm_populate()->populate_vma_page_range() would actually try mlocking them, and
they actually must remain on CMA areas?
--
Cheers,
David
^ permalink raw reply
* [PATCH] rtla/tests: Test all tracer options in runtime tests
From: Tomas Glozar @ 2026-07-09 9:17 UTC (permalink / raw)
To: Steven Rostedt, Tomas Glozar
Cc: John Kacur, Luis Goncalves, Crystal Wood, Costa Shulyupin,
Wander Lairson Costa, LKML, linux-trace-kernel
Currently, runtime tests only test the osnoise period option
(-p/--period of rtla-osnoise tools, backed by
/sys/kernel/tracing/osnoise/period_us), using the
check_with_osnoise_options function together with a hack relying on long
period (pre-set) timing out if RTLA fails to reset it to the default
value.
Extend tracer option testing to all options used by RTLA; test both RTLA
setting the default option by pre-setting the tracer to a different
value and user-requested value.
The tests are done using a script that reads the tracer values inside an
--on-threshold action, like existing tests for runtime behavior already
do. check_with_osnoise_option is modified to support grep filters, so
that it can be used together with the script pattern.
Assisted-by: Claude:claude-opus-4-6
Signed-off-by: Tomas Glozar <tglozar@redhat.com>
---
tools/tracing/rtla/tests/engine.sh | 41 +++++++++++--------
tools/tracing/rtla/tests/hwnoise.t | 3 ++
tools/tracing/rtla/tests/osnoise.t | 37 +++++++++++++++--
.../tests/scripts/check-osnoise-option.sh | 16 ++++++++
.../rtla/tests/scripts/check-tracefs-value.sh | 11 +++++
tools/tracing/rtla/tests/timerlat.t | 38 +++++++++++++++++
6 files changed, 125 insertions(+), 21 deletions(-)
create mode 100755 tools/tracing/rtla/tests/scripts/check-osnoise-option.sh
create mode 100755 tools/tracing/rtla/tests/scripts/check-tracefs-value.sh
diff --git a/tools/tracing/rtla/tests/engine.sh b/tools/tracing/rtla/tests/engine.sh
index 5bf8453d354d6..4287cd64ac314 100644
--- a/tools/tracing/rtla/tests/engine.sh
+++ b/tools/tracing/rtla/tests/engine.sh
@@ -98,30 +98,37 @@ check() {
}
check_with_osnoise_options() {
- # Do the same as "check", but with pre-set osnoise options.
- # Note: rtla should reset the osnoise options, this is used to test
- # if it indeed does so.
- # Save original arguments
- arg1=$1
- arg2=$2
- arg3=$3
-
- # Apply osnoise options (if not dry run)
+ # Do the same as "check", but with pre-set tracefs options.
+ # Resets osnoise first, then writes the given tracefs option=value
+ # pairs before running the check with NO_RESET_OSNOISE=1.
+ # Arguments: test_name command exit_code expected_output [path=value ...]
+ # Each path is relative to /sys/kernel/tracing/
+ local arg1=$1
+ local arg2=$2
+ local arg3=$3
+ local arg4=$4
+ local opt option value
+
+ # Apply tracefs options (if not dry run)
if [ -n "$TEST_COUNT" ]
then
[ "$NO_RESET_OSNOISE" == 1 ] || reset_osnoise
- shift
- shift
- while shift
+ shift 4
+ for opt in "$@"
do
- [ "$1" == "" ] && continue
- option=$(echo $1 | cut -d '=' -f 1)
- value=$(echo $1 | cut -d '=' -f 2)
- echo "$value" > "/sys/kernel/tracing/osnoise/$option" || return 1
+ [ -z "$opt" ] && continue
+ option="${opt%%=*}"
+ value="${opt#*=}"
+ # Try to apply the option, ignore errors: when pre-setting fails
+ # (e.g. kernel does not know the option), the test itself will likely
+ # also fail.
+ # Throwing an error here would cause the test to be incorrectly
+ # skipped.
+ echo "$value" > "/sys/kernel/tracing/$option"
done
fi
- NO_RESET_OSNOISE=1 check "$arg1" "$arg2" "$arg3"
+ NO_RESET_OSNOISE=1 check "$arg1" "$arg2" "$arg3" "$arg4"
}
check_top_hist() {
diff --git a/tools/tracing/rtla/tests/hwnoise.t b/tools/tracing/rtla/tests/hwnoise.t
index cfe687ff5ee1f..b53d8d440fc50 100644
--- a/tools/tracing/rtla/tests/hwnoise.t
+++ b/tools/tracing/rtla/tests/hwnoise.t
@@ -18,5 +18,8 @@ check "stop the trace if a single sample is higher than 1 us" \
check "enable a trace event trigger" \
"hwnoise -t -e osnoise:irq_noise --trigger=\"hist:key=desc,duration:sort=desc,duration:vals=hitcount\" -d 10s" \
0 "Saving event osnoise:irq_noise hist to osnoise_irq_noise_hist.txt"
+check "verify OSNOISE_IRQ_DISABLE" \
+ "hwnoise -S 1 --on-threshold shell,command=\"$testdir/scripts/check-osnoise-option.sh OSNOISE_IRQ_DISABLE\"" \
+ 2 "^OSNOISE_IRQ_DISABLE=enabled$"
test_end
diff --git a/tools/tracing/rtla/tests/osnoise.t b/tools/tracing/rtla/tests/osnoise.t
index 346a14a860c82..f773156e758fd 100644
--- a/tools/tracing/rtla/tests/osnoise.t
+++ b/tools/tracing/rtla/tests/osnoise.t
@@ -42,11 +42,40 @@ check "hist with --no-index" \
check "hist with --no-summary" \
"osnoise hist --no-summary -d 1s" 0 "" "^count:"
-# Test setting default period by putting an absurdly high period
-# and stopping on threshold.
-# If default period is not set, this will time out.
+# Tracer option tests - verify that rtla correctly sets tracefs options
+# Default tests: poison tracefs with wrong values, verify rtla resets to defaults
check_with_osnoise_options "apply default period" \
- "osnoise hist -s 1" 2 period_us=600000000
+ "osnoise top -q -S 1 --on-threshold shell,command=\"$testdir/scripts/check-tracefs-value.sh osnoise/period_us\"" \
+ 2 "^osnoise/period_us=1000000$" osnoise/period_us=600000000
+check_with_osnoise_options "apply default runtime" \
+ "osnoise top -q -S 1 --on-threshold shell,command=\"$testdir/scripts/check-tracefs-value.sh osnoise/runtime_us\"" \
+ 2 "^osnoise/runtime_us=1000000$" osnoise/runtime_us=100
+check_with_osnoise_options "apply default tracing_thresh" \
+ "osnoise top -q -S 1 --on-threshold shell,command=\"$testdir/scripts/check-tracefs-value.sh tracing_thresh\"" \
+ 2 "^tracing_thresh=0$" tracing_thresh=999999
+check_with_osnoise_options "apply default stop_tracing_us" \
+ "osnoise top -q -S 1 --on-threshold shell,command=\"$testdir/scripts/check-tracefs-value.sh osnoise/stop_tracing_us\"" \
+ 2 "^osnoise/stop_tracing_us=0$" osnoise/stop_tracing_us=999999
+check_with_osnoise_options "apply default stop_tracing_total_us" \
+ "osnoise top -q -s 1 --on-threshold shell,command=\"$testdir/scripts/check-tracefs-value.sh osnoise/stop_tracing_total_us\"" \
+ 2 "^osnoise/stop_tracing_total_us=0$" osnoise/stop_tracing_total_us=999999
+
+# Non-default tracer option tests: verify CLI options correctly set tracefs values
+check_top_q_hist "verify -p sets period_us" \
+ "osnoise TOOL -p 2000000 -S 1 --on-threshold shell,command=\"$testdir/scripts/check-tracefs-value.sh osnoise/period_us\"" \
+ 2 "^osnoise/period_us=2000000$"
+check_top_q_hist "verify -r sets runtime_us" \
+ "osnoise TOOL -r 500000 -S 1 --on-threshold shell,command=\"$testdir/scripts/check-tracefs-value.sh osnoise/runtime_us\"" \
+ 2 "^osnoise/runtime_us=500000$"
+check_top_q_hist "verify -T sets tracing_thresh" \
+ "osnoise TOOL -T 5 -S 1 --on-threshold shell,command=\"$testdir/scripts/check-tracefs-value.sh tracing_thresh\"" \
+ 2 "^tracing_thresh=5$"
+check_top_q_hist "verify -s sets stop_tracing_us" \
+ "osnoise TOOL -s 30 -S 1 --on-threshold shell,command=\"$testdir/scripts/check-tracefs-value.sh osnoise/stop_tracing_us\"" \
+ 2 "^osnoise/stop_tracing_us=30$"
+check_top_q_hist "verify -S sets stop_tracing_total_us" \
+ "osnoise TOOL -S 100 --on-threshold shell,command=\"$testdir/scripts/check-tracefs-value.sh osnoise/stop_tracing_total_us\"" \
+ 2 "^osnoise/stop_tracing_total_us=100$"
# Actions tests
check_top_q_hist "trace output through -t with custom filename" \
diff --git a/tools/tracing/rtla/tests/scripts/check-osnoise-option.sh b/tools/tracing/rtla/tests/scripts/check-osnoise-option.sh
new file mode 100755
index 0000000000000..37c62268cc151
--- /dev/null
+++ b/tools/tracing/rtla/tests/scripts/check-osnoise-option.sh
@@ -0,0 +1,16 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+# Check if osnoise options are enabled or disabled.
+# Usage: check-osnoise-option.sh <OPTION1> [<OPTION2> ...]
+# Output: one line per option in the format "OPTION=enabled" or "OPTION=disabled"
+
+options=$(tr ' ' '\n' < /sys/kernel/tracing/osnoise/options)
+for name in "$@"; do
+ if echo "$options" | grep -q "^NO_${name}$"; then
+ echo "$name=disabled"
+ elif echo "$options" | grep -q "^${name}$"; then
+ echo "$name=enabled"
+ else
+ echo "$name=unsupported"
+ fi
+done
diff --git a/tools/tracing/rtla/tests/scripts/check-tracefs-value.sh b/tools/tracing/rtla/tests/scripts/check-tracefs-value.sh
new file mode 100755
index 0000000000000..12d0eacd6a85d
--- /dev/null
+++ b/tools/tracing/rtla/tests/scripts/check-tracefs-value.sh
@@ -0,0 +1,11 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+# Read tracefs values and print them.
+# Usage: check-tracefs-value.sh <relative_path1> [<relative_path2> ...]
+# Each path is relative to /sys/kernel/tracing/
+# Output: one line per file in the format "path=value"
+
+for file in "$@"; do
+ read value < "/sys/kernel/tracing/$file"
+ echo "$file=$value"
+done
diff --git a/tools/tracing/rtla/tests/timerlat.t b/tools/tracing/rtla/tests/timerlat.t
index 8193048e8c8ce..aa5b91d88ca4b 100644
--- a/tools/tracing/rtla/tests/timerlat.t
+++ b/tools/tracing/rtla/tests/timerlat.t
@@ -55,6 +55,44 @@ check_top_q_hist "verify -k/--kernel-threads" \
check_top_q_hist "verify -u/--user-threads" \
"timerlat TOOL -u -c 0 -d 10s -T 1 --on-threshold shell,command=$testdir/scripts/check-user-kernel-threads.sh" 2 "0 kernel threads, 1 user threads"
+# Tracer option tests - verify that rtla correctly sets tracefs options
+# Default tests: poison tracefs with wrong values, verify rtla resets to defaults
+check_with_osnoise_options "apply default timerlat_period_us" \
+ "timerlat top -q -T 1 --on-threshold shell,command=\"$testdir/scripts/check-tracefs-value.sh osnoise/timerlat_period_us\"" \
+ 2 "^osnoise/timerlat_period_us=1000$" osnoise/timerlat_period_us=999999
+check_with_osnoise_options "apply default print_stack" \
+ "timerlat top -q -T 1 --on-threshold shell,command=\"$testdir/scripts/check-tracefs-value.sh osnoise/print_stack\"" \
+ 2 "^osnoise/print_stack=0$" osnoise/print_stack=999999
+check_with_osnoise_options "apply default stop_tracing_us" \
+ "timerlat top -q -T 1 --on-threshold shell,command=\"$testdir/scripts/check-tracefs-value.sh osnoise/stop_tracing_us\"" \
+ 2 "^osnoise/stop_tracing_us=0$" osnoise/stop_tracing_us=999999
+check_with_osnoise_options "apply default stop_tracing_total_us" \
+ "timerlat top -q -i 1 --on-threshold shell,command=\"$testdir/scripts/check-tracefs-value.sh osnoise/stop_tracing_total_us\"" \
+ 2 "^osnoise/stop_tracing_total_us=0$" osnoise/stop_tracing_total_us=999999
+
+# Non-default tracer option tests: verify CLI options correctly set tracefs values
+check_top_q_hist "verify -p sets timerlat_period_us" \
+ "timerlat TOOL -p 2000 -T 1 --on-threshold shell,command=\"$testdir/scripts/check-tracefs-value.sh osnoise/timerlat_period_us\"" \
+ 2 "^osnoise/timerlat_period_us=2000$"
+check_top_q_hist "verify -s sets print_stack" \
+ "timerlat TOOL -s 5 -T 1 --on-threshold shell,command=\"$testdir/scripts/check-tracefs-value.sh osnoise/print_stack\"" \
+ 2 "^osnoise/print_stack=5$"
+check_top_q_hist "verify -i sets stop_tracing_us" \
+ "timerlat TOOL -i 2 --on-threshold shell,command=\"$testdir/scripts/check-tracefs-value.sh osnoise/stop_tracing_us\"" \
+ 2 "^osnoise/stop_tracing_us=2$"
+check_top_q_hist "verify -T sets stop_tracing_total_us" \
+ "timerlat TOOL -T 2 --on-threshold shell,command=\"$testdir/scripts/check-tracefs-value.sh osnoise/stop_tracing_total_us\"" \
+ 2 "^osnoise/stop_tracing_total_us=2$"
+check_with_osnoise_options "apply default TIMERLAT_ALIGN" \
+ "timerlat top -q -T 1 --on-threshold shell,command=\"$testdir/scripts/check-osnoise-option.sh TIMERLAT_ALIGN\"" \
+ 2 "^TIMERLAT_ALIGN=disabled$" osnoise/options=TIMERLAT_ALIGN
+check_top_q_hist "verify -A sets TIMERLAT_ALIGN" \
+ "timerlat TOOL -A 100 -T 1 --on-threshold shell,command=\"$testdir/scripts/check-osnoise-option.sh TIMERLAT_ALIGN\"" \
+ 2 "^TIMERLAT_ALIGN=enabled$"
+check_top_q_hist "verify -A sets timerlat_align_us" \
+ "timerlat TOOL -A 100 -T 1 --on-threshold shell,command=\"$testdir/scripts/check-tracefs-value.sh osnoise/timerlat_align_us\"" \
+ 2 "^osnoise/timerlat_align_us=100$"
+
# Histogram tests
check "hist with -b/--bucket-size" \
"timerlat hist -b 1 -d 1s"
--
2.55.0
^ permalink raw reply related
* Re: [PATCH v2 4/4] mm/mlock: migrate folios out of CMA when mlocking a range
From: Sebastian Andrzej Siewior @ 2026-07-09 9:13 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Wandun Chen, vbabka, david, rostedt, mhiramat, Alexander.Krabler,
hughd, fvdl, linux-mm, linux-kernel, linux-trace-kernel,
linux-rt-devel, akpm, surenb, mhocko, jackmanb, hannes, ziy, riel,
liam, harry, jannh, lance.yang, mathieu.desnoyers, matthew.brost,
joshua.hahnjy, rakie.kim, byungchul, gourry, ying.huang, apopple,
pfalcato
In-Reply-To: <ak0OZKzapUefmA3v@lucifer>
On 2026-07-07 15:54:57 [+0100], Lorenzo Stoakes wrote:
> On Tue, Jul 07, 2026 at 08:59:25PM +0800, Wandun Chen wrote:
> > From: Wandun Chen <chenwandun@lixiang.com>
> >
> > The region covered by mlock[all] may contain CMA pages. cma_alloc installs
> > migration entries in the page table, if a memory access occurs at this
> > point, it must wait for the migration to complete, which may cause
> > latency spikes on the RT kernels.
> >
> > Try to move the migration cost into the mlock[all] caller, which is
> > typically a setup path. So reduce the chance of latency spikes on RT
> > kernels by migrating the currently mapped CMA pages out of CMA region.
>
> 'reduce the chances of latency' so do you have any data to back this invasive
> change or not?
The application gets pages assigned which belong a CMA area. If the
pages are in need by the CMA then those pages are replaced with other
pages during a migration phase. Since there is no guarantee how long
this will take and is also subject to general scheduling in the system
it will be measurable and painful once hit.
> And for RT, but nothing in here at all checks for RT? You're using this
> compaction sysctl as an RT check somehow? That's gross.
The man-page for mlock says that it guarantees to stay in RAM and/ or
preventing to be moved to swap area. I would however argue that
replacing physical pages in the background should fall under this since
the application can't access them and is blocked while trying. The notes
section (in the man-page) lists "real-time applications" and
"deterministic timing". Therefore I think it makes sense to do this
unconditionally for mlock areas regardless of the sysctl knob.
Security related application probably only care that their memory does
not hit the swap area and probably wouldn't mind 10ms delay.
> This doesn't feel like the right solution.
Sebastian
^ permalink raw reply
* Re: [PATCH v2 2/4] mm/mlock: wait for migration to finish when mlocking a folio
From: Sebastian Andrzej Siewior @ 2026-07-09 8:42 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Wandun Chen, vbabka, david, rostedt, mhiramat, Alexander.Krabler,
hughd, fvdl, linux-mm, linux-kernel, linux-trace-kernel,
linux-rt-devel, akpm, surenb, mhocko, jackmanb, hannes, ziy, riel,
liam, harry, jannh, lance.yang, mathieu.desnoyers, matthew.brost,
joshua.hahnjy, rakie.kim, byungchul, gourry, ying.huang, apopple,
pfalcato
In-Reply-To: <ak0C-DP_1ZrTVSLj@lucifer>
On 2026-07-07 15:33:32 [+0100], Lorenzo Stoakes wrote:
> On Tue, Jul 07, 2026 at 08:59:23PM +0800, Wandun Chen wrote:
> > From: Wandun Chen <chenwandun@lixiang.com>
> >
> > In RT kernels, sysctl_compact_unevictable_allowed is false by default,
> > when the mlock/mlockall system call try to lock all the present page,
> > the mlock_pte_range function skips non-present entries. If these
> > non-present entries are migration entries, and the migration is not
> > guaranteed to have completed before the mlock/mlockall, it may result
> > in a page fault on subsequent access, which then waits for the
> > migration to finish, causing spike latency in RT kernels.
>
> Is this really noticable and measurable?
You want to avoid page faults like this which is why you do mlock in the
first place.
If the thread has a RT priority and it blocks here then other RT threads
will be scheduled and your migration thread, which will resolve this, is
SCHED_OTHER and the last one in the line. Assuming that thread has a 1ms
cycle/ deadline then it will likely miss it.
> I suppose not too many ranges should be mock
Sebastian
^ permalink raw reply
* Re: [PATCH v2 1/4] mm/migrate: do not migrate folios mapped into VM_LOCKED VMAs under compaction
From: Wandun @ 2026-07-09 8:25 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: vbabka, david, rostedt, mhiramat, Alexander.Krabler, hughd, fvdl,
bigeasy, linux-mm, linux-kernel, linux-trace-kernel,
linux-rt-devel, akpm, surenb, mhocko, jackmanb, hannes, ziy, riel,
liam, harry, jannh, lance.yang, mathieu.desnoyers, matthew.brost,
joshua.hahnjy, rakie.kim, byungchul, gourry, ying.huang, apopple,
pfalcato
In-Reply-To: <ak0EsCeucJarlI7G@lucifer>
On 7/7/26 21:55, Lorenzo Stoakes wrote:
> On Tue, Jul 07, 2026 at 02:44:50PM +0100, Lorenzo Stoakes wrote:
>> See above about deduplicating.
>>
>>> + ttu |= TTU_RESPECT_MLOCK;
>>
>> Hmm. I don't love 'respect mlock'. I guess we only know about the reason
>> being compaction here.
>>
>> But I'm confused anyway. We have the folio, why aren't we just checking for
>> PG_mlocked() here instead of getting the rmap to see if it's mapped
>> anywhere with VMA_LOCKED_BIT?
>
> Also, since compaction_allow_unevictable() is a function that is accessible
> elsewhere, you could literally just have a TTU_MIGRATION here instead and have
> the rmap logic call compaction_allow_unevictable() instead rather than this.
Do you mean:
1. change TTU_RESPECT_MLOCK to TTU_MIGRATION, that'is OK.
2. move call compaction_allow_unevictable() to try_to_migrate_one? but as you suggested
migrate_mlock_allowed function, it already called compaction_allow_unevictable()
in order to determine whether TTU_MIGRATION needs to be added. Did I misunderstand
something somewhere?
>
> And then you could adapt the function I suggested before not to take a reason
> parameter but rather a 'is_migration' one instead possibly and then pass (ttu &
> TTU_MIGRATION) in.
>
> BUT. I still question whether this is at all needed since you have the folio you
> can check for PG_mlocked...
I described a race scenario at this link:
https://lore.kernel.org/lkml/c372e68f-2bfc-45b6-a431-01bf55717247@gmail.com/
>
> Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH v3 15/17] selftests/verification: Fix wrong errexit assumption
From: Nam Cao @ 2026-07-09 8:14 UTC (permalink / raw)
To: Gabriele Monaco, linux-trace-kernel, linux-kernel, Steven Rostedt,
Gabriele Monaco, Shuah Khan, linux-kselftest
Cc: Thomas Weissschuh, Tomas Glozar, John Kacur, Wen Yang
In-Reply-To: <20260625121440.116317-16-gmonaco@redhat.com>
Gabriele Monaco <gmonaco@redhat.com> writes:
> RV selftest rely on bash errexit (set -e) to terminate with error, when
> a step is expected to return false, the following syntax is used:
>
> ! cmd
>
> This however prevents the test from exiting when cmd is false (desired)
> but doesn't exit if cmd is true, since commands prefixed with ! are
> explicitly excluded from errexit.
>
> Use the syntax
>
> ! cmd || false
>
> Which ends up checking the exit value of ! cmd and supplies a false
> command for errexit to evaluate.
>
> Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
Sounds reasonable.
Acked-by: Nam Cao <namcao@linutronix.de>
^ permalink raw reply
* Re: [PATCH v3 14/17] verification/rvgen: Add selftests for rvgen kunit
From: Nam Cao @ 2026-07-09 8:11 UTC (permalink / raw)
To: Gabriele Monaco, linux-trace-kernel, linux-kernel, Steven Rostedt,
Gabriele Monaco
Cc: Thomas Weissschuh, Tomas Glozar, John Kacur, Wen Yang
In-Reply-To: <20260625121440.116317-15-gmonaco@redhat.com>
Gabriele Monaco <gmonaco@redhat.com> writes:
> The rvgen kunit command patches monitor files and adds necessary
> definitions for kunit tests.
>
> Add a test case validating its behaviour on dummy generated files and
> comparing it against reference files, like it's done for rvgen monitor.
>
> Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
I am not entirely sure about this. In the future, when the generation
output is changed, all the references files also need to be updated. So
it's not clear to me if this really saves future development effort.
But well, we will see. For now:
Reviewed-by: Nam Cao <namcao@linutronix.de>
^ permalink raw reply
* Re: [PATCH v3 13/17] verification/rvgen: Add the rvgen kunit subcommand
From: Nam Cao @ 2026-07-09 8:02 UTC (permalink / raw)
To: Gabriele Monaco, linux-trace-kernel, linux-kernel, Steven Rostedt,
Gabriele Monaco
Cc: Thomas Weissschuh, Tomas Glozar, John Kacur, Wen Yang
In-Reply-To: <20260625121440.116317-14-gmonaco@redhat.com>
Gabriele Monaco <gmonaco@redhat.com> writes:
> + def print_files(self):
> +
> + handlers = self.__parse_attach_handlers()
> +
> + if not handlers:
> + print(f"No handlers found registered with rv_attach_trace_probe in {self.monitor_path}")
> + return
There is no valid monitor without any handler, right? If so, should we
throw an exception here?
> +
> + print("Found tracepoint handler(s):")
> + for handler in handlers:
> + print(f" - {handler}")
> +
> + prototypes = []
> + assignments = []
> + for handler in handlers:
> + arguments = self.__extract_function_args(handler)
> +
> + prototypes.append(f"void (*{handler})({arguments});")
> + assignments.append(f".{handler} = {handler},")
> +
> + struct_name = f"rv_{self.name}_ops"
> +
> + self.__fill_monitor_handlers(struct_name, assignments)
> +
> + dir_path = os.path.dirname(self.monitor_path)
> +
> + header_file_path = os.path.join(dir_path, f"{self.name}_kunit.h")
> + kunit_c_file_path = os.path.join(dir_path, f"{self.name}_kunit.c")
> +
> + use_backup = True
> + if os.path.exists(header_file_path) or os.path.exists(kunit_c_file_path):
> + try:
> + response = input("KUnit file(s) already exist. Overwrite? [y/N] (N for backup): ")
> + if response.strip().lower() in ("y", "yes"):
> + use_backup = False
> + except EOFError:
> + print("Non-interactive session detected, not overwriting existing files.")
> + else:
> + use_backup = False
> +
> + if use_backup:
> + header_file_path += ".bak"
> + kunit_c_file_path += ".bak"
This is the opposite of what other software do. Usually they copy the
original file to a different name (with a prefix or a suffix), and
overwrite the original file.
I think it's best to follow the usual practice to avoid confusion, maybe
something like this:
if os.path.exists(header_file_path) or os.path.exists(kunit_c_file_path):
try:
response = input("KUnit file(s) already exist. Backup? [Y/n]")
if not response.strip().lower() in ("n", "no"):
...rename the file...
except EOFError:
print("Non-interactive session detected, not overwriting existing files.")
Nam
^ permalink raw reply
* Re: [PATCH v3 06/11] mm/cma: Allow dynamically creating CMA areas
From: Marek Szyprowski @ 2026-07-09 5:56 UTC (permalink / raw)
To: David Hildenbrand (Arm), Thierry Reding, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Hunter,
Mikko Perttunen, Yury Norov, Rasmus Villemoes, Russell King,
Alexander Gordeev, Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, Andrew Morton,
Lorenzo Stoakes, Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Robin Murphy, Sumit Semwal,
Benjamin Gaignard, Brian Starkey, John Stultz, T.J. Mercier,
Christian König, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Catalin Marinas, Will Deacon
Cc: devicetree, linux-tegra, linux-kernel, dri-devel, linux-media,
linux-arm-kernel, linux-s390, linux-mm, iommu, linaro-mm-sig,
linux-trace-kernel
In-Reply-To: <e212caac-6c30-448a-9e10-32fff8b842f6@kernel.org>
On 08.07.2026 10:35, David Hildenbrand (Arm) wrote:
> On 7/7/26 12:02, Marek Szyprowski wrote:
>> On 01.07.2026 18:08, Thierry Reding wrote:
>>> From: Thierry Reding <treding@nvidia.com>
>>>
>>> There is no technical reason why there should be a limited number of CMA
>>> regions, so extract some code into helpers and use them to create extra
>>> functions (cma_create() and cma_free()) that allow creating and freeing,
>>> respectively, CMA regions dynamically at runtime.
>>
>> Well, the technical reason for not creating cma regions dynamically at
>> runtime is that on some architectures (like 32bit ARM) the early fixup
>> for the region is needed to make it functional for DMA.
> Can you point me at the code that does that? Thanks!
Check dma_contiguous_early_fixup() and dma_contiguous_remap() in
arch/arm/mm/dma-mapping.c. Those functions ensures that the CPU mappings for
the CMA reserved region in linear map are remapped with 4k pages instead
of the 1M sections, so later, it will be possible to alter the mappings and
change them to coherent when needed (altering 1M sections is not possible,
because each process has it's own level-1 array even for the kernel linear
mapping).
However, in the use case in this patchset the reserved region is only shared
with buddy allocator by using the CMA infrastructure, not registered to the
regular DMA-mapping API, so it would work fine. I'm not convinced that this
is the right API to use for this though.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* Re: [PATCH] selftests/ftrace: Fix reading enabled_functions in add_remove_fprobe_module test
From: Masami Hiramatsu @ 2026-07-09 5:38 UTC (permalink / raw)
To: Steven Rostedt
Cc: LKML, Linux Trace Kernel, linux-kselftest, Masami Hiramatsu,
Mathieu Desnoyers, Shuah Khan, Shuah Khan
In-Reply-To: <20260708153239.055d56dd@gandalf.local.home>
On Wed, 8 Jul 2026 15:32:39 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:
> From: Steven Rostedt <rostedt@goodmis.org>
>
> The add_remove_fprobe_module test checks the number of functions added to
> the enabled_functions file to make sure that the functions added or
> removed is as expected. The issue is that it expects this file to be empty
> on start up.
>
> Now that systemd uses BPF that attaches to functions via ftrace, this file
> is not empty in several systems:
>
> # cat /sys/kernel/tracing/enabled_functions
> bpf_lsm_file_open (1) R D M tramp: ftrace_regs_caller+0x0/0x61 (call_direct_funcs+0x0/0x50)
> direct(jmp)-->bpf_trampoline_6442529439+0x0/0xe9
>
> Change the test to read the number of lines in enabled_functions at the
> start of the test and subtract that from the value of the count for the
> checks within the test.
Oops, good catch! I need to make a test environment which uses
systemd...
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Thanks,
>
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> ---
> .../dynevent/add_remove_fprobe_module.tc | 27 ++++++++++++-------
> 1 file changed, 18 insertions(+), 9 deletions(-)
>
> diff --git a/tools/testing/selftests/ftrace/test.d/dynevent/add_remove_fprobe_module.tc b/tools/testing/selftests/ftrace/test.d/dynevent/add_remove_fprobe_module.tc
> index 2915206777b6..89660a9adf44 100644
> --- a/tools/testing/selftests/ftrace/test.d/dynevent/add_remove_fprobe_module.tc
> +++ b/tools/testing/selftests/ftrace/test.d/dynevent/add_remove_fprobe_module.tc
> @@ -16,23 +16,32 @@ echo > dynamic_events
> FUNC1='foo_bar*'
> FUNC2='vfs_read'
>
> +:;: "Save enabled functions count" ;:
> +ecount=`cat enabled_functions | wc -l`
> +
> +count_enabled_functions() {
> + count=`cat enabled_functions | wc -l`
> + count=$(($count-$ecount))
> + echo $count
> +}
> +
> :;: "Add an event on the test module" ;:
> echo "f:test1 $FUNC1" >> dynamic_events
> echo 1 > events/fprobes/test1/enable
>
> :;: "Ensure it is enabled" ;:
> -funcs=`cat enabled_functions | wc -l`
> +funcs=`count_enabled_functions`
> test $funcs -ne 0
>
> :;: "Check the enabled_functions is cleared on unloading" ;:
> rmmod trace-events-sample
> -funcs=`cat enabled_functions | wc -l`
> +funcs=`count_enabled_functions`
> test $funcs -eq 0
>
> :;: "Check it is kept clean" ;:
> modprobe trace-events-sample
> echo 1 > events/fprobes/test1/enable || echo "OK"
> -funcs=`cat enabled_functions | wc -l`
> +funcs=`count_enabled_functions`
> test $funcs -eq 0
>
> :;: "Add another event not on the test module" ;:
> @@ -40,19 +49,19 @@ echo "f:test2 $FUNC2" >> dynamic_events
> echo 1 > events/fprobes/test2/enable
>
> :;: "Ensure it is enabled" ;:
> -ofuncs=`cat enabled_functions | wc -l`
> +ofuncs=`count_enabled_functions`
> test $ofuncs -ne 0
>
> :;: "Disable and remove the first event"
> echo 0 > events/fprobes/test1/enable
> echo "-:fprobes/test1" >> dynamic_events
> -funcs=`cat enabled_functions | wc -l`
> +funcs=`count_enabled_functions`
> test $ofuncs -eq $funcs
>
> :;: "Disable and remove other events" ;:
> echo 0 > events/fprobes/enable
> echo > dynamic_events
> -funcs=`cat enabled_functions | wc -l`
> +funcs=`count_enabled_functions`
> test $funcs -eq 0
>
> rmmod trace-events-sample
> @@ -63,12 +72,12 @@ echo "f:test1 $FUNC1" >> dynamic_events
> echo 1 > events/fprobes/test1/enable
> echo "f:test2 $FUNC2" >> dynamic_events
> echo 1 > events/fprobes/test2/enable
> -ofuncs=`cat enabled_functions | wc -l`
> +ofuncs=`count_enabled_functions`
> test $ofuncs -ne 0
>
> :;: "Unload module (ftrace entry should be removed)" ;:
> rmmod trace-events-sample
> -funcs=`cat enabled_functions | wc -l`
> +funcs=`count_enabled_functions`
> test $funcs -ne 0
> test $ofuncs -ne $funcs
>
> @@ -77,7 +86,7 @@ echo 0 > events/fprobes/test2/enable
> echo "-:fprobes/test2" >> dynamic_events
>
> :;: "Ensure ftrace is disabled." ;:
> -funcs=`cat enabled_functions | wc -l`
> +funcs=`count_enabled_functions`
> test $funcs -eq 0
>
> echo 0 > events/fprobes/enable
> --
> 2.53.0
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH] selftests/tracing: Have trigger-hist-poll.tc use sched_process_exit
From: Masami Hiramatsu @ 2026-07-09 4:58 UTC (permalink / raw)
To: Steven Rostedt
Cc: LKML, Linux Trace Kernel, linux-kselftest, Masami Hiramatsu,
Mathieu Desnoyers, Shuah Khan, Shuah Khan
In-Reply-To: <20260708163731.566a86aa@gandalf.local.home>
On Wed, 8 Jul 2026 16:37:31 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:
> On Wed, 8 Jul 2026 16:35:39 -0400
> Steven Rostedt <rostedt@goodmis.org> wrote:
>
> > I forgot to mention that I tested this with and without CONFIG_RCU_LAZY.
> > With that config disabled, the test passes. With it enabled, it always
> > fails.
>
> And I also traced it with:
>
> trace-cmd set -p function_graph -l event_hist_poll -O funcgraph-retval
>
> and it shows the sched_process_free being called for the sleep process
> *after* the poll finishes.
Thanks for fix and tested!!
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
>
> -- Steve
--
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