* [PATCH] rv: Fix dead link to monitor_synthesis.rst
From: Soham Metha @ 2025-12-03 20:22 UTC (permalink / raw)
To: linux-kernel-mentees
Cc: shuah, skhan, linux-kernel, Soham Metha, Steven Rostedt,
Gabriele Monaco, linux-trace-kernel
The file 'da_monitor_synthesis.rst' was renamed to 'monitor_synthesis.rst' in
commit f40a7c060207
("Documentation/rv: Prepare monitor synthesis document for LTL inclusion").
Update the reference to point to the new filename.
Signed-off-by: Soham Metha <sohammetha01@gmail.com>
---
No functional changes.
include/rv/da_monitor.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/rv/da_monitor.h b/include/rv/da_monitor.h
index 17fa4f6e5ea6..c2cea209f230 100644
--- a/include/rv/da_monitor.h
+++ b/include/rv/da_monitor.h
@@ -8,7 +8,7 @@
* The dot2k tool is available at tools/verification/dot2k/
*
* For further information, see:
- * Documentation/trace/rv/da_monitor_synthesis.rst
+ * Documentation/trace/rv/monitor_synthesis.rst
*/
#include <rv/automata.h>
--
2.34.1
^ permalink raw reply related
* Re: [PATCHv4 bpf-next 1/9] ftrace,bpf: Remove FTRACE_OPS_FL_JMP ftrace_ops flag
From: Jiri Olsa @ 2025-12-03 20:23 UTC (permalink / raw)
To: Menglong Dong
Cc: Steven Rostedt, Florent Revest, Mark Rutland, bpf, linux-kernel,
linux-trace-kernel, linux-arm-kernel, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Song Liu
In-Reply-To: <CADxym3awpEbMiSKE5aDcyd2Cg1Cdo7++SLAMSuZmaggt3BSbUA@mail.gmail.com>
On Wed, Dec 03, 2025 at 05:15:52PM +0800, Menglong Dong wrote:
> On Wed, Dec 3, 2025 at 4:24 PM Jiri Olsa <jolsa@kernel.org> wrote:
> >
> > At the moment the we allow the jmp attach only for ftrace_ops that
> > has FTRACE_OPS_FL_JMP set. This conflicts with following changes
> > where we use single ftrace_ops object for all direct call sites,
> > so all could be be attached via just call or jmp.
> >
> > We already limit the jmp attach support with config option and bit
> > (LSB) set on the trampoline address. It turns out that's actually
> > enough to limit the jmp attach for architecture and only for chosen
> > addresses (with LSB bit set).
> >
> > Each user of register_ftrace_direct or modify_ftrace_direct can set
> > the trampoline bit (LSB) to indicate it has to be attached by jmp.
> >
> > The bpf trampoline generation code uses trampoline flags to generate
> > jmp-attach specific code and ftrace inner code uses the trampoline
> > bit (LSB) to handle return from jmp attachment, so there's no harm
> > to remove the FTRACE_OPS_FL_JMP bit.
> >
> > The fexit/fmodret performance stays the same (did not drop),
> > current code:
> >
> > fentry : 77.904 ± 0.546M/s
> > fexit : 62.430 ± 0.554M/s
> > fmodret : 66.503 ± 0.902M/s
> >
> > with this change:
> >
> > fentry : 80.472 ± 0.061M/s
> > fexit : 63.995 ± 0.127M/s
> > fmodret : 67.362 ± 0.175M/s
> >
> > Fixes: 25e4e3565d45 ("ftrace: Introduce FTRACE_OPS_FL_JMP")
> > Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> > ---
> > include/linux/ftrace.h | 1 -
> > kernel/bpf/trampoline.c | 32 ++++++++++++++------------------
> > kernel/trace/ftrace.c | 14 --------------
> > 3 files changed, 14 insertions(+), 33 deletions(-)
> >
> > diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
> > index 015dd1049bea..505b7d3f5641 100644
> > --- a/include/linux/ftrace.h
> > +++ b/include/linux/ftrace.h
> > @@ -359,7 +359,6 @@ enum {
> > FTRACE_OPS_FL_DIRECT = BIT(17),
> > FTRACE_OPS_FL_SUBOP = BIT(18),
> > FTRACE_OPS_FL_GRAPH = BIT(19),
> > - FTRACE_OPS_FL_JMP = BIT(20),
>
> Yeah, the FTRACE_OPS_FL_JMP is not necessary. I added
> it in case that we maybe want to implement such "jmp" for
> ftrace trampoline in the feature. But it's OK to remove it now.
>
> > };
> >
> > #ifndef CONFIG_DYNAMIC_FTRACE_WITH_ARGS
> > diff --git a/kernel/bpf/trampoline.c b/kernel/bpf/trampoline.c
> > index 976d89011b15..b9a358d7a78f 100644
> > --- a/kernel/bpf/trampoline.c
> > +++ b/kernel/bpf/trampoline.c
> > @@ -214,10 +214,15 @@ static int modify_fentry(struct bpf_trampoline *tr, u32 orig_flags,
> > int ret;
> >
> > if (tr->func.ftrace_managed) {
> > + unsigned long addr = (unsigned long) new_addr;
> > +
> > + if (bpf_trampoline_use_jmp(tr->flags))
> > + addr = ftrace_jmp_set(addr);
I wanted to get rid of the void * -> unsigned long casting in all the
places.. this way it has to be just on one place above, but maybe we
could have already direct_ops_add with unsigned long addr, will check
jirka
>
> nit: It seems that we can remove the variable "addr" can use
> the "new_addr" directly?
>
> > +
> > if (lock_direct_mutex)
> > - ret = modify_ftrace_direct(tr->fops, (long)new_addr);
> > + ret = modify_ftrace_direct(tr->fops, addr);
> > else
> > - ret = modify_ftrace_direct_nolock(tr->fops, (long)new_addr);
> > + ret = modify_ftrace_direct_nolock(tr->fops, addr);
> > } else {
> > ret = bpf_trampoline_update_fentry(tr, orig_flags, old_addr,
> > new_addr);
> > @@ -240,10 +245,15 @@ static int register_fentry(struct bpf_trampoline *tr, void *new_addr)
> > }
> >
> > if (tr->func.ftrace_managed) {
> > + unsigned long addr = (unsigned long) new_addr;
> > +
> > + if (bpf_trampoline_use_jmp(tr->flags))
> > + addr = ftrace_jmp_set(addr);
>
> And here.
>
> Thanks!
> Menglong Dong
>
> > +
> [...]
> >
^ permalink raw reply
* Re: [PATCHv4 bpf-next 4/9] ftrace: Add update_ftrace_direct_add function
From: Jiri Olsa @ 2025-12-03 20:25 UTC (permalink / raw)
To: bot+bpf-ci
Cc: rostedt, revest, mark.rutland, bpf, linux-kernel,
linux-trace-kernel, linux-arm-kernel, ast, daniel, andrii,
menglong8.dong, song, martin.lau, eddyz87, yonghong.song, clm,
ihor.solodrai
In-Reply-To: <d0d8e0d78f614eb8b443772b50fb36093d48c7f43374316246ad3ad836b5c9ce@mail.kernel.org>
On Wed, Dec 03, 2025 at 08:47:45AM +0000, bot+bpf-ci@kernel.org wrote:
> > diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
> > index 8c034b028..eb60d971e 100644
> > --- a/include/linux/ftrace.h
> > +++ b/include/linux/ftrace.h
>
> [ ... ]
>
> > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> > index 84aee9096..1660a8754 100644
> > --- a/kernel/trace/ftrace.c
> > +++ b/kernel/trace/ftrace.c
>
> [ ... ]
>
> > +int update_ftrace_direct_add(struct ftrace_ops *ops, struct ftrace_hash *hash)
> > +{
> > + struct ftrace_hash *old_direct_functions = NULL, *new_direct_functions = NULL;
> > + struct ftrace_hash *old_filter_hash = NULL, *new_filter_hash = NULL;
> > + struct ftrace_func_entry *entry;
> > + int i, size, err = -EINVAL;
> > + bool reg;
> > +
> > + if (!hash_count(hash))
> > + return -EINVAL;
> > +
> > + mutex_lock(&direct_mutex);
> > +
> > + /* Make sure requested entries are not already registered. */
> > + size = 1 << hash->size_bits;
> > + for (i = 0; i < size; i++) {
> > + hlist_for_each_entry(entry, &hash->buckets[i], hlist) {
> > + if (__ftrace_lookup_ip(direct_functions, entry->ip))
> > + goto out_unlock;
> > + }
> > + }
> > +
> > + old_filter_hash = ops->func_hash ? ops->func_hash->filter_hash : NULL;
> > + old_direct_functions = direct_functions;
> > +
> > + /* If there's nothing in filter_hash we need to register the ops. */
> > + reg = hash_count(old_filter_hash) == 0;
> > + if (reg) {
> > + if (ops->func || ops->trampoline)
> > + goto out_unlock;
> > + if (ops->flags & FTRACE_OPS_FL_ENABLED)
> > + goto out_unlock;
> > + }
> > +
> > + err = -ENOMEM;
> > + new_filter_hash = hash_add(old_filter_hash, hash);
> > + if (!new_filter_hash)
> > + goto out_unlock;
> > +
> > + new_direct_functions = hash_add(old_direct_functions, hash);
> > + if (!new_direct_functions)
> > + goto out_unlock;
>
> Can new_filter_hash leak here? If the second hash_add() fails but the
> first one succeeds, update_ftrace_direct_add() will goto out_unlock
> with new_filter_hash pointing to allocated memory. At out_unlock, only
> old_filter_hash gets freed, not new_filter_hash.
mamma mia, can't get this right apparently.. yea, will fix in next
version, thanks
jirka
>
> register_ftrace_direct() handles this by freeing new_hash on error:
>
> out_unlock:
> mutex_unlock(&direct_mutex);
>
> if (free_hash && free_hash != EMPTY_HASH)
> call_rcu_tasks(&free_hash->rcu, register_ftrace_direct_cb);
>
> if (new_hash)
> free_ftrace_hash(new_hash);
>
> return err;
>
> > +
> > + rcu_assign_pointer(direct_functions, new_direct_functions);
> > +
> > + if (reg) {
> > + ops->func = call_direct_funcs;
> > + ops->flags |= MULTI_FLAGS;
> > + ops->trampoline = FTRACE_REGS_ADDR;
> > + ops->local_hash.filter_hash = new_filter_hash;
> > +
> > + err = register_ftrace_function_nolock(ops);
> > + if (err) {
> > + /* restore old filter on error */
> > + ops->local_hash.filter_hash = old_filter_hash;
> > + old_filter_hash = new_filter_hash;
> > +
> > + /* cleanup for possible another register call */
> > + ops->func = NULL;
> > + ops->trampoline = 0;
> > + }
> > + } else {
> > + err = ftrace_update_ops(ops, new_filter_hash, EMPTY_HASH);
> > + /*
> > + * new_filter_hash is dup-ed, so we need to release it anyway,
> > + * old_filter_hash either stays on error or is released already
> > + */
> > + old_filter_hash = new_filter_hash;
> > + }
> > +
> > + if (err) {
> > + /* reset direct_functions and free the new one */
> > + rcu_assign_pointer(direct_functions, old_direct_functions);
> > + old_direct_functions = new_direct_functions;
> > + }
> > +
> > + out_unlock:
> > + mutex_unlock(&direct_mutex);
> > +
> > + if (old_direct_functions && old_direct_functions != EMPTY_HASH)
> > + call_rcu_tasks(&old_direct_functions->rcu, register_ftrace_direct_cb);
> > + if (old_filter_hash)
> > + free_ftrace_hash(old_filter_hash);
> > +
> > + return err;
> > +}
>
>
> ---
> 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/19887401362
^ permalink raw reply
* Re: [PATCH v13 mm-new 07/16] khugepaged: introduce collapse_max_ptes_none helper function
From: Nico Pache @ 2025-12-03 21:02 UTC (permalink / raw)
To: akpm, linux-kernel, linux-trace-kernel, linux-mm, linux-doc
Cc: david, ziy, baolin.wang, lorenzo.stoakes, Liam.Howlett,
ryan.roberts, dev.jain, corbet, rostedt, mhiramat,
mathieu.desnoyers, baohua, willy, peterx, wangkefeng.wang,
usamaarif642, sunnanyong, vishal.moola, thomas.hellstrom, yang,
kas, aarcange, raquini, anshuman.khandual, catalin.marinas, tiwai,
will, dave.hansen, jack, cl, jglisse, surenb, zokeefe, hannes,
rientjes, mhocko, rdunlap, hughd, richard.weiyang, lance.yang,
vbabka, rppt, jannh, pfalcato
In-Reply-To: <20251201174627.23295-8-npache@redhat.com>
Hi Andrew,
The bot has reported a potential uninitialized use of a variable.
Can you please squash the following fixup to this commit.
Thank you,
Nico
----8<----
From 846f79d91a25ebad76cbab3690ae315cfe3cf278 Mon Sep 17 00:00:00 2001
From: Nico Pache <npache@redhat.com>
Date: Wed, 3 Dec 2025 13:42:18 -0700
Subject: [PATCH] khugepaged: fixup unintialized _pte variable
There is a potential use of an uninitialized variable after
`khugepaged: introduce collapse_max_ptes_none helper function`
Andrew can you please append this to Patch 7 of my series
as reported by the kernel test robot
>> mm/khugepaged.c:593:6: warning: variable '_pte' is used uninitialized
whenever 'if' condition is true [-Wsometimes-uninitialized]
593 | if (max_ptes_none == -EINVAL)
| ^~~~~~~~~~~~~~~~~~~~~~~~
mm/khugepaged.c:724:25: note: uninitialized use occurs here
724 | release_pte_pages(pte, _pte, compound_pagelist);
| ^~~~
mm/khugepaged.c:593:2: note: remove the 'if' if its condition is always false
593 | if (max_ptes_none == -EINVAL)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
594 | goto out;
| ~~~~~~~~
mm/khugepaged.c:588:13: note: initialize the variable '_pte' to silence this warning
588 | pte_t *_pte;
| ^
| = NULL
1 warning generated.
Signed-off-by: Nico Pache <npache@redhat.com>
---
mm/khugepaged.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index f425238d5d4f..7c7d04d6737e 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -585,7 +585,7 @@ static int __collapse_huge_page_isolate(struct
vm_area_struct *vma,
struct page *page = NULL;
struct folio *folio = NULL;
unsigned long addr = start_addr;
- pte_t *_pte;
+ pte_t *_pte = pte;
int none_or_zero = 0, shared = 0, result = SCAN_FAIL, referenced = 0;
const unsigned long nr_pages = 1UL << order;
int max_ptes_none = collapse_max_ptes_none(order, !cc->is_khugepaged);
@@ -593,8 +593,7 @@ static int __collapse_huge_page_isolate(struct
vm_area_struct *vma,
if (max_ptes_none == -EINVAL)
goto out;
- for (_pte = pte; _pte < pte + nr_pages;
- _pte++, addr += PAGE_SIZE) {
+ for (; _pte < pte + nr_pages; _pte++, addr += PAGE_SIZE) {
pte_t pteval = ptep_get(_pte);
if (pte_none_or_zero(pteval)) {
++none_or_zero;
--
2.52.0
On 12/1/25 10:46 AM, Nico Pache wrote:
> The current mechanism for determining mTHP collapse scales the
> khugepaged_max_ptes_none value based on the target order. This
> introduces an undesirable feedback loop, or "creep", when max_ptes_none
> is set to a value greater than HPAGE_PMD_NR / 2.
>
> With this configuration, a successful collapse to order N will populate
> enough pages to satisfy the collapse condition on order N+1 on the next
> scan. This leads to unnecessary work and memory churn.
>
> To fix this issue introduce a helper function that will limit mTHP
> collapse support to two max_ptes_none values, 0 and HPAGE_PMD_NR - 1.
> This effectively supports two modes:
>
> - max_ptes_none=0: never introduce new none-pages for mTHP collapse.
> - max_ptes_none=511 (on 4k pagesz): Always collapse to the highest
> available mTHP order.
>
> This removes the possiblilty of "creep", while not modifying any uAPI
> expectations. A warning will be emitted if any non-supported
> max_ptes_none value is configured with mTHP enabled.
>
> The limits can be ignored by passing full_scan=true, this is useful for
> madvise_collapse (which ignores limits), or in the case of
> collapse_scan_pmd(), allows the full PMD to be scanned when mTHP
> collapse is available.
>
> Signed-off-by: Nico Pache <npache@redhat.com>
> ---
> mm/khugepaged.c | 43 ++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 42 insertions(+), 1 deletion(-)
>
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index 8dab49c53128..f425238d5d4f 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -463,6 +463,44 @@ void __khugepaged_enter(struct mm_struct *mm)
> wake_up_interruptible(&khugepaged_wait);
> }
>
> +/**
> + * collapse_max_ptes_none - Calculate maximum allowed empty PTEs for collapse
> + * @order: The folio order being collapsed to
> + * @full_scan: Whether this is a full scan (ignore limits)
> + *
> + * For madvise-triggered collapses (full_scan=true), all limits are bypassed
> + * and allow up to HPAGE_PMD_NR - 1 empty PTEs.
> + *
> + * For PMD-sized collapses (order == HPAGE_PMD_ORDER), use the configured
> + * khugepaged_max_ptes_none value.
> + *
> + * For mTHP collapses, we currently only support khugepaged_max_pte_none values
> + * of 0 or (HPAGE_PMD_NR - 1). Any other value will emit a warning and no mTHP
> + * collapse will be attempted
> + *
> + * Return: Maximum number of empty PTEs allowed for the collapse operation
> + */
> +static unsigned int collapse_max_ptes_none(unsigned int order, bool full_scan)
> +{
> + /* ignore max_ptes_none limits */
> + if (full_scan)
> + return HPAGE_PMD_NR - 1;
> +
> + if (!is_mthp_order(order))
> + return khugepaged_max_ptes_none;
> +
> + /* Zero/non-present collapse disabled. */
> + if (!khugepaged_max_ptes_none)
> + return 0;
> +
> + if (khugepaged_max_ptes_none == HPAGE_PMD_NR - 1)
> + return (1 << order) - 1;
> +
> + pr_warn_once("mTHP collapse only supports max_ptes_none values of 0 or %d\n",
> + HPAGE_PMD_NR - 1);
> + return -EINVAL;
> +}
> +
> void khugepaged_enter_vma(struct vm_area_struct *vma,
> vm_flags_t vm_flags)
> {
> @@ -550,7 +588,10 @@ static int __collapse_huge_page_isolate(struct vm_area_struct *vma,
> pte_t *_pte;
> int none_or_zero = 0, shared = 0, result = SCAN_FAIL, referenced = 0;
> const unsigned long nr_pages = 1UL << order;
> - int max_ptes_none = khugepaged_max_ptes_none >> (HPAGE_PMD_ORDER - order);
> + int max_ptes_none = collapse_max_ptes_none(order, !cc->is_khugepaged);
> +
> + if (max_ptes_none == -EINVAL)
> + goto out;
>
> for (_pte = pte; _pte < pte + nr_pages;
> _pte++, addr += PAGE_SIZE) {
^ permalink raw reply related
* Re: [PATCH v2 1/3] tracing: Remove unneeded event_mutex lock in event_trigger_regex_release()
From: Tom Zanussi @ 2025-12-03 22:38 UTC (permalink / raw)
To: Steven Rostedt, linux-kernel, linux-trace-kernel
Cc: Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton
In-Reply-To: <20251125214031.975879283@kernel.org>
On Tue, 2025-11-25 at 16:40 -0500, Steven Rostedt wrote:
> From: Steven Rostedt <rostedt@goodmis.org>
>
> In event_trigger_regex_release(), the only code is:
>
> mutex_lock(&event_mutex);
> if (file->f_mode & FMODE_READ)
> seq_release(inode, file);
> mutex_unlock(&event_mutex);
>
> return 0;
>
> There's nothing special about the file->f_mode or the seq_release()
> that
> requires any locking. Remove the unnecessary locks.
>
> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Looks good to me.
Reviewed-by: Tom Zanussi <zanussi@kernel.org>
> ---
> kernel/trace/trace_events_trigger.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/kernel/trace/trace_events_trigger.c
> b/kernel/trace/trace_events_trigger.c
> index 7795af600466..e5dcfcbb2cd5 100644
> --- a/kernel/trace/trace_events_trigger.c
> +++ b/kernel/trace/trace_events_trigger.c
> @@ -314,13 +314,9 @@ static ssize_t event_trigger_regex_write(struct
> file *file,
>
> static int event_trigger_regex_release(struct inode *inode, struct
> file *file)
> {
> - mutex_lock(&event_mutex);
> -
> if (file->f_mode & FMODE_READ)
> seq_release(inode, file);
>
> - mutex_unlock(&event_mutex);
> -
> return 0;
> }
>
^ permalink raw reply
* Re: [PATCH v2 2/3] tracing: Add bulk garbage collection of freeing event_trigger_data
From: Tom Zanussi @ 2025-12-03 22:39 UTC (permalink / raw)
To: Steven Rostedt, linux-kernel, linux-trace-kernel
Cc: Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton
In-Reply-To: <20251125214032.151674992@kernel.org>
On Tue, 2025-11-25 at 16:40 -0500, Steven Rostedt wrote:
> From: Steven Rostedt <rostedt@goodmis.org>
>
> The event trigger data requires a full tracepoint_synchronize_unregister()
> call before freeing. That call can take 100s of milliseconds to complete.
> In order to allow for bulk freeing of the trigger data, it can not call
> the tracepoint_synchronize_unregister() for every individual trigger data
> being free.
>
> Create a kthread that gets created the first time a trigger data is freed,
> and have it use the lockless llist to get the list of data to free, run
> the tracepoint_synchronize_unregister() then free everything in the list.
>
> By freeing hundreds of event_trigger_data elements together, it only
> requires two runs of the synchronization function, and not hundreds of
> runs. This speeds up the operation by orders of magnitude (milliseconds
> instead of several seconds).
>
> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Very nice!
Reviewed-by: Tom Zanussi <zanussi@kernel.org>
> ---
> Changes since v1: https://patch.msgid.link/20251120205710.151041470@kernel.org
>
> - Moved include of llist.h to trace.h as it is used there (Masami Hiramatsu)
>
> kernel/trace/trace.h | 2 ++
> kernel/trace/trace_events_trigger.c | 55 +++++++++++++++++++++++++++--
> 2 files changed, 54 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
> index 5863800b1ab3..911fc75dc6c4 100644
> --- a/kernel/trace/trace.h
> +++ b/kernel/trace/trace.h
> @@ -22,6 +22,7 @@
> #include <linux/ctype.h>
> #include <linux/once_lite.h>
> #include <linux/ftrace_regs.h>
> +#include <linux/llist.h>
>
> #include "pid_list.h"
>
> @@ -1808,6 +1809,7 @@ struct event_trigger_data {
> char *name;
> struct list_head named_list;
> struct event_trigger_data *named_data;
> + struct llist_node llist;
> };
>
> /* Avoid typos */
> diff --git a/kernel/trace/trace_events_trigger.c b/kernel/trace/trace_events_trigger.c
> index e5dcfcbb2cd5..3b97c242b795 100644
> --- a/kernel/trace/trace_events_trigger.c
> +++ b/kernel/trace/trace_events_trigger.c
> @@ -6,6 +6,7 @@
> */
>
> #include <linux/security.h>
> +#include <linux/kthread.h>
> #include <linux/module.h>
> #include <linux/ctype.h>
> #include <linux/mutex.h>
> @@ -17,15 +18,63 @@
> static LIST_HEAD(trigger_commands);
> static DEFINE_MUTEX(trigger_cmd_mutex);
>
> +static struct task_struct *trigger_kthread;
> +static struct llist_head trigger_data_free_list;
> +static DEFINE_MUTEX(trigger_data_kthread_mutex);
> +
> +/* Bulk garbage collection of event_trigger_data elements */
> +static int trigger_kthread_fn(void *ignore)
> +{
> + struct event_trigger_data *data, *tmp;
> + struct llist_node *llnodes;
> +
> + /* Once this task starts, it lives forever */
> + for (;;) {
> + set_current_state(TASK_INTERRUPTIBLE);
> + if (llist_empty(&trigger_data_free_list))
> + schedule();
> +
> + __set_current_state(TASK_RUNNING);
> +
> + llnodes = llist_del_all(&trigger_data_free_list);
> +
> + /* make sure current triggers exit before free */
> + tracepoint_synchronize_unregister();
> +
> + llist_for_each_entry_safe(data, tmp, llnodes, llist)
> + kfree(data);
> + }
> +
> + return 0;
> +}
> +
> void trigger_data_free(struct event_trigger_data *data)
> {
> if (data->cmd_ops->set_filter)
> data->cmd_ops->set_filter(NULL, data, NULL);
>
> - /* make sure current triggers exit before free */
> - tracepoint_synchronize_unregister();
> + if (unlikely(!trigger_kthread)) {
> + guard(mutex)(&trigger_data_kthread_mutex);
> + /* Check again after taking mutex */
> + if (!trigger_kthread) {
> + struct task_struct *kthread;
> +
> + kthread = kthread_create(trigger_kthread_fn, NULL,
> + "trigger_data_free");
> + if (!IS_ERR(kthread))
> + WRITE_ONCE(trigger_kthread, kthread);
> + }
> + }
> +
> + if (!trigger_kthread) {
> + /* Do it the slow way */
> + tracepoint_synchronize_unregister();
> + kfree(data);
> + return;
> + }
>
> - kfree(data);
> + llist_add(&data->llist, &trigger_data_free_list);
> + wake_up_process(trigger_kthread);
> }
>
> static inline void data_ops_trigger(struct event_trigger_data *data,
^ permalink raw reply
* Re: [PATCH v2 3/3] tracing: Use strim() in trigger_process_regex() instead of skip_spaces()
From: Tom Zanussi @ 2025-12-03 22:40 UTC (permalink / raw)
To: Steven Rostedt, linux-kernel, linux-trace-kernel
Cc: Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton
In-Reply-To: <20251125214032.323747707@kernel.org>
On Tue, 2025-11-25 at 16:40 -0500, Steven Rostedt wrote:
> From: Steven Rostedt <rostedt@goodmis.org>
>
> The function trigger_process_regex() is called by a few functions, where
> only one calls strim() on the buffer passed to it. That leaves the other
> functions not trimming the end of the buffer passed in and making it a
> little inconsistent.
>
> Remove the strim() from event_trigger_regex_write() and have
> trigger_process_regex() use strim() instead of skip_spaces(). The buff
> variable is not passed in as const, so it can be modified.
>
> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Looks good to me.
Reviewed-by: Tom Zanussi <zanussi@kernel.org>
> ---
> kernel/trace/trace_events_trigger.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/trace/trace_events_trigger.c b/kernel/trace/trace_events_trigger.c
> index 3b97c242b795..96aad82b1628 100644
> --- a/kernel/trace/trace_events_trigger.c
> +++ b/kernel/trace/trace_events_trigger.c
> @@ -308,7 +308,8 @@ int trigger_process_regex(struct trace_event_file *file, char *buff)
> char *command, *next;
> struct event_command *p;
>
> - next = buff = skip_spaces(buff);
> + next = buff = strim(buff);
> +
> command = strsep(&next, ": \t");
> if (next) {
> next = skip_spaces(next);
> @@ -345,8 +346,6 @@ static ssize_t event_trigger_regex_write(struct file *file,
> if (IS_ERR(buf))
> return PTR_ERR(buf);
>
> - strim(buf);
> -
> guard(mutex)(&event_mutex);
>
> event_file = event_file_file(file);
^ permalink raw reply
* Re: [PATCH v2 3/3] tracing: Use strim() in trigger_process_regex() instead of skip_spaces()
From: Steven Rostedt @ 2025-12-03 22:46 UTC (permalink / raw)
To: Tom Zanussi
Cc: Steven Rostedt, linux-kernel, linux-trace-kernel,
Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton
In-Reply-To: <9393741d90fff46709a2c9b0b04f406d5245d000.camel@kernel.org>
On Wed, 03 Dec 2025 16:40:04 -0600
Tom Zanussi <zanussi@kernel.org> wrote:
> > Remove the strim() from event_trigger_regex_write() and have
> > trigger_process_regex() use strim() instead of skip_spaces(). The buff
> > variable is not passed in as const, so it can be modified.
> >
> > Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
> > Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
>
> Looks good to me.
>
> Reviewed-by: Tom Zanussi <zanussi@kernel.org>
Thanks for all the reviews, but I already did the pull request ;-)
Although it hasn't been accepted yet and there's always a chance Linus may
have an issue with one of the commits (I had a lot of commits this time,
affecting various aspects of the code, but couldn't use topic branches due
to too many conflicts). If it is rejected, I'll add your reviewed-by tags.
-- Steve
^ permalink raw reply
* Re: [PATCH v2 3/3] tracing: Use strim() in trigger_process_regex() instead of skip_spaces()
From: Tom Zanussi @ 2025-12-03 22:58 UTC (permalink / raw)
To: Steven Rostedt
Cc: Steven Rostedt, linux-kernel, linux-trace-kernel,
Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton
In-Reply-To: <20251203174604.0405a90d@gandalf.local.home>
On Wed, 2025-12-03 at 17:46 -0500, Steven Rostedt wrote:
> On Wed, 03 Dec 2025 16:40:04 -0600
> Tom Zanussi <zanussi@kernel.org> wrote:
>
> > > Remove the strim() from event_trigger_regex_write() and have
> > > trigger_process_regex() use strim() instead of skip_spaces(). The buff
> > > variable is not passed in as const, so it can be modified.
> > >
> > > Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
> > > Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
> >
> > Looks good to me.
> >
> > Reviewed-by: Tom Zanussi <zanussi@kernel.org>
>
> Thanks for all the reviews, but I already did the pull request ;-)
>
> Although it hasn't been accepted yet and there's always a chance Linus may
> have an issue with one of the commits (I had a lot of commits this time,
> affecting various aspects of the code, but couldn't use topic branches due
> to too many conflicts). If it is rejected, I'll add your reviewed-by tags.
>
> -- Steve
No problem, my fault for being so slow to get to these. :-/
Tom
^ permalink raw reply
* Re: [PATCH v3 1/2] cpufreq: Replace trace_cpu_frequency with trace_policy_frequency
From: Samuel Wu @ 2025-12-04 0:33 UTC (permalink / raw)
To: Douglas Raillard
Cc: Huang Rui, Gautham R. Shenoy, Mario Limonciello, Perry Yuan,
Jonathan Corbet, Rafael J. Wysocki, Viresh Kumar, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Srinivas Pandruvada,
Len Brown, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Ian Rogers,
Adrian Hunter, James Clark, christian.loehle, kernel-team,
linux-pm, linux-doc, linux-kernel, linux-trace-kernel, bpf,
linux-perf-users, Lalit Maganti
In-Reply-To: <51711ea1-2e5c-457d-902d-68797eb496cb@arm.com>
On Tue, Dec 2, 2025 at 4:03 AM Douglas Raillard
<douglas.raillard@arm.com> wrote:
>
> Hi Samuel,
>
> On 01-12-2025 20:24, Samuel Wu wrote:
> > The existing cpu_frequency trace_event can be verbose, emitting a nearly
> > identical trace event for every CPU in the policy even when their
> > frequencies are identical.
> >
> > This patch replaces the cpu_frequency trace event with policy_frequency
> > trace event, a more efficient alternative. From the kernel's
> > perspective, emitting a trace event once per policy instead of once per
> > cpu saves some memory and is less overhead.
>
> I'd be fully behind that as a general guideline.
>
> > From the post-processing
> > perspective, analysis of the trace log is simplified without any loss of
> > information.
>
> Unfortunately I'm not so sure about the "simplified" part (as of today),
> more on that below.
>
> >
> > Signed-off-by: Samuel Wu <wusamuel@google.com>
> > ---
> > drivers/cpufreq/cpufreq.c | 14 ++------------
> > drivers/cpufreq/intel_pstate.c | 6 ++++--
> > include/trace/events/power.h | 24 +++++++++++++++++++++---
> > kernel/trace/power-traces.c | 2 +-
> > samples/bpf/cpustat_kern.c | 8 ++++----
> > samples/bpf/cpustat_user.c | 6 +++---
> > tools/perf/builtin-timechart.c | 12 ++++++------
> > 7 files changed, 41 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index 4472bb1ec83c..dd3f08f3b958 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -309,8 +309,6 @@ static void cpufreq_notify_transition(struct cpufreq_policy *policy,
> > struct cpufreq_freqs *freqs,
> > unsigned int state)
> > {
> > - int cpu;
> > -
> > BUG_ON(irqs_disabled());
> >
> > if (cpufreq_disabled())
> > @@ -344,10 +342,7 @@ static void cpufreq_notify_transition(struct cpufreq_policy *policy,
> > adjust_jiffies(CPUFREQ_POSTCHANGE, freqs);
> > pr_debug("FREQ: %u - CPUs: %*pbl\n", freqs->new,
> > cpumask_pr_args(policy->cpus));
> > -
> > - for_each_cpu(cpu, policy->cpus)
> > - trace_cpu_frequency(freqs->new, cpu);
> > -
> > + trace_policy_frequency(freqs->new, policy->cpu, policy->cpus);
> > srcu_notifier_call_chain(&cpufreq_transition_notifier_list,
> > CPUFREQ_POSTCHANGE, freqs);
> >
> > @@ -2201,7 +2196,6 @@ unsigned int cpufreq_driver_fast_switch(struct cpufreq_policy *policy,
> > unsigned int target_freq)
> > {
> > unsigned int freq;
> > - int cpu;
> >
> > target_freq = clamp_val(target_freq, policy->min, policy->max);
> > freq = cpufreq_driver->fast_switch(policy, target_freq);
> > @@ -2213,11 +2207,7 @@ unsigned int cpufreq_driver_fast_switch(struct cpufreq_policy *policy,
> > arch_set_freq_scale(policy->related_cpus, freq,
> > arch_scale_freq_ref(policy->cpu));
> > cpufreq_stats_record_transition(policy, freq);
> > -
> > - if (trace_cpu_frequency_enabled()) {
> > - for_each_cpu(cpu, policy->cpus)
> > - trace_cpu_frequency(freq, cpu);
> > - }
> > + trace_policy_frequency(freq, policy->cpu, policy->cpus);
> >
> > return freq;
> > }
> > diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> > index ec4abe374573..9724b5d19d83 100644
> > --- a/drivers/cpufreq/intel_pstate.c
> > +++ b/drivers/cpufreq/intel_pstate.c
> > @@ -2297,7 +2297,8 @@ static int hwp_get_cpu_scaling(int cpu)
> >
> > static void intel_pstate_set_pstate(struct cpudata *cpu, int pstate)
> > {
> > - trace_cpu_frequency(pstate * cpu->pstate.scaling, cpu->cpu);
> > + trace_policy_frequency(pstate * cpu->pstate.scaling, cpu->cpu,
> > + cpumask_of(cpu->cpu));
> > cpu->pstate.current_pstate = pstate;
> > /*
> > * Generally, there is no guarantee that this code will always run on
> > @@ -2587,7 +2588,8 @@ static void intel_pstate_adjust_pstate(struct cpudata *cpu)
> >
> > target_pstate = get_target_pstate(cpu);
> > target_pstate = intel_pstate_prepare_request(cpu, target_pstate);
> > - trace_cpu_frequency(target_pstate * cpu->pstate.scaling, cpu->cpu);
> > + trace_policy_frequency(target_pstate * cpu->pstate.scaling, cpu->cpu,
> > + cpumask_of(cpu->cpu));
> > intel_pstate_update_pstate(cpu, target_pstate);
> >
> > sample = &cpu->sample;
> > diff --git a/include/trace/events/power.h b/include/trace/events/power.h
> > index 370f8df2fdb4..317098ffdd5f 100644
> > --- a/include/trace/events/power.h
> > +++ b/include/trace/events/power.h
> > @@ -182,11 +182,29 @@ TRACE_EVENT(pstate_sample,
> > { PM_EVENT_RECOVER, "recover" }, \
> > { PM_EVENT_POWEROFF, "poweroff" })
> >
> > -DEFINE_EVENT(cpu, cpu_frequency,
> > +TRACE_EVENT(policy_frequency,
> >
> > - TP_PROTO(unsigned int frequency, unsigned int cpu_id),
> > + TP_PROTO(unsigned int frequency, unsigned int cpu_id,
> > + const struct cpumask *policy_cpus),
> >
> > - TP_ARGS(frequency, cpu_id)
> > + TP_ARGS(frequency, cpu_id, policy_cpus),
> > +
> > + TP_STRUCT__entry(
> > + __field(u32, state)
> > + __field(u32, cpu_id)
> > + __cpumask(cpumask)
>
> Using a cpumask is the most technically correct option here, but it also carries a big issue.
> Userspace tooling will have a very hard time doing anything with it. A lot of that is down
> to having no appropriate counterpart in "table libraries" in general (e.g. what would you
> map that to in pandas, polars or SQL ?). Some of the lack of support is probably also down to how
> infrequently used it is. For example I don't think Perfetto would be able to handle that
> in the ftrace_event and args table, as the documented supported value types are:
I've been in touch with the Perfetto team through this process, and it
is an easy update for them to handle. If there are other libraries
using this event, I think their approach would be similar to how
Perfetto's SQL tables handle this new trace event.
> args table:
> value_type STRING The type of the value of the arg. Will be one of 'int', 'uint', 'string', 'real', 'pointer', 'bool' or 'json'.
> https://perfetto.dev/docs/analysis/stdlib-docs
In the same URL as above, there is a 'cpu_frequency_counters' SQL
table documentation. The new tracepoint would be parsed by Perfetto's
C++ parser before being inserted into the aforementioned SQL table as
four separate rows, given a policy with 4 CPUs. This effectively
creates the same table with the same data (just slightly different
timestamps) as prior to this patch.
>
> So while I definitely support improving the situation around cpumasks (I lobbied a bit for that),
> I don't think the ecosystem is ready for it yet and having such a core event switched to using it
> is going to cause a lot of pain.
>
> Some alternatives for tooling could be:
> 1. Record the policy cpumasks in a tool-friendly format in the trace header, but no current format I know
> of provides that, and ftrace does not provide a "JSON blob to be passed through" we could easily append to.
> Any such addition will therefore require libraries update which will take time.
>
> 3. Doing without the data in the trace. That means collecting and bundling another sidecar file, which
> is really not convenient and still requires 3rd party tool modifications for end users.
>
> 2. Add policy_frequency event, but not remove cpu_frequency yet. Possibly with a deprecation warning
> when enabling the event.
>
These alternatives should work, but I feel are probably too complex to
be worth the effort.
> > + ),
> > +
> > + TP_fast_assign(
> > + __entry->state = frequency;
> > + __entry->cpu_id = cpu_id;
> > + __assign_cpumask(cpumask, policy_cpus);
>
> ipi_send_cpumask uses cpumask_bits():
>
> __assign_cpumask(cpumask, cpumask_bits(cpumask));
>
> It's not clear what is best practice, as struct cpumask contains a single member anyway and
> __assign_cpumask() expands to a memcpy() so they are functionally identical.
>
> > + ),
> > +
> > + TP_printk("state=%lu cpu_id=%lu policy_cpus=%*pb",
> > + (unsigned long)__entry->state,
> > + (unsigned long)__entry->cpu_id,
> > + cpumask_pr_args((struct cpumask *)__get_dynamic_array(cpumask)))
>
> Looking at ipi_send_cpumask, this should be:
>
> __get_cpumask(cpumask)
>
> The cast and cpumask_pr_args() may look like it's working, but there is only a very slim
> chance any downstream tool will know what to do with this. Looking at libtraceevent
> (which trace-cmd is based on):
>
> ./utest/traceevent-utest.c:116: "print fmt: \"cpumask=%s\", __get_cpumask(cpumask)\n";
> ./src/event-parse.c:3674: if (strcmp(token, "__get_cpumask") == 0 ||
> ./src/event-parse.c:7568: printf("__get_cpumask(%s)", args->bitmask.bitmask);
>
> But there is no match for "cpumask_pr_args".
Thanks for pointing out libtraceevent- I didn't know about this tool,
but I'll take a look at compatibility and adjust appropriately. The
macros are a little tricky, but I agree that it seems best to follow
the template set out by the pre-existing ipi_send_cpumask.
>
> Considering the gap between what works when using the in-kernel text rendering and what can be
> reasonably expected to work in any other userspace tool, it's a good idea to try
> as many as possible unfortunately.
>
Overall, I appreciate the thorough and insightful feedback Douglas! If
there are any other tools consuming cpu_frequency, I can help update
them appropriately. AFAICT Perfetto is by far, the most widespread
tool consuming cpu_frequency.
> > );
> >
> > TRACE_EVENT(cpu_frequency_limits,
> > diff --git a/kernel/trace/power-traces.c b/kernel/trace/power-traces.c
> > index f2fe33573e54..a537e68a6878 100644
> > --- a/kernel/trace/power-traces.c
> > +++ b/kernel/trace/power-traces.c
> > @@ -16,5 +16,5 @@
> >
> > EXPORT_TRACEPOINT_SYMBOL_GPL(suspend_resume);
> > EXPORT_TRACEPOINT_SYMBOL_GPL(cpu_idle);
> > -EXPORT_TRACEPOINT_SYMBOL_GPL(cpu_frequency);
> > +EXPORT_TRACEPOINT_SYMBOL_GPL(policy_frequency);
> >
> > diff --git a/samples/bpf/cpustat_kern.c b/samples/bpf/cpustat_kern.c
> > index 7ec7143e2757..f485de0f89b2 100644
> > --- a/samples/bpf/cpustat_kern.c
> > +++ b/samples/bpf/cpustat_kern.c
> > @@ -75,9 +75,9 @@ struct {
> > } pstate_duration SEC(".maps");
> >
> > /*
> > - * The trace events for cpu_idle and cpu_frequency are taken from:
> > + * The trace events for cpu_idle and policy_frequency are taken from:
> > * /sys/kernel/tracing/events/power/cpu_idle/format
> > - * /sys/kernel/tracing/events/power/cpu_frequency/format
> > + * /sys/kernel/tracing/events/power/policy_frequency/format
> > *
> > * These two events have same format, so define one common structure.
> > */
> > @@ -162,7 +162,7 @@ int bpf_prog1(struct cpu_args *ctx)
> > */
> > if (ctx->state != (u32)-1) {
> >
> > - /* record pstate after have first cpu_frequency event */
> > + /* record pstate after have first policy_frequency event */
> > if (!*pts)
> > return 0;
> >
> > @@ -208,7 +208,7 @@ int bpf_prog1(struct cpu_args *ctx)
> > return 0;
> > }
> >
> > -SEC("tracepoint/power/cpu_frequency")
> > +SEC("tracepoint/power/policy_frequency")
> > int bpf_prog2(struct cpu_args *ctx)
> > {
> > u64 *pts, *cstate, *pstate, cur_ts, delta;
> > diff --git a/samples/bpf/cpustat_user.c b/samples/bpf/cpustat_user.c
> > index 356f756cba0d..f7e81f702358 100644
> > --- a/samples/bpf/cpustat_user.c
> > +++ b/samples/bpf/cpustat_user.c
> > @@ -143,12 +143,12 @@ static int cpu_stat_inject_cpu_idle_event(void)
> >
> > /*
> > * It's possible to have no any frequency change for long time and cannot
> > - * get ftrace event 'trace_cpu_frequency' for long period, this introduces
> > + * get ftrace event 'trace_policy_frequency' for long period, this introduces
> > * big deviation for pstate statistics.
> > *
> > * To solve this issue, below code forces to set 'scaling_max_freq' to 208MHz
> > - * for triggering ftrace event 'trace_cpu_frequency' and then recovery back to
> > - * the maximum frequency value 1.2GHz.
> > + * for triggering ftrace event 'trace_policy_frequency' and then recovery back
> > + * to the maximum frequency value 1.2GHz.
> > */
> > static int cpu_stat_inject_cpu_frequency_event(void)
> > {
> > diff --git a/tools/perf/builtin-timechart.c b/tools/perf/builtin-timechart.c
> > index 22050c640dfa..3ef1a2fd0493 100644
> > --- a/tools/perf/builtin-timechart.c
> > +++ b/tools/perf/builtin-timechart.c
> > @@ -612,10 +612,10 @@ process_sample_cpu_idle(struct timechart *tchart __maybe_unused,
> > }
> >
> > static int
> > -process_sample_cpu_frequency(struct timechart *tchart,
> > - struct evsel *evsel,
> > - struct perf_sample *sample,
> > - const char *backtrace __maybe_unused)
> > +process_sample_policy_frequency(struct timechart *tchart,
> > + struct evsel *evsel,
> > + struct perf_sample *sample,
> > + const char *backtrace __maybe_unused)
> > {
> > u32 state = evsel__intval(evsel, sample, "state");
> > u32 cpu_id = evsel__intval(evsel, sample, "cpu_id");
> > @@ -1541,7 +1541,7 @@ static int __cmd_timechart(struct timechart *tchart, const char *output_name)
> > {
> > const struct evsel_str_handler power_tracepoints[] = {
> > { "power:cpu_idle", process_sample_cpu_idle },
> > - { "power:cpu_frequency", process_sample_cpu_frequency },
> > + { "power:policy_frequency", process_sample_policy_frequency },
> > { "sched:sched_wakeup", process_sample_sched_wakeup },
> > { "sched:sched_switch", process_sample_sched_switch },
> > #ifdef SUPPORT_OLD_POWER_EVENTS
> > @@ -1804,7 +1804,7 @@ static int timechart__record(struct timechart *tchart, int argc, const char **ar
> > unsigned int backtrace_args_no = ARRAY_SIZE(backtrace_args);
> >
> > const char * const power_args[] = {
> > - "-e", "power:cpu_frequency",
> > + "-e", "power:policy_frequency",
> > "-e", "power:cpu_idle",
> > };
> > unsigned int power_args_nr = ARRAY_SIZE(power_args);
>
> --
>
> Douglas
>
^ permalink raw reply
* Re: [PATCH v2] Documentation/rv: Fix dead link to monitor_synthesis.rst
From: Bagas Sanjaya @ 2025-12-04 1:23 UTC (permalink / raw)
To: Soham Metha, linux-kernel-mentees
Cc: shuah, skhan, linux-kernel, Steven Rostedt, Gabriele Monaco,
Jonathan Corbet, linux-trace-kernel, linux-doc, Nam Cao,
Masami Hiramatsu, Mathieu Desnoyers
In-Reply-To: <20251203182121.52759-1-sohammetha01@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1757 bytes --]
On Wed, Dec 03, 2025 at 11:51:21PM +0530, Soham Metha wrote:
> The file 'da_monitor_synthesis.rst' was renamed to 'monitor_synthesis.rst' in
> commit f40a7c060207090f41998025fcd1cfad06ea2780
> ("Documentation/rv: Prepare monitor synthesis document for LTL inclusion").
[also Cc: people in the commit's SoB chain]
Nit: For commit references, please use abbreviated commit hash (at least 12
characters; I personally prefer 14).
>
> Update the reference to point to the new filename.
>
> Signed-off-by: Soham Metha <sohammetha01@gmail.com>
Fixes: f40a7c06020709 ("Documentation/rv: Prepare monitor synthesis document for LTL inclusion")
> The wip monitor is presented in::
>
> - Documentation/trace/rv/da_monitor_synthesis.rst
> + Documentation/trace/rv/monitor_synthesis.rst
Thanks for the catch! Can you also unwrap the references (which are in
literal code blocks) so that these can be linked? Like:
---- >8 ----
diff --git a/Documentation/trace/rv/da_monitor_instrumentation.rst b/Documentation/trace/rv/da_monitor_instrumentation.rst
index 6c67c7b5781118..9eff38a4ad1ff4 100644
--- a/Documentation/trace/rv/da_monitor_instrumentation.rst
+++ b/Documentation/trace/rv/da_monitor_instrumentation.rst
@@ -162,10 +162,10 @@ For example, from the wip sample model::
The probes then need to be detached at the disable phase.
-[1] The wip model is presented in::
+[1] The wip model is presented in:
Documentation/trace/rv/deterministic_automata.rst
-The wip monitor is presented in::
+The wip monitor is presented in:
- Documentation/trace/rv/da_monitor_synthesis.rst
+ Documentation/trace/rv/monitor_synthesis.rst
Thanks.
--
An old man doll... just what I always wanted! - Clara
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply related
* Re: [PATCH V3 1/2] mm/khugepaged: map dirty/writeback pages failures to EAGAIN
From: wang lian @ 2025-12-04 1:54 UTC (permalink / raw)
To: shivankg
Cc: Branden.Moore, Liam.Howlett, akpm, baohua, baolin.wang, david,
dev.jain, lance.yang, linux-kernel, linux-mm, linux-trace-kernel,
lorenzo.stoakes, mathieu.desnoyers, mhiramat, npache, rostedt,
ryan.roberts, ziy, zokeefe, wang lian
In-Reply-To: <20251201185604.210634-8-shivankg@amd.com>
> When collapse_file encounters dirty or writeback pages in file-backed
> mappings, it currently returns SCAN_FAIL which maps to -EINVAL. This is
> misleading as EINVAL suggests invalid arguments, whereas dirty/writeback
> pages represent transient conditions that may resolve on retry.
>
> Introduce SCAN_PAGE_DIRTY_OR_WRITEBACK to cover both dirty and writeback
> states, mapping it to -EAGAIN. For MADV_COLLAPSE, this provides userspace
> with a clear signal that retry may succeed after writeback completes.
> For khugepaged, this is harmless as it will naturally revisit the range
> during periodic scans after async writeback completes.
>
> Reported-by: Branden Moore <Branden.Moore@amd.com>
> Closes: https://lore.kernel.org/all/4e26fe5e-7374-467c-a333-9dd48f85d7cc@amd.com
> Fixes: 34488399fa08 ("mm/madvise: add file and shmem support to MADV_COLLAPSE")
> Reviewed-by: Dev Jain <dev.jain@arm.com>
> Reviewed-by: Lance Yang <lance.yang@linux.dev>
> Signed-off-by: Shivank Garg <shivankg@amd.com>
> ---
LGTM.
Reviewed-by: wang lian <lianux.mm@gmail.com>
--
Best Regards,
wang lian
^ permalink raw reply
* [PATCH v2] libtracecmd: Fix continuing in tracecmd_iterate_events_reverse()
From: Steven Rostedt @ 2025-12-04 3:02 UTC (permalink / raw)
To: Linux trace kernel; +Cc: Felix Moessbauer
From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
When a callback from tracecmd_iterate_events_reverse() returns non-zero it
cause the function to exit out early. Calling tracecmd_iterate_events_reverse()
again with cont=true, is supposed to restart where it left off. But
because of the way the reverse traverses all the events on a page, by
calling tracecmd_read_data() to find the next task, it does not pick the
next task. It can pick the next task at the start of the page.
If the callback back causes the function to exit out early, record the
page_offset of the last record read, and then set the cursor back to that
event. Then the next tracecmd_iterate_events_reverse() called with
continue will start with the next record after the one that was last
read.
Link: https://lore.kernel.org/all/20251121120117.20e82d9e@gandalf.local.home/
Fixes: 56cbc522518a5 ("trace-cmd library: Add tracecmd_iterate_events_reverse() API")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
---
Changes since v1: https://lore.kernel.org/all/20251121120947.368ad1bd@gandalf.local.home/
- Make the next call to tracecmd_iterate_events_reverse() start with
the next record after the last one read and not the last one that was
read.
lib/trace-cmd/trace-input.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/lib/trace-cmd/trace-input.c b/lib/trace-cmd/trace-input.c
index afdbd2aa98b6..5cb13c3f804b 100644
--- a/lib/trace-cmd/trace-input.c
+++ b/lib/trace-cmd/trace-input.c
@@ -3036,6 +3036,7 @@ int tracecmd_iterate_events_reverse(struct tracecmd_input *handle,
void *callback_data, bool cont)
{
unsigned long long last_timestamp = 0;
+ unsigned long long page_offset = 0;
struct tep_record **records;
struct tep_record *record;
int next_cpu;
@@ -3072,6 +3073,8 @@ int tracecmd_iterate_events_reverse(struct tracecmd_input *handle,
record = next_last_event(handle, records, next_cpu);;
ret = call_callbacks(handle, record, next_cpu,
callback, callback_data);
+ if (ret)
+ page_offset = record->offset;
tracecmd_free_record(record);
}
} while (next_cpu >= 0 && ret == 0);
@@ -3079,6 +3082,17 @@ int tracecmd_iterate_events_reverse(struct tracecmd_input *handle,
free_last_events(handle, records, cpus, cpu_size, max_cpus);
free(records);
+ /*
+ * If the callback exited out early, then set the cursor back
+ * to the location of that record so that if this gets called
+ * again with cont = true, it will continue where it left off.
+ */
+ if (page_offset) {
+ /* Set the internal cursor to the last record that was read */
+ record = tracecmd_read_at(handle, page_offset, NULL);
+ tracecmd_free_record(record);
+ }
+
return ret;
}
--
2.51.0
^ permalink raw reply related
* [PATCH v3] Documentation/rv: Fix dead link to monitor_synthesis.rst
From: Soham Metha @ 2025-12-04 3:24 UTC (permalink / raw)
To: linux-kernel-mentees
Cc: shuah, skhan, rostedt, namcao, gmonaco, mathieu.desnoyers,
mhiramat, bagasdotme, linux-kernel, Soham Metha, Jonathan Corbet,
linux-trace-kernel, linux-doc
The file 'da_monitor_synthesis.rst' was renamed to 'monitor_synthesis.rst' in
commit f40a7c06020709
("Documentation/rv: Prepare monitor synthesis document for LTL inclusion").
Signed-off-by: Soham Metha <sohammetha01@gmail.com>
---
Changelog:
v3:
- use a 14 character commit hash
- unwrap Code Blocks so that the references can be linked
v2:
- Use proper commit SHA reference syntax
Documentation/trace/rv/da_monitor_instrumentation.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/trace/rv/da_monitor_instrumentation.rst b/Documentation/trace/rv/da_monitor_instrumentation.rst
index 6c67c7b57811..9eff38a4ad1f 100644
--- a/Documentation/trace/rv/da_monitor_instrumentation.rst
+++ b/Documentation/trace/rv/da_monitor_instrumentation.rst
@@ -162,10 +162,10 @@ For example, from the wip sample model::
The probes then need to be detached at the disable phase.
-[1] The wip model is presented in::
+[1] The wip model is presented in:
Documentation/trace/rv/deterministic_automata.rst
-The wip monitor is presented in::
+The wip monitor is presented in:
- Documentation/trace/rv/da_monitor_synthesis.rst
+ Documentation/trace/rv/monitor_synthesis.rst
--
2.34.1
^ permalink raw reply related
* Re: [PATCH bpf v3 2/2] selftests/bpf: fix and consolidate d_path LSM regression test
From: Shuran Liu @ 2025-12-04 4:34 UTC (permalink / raw)
To: song
Cc: andrii, ast, bpf, daniel, dxu, eddyz87, electronlsr, ftyg,
gplhust955, haoluo, haoran.ni.cs, john.fastabend, jolsa, kpsingh,
linux-kernel, linux-kselftest, linux-trace-kernel, martin.lau,
mathieu.desnoyers, mattbobrowski, mhiramat, rostedt, sdf, shuah,
yonghong.song
In-Reply-To: <CAPhsuW6hmKjJF5gYvp=9Jue2N6oW8-Mj-LdFbGnQVwW1bTB=qg@mail.gmail.com>
Hi Song,
Thanks for the review.
> I don't get why we add this selftest here. It doesn't appear to be related to
> patch 1/2.
The regression that patch 1/2 fixes was originally hit by an LSM program
calling bpf_d_path() from the bprm_check_security hook. The new subtest is a
minimal reproducer for that scenario: without patch 1/2 the string comparison
never matches due to verifier's faulty optimization, and with patch 1/2 it
behaves correctly.
> The paragraph above is not really necessary. Just curious, did some AI
> write it?
The paragraph was indeed generated with the help of an AI assistant, and I didn’t
trim it down enough. I’ll drop it and keep the changelog focused and brief in v4.
> This {} block is not necessary.
I’ll remove that extra block in v4.
Thanks again for the feedback.
Best regards,
Shuran Liu
^ permalink raw reply
* Re: [PATCH bpf v3 2/2] selftests/bpf: fix and consolidate d_path LSM regression test
From: Shuran Liu @ 2025-12-04 4:39 UTC (permalink / raw)
To: mattbobrowski, alexei.starovoitov
Cc: andrii, ast, bpf, daniel, dxu, eddyz87, electronlsr, ftyg,
gplhust955, haoluo, haoran.ni.cs, john.fastabend, jolsa, kpsingh,
linux-kernel, linux-kselftest, linux-trace-kernel, martin.lau,
mathieu.desnoyers, mhiramat, rostedt, sdf, shuah, song,
yonghong.song
In-Reply-To: <aTARqrMyC36CXa_L@google.com>
Hi Matt and Alexei,
Thanks for the feedback.
I have updated the test to use fallocate instead, which is in the allowlist of the d_path helper. I also minimized the test case while retaining the ability to reproduce the issue.
I will send the updated patch shortly. Thanks again for the review.
Best regards,
Shuran Liu
^ permalink raw reply
* Re: [PATCH v3] Documentation/rv: Fix dead link to monitor_synthesis.rst
From: Gabriele Monaco @ 2025-12-04 6:36 UTC (permalink / raw)
To: Soham Metha, linux-kernel-mentees
Cc: shuah, skhan, rostedt, namcao, mathieu.desnoyers, mhiramat,
bagasdotme, linux-kernel, Jonathan Corbet, linux-trace-kernel,
linux-doc
In-Reply-To: <20251204032452.9523-1-sohammetha01@gmail.com>
On Thu, 2025-12-04 at 08:54 +0530, Soham Metha wrote:
> The file 'da_monitor_synthesis.rst' was renamed to 'monitor_synthesis.rst' in
> commit f40a7c06020709
> ("Documentation/rv: Prepare monitor synthesis document for LTL inclusion").
>
> Signed-off-by: Soham Metha <sohammetha01@gmail.com>
Thanks for catching this!
> ---
> Changelog:
> v3:
> - use a 14 character commit hash
> - unwrap Code Blocks so that the references can be linked
You may want to add this to the commit message next time, you are in fact not
only fixing the broken link.
Since the change is small I wouldn't bother this time, though.
> v2:
> - Use proper commit SHA reference syntax
I suggest you run your patches through script/checkpatch.pl (in the kernel
tree), it's usually finding this kind of formatting issues and even more before
you even send it.
On a side note, apparently it wouldn't have worked this time since you quoted
the hash.
Anyway looks good to me.
Acked-by: Gabriele Monaco <gmonaco@redhat.com>
Thanks,
Gabriele
>
> Documentation/trace/rv/da_monitor_instrumentation.rst | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/trace/rv/da_monitor_instrumentation.rst
> b/Documentation/trace/rv/da_monitor_instrumentation.rst
> index 6c67c7b57811..9eff38a4ad1f 100644
> --- a/Documentation/trace/rv/da_monitor_instrumentation.rst
> +++ b/Documentation/trace/rv/da_monitor_instrumentation.rst
> @@ -162,10 +162,10 @@ For example, from the wip sample model::
>
> The probes then need to be detached at the disable phase.
>
> -[1] The wip model is presented in::
> +[1] The wip model is presented in:
>
> Documentation/trace/rv/deterministic_automata.rst
>
> -The wip monitor is presented in::
> +The wip monitor is presented in:
>
> - Documentation/trace/rv/da_monitor_synthesis.rst
> + Documentation/trace/rv/monitor_synthesis.rst
^ permalink raw reply
* Re: [PATCH V3 2/2] mm/khugepaged: retry with sync writeback for MADV_COLLAPSE
From: Lance Yang @ 2025-12-04 6:53 UTC (permalink / raw)
To: Garg, Shivank
Cc: Zi Yan, Baolin Wang, Liam R . Howlett, Nico Pache, Andrew Morton,
Ryan Roberts, Dev Jain, Lorenzo Stoakes, Barry Song,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Zach O'Keefe, David Hildenbrand, linux-mm, linux-kernel,
linux-trace-kernel, Branden Moore
In-Reply-To: <26e51398-02e1-4ca7-80f0-0cd76a966188@amd.com>
On 2025/12/4 02:25, Garg, Shivank wrote:
>
>
> On 12/2/2025 10:20 AM, Lance Yang wrote:
>>
>>
>> On 2025/12/2 02:56, Shivank Garg wrote:
>>> When MADV_COLLAPSE is called on file-backed mappings (e.g., executable
>>> text sections), the pages may still be dirty from recent writes.
>>> collapse_file() will trigger async writeback and fail with
>>> SCAN_PAGE_DIRTY_OR_WRITEBACK (-EAGAIN).
>>>
>>> MADV_COLLAPSE is a synchronous operation where userspace expects
>>> immediate results. If the collapse fails due to dirty pages, perform
>>> synchronous writeback on the specific range and retry once.
>>>
>>> This avoids spurious failures for freshly written executables while
>>> avoiding unnecessary synchronous I/O for mappings that are already clean.
>>>
>>> Reported-by: Branden Moore <Branden.Moore@amd.com>
>>> Closes: https://lore.kernel.org/all/4e26fe5e-7374-467c-a333-9dd48f85d7cc@amd.com
>>> Fixes: 34488399fa08 ("mm/madvise: add file and shmem support to MADV_COLLAPSE")
>>> Suggested-by: David Hildenbrand <david@kernel.org>
>>> Signed-off-by: Shivank Garg <shivankg@amd.com>
>>> ---
>>> mm/khugepaged.c | 41 +++++++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 41 insertions(+)
>>>
>>> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
>>> index 219dfa2e523c..7a12e9ef30b4 100644
>>> --- a/mm/khugepaged.c
>>> +++ b/mm/khugepaged.c
>>> @@ -22,6 +22,7 @@
>>> #include <linux/dax.h>
>>> #include <linux/ksm.h>
>>> #include <linux/pgalloc.h>
>>> +#include <linux/backing-dev.h>
>>> #include <asm/tlb.h>
>>> #include "internal.h"
>>> @@ -2787,9 +2788,11 @@ int madvise_collapse(struct vm_area_struct *vma, unsigned long start,
>>> hend = end & HPAGE_PMD_MASK;
>>> for (addr = hstart; addr < hend; addr += HPAGE_PMD_SIZE) {
>>> + bool retried = false;
>>> int result = SCAN_FAIL;
>>> if (!mmap_locked) {
>>> +retry:
>>> cond_resched();
>>> mmap_read_lock(mm);
>>> mmap_locked = true;
>>> @@ -2819,6 +2822,44 @@ int madvise_collapse(struct vm_area_struct *vma, unsigned long start,
>>> if (!mmap_locked)
>>> *lock_dropped = true;
>>> + /*
>>> + * If the file-backed VMA has dirty pages, the scan triggers
>>> + * async writeback and returns SCAN_PAGE_DIRTY_OR_WRITEBACK.
>>> + * Since MADV_COLLAPSE is sync, we force sync writeback and
>>> + * retry once.
>>> + */
>>> + if (result == SCAN_PAGE_DIRTY_OR_WRITEBACK && !retried) {
>>> + /*
>>> + * File scan drops the lock. We must re-acquire it to
>>> + * safely inspect the VMA and hold the file reference.
>>> + */
>>> + if (!mmap_locked) {
>>> + cond_resched();
>>> + mmap_read_lock(mm);
>>> + mmap_locked = true;
>>> + result = hugepage_vma_revalidate(mm, addr, false, &vma, cc);
>>> + if (result != SCAN_SUCCEED)
>>> + goto handle_result;
>>> + }
>>> +
>>> + if (!vma_is_anonymous(vma) && vma->vm_file &&
>>> + mapping_can_writeback(vma->vm_file->f_mapping)) {
>>> + struct file *file = get_file(vma->vm_file);
>>> + pgoff_t pgoff = linear_page_index(vma, addr);
>>> + loff_t lstart = (loff_t)pgoff << PAGE_SHIFT;
>>> + loff_t lend = lstart + HPAGE_PMD_SIZE - 1;
>>> +
>>> + mmap_read_unlock(mm);
>>> + mmap_locked = false;
>>> + *lock_dropped = true;
>>> + filemap_write_and_wait_range(file->f_mapping, lstart, lend);
>>> + fput(file);
>>> + retried = true;
>>> + goto retry;
>>> + }
>>> + }
>>> +
>>> +
>>
>> Nit: spurious blank line.
>
> Ah, I completely missed this. I’ll fix it in the next version.
> Hope the rest of the patch looks reasonable. Thanks for the review.
Apart from that nit, nothing else jumped out at me :)
Confirmed that the spurious EINVAL is gone, and it works as expected ;p
Tested-by: Lance Yang <lance.yang@linux.dev>
[...]
Cheers,
Lance
^ permalink raw reply
* Re: [PATCH v2 1/4] kernel.h: drop STACK_MAGIC macro
From: Christophe Leroy (CS GROUP) @ 2025-12-04 7:43 UTC (permalink / raw)
To: Yury Norov (NVIDIA), Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Andy Shevchenko, Randy Dunlap, Ingo Molnar,
Jani Nikula, Joonas Lahtinen, David Laight, Petr Pavlu,
Andi Shyti, Rodrigo Vivi, Tvrtko Ursulin, Daniel Gomez,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Andrew Morton, linux-kernel, intel-gfx, dri-devel, linux-modules,
linux-trace-kernel
Cc: Jani Nikula
In-Reply-To: <20251203162329.280182-2-yury.norov@gmail.com>
Le 03/12/2025 à 17:23, Yury Norov (NVIDIA) a écrit :
> The macro was introduced in 1994, v1.0.4, for stacks protection. Since
> that, people found better ways to protect stacks, and now the macro is
> only used by i915 selftests. Move it to a local header and drop from
> the kernel.h.
>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Acked-by: Randy Dunlap <rdunlap@infradead.org>
> Acked-by: Jani Nikula <jani.nikula@intel.com>
> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
> ---
> drivers/gpu/drm/i915/gt/selftest_ring_submission.c | 1 +
> drivers/gpu/drm/i915/i915_selftest.h | 2 ++
> include/linux/kernel.h | 2 --
> 3 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/selftest_ring_submission.c b/drivers/gpu/drm/i915/gt/selftest_ring_submission.c
> index 87ceb0f374b6..600333ae6c8c 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_ring_submission.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_ring_submission.c
> @@ -3,6 +3,7 @@
> * Copyright © 2020 Intel Corporation
> */
>
> +#include "i915_selftest.h"
> #include "intel_engine_pm.h"
> #include "selftests/igt_flush_test.h"
>
> diff --git a/drivers/gpu/drm/i915/i915_selftest.h b/drivers/gpu/drm/i915/i915_selftest.h
> index bdf3e22c0a34..72922028f4ba 100644
> --- a/drivers/gpu/drm/i915/i915_selftest.h
> +++ b/drivers/gpu/drm/i915/i915_selftest.h
> @@ -26,6 +26,8 @@
>
> #include <linux/types.h>
>
> +#define STACK_MAGIC 0xdeadbeef
> +
> struct pci_dev;
> struct drm_i915_private;
>
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 5b46924fdff5..61d63c57bc2d 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -40,8 +40,6 @@
>
> #include <uapi/linux/kernel.h>
>
> -#define STACK_MAGIC 0xdeadbeef
> -
> struct completion;
> struct user;
>
^ permalink raw reply
* [PATCH bpf v4 0/2] bpf: fix bpf_d_path() helper prototype
From: Shuran Liu @ 2025-12-04 7:46 UTC (permalink / raw)
To: song, mattbobrowski, bpf
Cc: ast, daniel, andrii, martin.lau, eddyz87, yonghong.song,
john.fastabend, kpsingh, sdf, haoluo, jolsa, rostedt, mhiramat,
mathieu.desnoyers, linux-kernel, linux-trace-kernel, dxu,
linux-kselftest, shuah, electronlsr
Hi,
This series fixes a verifier issue with bpf_d_path() and adds a
regression test to cover its use within a hook function.
Patch 1 updates the bpf_d_path() helper prototype so that the second
argument is marked as MEM_WRITE. This makes it explicit to the verifier
that the helper writes into the provided buffer.
Patch 2 extends the existing d_path selftest to cover incorrect verifier
assumptions caused by an incorrect function prototype. The test program calls
bpf_d_path() and checks if the first character of the path is '/'.
It ensures the verifier does not assume the buffer remains unwritten.
Changelog
=========
v4:
- Use the fallocate hook instead of an LSM hook to simplify the selftest,
as suggested by Matt and Alexei.
- Add a utility function in test_d_path.c to load the BPF program,
improving code reuse.
v3:
- Switch the pathname prefix loop to use bpf_for() instead of
#pragma unroll, as suggested by Matt.
- Remove /tmp/bpf_d_path_test in the test cleanup path.
- Add the missing Reviewed-by tags.
v2:
- Merge the new test into the existing d_path selftest rather than
creating new files.
- Add PID filtering in the LSM program to avoid nondeterministic failures
due to unrelated processes triggering bprm_check_security.
- Synchronize child execution using a pipe to ensure deterministic
updates to the PID.
Thanks for your time and reviews.
Shuran Liu (2):
bpf: mark bpf_d_path() buffer as writeable
selftests/bpf: add regression test for bpf_d_path()
kernel/trace/bpf_trace.c | 2 +-
.../testing/selftests/bpf/prog_tests/d_path.c | 90 +++++++++++++++----
.../testing/selftests/bpf/progs/test_d_path.c | 23 +++++
3 files changed, 96 insertions(+), 19 deletions(-)
--
2.52.0
^ permalink raw reply
* [PATCH bpf v4 1/2] bpf: mark bpf_d_path() buffer as writeable
From: Shuran Liu @ 2025-12-04 7:46 UTC (permalink / raw)
To: song, mattbobrowski, bpf
Cc: ast, daniel, andrii, martin.lau, eddyz87, yonghong.song,
john.fastabend, kpsingh, sdf, haoluo, jolsa, rostedt, mhiramat,
mathieu.desnoyers, linux-kernel, linux-trace-kernel, dxu,
linux-kselftest, shuah, electronlsr, Zesen Liu, Peili Gao,
Haoran Ni
In-Reply-To: <20251204074632.8562-1-electronlsr@gmail.com>
Commit 37cce22dbd51 ("bpf: verifier: Refactor helper access type
tracking") started distinguishing read vs write accesses performed by
helpers.
The second argument of bpf_d_path() is a pointer to a buffer that the
helper fills with the resulting path. However, its prototype currently
uses ARG_PTR_TO_MEM without MEM_WRITE.
Before 37cce22dbd51, helper accesses were conservatively treated as
potential writes, so this mismatch did not cause issues. Since that
commit, the verifier may incorrectly assume that the buffer contents
are unchanged across the helper call and base its optimizations on this
wrong assumption. This can lead to misbehaviour in BPF programs that
read back the buffer, such as prefix comparisons on the returned path.
Fix this by marking the second argument of bpf_d_path() as
ARG_PTR_TO_MEM | MEM_WRITE so that the verifier correctly models the
write to the caller-provided buffer.
Fixes: 37cce22dbd51 ("bpf: verifier: Refactor helper access type tracking")
Co-developed-by: Zesen Liu <ftyg@live.com>
Signed-off-by: Zesen Liu <ftyg@live.com>
Co-developed-by: Peili Gao <gplhust955@gmail.com>
Signed-off-by: Peili Gao <gplhust955@gmail.com>
Co-developed-by: Haoran Ni <haoran.ni.cs@gmail.com>
Signed-off-by: Haoran Ni <haoran.ni.cs@gmail.com>
Signed-off-by: Shuran Liu <electronlsr@gmail.com>
Reviewed-by: Matt Bobrowski <mattbobrowski@google.com>
---
kernel/trace/bpf_trace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 4f87c16d915a..49e0bdaa7a1b 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -965,7 +965,7 @@ static const struct bpf_func_proto bpf_d_path_proto = {
.ret_type = RET_INTEGER,
.arg1_type = ARG_PTR_TO_BTF_ID,
.arg1_btf_id = &bpf_d_path_btf_ids[0],
- .arg2_type = ARG_PTR_TO_MEM,
+ .arg2_type = ARG_PTR_TO_MEM | MEM_WRITE,
.arg3_type = ARG_CONST_SIZE_OR_ZERO,
.allowed = bpf_d_path_allowed,
};
--
2.52.0
^ permalink raw reply related
* [PATCH bpf v4 2/2] selftests/bpf: add regression test for bpf_d_path()
From: Shuran Liu @ 2025-12-04 7:46 UTC (permalink / raw)
To: song, mattbobrowski, bpf
Cc: ast, daniel, andrii, martin.lau, eddyz87, yonghong.song,
john.fastabend, kpsingh, sdf, haoluo, jolsa, rostedt, mhiramat,
mathieu.desnoyers, linux-kernel, linux-trace-kernel, dxu,
linux-kselftest, shuah, electronlsr, Zesen Liu, Peili Gao,
Haoran Ni
In-Reply-To: <20251204074632.8562-1-electronlsr@gmail.com>
Add a regression test for bpf_d_path() to cover incorrect verifier
assumptions caused by an incorrect function prototype. The test
attaches to the fallocate hook, calls bpf_d_path() and verifies that
a simple prefix comparison on the returned pathname behaves correctly
after the fix in patch 1. It ensures the verifier does not assume
the buffer remains unwritten.
Co-developed-by: Zesen Liu <ftyg@live.com>
Signed-off-by: Zesen Liu <ftyg@live.com>
Co-developed-by: Peili Gao <gplhust955@gmail.com>
Signed-off-by: Peili Gao <gplhust955@gmail.com>
Co-developed-by: Haoran Ni <haoran.ni.cs@gmail.com>
Signed-off-by: Haoran Ni <haoran.ni.cs@gmail.com>
Signed-off-by: Shuran Liu <electronlsr@gmail.com>
---
.../testing/selftests/bpf/prog_tests/d_path.c | 90 +++++++++++++++----
.../testing/selftests/bpf/progs/test_d_path.c | 23 +++++
2 files changed, 95 insertions(+), 18 deletions(-)
diff --git a/tools/testing/selftests/bpf/prog_tests/d_path.c b/tools/testing/selftests/bpf/prog_tests/d_path.c
index ccc768592e66..c725d5258e65 100644
--- a/tools/testing/selftests/bpf/prog_tests/d_path.c
+++ b/tools/testing/selftests/bpf/prog_tests/d_path.c
@@ -38,6 +38,14 @@ static int set_pathname(int fd, pid_t pid)
return readlink(buf, src.paths[src.cnt++], MAX_PATH_LEN);
}
+static inline long syscall_close(int fd)
+{
+ return syscall(__NR_close_range,
+ (unsigned int)fd,
+ (unsigned int)fd,
+ 0u);
+}
+
static int trigger_fstat_events(pid_t pid)
{
int sockfd = -1, procfd = -1, devfd = -1;
@@ -104,36 +112,47 @@ static int trigger_fstat_events(pid_t pid)
/* sys_close no longer triggers filp_close, but we can
* call sys_close_range instead which still does
*/
-#define close(fd) syscall(__NR_close_range, fd, fd, 0)
-
- close(pipefd[0]);
- close(pipefd[1]);
- close(sockfd);
- close(procfd);
- close(devfd);
- close(localfd);
- close(indicatorfd);
-
-#undef close
+ syscall_close(pipefd[0]);
+ syscall_close(pipefd[1]);
+ syscall_close(sockfd);
+ syscall_close(procfd);
+ syscall_close(devfd);
+ syscall_close(localfd);
+ syscall_close(indicatorfd);
return ret;
}
+static void attach_and_load(struct test_d_path **skel)
+{
+ int err;
+
+ *skel = test_d_path__open_and_load();
+ if (CHECK(!*skel, "setup", "d_path skeleton failed\n"))
+ goto cleanup;
+
+ err = test_d_path__attach(*skel);
+ if (CHECK(err, "setup", "attach failed: %d\n", err))
+ goto cleanup;
+
+ (*skel)->bss->my_pid = getpid();
+ return;
+
+cleanup:
+ test_d_path__destroy(*skel);
+ *skel = NULL;
+}
+
static void test_d_path_basic(void)
{
struct test_d_path__bss *bss;
struct test_d_path *skel;
int err;
- skel = test_d_path__open_and_load();
- if (CHECK(!skel, "setup", "d_path skeleton failed\n"))
- goto cleanup;
-
- err = test_d_path__attach(skel);
- if (CHECK(err, "setup", "attach failed: %d\n", err))
+ attach_and_load(&skel);
+ if (!skel)
goto cleanup;
bss = skel->bss;
- bss->my_pid = getpid();
err = trigger_fstat_events(bss->my_pid);
if (err < 0)
@@ -195,6 +214,38 @@ static void test_d_path_check_types(void)
test_d_path_check_types__destroy(skel);
}
+/* Check if the verifier correctly generates code for
+ * accessing the memory modified by d_path helper.
+ */
+static void test_d_path_mem_access(void)
+{
+ int localfd = -1;
+ struct test_d_path__bss *bss;
+ struct test_d_path *skel;
+
+ attach_and_load(&skel);
+ if (!skel)
+ goto cleanup;
+
+ bss = skel->bss;
+
+ localfd = open("/tmp/d_path_loadgen.txt", O_CREAT | O_RDWR, 0644);
+ if (CHECK(localfd < 0, "trigger", "open /tmp/d_path_loadgen.txt failed\n"))
+ goto cleanup;
+
+ if (CHECK(fallocate(localfd, 0, 0, 1024) < 0, "trigger", "fallocate failed\n"))
+ goto cleanup;
+ remove("/tmp/d_path_loadgen.txt");
+
+ if (CHECK(!bss->path_match_fallocate, "check",
+ "failed to match actual opened path"))
+ goto cleanup;
+
+cleanup:
+ syscall_close(localfd);
+ test_d_path__destroy(skel);
+}
+
void test_d_path(void)
{
if (test__start_subtest("basic"))
@@ -205,4 +256,7 @@ void test_d_path(void)
if (test__start_subtest("check_alloc_mem"))
test_d_path_check_types();
+
+ if (test__start_subtest("check_mem_access"))
+ test_d_path_mem_access();
}
diff --git a/tools/testing/selftests/bpf/progs/test_d_path.c b/tools/testing/selftests/bpf/progs/test_d_path.c
index 84e1f883f97b..2f9b4cb67931 100644
--- a/tools/testing/selftests/bpf/progs/test_d_path.c
+++ b/tools/testing/selftests/bpf/progs/test_d_path.c
@@ -17,6 +17,7 @@ int rets_close[MAX_FILES] = {};
int called_stat = 0;
int called_close = 0;
+int path_match_fallocate = 0;
SEC("fentry/security_inode_getattr")
int BPF_PROG(prog_stat, struct path *path, struct kstat *stat,
@@ -62,4 +63,26 @@ int BPF_PROG(prog_close, struct file *file, void *id)
return 0;
}
+SEC("fentry/vfs_fallocate")
+int BPF_PROG(prog_fallocate, struct file *file, int mode, loff_t offset, loff_t len)
+{
+ pid_t pid = bpf_get_current_pid_tgid() >> 32;
+ int ret = 0;
+ char path_fallocate[MAX_PATH_LEN] = {};
+
+ if (pid != my_pid)
+ return 0;
+
+ ret = bpf_d_path(&file->f_path,
+ path_fallocate, MAX_PATH_LEN);
+ if (ret < 0)
+ return 0;
+
+ if (path_fallocate[0] != '/')
+ return 0;
+
+ path_match_fallocate = 1;
+ return 0;
+}
+
char _license[] SEC("license") = "GPL";
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v3] Documentation/rv: Fix dead link to monitor_synthesis.rst
From: Bagas Sanjaya @ 2025-12-04 8:39 UTC (permalink / raw)
To: Soham Metha, linux-kernel-mentees
Cc: shuah, skhan, rostedt, namcao, gmonaco, mathieu.desnoyers,
mhiramat, linux-kernel, Jonathan Corbet, linux-trace-kernel,
linux-doc
In-Reply-To: <20251204032452.9523-1-sohammetha01@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]
On Thu, Dec 04, 2025 at 08:54:52AM +0530, Soham Metha wrote:
> diff --git a/Documentation/trace/rv/da_monitor_instrumentation.rst b/Documentation/trace/rv/da_monitor_instrumentation.rst
> index 6c67c7b57811..9eff38a4ad1f 100644
> --- a/Documentation/trace/rv/da_monitor_instrumentation.rst
> +++ b/Documentation/trace/rv/da_monitor_instrumentation.rst
> @@ -162,10 +162,10 @@ For example, from the wip sample model::
>
> The probes then need to be detached at the disable phase.
>
> -[1] The wip model is presented in::
> +[1] The wip model is presented in:
>
> Documentation/trace/rv/deterministic_automata.rst
>
> -The wip monitor is presented in::
> +The wip monitor is presented in:
>
> - Documentation/trace/rv/da_monitor_synthesis.rst
> + Documentation/trace/rv/monitor_synthesis.rst
Looks good, thanks!
Fixes: f40a7c06020709 ("Documentation/rv: Prepare monitor synthesis document for LTL inclusion")
Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>
--
An old man doll... just what I always wanted! - Clara
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH bpf v4 2/2] selftests/bpf: add regression test for bpf_d_path()
From: Shuran Liu @ 2025-12-04 12:38 UTC (permalink / raw)
To: song, mattbobrowski, bpf
Cc: ast, daniel, andrii, martin.lau, eddyz87, yonghong.song,
john.fastabend, kpsingh, sdf, haoluo, jolsa, rostedt, mhiramat,
mathieu.desnoyers, linux-kernel, linux-trace-kernel, dxu,
linux-kselftest, shuah, electronlsr
In-Reply-To: <20251204074632.8562-3-electronlsr@gmail.com>
Hi,
I looked into the CI failure and it’s caused by the test assuming
/tmp is on tmpfs, which is not true in the CI environment, so
fallocate() fails there. Since /dev/shm is mounted as tmpfs on that
setup, would it be acceptable to change the test to use a file under
/dev/shm instead of /tmp?
^ permalink raw reply
* Re: [PATCH v3 1/2] cpufreq: Replace trace_cpu_frequency with trace_policy_frequency
From: Christian Loehle @ 2025-12-04 12:48 UTC (permalink / raw)
To: Samuel Wu, Huang Rui, Gautham R. Shenoy, Mario Limonciello,
Perry Yuan, Jonathan Corbet, Rafael J. Wysocki, Viresh Kumar,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Srinivas Pandruvada, Len Brown, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, Peter Zijlstra,
Ingo Molnar, Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Ian Rogers, Adrian Hunter, James Clark
Cc: kernel-team, linux-pm, linux-doc, linux-kernel,
linux-trace-kernel, bpf, linux-perf-users
In-Reply-To: <20251201202437.3750901-2-wusamuel@google.com>
On 12/1/25 20:24, Samuel Wu wrote:
> The existing cpu_frequency trace_event can be verbose, emitting a nearly
> identical trace event for every CPU in the policy even when their
> frequencies are identical.
>
> This patch replaces the cpu_frequency trace event with policy_frequency
> trace event, a more efficient alternative. From the kernel's
> perspective, emitting a trace event once per policy instead of once per
> cpu saves some memory and is less overhead. From the post-processing
> perspective, analysis of the trace log is simplified without any loss of
> information.
>
> Signed-off-by: Samuel Wu <wusamuel@google.com>
> ---
> drivers/cpufreq/cpufreq.c | 14 ++------------
> drivers/cpufreq/intel_pstate.c | 6 ++++--
> include/trace/events/power.h | 24 +++++++++++++++++++++---
> kernel/trace/power-traces.c | 2 +-
> samples/bpf/cpustat_kern.c | 8 ++++----
> samples/bpf/cpustat_user.c | 6 +++---
> tools/perf/builtin-timechart.c | 12 ++++++------
> 7 files changed, 41 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 4472bb1ec83c..dd3f08f3b958 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -309,8 +309,6 @@ static void cpufreq_notify_transition(struct cpufreq_policy *policy,
> struct cpufreq_freqs *freqs,
> unsigned int state)
> {
> - int cpu;
> -
> BUG_ON(irqs_disabled());
>
> if (cpufreq_disabled())
> @@ -344,10 +342,7 @@ static void cpufreq_notify_transition(struct cpufreq_policy *policy,
> adjust_jiffies(CPUFREQ_POSTCHANGE, freqs);
> pr_debug("FREQ: %u - CPUs: %*pbl\n", freqs->new,
> cpumask_pr_args(policy->cpus));
> -
> - for_each_cpu(cpu, policy->cpus)
> - trace_cpu_frequency(freqs->new, cpu);
> -
> + trace_policy_frequency(freqs->new, policy->cpu, policy->cpus);
> srcu_notifier_call_chain(&cpufreq_transition_notifier_list,
> CPUFREQ_POSTCHANGE, freqs);
>
> @@ -2201,7 +2196,6 @@ unsigned int cpufreq_driver_fast_switch(struct cpufreq_policy *policy,
> unsigned int target_freq)
> {
> unsigned int freq;
> - int cpu;
>
> target_freq = clamp_val(target_freq, policy->min, policy->max);
> freq = cpufreq_driver->fast_switch(policy, target_freq);
> @@ -2213,11 +2207,7 @@ unsigned int cpufreq_driver_fast_switch(struct cpufreq_policy *policy,
> arch_set_freq_scale(policy->related_cpus, freq,
> arch_scale_freq_ref(policy->cpu));
> cpufreq_stats_record_transition(policy, freq);
> -
> - if (trace_cpu_frequency_enabled()) {
> - for_each_cpu(cpu, policy->cpus)
> - trace_cpu_frequency(freq, cpu);
> - }
> + trace_policy_frequency(freq, policy->cpu, policy->cpus);
>
> return freq;
> }
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index ec4abe374573..9724b5d19d83 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -2297,7 +2297,8 @@ static int hwp_get_cpu_scaling(int cpu)
>
> static void intel_pstate_set_pstate(struct cpudata *cpu, int pstate)
> {
> - trace_cpu_frequency(pstate * cpu->pstate.scaling, cpu->cpu);
> + trace_policy_frequency(pstate * cpu->pstate.scaling, cpu->cpu,
> + cpumask_of(cpu->cpu));
> cpu->pstate.current_pstate = pstate;
> /*
> * Generally, there is no guarantee that this code will always run on
> @@ -2587,7 +2588,8 @@ static void intel_pstate_adjust_pstate(struct cpudata *cpu)
>
> target_pstate = get_target_pstate(cpu);
> target_pstate = intel_pstate_prepare_request(cpu, target_pstate);
> - trace_cpu_frequency(target_pstate * cpu->pstate.scaling, cpu->cpu);
> + trace_policy_frequency(target_pstate * cpu->pstate.scaling, cpu->cpu,
> + cpumask_of(cpu->cpu));
> intel_pstate_update_pstate(cpu, target_pstate);
>
> sample = &cpu->sample;
> diff --git a/include/trace/events/power.h b/include/trace/events/power.h
> index 370f8df2fdb4..317098ffdd5f 100644
> --- a/include/trace/events/power.h
> +++ b/include/trace/events/power.h
> @@ -182,11 +182,29 @@ TRACE_EVENT(pstate_sample,
> { PM_EVENT_RECOVER, "recover" }, \
> { PM_EVENT_POWEROFF, "poweroff" })
>
> -DEFINE_EVENT(cpu, cpu_frequency,
> +TRACE_EVENT(policy_frequency,
>
> - TP_PROTO(unsigned int frequency, unsigned int cpu_id),
> + TP_PROTO(unsigned int frequency, unsigned int cpu_id,
> + const struct cpumask *policy_cpus),
>
> - TP_ARGS(frequency, cpu_id)
> + TP_ARGS(frequency, cpu_id, policy_cpus),
> +
> + TP_STRUCT__entry(
> + __field(u32, state)
> + __field(u32, cpu_id)
> + __cpumask(cpumask)
> + ),
> +
> + TP_fast_assign(
> + __entry->state = frequency;
> + __entry->cpu_id = cpu_id;
> + __assign_cpumask(cpumask, policy_cpus);
> + ),
> +
> + TP_printk("state=%lu cpu_id=%lu policy_cpus=%*pb",
> + (unsigned long)__entry->state,
> + (unsigned long)__entry->cpu_id,
> + cpumask_pr_args((struct cpumask *)__get_dynamic_array(cpumask)))
> );
>
> TRACE_EVENT(cpu_frequency_limits,
> diff --git a/kernel/trace/power-traces.c b/kernel/trace/power-traces.c
> index f2fe33573e54..a537e68a6878 100644
> --- a/kernel/trace/power-traces.c
> +++ b/kernel/trace/power-traces.c
> @@ -16,5 +16,5 @@
>
> EXPORT_TRACEPOINT_SYMBOL_GPL(suspend_resume);
> EXPORT_TRACEPOINT_SYMBOL_GPL(cpu_idle);
> -EXPORT_TRACEPOINT_SYMBOL_GPL(cpu_frequency);
> +EXPORT_TRACEPOINT_SYMBOL_GPL(policy_frequency);
>
> diff --git a/samples/bpf/cpustat_kern.c b/samples/bpf/cpustat_kern.c
> index 7ec7143e2757..f485de0f89b2 100644
> --- a/samples/bpf/cpustat_kern.c
> +++ b/samples/bpf/cpustat_kern.c
> @@ -75,9 +75,9 @@ struct {
> } pstate_duration SEC(".maps");
>
> /*
> - * The trace events for cpu_idle and cpu_frequency are taken from:
> + * The trace events for cpu_idle and policy_frequency are taken from:
> * /sys/kernel/tracing/events/power/cpu_idle/format
> - * /sys/kernel/tracing/events/power/cpu_frequency/format
> + * /sys/kernel/tracing/events/power/policy_frequency/format
> *
> * These two events have same format, so define one common structure.
> */
> @@ -162,7 +162,7 @@ int bpf_prog1(struct cpu_args *ctx)
> */
> if (ctx->state != (u32)-1) {
>
> - /* record pstate after have first cpu_frequency event */
> + /* record pstate after have first policy_frequency event */
> if (!*pts)
> return 0;
>
> @@ -208,7 +208,7 @@ int bpf_prog1(struct cpu_args *ctx)
> return 0;
> }
>
> -SEC("tracepoint/power/cpu_frequency")
> +SEC("tracepoint/power/policy_frequency")
> int bpf_prog2(struct cpu_args *ctx)
> {
> u64 *pts, *cstate, *pstate, cur_ts, delta;
> diff --git a/samples/bpf/cpustat_user.c b/samples/bpf/cpustat_user.c
> index 356f756cba0d..f7e81f702358 100644
> --- a/samples/bpf/cpustat_user.c
> +++ b/samples/bpf/cpustat_user.c
> @@ -143,12 +143,12 @@ static int cpu_stat_inject_cpu_idle_event(void)
>
> /*
> * It's possible to have no any frequency change for long time and cannot
> - * get ftrace event 'trace_cpu_frequency' for long period, this introduces
> + * get ftrace event 'trace_policy_frequency' for long period, this introduces
> * big deviation for pstate statistics.
> *
> * To solve this issue, below code forces to set 'scaling_max_freq' to 208MHz
> - * for triggering ftrace event 'trace_cpu_frequency' and then recovery back to
> - * the maximum frequency value 1.2GHz.
> + * for triggering ftrace event 'trace_policy_frequency' and then recovery back
> + * to the maximum frequency value 1.2GHz.
> */
> static int cpu_stat_inject_cpu_frequency_event(void)
> {
> diff --git a/tools/perf/builtin-timechart.c b/tools/perf/builtin-timechart.c
> index 22050c640dfa..3ef1a2fd0493 100644
> --- a/tools/perf/builtin-timechart.c
> +++ b/tools/perf/builtin-timechart.c
> @@ -612,10 +612,10 @@ process_sample_cpu_idle(struct timechart *tchart __maybe_unused,
> }
>
> static int
> -process_sample_cpu_frequency(struct timechart *tchart,
> - struct evsel *evsel,
> - struct perf_sample *sample,
> - const char *backtrace __maybe_unused)
> +process_sample_policy_frequency(struct timechart *tchart,
> + struct evsel *evsel,
> + struct perf_sample *sample,
> + const char *backtrace __maybe_unused)
> {
> u32 state = evsel__intval(evsel, sample, "state");
> u32 cpu_id = evsel__intval(evsel, sample, "cpu_id");
> @@ -1541,7 +1541,7 @@ static int __cmd_timechart(struct timechart *tchart, const char *output_name)
> {
> const struct evsel_str_handler power_tracepoints[] = {
> { "power:cpu_idle", process_sample_cpu_idle },
> - { "power:cpu_frequency", process_sample_cpu_frequency },
> + { "power:policy_frequency", process_sample_policy_frequency },
> { "sched:sched_wakeup", process_sample_sched_wakeup },
> { "sched:sched_switch", process_sample_sched_switch },
> #ifdef SUPPORT_OLD_POWER_EVENTS
> @@ -1804,7 +1804,7 @@ static int timechart__record(struct timechart *tchart, int argc, const char **ar
> unsigned int backtrace_args_no = ARRAY_SIZE(backtrace_args);
>
> const char * const power_args[] = {
> - "-e", "power:cpu_frequency",
> + "-e", "power:policy_frequency",
> "-e", "power:cpu_idle",
> };
> unsigned int power_args_nr = ARRAY_SIZE(power_args);
perf timechart seem to do per-CPU reporting though?
So this is broken by not emitting an event per-CPU? At least with a simple s/cpu_frequency/policy_frequency/
like here.
Similar for the bpf samples technically...
^ 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