* [RFC PATCH bpf-next v3 2/3] ftrace: Use kallsyms binary search for single-symbol lookup
From: Andrey Grodzovsky @ 2026-02-27 20:40 UTC (permalink / raw)
To: bpf, linux-open-source
Cc: ast, daniel, andrii, jolsa, rostedt, linux-trace-kernel
In-Reply-To: <20260227204052.725813-1-andrey.grodzovsky@crowdstrike.com>
When ftrace_lookup_symbols() is called with a single symbol (cnt == 1),
use kallsyms_lookup_name() for O(log N) binary search instead of the
full linear scan via kallsyms_on_each_symbol().
ftrace_lookup_symbols() was designed for batch resolution of many
symbols in a single pass. For large cnt this is efficient: a single
O(N) walk over all symbols with O(log cnt) binary search into the
sorted input array. But for cnt == 1 it still decompresses all ~200K
kernel symbols only to match one.
kallsyms_lookup_name() uses the sorted kallsyms index and needs only
~17 decompressions for a single lookup.
This is the common path for kprobe.session with exact function names,
where libbpf sends one symbol per BPF_LINK_CREATE syscall.
If binary lookup fails (duplicate symbol names where the first match
is not ftrace-instrumented), the function falls through to the existing
linear scan path.
Before (cnt=1, 50 kprobe.session programs):
Attach: 858 ms (kallsyms_expand_symbol 25% of CPU)
After:
Attach: 52 ms (16x faster)
Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@crowdstrike.com>
---
kernel/trace/ftrace.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 827fb9a0bf0d..13906af8098a 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -9263,6 +9263,15 @@ static int kallsyms_callback(void *data, const char *name, unsigned long addr)
* @addrs array, which needs to be big enough to store at least @cnt
* addresses.
*
+ * For a single symbol (cnt == 1), uses kallsyms_lookup_name() which
+ * performs an O(log N) binary search via the sorted kallsyms index.
+ * This avoids the full O(N) linear scan over all kernel symbols that
+ * the multi-symbol path requires.
+ *
+ * For multiple symbols, uses a single-pass linear scan via
+ * kallsyms_on_each_symbol() with binary search into the sorted input
+ * array.
+ *
* Returns: 0 if all provided symbols are found, -ESRCH otherwise.
*/
int ftrace_lookup_symbols(const char **sorted_syms, size_t cnt, unsigned long *addrs)
@@ -9270,6 +9279,19 @@ int ftrace_lookup_symbols(const char **sorted_syms, size_t cnt, unsigned long *a
struct kallsyms_data args;
int found_all;
+ /* Fast path: single symbol uses O(log N) binary search */
+ if (cnt == 1) {
+ addrs[0] = kallsyms_lookup_name(sorted_syms[0]);
+ if (addrs[0] && ftrace_location(addrs[0]))
+ return 0;
+ /*
+ * Binary lookup can fail for duplicate symbol names
+ * where the first match is not ftrace-instrumented.
+ * Retry with linear scan.
+ */
+ }
+
+ /* Batch path: single-pass O(N) linear scan */
memset(addrs, 0, sizeof(*addrs) * cnt);
args.addrs = addrs;
args.syms = sorted_syms;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] tracefs: Simplify get_dname() with kmemdup_nul()
From: Steven Rostedt @ 2026-02-27 20:42 UTC (permalink / raw)
To: Al Viro
Cc: AnishMulay, mhiramat, mathieu.desnoyers, linux-trace-kernel,
linux-kernel
In-Reply-To: <20260227201824.GE3836593@ZenIV>
On Fri, 27 Feb 2026 20:18:24 +0000
Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Fri, Feb 27, 2026 at 02:44:53PM -0500, AnishMulay wrote:
> > index d9d8932a7b9c9..86ba8dc25aaef 100644
> > --- a/fs/tracefs/inode.c
> > +++ b/fs/tracefs/inode.c
> > @@ -96,17 +96,7 @@ static struct tracefs_dir_ops {
> >
> > static char *get_dname(struct dentry *dentry)
> > {
> > - const char *dname;
> > - char *name;
> > - int len = dentry->d_name.len;
> > -
> > - dname = dentry->d_name.name;
> > - name = kmalloc(len + 1, GFP_KERNEL);
> > - if (!name)
> > - return NULL;
> > - memcpy(name, dname, len);
> > - name[len] = 0;
> > - return name;
> > + return kmemdup_nul(dentry->d_name.name, dentry->d_name.len, GFP_KERNEL);
> > }
>
> Why not have the callers use {take,release}_dentry_name_snapshot()
> instead of doing any allocations at all?
>
> I mean,
> static struct dentry *tracefs_syscall_mkdir(struct mnt_idmap *idmap,
> struct inode *inode, struct dentry *dentry,
> umode_t mode)
> {
> struct tracefs_inode *ti;
> struct name_snapshot s;
> int ret;
>
> take_dentry_name_snapshot(&s, dentry);
> ...
> ret = tracefs_ops.mkdir(s.name.name);
> release_dentry_name_snapshot(&s);
> ...
> }
>
> and similar on the rmdir side. Then remove get_dname()...
That sounds good to me.
-- Steve
^ permalink raw reply
* Re: [RFC PATCH bpf-next v3 0/3] Optimize kprobe.session attachment for exact function names
From: Alexei Starovoitov @ 2026-02-27 20:43 UTC (permalink / raw)
To: Andrey Grodzovsky
Cc: bpf, DL Linux Open Source Team, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Jiri Olsa, Steven Rostedt,
linux-trace-kernel
In-Reply-To: <20260227204052.725813-1-andrey.grodzovsky@crowdstrike.com>
On Fri, Feb 27, 2026 at 12:41 PM Andrey Grodzovsky
<andrey.grodzovsky@crowdstrike.com> wrote:
>
>
> Changes since v2 [2]:
> - Use if/else-if instead of goto (Jiri Olsa)
> - Use syms = &pattern directly (Jiri Olsa)
> - Drop unneeded pattern = NULL (Jiri Olsa)
> - Revert cosmetic rename in attach_kprobe_session (Jiri Olsa)
> - Remove "module symbols" from ftrace comment (CI bot)
RFC series are ignored by CI.
If you want things to land, drop RFC.
^ permalink raw reply
* Re: [External] Re: [RFC PATCH bpf-next v2 1/3] libbpf: Optimize kprobe.session attachment for exact function names
From: Andrey Grodzovsky @ 2026-02-27 20:52 UTC (permalink / raw)
To: Jiri Olsa
Cc: bpf, linux-open-source, ast, daniel, andrii, rostedt,
linux-trace-kernel
In-Reply-To: <aaHPfR_cOwKIm-lU@krava>
> - if (pattern) {
> + /*
> + * Exact function name (no wildcards): bypass kallsyms parsing
> + * and pass the symbol directly to the kernel via syms[] array.
> + * The kernel's ftrace_lookup_symbols() resolves it efficiently.
> + */
> + if (pattern && !strpbrk(pattern, "*?")) {
> + syms = &pattern;
> + cnt = 1;
> + } else if (pattern) {
> if (has_available_filter_functions_addrs())
> err = libbpf_available_kprobes_parse(&res);
>
>
> wdyt?
Totally agree, updated in V3.
Thanks,
Andrey
^ permalink raw reply
* Re: [PATCH] tracing: Fix WARN_ON in tracing_buffers_mmap_close
From: Steven Rostedt @ 2026-02-27 20:56 UTC (permalink / raw)
To: Vincent Donnefort
Cc: Qing Wang, Masami Hiramatsu, Mathieu Desnoyers, linux-kernel,
linux-trace-kernel, syzbot+3b5dd2030fe08afdf65d, linux-mm,
Andrew Morton, Lorenzo Stoakes, Vlastimil Babka
In-Reply-To: <20260227102038.0fef81e9@gandalf.local.home>
On Fri, 27 Feb 2026 10:20:38 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:
> On Fri, 27 Feb 2026 11:22:22 +0000
> Vincent Donnefort <vdonnefort@google.com> wrote:
>
> > > Ah right, Syzkaller is using madvise(MADVISE_DOFORK) which resets VM_DONTCOPY.
> >
> > As we are applying restrictive rules for this mapping, I believe setting VM_IO
> > might be a better fix.
>
> Agreed.
>
Adding MM folks so we do this right.
Dear MM folks,
Here's the issue. When the ftrace ring buffer is memory mapped to user
space, we do not want anything "special" done to it. One of those things we
did not want done was to have it copied on fork. To do that, we added
VM_DONTCOPY, but we didn't know that an madvise() could disable that. It
looks like VM_IO will prevent that from happening.
But looking at the various flags, I see there's a VM_SPECIAL. I'm wondering
if that is what we should use?
The effected code is here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/trace/ring_buffer.c#n7172
What's your thoughts?
Thanks,
-- Steve
^ permalink raw reply
* Re: [PATCH 03/61] trace: update VFS-layer trace events for u64 i_ino
From: Jeff Layton @ 2026-02-27 21:05 UTC (permalink / raw)
To: Steven Rostedt
Cc: Alexander Viro, Christian Brauner, Jan Kara, Masami Hiramatsu,
Mathieu Desnoyers, Dan Williams, Matthew Wilcox, Eric Biggers,
Theodore Y. Ts'o, Muchun Song, Oscar Salvador,
David Hildenbrand, David Howells, Paulo Alcantara, Andreas Dilger,
Jan Kara, Jaegeuk Kim, Chao Yu, Trond Myklebust, Anna Schumaker,
Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
Steve French, Ronnie Sahlberg, Shyam Prasad N, Bharath SM,
Alexander Aring, Ryusuke Konishi, Viacheslav Dubeyko,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, David Sterba, Marc Dionne, Ian Kent,
Luis de Bethencourt, Salah Triki, Tigran A. Aivazian,
Ilya Dryomov, Alex Markuze, Jan Harkes, coda, Nicolas Pitre,
Tyler Hicks, Amir Goldstein, Christoph Hellwig,
John Paul Adrian Glaubitz, Yangtao Li, Mikulas Patocka,
David Woodhouse, Richard Weinberger, Dave Kleikamp,
Konstantin Komarov, Mark Fasheh, Joel Becker, Joseph Qi,
Mike Marshall, Martin Brandenburg, Miklos Szeredi, Anders Larsen,
Zhihao Cheng, Damien Le Moal, Naohiro Aota, Johannes Thumshirn,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Fan Wu,
Stephen Smalley, Ondrej Mosnacek, Casey Schaufler, Alex Deucher,
Christian König, David Airlie, Simona Vetter, Sumit Semwal,
Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Darrick J. Wong,
Martin Schiller, linux-fsdevel, linux-kernel, linux-trace-kernel,
nvdimm, fsverity, linux-mm, netfs, linux-ext4, linux-f2fs-devel,
linux-nfs, linux-cifs, samba-technical, linux-nilfs, v9fs,
linux-afs, autofs, ceph-devel, codalist, ecryptfs, linux-mtd,
jfs-discussion, ntfs3, ocfs2-devel, devel, linux-unionfs,
apparmor, linux-security-module, linux-integrity, selinux,
amd-gfx, dri-devel, linux-media, linaro-mm-sig, netdev,
linux-perf-users, linux-fscrypt, linux-xfs, linux-hams, linux-x25
In-Reply-To: <20260226124842.5593ed85@gandalf.local.home>
On Thu, 2026-02-26 at 12:48 -0500, Steven Rostedt wrote:
> On Thu, 26 Feb 2026 10:55:05 -0500
> Jeff Layton <jlayton@kernel.org> wrote:
>
> > Update trace event definitions in VFS-layer trace headers to use u64
> > instead of ino_t/unsigned long for inode number fields, and change
> > format strings from %lu/%lx to %llu/%llx to match.
> >
> > This is needed because i_ino is now u64. Changing trace event field
> > types changes the binary trace format, but the self-describing format
> > metadata handles this transparently for modern trace-cmd and perf.
> >
> > Files updated:
> > - cachefiles.h, filelock.h, filemap.h, fs_dax.h, fsverity.h,
> > hugetlbfs.h, netfs.h, readahead.h, timestamp.h, writeback.h
> >
>
> Hmm, on 32 bit systems, this will likely cause "holes" in a lot of these
> events.
>
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> > include/trace/events/cachefiles.h | 18 ++---
> > include/trace/events/filelock.h | 16 ++---
> > include/trace/events/filemap.h | 20 +++---
> > include/trace/events/fs_dax.h | 20 +++---
> > include/trace/events/fsverity.h | 30 ++++----
> > include/trace/events/hugetlbfs.h | 28 ++++----
> > include/trace/events/netfs.h | 4 +-
> > include/trace/events/readahead.h | 12 ++--
> > include/trace/events/timestamp.h | 12 ++--
> > include/trace/events/writeback.h | 148 +++++++++++++++++++-------------------
> > 10 files changed, 154 insertions(+), 154 deletions(-)
> >
> > diff --git a/include/trace/events/cachefiles.h b/include/trace/events/cachefiles.h
> > index a743b2a35ea7001447b3e05d41539cb88013bc7f..f967027711ee823f224abc1b8ab03f63da06ae6f 100644
> > --- a/include/trace/events/cachefiles.h
> > +++ b/include/trace/events/cachefiles.h
> > @@ -251,8 +251,8 @@ TRACE_EVENT(cachefiles_lookup,
> > TP_STRUCT__entry(
> > __field(unsigned int, obj)
> > __field(short, error)
>
> There was already a 2 byte hole here, but that's not a big deal.
>
> > - __field(unsigned long, dino)
> > - __field(unsigned long, ino)
> > + __field(u64, dino)
> > + __field(u64, ino)
> > ),
> >
> > TP_fast_assign(
> > @@ -263,7 +263,7 @@ TRACE_EVENT(cachefiles_lookup,
> > __entry->error = IS_ERR(de) ? PTR_ERR(de) : 0;
> > ),
> >
> > - TP_printk("o=%08x dB=%lx B=%lx e=%d",
> > + TP_printk("o=%08x dB=%llx B=%llx e=%d",
> > __entry->obj, __entry->dino, __entry->ino, __entry->error)
> > );
> >
> > @@ -579,7 +579,7 @@ TRACE_EVENT(cachefiles_mark_active,
> > /* Note that obj may be NULL */
> > TP_STRUCT__entry(
> > __field(unsigned int, obj)
> > - __field(ino_t, inode)
> > + __field(u64, inode)
>
> Might be better to reorder any of these that have int first.
>
> u64 inode;
> int obj;
>
> Will be packed tighter than:
>
> int obj
> u64 inode;
>
> Probably should have changed that before anyway.
>
Ok, I'll look at that. Given the number of places that need it though I
may do it in a separate patch.
> > ),
> >
> > TP_fast_assign(
> > @@ -587,7 +587,7 @@ TRACE_EVENT(cachefiles_mark_active,
> > __entry->inode = inode->i_ino;
> > ),
> >
> > - TP_printk("o=%08x B=%lx",
> > + TP_printk("o=%08x B=%llx",
> > __entry->obj, __entry->inode)
> > );
> >
> > @@ -600,7 +600,7 @@ TRACE_EVENT(cachefiles_mark_failed,
> > /* Note that obj may be NULL */
> > TP_STRUCT__entry(
> > __field(unsigned int, obj)
> > - __field(ino_t, inode)
> > + __field(u64, inode)
>
> Is ino_t being changed? Why the update here?
>
No, ino_t isn't. That's part of the ABI and has to remain unsigned
long. The point of this series is to make inode->i_ino a u64. Any event
holding an ino_t today is going to need a 64-bit field to fully
describe it.
And to be clear, this should make things better for 32-bit boxes in the
long run. Once this change is done, i_ino should be a reliable source
of info regardless of machine's word size.
For the tracepoints, I think it's best to just extend them to 64-bit
fields outright rather than using the new (temporary) kino_t typedef
that I'm adding.
> > ),
> >
> > TP_fast_assign(
> > @@ -608,7 +608,7 @@ TRACE_EVENT(cachefiles_mark_failed,
> > __entry->inode = inode->i_ino;
> > ),
> >
> > - TP_printk("o=%08x B=%lx",
> > + TP_printk("o=%08x B=%llx",
> > __entry->obj, __entry->inode)
> > );
> >
> > @@ -621,7 +621,7 @@ TRACE_EVENT(cachefiles_mark_inactive,
> > /* Note that obj may be NULL */
> > TP_STRUCT__entry(
> > __field(unsigned int, obj)
> > - __field(ino_t, inode)
> > + __field(u64, inode)
>
> Ditto.
>
> > ),
> >
> > TP_fast_assign(
> > @@ -629,7 +629,7 @@ TRACE_EVENT(cachefiles_mark_inactive,
> > __entry->inode = inode->i_ino;
> > ),
> >
> > - TP_printk("o=%08x B=%lx",
> > + TP_printk("o=%08x B=%llx",
> > __entry->obj, __entry->inode)
> > );
> >
> > diff --git a/include/trace/events/filelock.h b/include/trace/events/filelock.h
> > index 370016c38a5bbc07d5ba6c102030b49c9eb6424d..41bc752616b25d6cd7955203e2c604029d0b440c 100644
> > --- a/include/trace/events/filelock.h
> > +++ b/include/trace/events/filelock.h
> > @@ -42,7 +42,7 @@ TRACE_EVENT(locks_get_lock_context,
> > TP_ARGS(inode, type, ctx),
> >
> > TP_STRUCT__entry(
> > - __field(unsigned long, i_ino)
> > + __field(u64, i_ino)
> > __field(dev_t, s_dev)
> > __field(unsigned char, type)
> > __field(struct file_lock_context *, ctx)
> > @@ -55,7 +55,7 @@ TRACE_EVENT(locks_get_lock_context,
> > __entry->ctx = ctx;
> > ),
> >
> > - TP_printk("dev=0x%x:0x%x ino=0x%lx type=%s ctx=%p",
> > + TP_printk("dev=0x%x:0x%x ino=0x%llx type=%s ctx=%p",
> > MAJOR(__entry->s_dev), MINOR(__entry->s_dev),
> > __entry->i_ino, show_fl_type(__entry->type), __entry->ctx)
> > );
> > @@ -67,7 +67,7 @@ DECLARE_EVENT_CLASS(filelock_lock,
> >
> > TP_STRUCT__entry(
> > __field(struct file_lock *, fl)
> > - __field(unsigned long, i_ino)
> > + __field(u64, i_ino)
>
> Having u64 before a pointer would be tighter on 32 bit systems, and leaves
> out any holes in the trace.
>
> > __field(dev_t, s_dev)
> > __field(struct file_lock_core *, blocker)
> > __field(fl_owner_t, owner)
> > @@ -93,7 +93,7 @@ DECLARE_EVENT_CLASS(filelock_lock,
> > __entry->ret = ret;
> > ),
> >
> > - TP_printk("fl=%p dev=0x%x:0x%x ino=0x%lx fl_blocker=%p fl_owner=%p fl_pid=%u fl_flags=%s fl_type=%s fl_start=%lld fl_end=%lld ret=%d",
> > + TP_printk("fl=%p dev=0x%x:0x%x ino=0x%llx fl_blocker=%p fl_owner=%p fl_pid=%u fl_flags=%s fl_type=%s fl_start=%lld fl_end=%lld ret=%d",
> > __entry->fl, MAJOR(__entry->s_dev), MINOR(__entry->s_dev),
> > __entry->i_ino, __entry->blocker, __entry->owner,
> > __entry->pid, show_fl_flags(__entry->flags),
> > @@ -124,7 +124,7 @@ DECLARE_EVENT_CLASS(filelock_lease,
> >
> > TP_STRUCT__entry(
> > __field(struct file_lease *, fl)
> > - __field(unsigned long, i_ino)
> > + __field(u64, i_ino)
>
> Same here.
>
> > __field(dev_t, s_dev)
> > __field(struct file_lock_core *, blocker)
> > __field(fl_owner_t, owner)
> > @@ -146,7 +146,7 @@ DECLARE_EVENT_CLASS(filelock_lease,
> > __entry->downgrade_time = fl ? fl->fl_downgrade_time : 0;
> > ),
> >
> > - TP_printk("fl=%p dev=0x%x:0x%x ino=0x%lx fl_blocker=%p fl_owner=%p fl_flags=%s fl_type=%s fl_break_time=%lu fl_downgrade_time=%lu",
> > + TP_printk("fl=%p dev=0x%x:0x%x ino=0x%llx fl_blocker=%p fl_owner=%p fl_flags=%s fl_type=%s fl_break_time=%lu fl_downgrade_time=%lu",
> > __entry->fl, MAJOR(__entry->s_dev), MINOR(__entry->s_dev),
> > __entry->i_ino, __entry->blocker, __entry->owner,
> > show_fl_flags(__entry->flags),
> > @@ -175,7 +175,7 @@ TRACE_EVENT(generic_add_lease,
> > TP_ARGS(inode, fl),
> >
> > TP_STRUCT__entry(
> > - __field(unsigned long, i_ino)
> > + __field(u64, i_ino)
> > __field(int, wcount)
> > __field(int, rcount)
> > __field(int, icount)
> > @@ -196,7 +196,7 @@ TRACE_EVENT(generic_add_lease,
> > __entry->type = fl->c.flc_type;
> > ),
> >
> > - TP_printk("dev=0x%x:0x%x ino=0x%lx wcount=%d rcount=%d icount=%d fl_owner=%p fl_flags=%s fl_type=%s",
> > + TP_printk("dev=0x%x:0x%x ino=0x%llx wcount=%d rcount=%d icount=%d fl_owner=%p fl_flags=%s fl_type=%s",
> > MAJOR(__entry->s_dev), MINOR(__entry->s_dev),
> > __entry->i_ino, __entry->wcount, __entry->rcount,
> > __entry->icount, __entry->owner,
> > diff --git a/include/trace/events/filemap.h b/include/trace/events/filemap.h
> > index f48fe637bfd25885dc6daaf09336ab60626b4944..153491e57cce6df73e30ddee60a52ed7d8923c24 100644
> > --- a/include/trace/events/filemap.h
> > +++ b/include/trace/events/filemap.h
> > @@ -21,7 +21,7 @@ DECLARE_EVENT_CLASS(mm_filemap_op_page_cache,
> >
> > TP_STRUCT__entry(
> > __field(unsigned long, pfn)
> > - __field(unsigned long, i_ino)
> > + __field(u64, i_ino)
>
> Again, this would cause a 32 bit hole.
>
> > __field(unsigned long, index)
> > __field(dev_t, s_dev)
> > __field(unsigned char, order)
> > @@ -38,7 +38,7 @@ DECLARE_EVENT_CLASS(mm_filemap_op_page_cache,
> > __entry->order = folio_order(folio);
> > ),
> >
> > - TP_printk("dev %d:%d ino %lx pfn=0x%lx ofs=%lu order=%u",
> > + TP_printk("dev %d:%d ino %llx pfn=0x%lx ofs=%lu order=%u",
> > MAJOR(__entry->s_dev), MINOR(__entry->s_dev),
> > __entry->i_ino,
> > __entry->pfn,
> > @@ -67,7 +67,7 @@ DECLARE_EVENT_CLASS(mm_filemap_op_page_cache_range,
> > TP_ARGS(mapping, index, last_index),
> >
> > TP_STRUCT__entry(
> > - __field(unsigned long, i_ino)
> > + __field(u64, i_ino)
> > __field(dev_t, s_dev)
> > __field(unsigned long, index)
> > __field(unsigned long, last_index)
> > @@ -85,7 +85,7 @@ DECLARE_EVENT_CLASS(mm_filemap_op_page_cache_range,
> > ),
> >
> > TP_printk(
> > - "dev=%d:%d ino=%lx ofs=%lld-%lld",
> > + "dev=%d:%d ino=%llx ofs=%lld-%lld",
> > MAJOR(__entry->s_dev),
> > MINOR(__entry->s_dev), __entry->i_ino,
> > ((loff_t)__entry->index) << PAGE_SHIFT,
> > @@ -117,7 +117,7 @@ TRACE_EVENT(mm_filemap_fault,
> > TP_ARGS(mapping, index),
> >
> > TP_STRUCT__entry(
> > - __field(unsigned long, i_ino)
> > + __field(u64, i_ino)
> > __field(dev_t, s_dev)
> > __field(unsigned long, index)
> > ),
> > @@ -133,7 +133,7 @@ TRACE_EVENT(mm_filemap_fault,
> > ),
> >
> > TP_printk(
> > - "dev=%d:%d ino=%lx ofs=%lld",
> > + "dev=%d:%d ino=%llx ofs=%lld",
> > MAJOR(__entry->s_dev),
> > MINOR(__entry->s_dev), __entry->i_ino,
> > ((loff_t)__entry->index) << PAGE_SHIFT
> > @@ -146,7 +146,7 @@ TRACE_EVENT(filemap_set_wb_err,
> > TP_ARGS(mapping, eseq),
> >
> > TP_STRUCT__entry(
> > - __field(unsigned long, i_ino)
> > + __field(u64, i_ino)
> > __field(dev_t, s_dev)
> > __field(errseq_t, errseq)
> > ),
> > @@ -160,7 +160,7 @@ TRACE_EVENT(filemap_set_wb_err,
> > __entry->s_dev = mapping->host->i_rdev;
> > ),
> >
> > - TP_printk("dev=%d:%d ino=0x%lx errseq=0x%x",
> > + TP_printk("dev=%d:%d ino=0x%llx errseq=0x%x",
> > MAJOR(__entry->s_dev), MINOR(__entry->s_dev),
> > __entry->i_ino, __entry->errseq)
> > );
> > @@ -172,7 +172,7 @@ TRACE_EVENT(file_check_and_advance_wb_err,
> >
> > TP_STRUCT__entry(
> > __field(struct file *, file)
> > - __field(unsigned long, i_ino)
> > + __field(u64, i_ino)
>
> Having a pointer after the u64 is better.
>
> > __field(dev_t, s_dev)
> > __field(errseq_t, old)
> > __field(errseq_t, new)
> > @@ -191,7 +191,7 @@ TRACE_EVENT(file_check_and_advance_wb_err,
> > __entry->new = file->f_wb_err;
> > ),
> >
> > - TP_printk("file=%p dev=%d:%d ino=0x%lx old=0x%x new=0x%x",
> > + TP_printk("file=%p dev=%d:%d ino=0x%llx old=0x%x new=0x%x",
> > __entry->file, MAJOR(__entry->s_dev),
> > MINOR(__entry->s_dev), __entry->i_ino, __entry->old,
> > __entry->new)
> > diff --git a/include/trace/events/fs_dax.h b/include/trace/events/fs_dax.h
> > index 50ebc1290ab062a9c30ab00049fb96691f9a0f23..11121baa8ece7928c653b4f874fb10ffbdd02fd0 100644
> > --- a/include/trace/events/fs_dax.h
> > +++ b/include/trace/events/fs_dax.h
> > @@ -12,7 +12,7 @@ DECLARE_EVENT_CLASS(dax_pmd_fault_class,
> > pgoff_t max_pgoff, int result),
> > TP_ARGS(inode, vmf, max_pgoff, result),
> > TP_STRUCT__entry(
> > - __field(unsigned long, ino)
> > + __field(u64, ino)
> > __field(unsigned long, vm_start)
> > __field(unsigned long, vm_end)
> > __field(vm_flags_t, vm_flags)
> > @@ -35,7 +35,7 @@ DECLARE_EVENT_CLASS(dax_pmd_fault_class,
> > __entry->max_pgoff = max_pgoff;
> > __entry->result = result;
> > ),
> > - TP_printk("dev %d:%d ino %#lx %s %s address %#lx vm_start "
> > + TP_printk("dev %d:%d ino %#llx %s %s address %#lx vm_start "
> > "%#lx vm_end %#lx pgoff %#lx max_pgoff %#lx %s",
> > MAJOR(__entry->dev),
> > MINOR(__entry->dev),
> > @@ -66,7 +66,7 @@ DECLARE_EVENT_CLASS(dax_pmd_load_hole_class,
> > void *radix_entry),
> > TP_ARGS(inode, vmf, zero_folio, radix_entry),
> > TP_STRUCT__entry(
> > - __field(unsigned long, ino)
> > + __field(u64, ino)
> > __field(vm_flags_t, vm_flags)
> > __field(unsigned long, address)
> > __field(struct folio *, zero_folio)
> > @@ -81,7 +81,7 @@ DECLARE_EVENT_CLASS(dax_pmd_load_hole_class,
> > __entry->zero_folio = zero_folio;
> > __entry->radix_entry = radix_entry;
> > ),
> > - TP_printk("dev %d:%d ino %#lx %s address %#lx zero_folio %p "
> > + TP_printk("dev %d:%d ino %#llx %s address %#lx zero_folio %p "
> > "radix_entry %#lx",
> > MAJOR(__entry->dev),
> > MINOR(__entry->dev),
> > @@ -106,7 +106,7 @@ DECLARE_EVENT_CLASS(dax_pte_fault_class,
> > TP_PROTO(struct inode *inode, struct vm_fault *vmf, int result),
> > TP_ARGS(inode, vmf, result),
> > TP_STRUCT__entry(
> > - __field(unsigned long, ino)
> > + __field(u64, ino)
> > __field(vm_flags_t, vm_flags)
> > __field(unsigned long, address)
> > __field(pgoff_t, pgoff)
> > @@ -123,7 +123,7 @@ DECLARE_EVENT_CLASS(dax_pte_fault_class,
> > __entry->pgoff = vmf->pgoff;
> > __entry->result = result;
> > ),
> > - TP_printk("dev %d:%d ino %#lx %s %s address %#lx pgoff %#lx %s",
> > + TP_printk("dev %d:%d ino %#llx %s %s address %#lx pgoff %#lx %s",
> > MAJOR(__entry->dev),
> > MINOR(__entry->dev),
> > __entry->ino,
> > @@ -150,7 +150,7 @@ DECLARE_EVENT_CLASS(dax_writeback_range_class,
> > TP_PROTO(struct inode *inode, pgoff_t start_index, pgoff_t end_index),
> > TP_ARGS(inode, start_index, end_index),
> > TP_STRUCT__entry(
> > - __field(unsigned long, ino)
> > + __field(u64, ino)
> > __field(pgoff_t, start_index)
> > __field(pgoff_t, end_index)
> > __field(dev_t, dev)
> > @@ -161,7 +161,7 @@ DECLARE_EVENT_CLASS(dax_writeback_range_class,
> > __entry->start_index = start_index;
> > __entry->end_index = end_index;
> > ),
> > - TP_printk("dev %d:%d ino %#lx pgoff %#lx-%#lx",
> > + TP_printk("dev %d:%d ino %#llx pgoff %#lx-%#lx",
> > MAJOR(__entry->dev),
> > MINOR(__entry->dev),
> > __entry->ino,
> > @@ -182,7 +182,7 @@ TRACE_EVENT(dax_writeback_one,
> > TP_PROTO(struct inode *inode, pgoff_t pgoff, pgoff_t pglen),
> > TP_ARGS(inode, pgoff, pglen),
> > TP_STRUCT__entry(
> > - __field(unsigned long, ino)
> > + __field(u64, ino)
> > __field(pgoff_t, pgoff)
> > __field(pgoff_t, pglen)
> > __field(dev_t, dev)
> > @@ -193,7 +193,7 @@ TRACE_EVENT(dax_writeback_one,
> > __entry->pgoff = pgoff;
> > __entry->pglen = pglen;
> > ),
> > - TP_printk("dev %d:%d ino %#lx pgoff %#lx pglen %#lx",
> > + TP_printk("dev %d:%d ino %#llx pgoff %#lx pglen %#lx",
> > MAJOR(__entry->dev),
> > MINOR(__entry->dev),
> > __entry->ino,
> > diff --git a/include/trace/events/fsverity.h b/include/trace/events/fsverity.h
> > index a8c52f21cbd5eb010c7e7b2fdb8f9de49c8ea326..4477c17e05748360965c4e1840590efe96d6335e 100644
> > --- a/include/trace/events/fsverity.h
> > +++ b/include/trace/events/fsverity.h
> > @@ -16,7 +16,7 @@ TRACE_EVENT(fsverity_enable,
> > const struct merkle_tree_params *params),
> > TP_ARGS(inode, params),
> > TP_STRUCT__entry(
> > - __field(ino_t, ino)
> > + __field(u64, ino)
>
> Do you need to convert all these ino_t's?
>
> > __field(u64, data_size)
> > __field(u64, tree_size)
> > __field(unsigned int, merkle_block)
> > @@ -29,8 +29,8 @@ TRACE_EVENT(fsverity_enable,
> > __entry->merkle_block = params->block_size;
> > __entry->num_levels = params->num_levels;
> > ),
> > - TP_printk("ino %lu data_size %llu tree_size %llu merkle_block %u levels %u",
> > - (unsigned long) __entry->ino,
> > + TP_printk("ino %llu data_size %llu tree_size %llu merkle_block %u levels %u",
> > + __entry->ino,
> > __entry->data_size,
> > __entry->tree_size,
> > __entry->merkle_block,
> > @@ -42,7 +42,7 @@ TRACE_EVENT(fsverity_tree_done,
> > const struct merkle_tree_params *params),
> > TP_ARGS(inode, vi, params),
> > TP_STRUCT__entry(
> > - __field(ino_t, ino)
> > + __field(u64, ino)
> > __field(u64, data_size)
> > __field(u64, tree_size)
> > __field(unsigned int, merkle_block)
> > @@ -59,8 +59,8 @@ TRACE_EVENT(fsverity_tree_done,
> > memcpy(__get_dynamic_array(root_hash), vi->root_hash, __get_dynamic_array_len(root_hash));
> > memcpy(__get_dynamic_array(file_digest), vi->file_digest, __get_dynamic_array_len(file_digest));
> > ),
> > - TP_printk("ino %lu data_size %llu tree_size %lld merkle_block %u levels %u root_hash %s digest %s",
> > - (unsigned long) __entry->ino,
> > + TP_printk("ino %llu data_size %llu tree_size %lld merkle_block %u levels %u root_hash %s digest %s",
> > + __entry->ino,
> > __entry->data_size,
> > __entry->tree_size,
> > __entry->merkle_block,
> > @@ -75,7 +75,7 @@ TRACE_EVENT(fsverity_verify_data_block,
> > u64 data_pos),
> > TP_ARGS(inode, params, data_pos),
> > TP_STRUCT__entry(
> > - __field(ino_t, ino)
> > + __field(u64, ino)
> > __field(u64, data_pos)
> > __field(unsigned int, merkle_block)
> > ),
> > @@ -84,8 +84,8 @@ TRACE_EVENT(fsverity_verify_data_block,
> > __entry->data_pos = data_pos;
> > __entry->merkle_block = params->block_size;
> > ),
> > - TP_printk("ino %lu data_pos %llu merkle_block %u",
> > - (unsigned long) __entry->ino,
> > + TP_printk("ino %llu data_pos %llu merkle_block %u",
> > + __entry->ino,
> > __entry->data_pos,
> > __entry->merkle_block)
> > );
> > @@ -96,7 +96,7 @@ TRACE_EVENT(fsverity_merkle_hit,
> > unsigned int hidx),
> > TP_ARGS(inode, data_pos, hblock_idx, level, hidx),
> > TP_STRUCT__entry(
> > - __field(ino_t, ino)
> > + __field(u64, ino)
> > __field(u64, data_pos)
>
> Heh, this actually removed a hole, but again, why convert ino_t?
>
> Anyway, I stopped here. But you get the idea.
>
>
> > __field(unsigned long, hblock_idx)
> > __field(unsigned int, level)
Thanks for the review! I'll definitely look at reordering the
tracepoint fields for better packing since that has material
consequences.
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* [PATCH v2] tracefs: Use dentry name snapshots instead of heap allocation
From: AnishMulay @ 2026-02-27 21:15 UTC (permalink / raw)
To: rostedt, viro
Cc: mhiramat, mathieu.desnoyers, linux-trace-kernel, linux-kernel,
AnishMulay
In-Reply-To: <20260227154210.5bd19a45@gandalf.local.home>
In fs/tracefs/inode.c, tracefs_syscall_mkdir() and tracefs_syscall_rmdir()
previously used a local helper, get_dname(), which allocated a temporary
buffer on the heap via kmalloc() to hold the dentry name. This introduced
unnecessary overhead, an ENOMEM failure path, and required manual memory
cleanup via kfree().
As suggested by Al Viro, replace this heap allocation with the VFS dentry
name snapshot API. By stack-allocating a `struct name_snapshot` and using
take_dentry_name_snapshot() and release_dentry_name_snapshot(), we safely
capture the dentry name locklessly, eliminate the heap allocation entirely,
and remove the now-obsolete error handling paths. The get_dname() helper
is completely removed.
Testing:
Booted a custom kernel natively in virtme-ng (ARM64). Triggered tracefs
inode and dentry allocation by creating and removing a custom directory
under a temporary tracefs mount. Verified that the instance is created
successfully and that no memory errors or warnings are emitted in dmesg.
Signed-off-by: AnishMulay <anishm7030@gmail.com>
---
fs/tracefs/inode.c | 29 ++++++++---------------------
1 file changed, 8 insertions(+), 21 deletions(-)
diff --git a/fs/tracefs/inode.c b/fs/tracefs/inode.c
index 86ba8dc25aaef..ad322e8f9e2ad 100644
--- a/fs/tracefs/inode.c
+++ b/fs/tracefs/inode.c
@@ -94,23 +94,14 @@ static struct tracefs_dir_ops {
int (*rmdir)(const char *name);
} tracefs_ops __ro_after_init;
-static char *get_dname(struct dentry *dentry)
-{
- return kmemdup_nul(dentry->d_name.name, dentry->d_name.len, GFP_KERNEL);
-}
-
static struct dentry *tracefs_syscall_mkdir(struct mnt_idmap *idmap,
struct inode *inode, struct dentry *dentry,
umode_t mode)
{
struct tracefs_inode *ti;
- char *name;
+ struct name_snapshot name;
int ret;
- name = get_dname(dentry);
- if (!name)
- return ERR_PTR(-ENOMEM);
-
/*
* This is a new directory that does not take the default of
* the rootfs. It becomes the default permissions for all the
@@ -125,24 +116,20 @@ static struct dentry *tracefs_syscall_mkdir(struct mnt_idmap *idmap,
* the files within the tracefs system. It is up to the individual
* mkdir routine to handle races.
*/
+ take_dentry_name_snapshot(&name, dentry);
inode_unlock(inode);
- ret = tracefs_ops.mkdir(name);
+ ret = tracefs_ops.mkdir(name.name.name);
inode_lock(inode);
-
- kfree(name);
+ release_dentry_name_snapshot(&name);
return ERR_PTR(ret);
}
static int tracefs_syscall_rmdir(struct inode *inode, struct dentry *dentry)
{
- char *name;
+ struct name_snapshot name;
int ret;
- name = get_dname(dentry);
- if (!name)
- return -ENOMEM;
-
/*
* The rmdir call can call the generic functions that create
* the files within the tracefs system. It is up to the individual
@@ -150,15 +137,15 @@ static int tracefs_syscall_rmdir(struct inode *inode, struct dentry *dentry)
* This time we need to unlock not only the parent (inode) but
* also the directory that is being deleted.
*/
+ take_dentry_name_snapshot(&name, dentry);
inode_unlock(inode);
inode_unlock(d_inode(dentry));
- ret = tracefs_ops.rmdir(name);
+ ret = tracefs_ops.rmdir(name.name.name);
inode_lock_nested(inode, I_MUTEX_PARENT);
inode_lock(d_inode(dentry));
-
- kfree(name);
+ release_dentry_name_snapshot(&name);
return ret;
}
--
2.51.0
^ permalink raw reply related
* Re: [External] Re: [RFC PATCH bpf-next v3 0/3] Optimize kprobe.session attachment for exact function names
From: Andrey Grodzovsky @ 2026-02-27 21:15 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: bpf, DL Linux Open Source Team, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Jiri Olsa, Steven Rostedt,
linux-trace-kernel
In-Reply-To: <CAADnVQLrhkCkpE6UZbkPaNTFMYRoa_ZtyknhVM7FMmsH7Lvj5A@mail.gmail.com>
Hey Alexei, just to be clear, do you mean drop the entire RFC letter or,
Drop the RFC prefix from the letter so the CI pipeline can be properly
triggered ?
Thanks,
Andrey
On Fri, Feb 27, 2026 at 3:43 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Fri, Feb 27, 2026 at 12:41 PM Andrey Grodzovsky
> <andrey.grodzovsky@crowdstrike.com> wrote:
> >
> >
> > Changes since v2 [2]:
> > - Use if/else-if instead of goto (Jiri Olsa)
> > - Use syms = &pattern directly (Jiri Olsa)
> > - Drop unneeded pattern = NULL (Jiri Olsa)
> > - Revert cosmetic rename in attach_kprobe_session (Jiri Olsa)
> > - Remove "module symbols" from ftrace comment (CI bot)
>
> RFC series are ignored by CI.
> If you want things to land, drop RFC.
^ permalink raw reply
* Re: [RFC PATCH bpf-next v3 1/3] libbpf: Optimize kprobe.session attachment for exact function names
From: bot+bpf-ci @ 2026-02-27 21:17 UTC (permalink / raw)
To: andrey.grodzovsky, bpf, linux-open-source
Cc: ast, daniel, andrii, jolsa, rostedt, linux-trace-kernel, ast,
andrii, daniel, martin.lau, eddyz87, yonghong.song, clm,
ihor.solodrai
In-Reply-To: <20260227204052.725813-2-andrey.grodzovsky@crowdstrike.com>
[-- Attachment #1: Type: text/plain, Size: 2490 bytes --]
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -12041,7 +12041,15 @@ struct kprobe_multi_resolve res = {
> if (addrs && syms)
> return libbpf_err_ptr(-EINVAL);
>
> - if (pattern) {
> + /*
> + * Exact function name (no wildcards): bypass kallsyms parsing
> + * and pass the symbol directly to the kernel via syms[] array.
> + * The kernel's ftrace_lookup_symbols() resolves it efficiently.
> + */
> + if (pattern && !strpbrk(pattern, "*?")) {
> + syms = &pattern;
> + cnt = 1;
> + } else if (pattern) {
When the fast path is taken here, unique_match is never checked.
The unique_match validation is inside the "else if (pattern)"
branch:
if (unique_match && res.cnt != 1) {
pr_warn("prog '%s': failed to find a unique match ...");
err = -EINVAL;
goto error;
}
Before this change, a caller passing an exact function name with
unique_match = true would go through kallsyms parsing, which could
find multiple addresses for same-named static functions across
different translation units, and the unique_match check would
correctly return an error.
With the fast path, the name goes directly to the kernel's
ftrace_lookup_symbols(), which resolves only the first match via
kallsyms_callback() skipping duplicates:
if (args->addrs[idx])
return 0;
Should the fast path condition also check unique_match, for
example:
if (pattern && !strpbrk(pattern, "*?") && !unique_match) {
This would preserve the optimization for the common case while
falling back to the slow path when unique_match is explicitly
requested.
> [ ... ]
---
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/22503275616
AI-authorship-score: medium
AI-authorship-explanation: Comments are unusually verbose for a simple optimization, and the commit message is well-structured with distinct sections, but the iterative v1-v3 refinement following reviewer feedback is typical of human development.
issues-found: 1
issue-severity-score: low
issue-severity-explanation: The fast path bypasses the unique_match check, which could silently attach to the wrong function among same-named statics, but requires the uncommon combination of unique_match=true with an exact name matching multiple kernel functions.
^ permalink raw reply
* Re: [PATCHv6 bpf-next 9/9] bpf,x86: Use single ftrace_ops for direct calls
From: Jiri Olsa @ 2026-02-27 21:24 UTC (permalink / raw)
To: Ihor Solodrai
Cc: Jiri Olsa, Steven Rostedt, Florent Revest, Mark Rutland, bpf,
linux-kernel, linux-trace-kernel, linux-arm-kernel,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Menglong Dong, Song Liu, Kumar Kartikeya Dwivedi
In-Reply-To: <aaIAoBZGkP7RQrvc@krava>
On Fri, Feb 27, 2026 at 09:37:52PM +0100, Jiri Olsa wrote:
> On Fri, Feb 27, 2026 at 09:40:12AM -0800, Ihor Solodrai wrote:
> > On 12/30/25 6:50 AM, Jiri Olsa wrote:
> > > Using single ftrace_ops for direct calls update instead of allocating
> > > ftrace_ops object for each trampoline.
> > >
> > > With single ftrace_ops object we can use update_ftrace_direct_* api
> > > that allows multiple ip sites updates on single ftrace_ops object.
> > >
> > > Adding HAVE_SINGLE_FTRACE_DIRECT_OPS config option to be enabled on
> > > each arch that supports this.
> > >
> > > At the moment we can enable this only on x86 arch, because arm relies
> > > on ftrace_ops object representing just single trampoline image (stored
> > > in ftrace_ops::direct_call). Archs that do not support this will continue
> > > to use *_ftrace_direct api.
> > >
> > > Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> >
> > Hi Jiri,
> >
> > Me and Kumar stumbled on kernel splats with "ftrace failed to modify",
> > and if running with KASAN:
> >
> > BUG: KASAN: slab-use-after-free in __get_valid_kprobe+0x224/0x2a0
> >
> > Pasting a full splat example at the bottom.
> >
> > I was able to create a reproducer with AI, and then used it to bisect
> > to this patch. You can run it with ./test_progs -t ftrace_direct_race
> >
> > Below is my (human-generated, haha) summary of AI's analysis of what's
> > happening. It makes sense to me conceptually, but I don't know enough
> > details here to call bullshit. Please take a look:
>
> hi, nice :)
>
> >
> > With CONFIG_HAVE_SINGLE_FTRACE_DIRECT_OPS ftrace_replace_code()
> > operates on all call sites in the shared ops. Then if a concurrent
> > ftrace user (like kprobe) modifies a call site in between
> > ftrace_replace_code's verify pass and its patch pass, then ftrace_bug
> > fires and sets ftrace_disabled to 1.
>
> hum, I'd think that's all under ftrace_lock/direct_mutex,
> but we might be missing some paths
>
could you please try with change below? I can no longer trigger the bug with it
thanks,
jirka
---
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 827fb9a0bf0d..e333749a5896 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -6404,7 +6404,9 @@ int update_ftrace_direct_add(struct ftrace_ops *ops, struct ftrace_hash *hash)
new_filter_hash = old_filter_hash;
}
} else {
+ mutex_lock(&ftrace_lock);
err = ftrace_update_ops(ops, new_filter_hash, EMPTY_HASH);
+ mutex_unlock(&ftrace_lock);
/*
* new_filter_hash is dup-ed, so we need to release it anyway,
* old_filter_hash either stays on error or is already released
@@ -6530,7 +6532,9 @@ int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash)
ops->func_hash->filter_hash = NULL;
}
} else {
+ mutex_lock(&ftrace_lock);
err = ftrace_update_ops(ops, new_filter_hash, EMPTY_HASH);
+ mutex_unlock(&ftrace_lock);
/*
* new_filter_hash is dup-ed, so we need to release it anyway,
* old_filter_hash either stays on error or is already released
^ permalink raw reply related
* Re: [PATCH v18 0/3] Improve proc RSS accuracy
From: Andrew Morton @ 2026-02-27 21:27 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: linux-kernel, Paul E. McKenney, Steven Rostedt, Masami Hiramatsu,
Dennis Zhou, Tejun Heo, Christoph Lameter, Martin Liu,
David Rientjes, christian.koenig, Shakeel Butt, SeongJae Park,
Michal Hocko, Johannes Weiner, Sweet Tea Dorminy, Lorenzo Stoakes,
Liam R . Howlett, Mike Rapoport, Suren Baghdasaryan,
Vlastimil Babka, Christian Brauner, Wei Yang, David Hildenbrand,
Miaohe Lin, Al Viro, linux-mm, linux-trace-kernel, Yu Zhao,
Roman Gushchin, Mateusz Guzik, Matthew Wilcox, Baolin Wang,
Aboorva Devarajan
In-Reply-To: <20260227153730.1556542-1-mathieu.desnoyers@efficios.com>
On Fri, 27 Feb 2026 10:37:27 -0500 Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
> This series introduces the hierarchical tree counter (hpcc) to increase
> accuracy of approximated RSS counters exposed through proc interfaces.
>
> With a test program hopping across CPUs doing frequent mmap/munmap
> operations, the upstream implementation approximation reaches a 1GB
> delta from the precise value after a few minutes, compared to a 80MB
> delta with the hierarchical counter. The hierarchical counter provides a
> guaranteed maximum approximation inaccuracy of 192MB on that hardware
> topology.
>
> This series is based on tag v7.0-rc1.
>
> The main changes since v17:
> - Fix patch series bissectability.
> - Export GPL symbols for kunit tests.
> - Improve kunit tests coverage.
> - Fix kunit tests wait queue head reinit bug.
> - Fix an out-of-bound on bootup on configurations where nr_cpu_ids is
> close to NR_CPUS.
Updated, thanks.
> Andrew, this series targets 7.1.
Some review would be useful. Can you think of someone we could ask to
undertake this?
^ permalink raw reply
* Re: [PATCHv6 bpf-next 9/9] bpf,x86: Use single ftrace_ops for direct calls
From: Ihor Solodrai @ 2026-02-27 22:00 UTC (permalink / raw)
To: Jiri Olsa
Cc: Steven Rostedt, Florent Revest, Mark Rutland, bpf, linux-kernel,
linux-trace-kernel, linux-arm-kernel, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Menglong Dong, Song Liu,
Kumar Kartikeya Dwivedi
In-Reply-To: <aaILlSuEgaYDq41r@krava>
On 2/27/26 1:24 PM, Jiri Olsa wrote:
> On Fri, Feb 27, 2026 at 09:37:52PM +0100, Jiri Olsa wrote:
>> [...]
>>
>>>
>>> With CONFIG_HAVE_SINGLE_FTRACE_DIRECT_OPS ftrace_replace_code()
>>> operates on all call sites in the shared ops. Then if a concurrent
>>> ftrace user (like kprobe) modifies a call site in between
>>> ftrace_replace_code's verify pass and its patch pass, then ftrace_bug
>>> fires and sets ftrace_disabled to 1.
>>
>> hum, I'd think that's all under ftrace_lock/direct_mutex,
>> but we might be missing some paths
>>
>
> could you please try with change below? I can no longer trigger the bug with it
Can confirm that the bug doesn't trigger with this change.
At least by the reproducer test.
Tested-by: Ihor Solodrai <ihor.solodrai@linux.dev>
Thanks!
>
> thanks,
> jirka
>
>
> ---
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 827fb9a0bf0d..e333749a5896 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -6404,7 +6404,9 @@ int update_ftrace_direct_add(struct ftrace_ops *ops, struct ftrace_hash *hash)
> new_filter_hash = old_filter_hash;
> }
> } else {
> + mutex_lock(&ftrace_lock);
> err = ftrace_update_ops(ops, new_filter_hash, EMPTY_HASH);
> + mutex_unlock(&ftrace_lock);
> /*
> * new_filter_hash is dup-ed, so we need to release it anyway,
> * old_filter_hash either stays on error or is already released
> @@ -6530,7 +6532,9 @@ int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash)
> ops->func_hash->filter_hash = NULL;
> }
> } else {
> + mutex_lock(&ftrace_lock);
> err = ftrace_update_ops(ops, new_filter_hash, EMPTY_HASH);
> + mutex_unlock(&ftrace_lock);
> /*
> * new_filter_hash is dup-ed, so we need to release it anyway,
> * old_filter_hash either stays on error or is already released
^ permalink raw reply
* Re: [External] Re: [RFC PATCH bpf-next v3 1/3] libbpf: Optimize kprobe.session attachment for exact function names
From: Andrey Grodzovsky @ 2026-02-27 22:28 UTC (permalink / raw)
To: bot+bpf-ci, yonghong.song
Cc: bpf, linux-open-source, ast, daniel, andrii, jolsa, rostedt,
linux-trace-kernel, martin.lau, eddyz87, clm, ihor.solodrai
In-Reply-To: <2d0e9de12b7bf49a0b5117da6d305b0e918785818b63798dfd85de1635b68e8b@mail.kernel.org>
On Fri, Feb 27, 2026 at 4:18 PM <bot+bpf-ci@kernel.org> wrote:
>
> > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> > --- a/tools/lib/bpf/libbpf.c
> > +++ b/tools/lib/bpf/libbpf.c
> > @@ -12041,7 +12041,15 @@ struct kprobe_multi_resolve res = {
> > if (addrs && syms)
> > return libbpf_err_ptr(-EINVAL);
> >
> > - if (pattern) {
> > + /*
> > + * Exact function name (no wildcards): bypass kallsyms parsing
> > + * and pass the symbol directly to the kernel via syms[] array.
> > + * The kernel's ftrace_lookup_symbols() resolves it efficiently.
> > + */
> > + if (pattern && !strpbrk(pattern, "*?")) {
> > + syms = &pattern;
> > + cnt = 1;
> > + } else if (pattern) {
>
> When the fast path is taken here, unique_match is never checked.
> The unique_match validation is inside the "else if (pattern)"
> branch:
>
> if (unique_match && res.cnt != 1) {
> pr_warn("prog '%s': failed to find a unique match ...");
> err = -EINVAL;
> goto error;
> }
>
> Before this change, a caller passing an exact function name with
> unique_match = true would go through kallsyms parsing, which could
> find multiple addresses for same-named static functions across
> different translation units, and the unique_match check would
> correctly return an error.
>
> With the fast path, the name goes directly to the kernel's
> ftrace_lookup_symbols(), which resolves only the first match via
> kallsyms_callback() skipping duplicates:
>
> if (args->addrs[idx])
> return 0;
>
> Should the fast path condition also check unique_match, for
> example:
>
> if (pattern && !strpbrk(pattern, "*?") && !unique_match) {
>
> This would preserve the optimization for the common case while
> falling back to the slow path when unique_match is explicitly
> requested.
>
I am not sure this makes sense, according to the original patchset [1]
this flag was specifically tailored for patterns with wildcards where
this indeed
makes sense. in our case, cnt == 1 from the get go since no wildcards so this
check can't ever fail.
Andrii, Yonghong - any suggestions ?
[1] - https://lore.kernel.org/bpf/20241218225246.3170300-1-yonghong.song@linux.dev/
Andrey
> > [ ... ]
>
>
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://urldefense.com/v3/__https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md__;!!BmdzS3_lV9HdKG8!z-aIXCz8YRZcraMmGI2bmb4YrDgW0brRTcX_BaJCWYwj7xfmkZL6qka6aqqIwzDPUjR1TxUU-Mc50s9AAYQf-vQMuPuGlVKW$
>
> CI run summary: https://urldefense.com/v3/__https://github.com/kernel-patches/bpf/actions/runs/22503275616__;!!BmdzS3_lV9HdKG8!z-aIXCz8YRZcraMmGI2bmb4YrDgW0brRTcX_BaJCWYwj7xfmkZL6qka6aqqIwzDPUjR1TxUU-Mc50s9AAYQf-vQMuGeekJPd$
>
> AI-authorship-score: medium
> AI-authorship-explanation: Comments are unusually verbose for a simple optimization, and the commit message is well-structured with distinct sections, but the iterative v1-v3 refinement following reviewer feedback is typical of human development.
> issues-found: 1
> issue-severity-score: low
> issue-severity-explanation: The fast path bypasses the unique_match check, which could silently attach to the wrong function among same-named statics, but requires the uncommon combination of unique_match=true with an exact name matching multiple kernel functions.
^ permalink raw reply
* Re: [PATCH] blktrace: fix __this_cpu_read/write in preemptible context
From: Chaitanya Kulkarni @ 2026-02-27 23:08 UTC (permalink / raw)
To: Steven Rostedt, axboe@kernel.dk
Cc: mhiramat@kernel.org, mathieu.desnoyers@efficios.com,
shinichiro.kawasaki@wdc.com, linux-block@vger.kernel.org,
Chaitanya Kulkarni, linux-trace-kernel@vger.kernel.org
In-Reply-To: <20260227141951.102e19ce@gandalf.local.home>
On 2/27/26 11:19, Steven Rostedt wrote:
> On Thu, 26 Feb 2026 21:03:03 -0800
> Chaitanya Kulkarni <kch@nvidia.com> wrote:
>
>> diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
>> index 3b7c102a6eb3..488552036583 100644
>> --- a/kernel/trace/blktrace.c
>> +++ b/kernel/trace/blktrace.c
>> @@ -383,7 +383,9 @@ static void __blk_add_trace(struct blk_trace *bt, sector_t sector, int bytes,
>> cpu = raw_smp_processor_id();
>>
>> if (blk_tracer) {
>> + preempt_disable_notrace();
>> tracing_record_cmdline(current);
>> + preempt_enable_notrace();
>>
>> buffer = blk_tr->array_buffer.buffer;
>> trace_ctx = tracing_gen_ctx_flags(0);
> Do you know when this started? rcu_read_lock() doesn't disable preemption
> in PREEMPT environments, and hasn't for a very long time. I'm surprised it
> took this long to detect this? Perhaps this was a bug from day one?
This started with latest pull which I did on Wed.
Last time same test passed on 2/11/26 since I ran blktests and posted
following patch on 2/11/26 12:47 pacific :-
[PATCH V4] blktrace: log dropped REQ_OP_ZONE_XXX events ver1
Shinichiro CC'd here also reported same bug.
I think Fixes tag would be :-
Fixes: 7ffbd48d5cab ("tracing: Cache comms only after an event occurred")
Since above commit added __this_cpu_read(trace_cmdline_save) and
__this_cpu_write(trace_cmdline_save) :-
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index b90a827a4641..88111b08b2c1 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -77,6 +77,13 @@ static int dummy_set_flag(u32 old_flags, u32 bit, int set)
return 0;
}
+/*
+ * To prevent the comm cache from being overwritten when no
+ * tracing is active, only save the comm when a trace event
+ * occurred.
+ */
+static DEFINE_PER_CPU(bool, trace_cmdline_save);
+
/*
* Kill all tracing for good (never come back).
* It is initialized to 1 but will turn to zero if the initialization
@@ -1135,6 +1142,11 @@ void tracing_record_cmdline(struct task_struct *tsk)
!tracing_is_on())
return;
+ if (!__this_cpu_read(trace_cmdline_save))
+ return;
+
+ __this_cpu_write(trace_cmdline_save, false);
+
trace_save_cmdline(tsk);
}
Full disclosure I've no idea why it has started showing up this month.
I've worked on blktrace extensively and tested my code a lot for form
2020-2021 after above commit but never has seen this even with my patches.
> Anyway, the tracing_record_cmdline() is to update the COMM cache so that
> the trace has way to show the task->comm based on the saved PID in the
> trace. It sets a flag to record the COMM from the sched_switch event if a
> trace event happened. It's not needed if no trace event occurred. That
> means, instead of adding preempt_disable() here, just move it after the
> ring buffer event is reserved, as that means preemption is disabled until
> the event is committed.
>
> i.e.
>
> diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
> index e6988929ead2..3735cbc1f99f 100644
> --- a/kernel/trace/blktrace.c
> +++ b/kernel/trace/blktrace.c
> @@ -383,8 +383,6 @@ static void __blk_add_trace(struct blk_trace *bt, sector_t sector, int bytes,
> cpu = raw_smp_processor_id();
>
> if (blk_tracer) {
> - tracing_record_cmdline(current);
> -
> buffer = blk_tr->array_buffer.buffer;
> trace_ctx = tracing_gen_ctx_flags(0);
> switch (bt->version) {
> @@ -419,6 +417,8 @@ static void __blk_add_trace(struct blk_trace *bt, sector_t sector, int bytes,
> if (!event)
> return;
>
> + tracing_record_cmdline(current);
> +
> switch (bt->version) {
> case 1:
> record_blktrace_event(ring_buffer_event_data(event),
>
> -- Steve
Above does fix the problem and make testcase pass :-
blktests (master) # ./check blktrace
blktrace/001 (blktrace zone management command tracing) [passed]
runtime 3.650s ... 3.647s
blktrace/002 (blktrace ftrace corruption with sysfs trace) [passed]
runtime 0.411s ... 0.384s
blktests (master) #
I'll send a V2.
-ck
^ permalink raw reply related
* Re: [PATCH] tracing/osnoise: Add option to align tlat threads
From: Crystal Wood @ 2026-02-27 23:49 UTC (permalink / raw)
To: Tomas Glozar, Steven Rostedt, Masami Hiramatsu
Cc: Mathieu Desnoyers, John Kacur, Luis Goncalves, Costa Shulyupin,
Wander Lairson Costa, LKML, linux-trace-kernel
In-Reply-To: <20260227150420.319528-1-tglozar@redhat.com>
On Fri, 2026-02-27 at 16:04 +0100, Tomas Glozar wrote:
> Add an option called TIMERLAT_ALIGN to osnoise/options, together with a
> corresponding setting osnoise/timerlat_align_us.
>
> This option sets the alignment of wakeup times between different
> timerlat threads, similarly to cyclictest's -A/--aligned option. If
> TIMERLAT_ALIGN is set, the first thread that reaches the first cycle
> records its first wake-up time. Each following thread sets its first
> wake-up time to a fixed offset from the recorded time, and incremenets
> it by the same offset.
Why not just set the initial timer expiration to be
"period + cpu * align_us"? Then you wouldn't need any interaction
between CPUs.
> kernel/trace/trace_osnoise.c | 34 +++++++++++++++++++++++++++++++++-
> 1 file changed, 33 insertions(+), 1 deletion(-)
Documentation needs to be updated as well.
Should mention that updating align_us while the timer is running won't
take effect immediately (unlike period, which does).
> diff --git a/kernel/trace/trace_osnoise.c b/kernel/trace/trace_osnoise.c
> index dee610e465b9..df1d4529d226 100644
> --- a/kernel/trace/trace_osnoise.c
> +++ b/kernel/trace/trace_osnoise.c
> @@ -58,6 +58,7 @@ enum osnoise_options_index {
> OSN_PANIC_ON_STOP,
> OSN_PREEMPT_DISABLE,
> OSN_IRQ_DISABLE,
> + OSN_TIMERLAT_ALIGN,
> OSN_MAX
> };
>
> @@ -66,7 +67,8 @@ static const char * const osnoise_options_str[OSN_MAX] = {
> "OSNOISE_WORKLOAD",
> "PANIC_ON_STOP",
> "OSNOISE_PREEMPT_DISABLE",
> - "OSNOISE_IRQ_DISABLE" };
> + "OSNOISE_IRQ_DISABLE",
> + "TIMERLAT_ALIGN" };
Do we really need a flag for this, or can we just interpret a non-zero
align_us value as enabling the feature?
> @@ -1820,6 +1824,7 @@ static int wait_next_period(struct timerlat_variables *tlat)
> {
> ktime_t next_abs_period, now;
> u64 rel_period = osnoise_data.timerlat_period * 1000;
> + static atomic64_t align_next;
How will this get reset if the tracer is stopped and restarted?
> now = hrtimer_cb_get_time(&tlat->timer);
> next_abs_period = ns_to_ktime(tlat->abs_period + rel_period);
> @@ -1829,6 +1834,17 @@ static int wait_next_period(struct timerlat_variables *tlat)
> */
> tlat->abs_period = (u64) ktime_to_ns(next_abs_period);
>
> + if (test_bit(OSN_TIMERLAT_ALIGN, &osnoise_options) && !tlat->count
> + && atomic64_cmpxchg_relaxed(&align_next, 0, tlat->abs_period)) {
> + /*
> + * Align thread in first cycle on each CPU to the set alignment.
> + */
> + tlat->abs_period = atomic64_fetch_add_relaxed(osnoise_data.timerlat_align_us * 1000,
> + &align_next);
> + tlat->abs_period += osnoise_data.timerlat_align_us * 1000;
> + next_abs_period = ns_to_ktime(tlat->abs_period);
> + }
I'm already unclear about the existing purpose of next_abs_period, but
if it has any use at all shouldn't it be to avoid writing intermediate
values like this back to tlat?
-Crystal
^ permalink raw reply
* Re: [PATCH v4 1/5] mm: introduce zone lock wrappers
From: Zi Yan @ 2026-02-28 1:13 UTC (permalink / raw)
To: Dmitry Ilvokhin
Cc: Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Axel Rasmussen, Yuanchu Xie,
Wei Xu, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Rafael J. Wysocki, Pavel Machek, Len Brown, Brendan Jackman,
Johannes Weiner, Oscar Salvador, Qi Zheng, Shakeel Butt,
linux-kernel, linux-mm, linux-trace-kernel, linux-pm, linux-cxl,
kernel-team
In-Reply-To: <849dee9c47df1e6fba97c9933af0d5a08b8e15d3.1772206930.git.d@ilvokhin.com>
On 27 Feb 2026, at 11:00, Dmitry Ilvokhin wrote:
> Add thin wrappers around zone lock acquire/release operations. This
> prepares the code for future tracepoint instrumentation without
> modifying individual call sites.
>
> Centralizing zone lock operations behind wrappers allows future
> instrumentation or debugging hooks to be added without touching
> all users.
>
> No functional change intended. The wrappers are introduced in
> preparation for subsequent patches and are not yet used.
>
> Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
> Acked-by: Shakeel Butt <shakeel.butt@linux.dev>
> ---
> MAINTAINERS | 1 +
> include/linux/mmzone_lock.h | 38 +++++++++++++++++++++++++++++++++++++
> 2 files changed, 39 insertions(+)
> create mode 100644 include/linux/mmzone_lock.h
>
Acked-by: Zi Yan <ziy@nvidia.com>
Best Regards,
Yan, Zi
^ permalink raw reply
* Re: [PATCH v4 2/5] mm: convert zone lock users to wrappers
From: Zi Yan @ 2026-02-28 1:14 UTC (permalink / raw)
To: Dmitry Ilvokhin
Cc: Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Axel Rasmussen, Yuanchu Xie,
Wei Xu, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Rafael J. Wysocki, Pavel Machek, Len Brown, Brendan Jackman,
Johannes Weiner, Oscar Salvador, Qi Zheng, Shakeel Butt,
linux-kernel, linux-mm, linux-trace-kernel, linux-pm,
SeongJae Park
In-Reply-To: <d26a43ebed2f0f1edb9cfe4fbed16dd31c7a069c.1772206930.git.d@ilvokhin.com>
On 27 Feb 2026, at 11:00, Dmitry Ilvokhin wrote:
> Replace direct zone lock acquire/release operations with the
> newly introduced wrappers.
>
> The changes are purely mechanical substitutions. No functional change
> intended. Locking semantics and ordering remain unchanged.
>
> The compaction path is left unchanged for now and will be
> handled separately in the following patch due to additional
> non-trivial modifications.
>
> Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
> Acked-by: Shakeel Butt <shakeel.butt@linux.dev>
> Reviewed-by: SeongJae Park <sj@kernel.org>
> ---
> kernel/power/snapshot.c | 5 +--
> mm/compaction.c | 25 +++++++-------
> mm/memory_hotplug.c | 9 ++---
> mm/mm_init.c | 3 +-
> mm/page_alloc.c | 73 +++++++++++++++++++++--------------------
> mm/page_isolation.c | 19 ++++++-----
> mm/page_reporting.c | 13 ++++----
> mm/show_mem.c | 5 +--
> mm/shuffle.c | 9 ++---
> mm/vmscan.c | 5 +--
> mm/vmstat.c | 9 ++---
> 11 files changed, 94 insertions(+), 81 deletions(-)
>
Acked-by: Zi Yan <ziy@nvidia.com>
Best Regards,
Yan, Zi
^ permalink raw reply
* Re: [PATCH v4 3/5] mm: convert compaction to zone lock wrappers
From: Zi Yan @ 2026-02-28 1:16 UTC (permalink / raw)
To: Dmitry Ilvokhin
Cc: Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Axel Rasmussen, Yuanchu Xie,
Wei Xu, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Rafael J. Wysocki, Pavel Machek, Len Brown, Brendan Jackman,
Johannes Weiner, Oscar Salvador, Qi Zheng, Shakeel Butt,
linux-kernel, linux-mm, linux-trace-kernel, linux-pm
In-Reply-To: <3a09e46f52cf9f709b0725bc2b648cc5212843b2.1772206930.git.d@ilvokhin.com>
On 27 Feb 2026, at 11:00, Dmitry Ilvokhin wrote:
> Compaction uses compact_lock_irqsave(), which currently operates
> on a raw spinlock_t pointer so it can be used for both zone->lock
> and lruvec->lru_lock. Since zone lock operations are now wrapped,
> compact_lock_irqsave() can no longer directly operate on a
> spinlock_t when the lock belongs to a zone.
>
> Split the helper into compact_zone_lock_irqsave() and
> compact_lruvec_lock_irqsave(), duplicating the small amount of
> shared logic. As there are only two call sites and both statically
> know the lock type, this avoids introducing additional abstraction
> or runtime dispatch in the compaction path.
>
> No functional change intended.
>
> Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
> Acked-by: Shakeel Butt <shakeel.butt@linux.dev>
> ---
> mm/compaction.c | 33 ++++++++++++++++++++++++---------
> 1 file changed, 24 insertions(+), 9 deletions(-)
>
Acked-by: Zi Yan <ziy@nvidia.com>
Best Regards,
Yan, Zi
^ permalink raw reply
* Re: [PATCH v4 4/5] mm: rename zone->lock to zone->_lock
From: Zi Yan @ 2026-02-28 1:17 UTC (permalink / raw)
To: Dmitry Ilvokhin
Cc: Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Axel Rasmussen, Yuanchu Xie,
Wei Xu, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Rafael J. Wysocki, Pavel Machek, Len Brown, Brendan Jackman,
Johannes Weiner, Oscar Salvador, Qi Zheng, Shakeel Butt,
linux-kernel, linux-mm, linux-trace-kernel, linux-pm,
SeongJae Park
In-Reply-To: <d61500c5784c64e971f4d328c57639303c475f81.1772206930.git.d@ilvokhin.com>
On 27 Feb 2026, at 11:00, Dmitry Ilvokhin wrote:
> This intentionally breaks direct users of zone->lock at compile time so
> all call sites are converted to the zone lock wrappers. Without the
> rename, present and future out-of-tree code could continue using
> spin_lock(&zone->lock) and bypass the wrappers and tracing
> infrastructure.
>
> No functional change intended.
>
> Suggested-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
> Acked-by: Shakeel Butt <shakeel.butt@linux.dev>
> Acked-by: SeongJae Park <sj@kernel.org>
> ---
> include/linux/mmzone.h | 7 +++++--
> include/linux/mmzone_lock.h | 12 ++++++------
> mm/compaction.c | 4 ++--
> mm/internal.h | 2 +-
> mm/page_alloc.c | 16 ++++++++--------
> mm/page_isolation.c | 4 ++--
> mm/page_owner.c | 2 +-
> 7 files changed, 25 insertions(+), 22 deletions(-)
>
Acked-by: Zi Yan <ziy@nvidia.com>
Best Regards,
Yan, Zi
^ permalink raw reply
* Re: [PATCH] tracing: Fix WARN_ON in tracing_buffers_mmap_close
From: Qing Wang @ 2026-02-28 8:59 UTC (permalink / raw)
To: vdonnefort
Cc: linux-kernel, linux-trace-kernel, mathieu.desnoyers, mhiramat,
rostedt, syzbot+3b5dd2030fe08afdf65d, wangqing7171
In-Reply-To: <aaF-bhAIhCgusG9k@google.com>
On Fri, 27 Feb 2026 at 19:22, Vincent Donnefort <vdonnefort@google.com> wrote:
> As we are applying restrictive rules for this mapping, I believe setting VM_IO
> might be a better fix.
Restrictive rules for this mapping is a better idea, I agreed with it.
--
Qing
^ permalink raw reply
* Re: [PATCH v4 1/5] mm: introduce zone lock wrappers
From: SeongJae Park @ 2026-02-28 16:23 UTC (permalink / raw)
To: Dmitry Ilvokhin
Cc: SeongJae Park, Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Axel Rasmussen, Yuanchu Xie,
Wei Xu, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Rafael J. Wysocki, Pavel Machek, Len Brown, Brendan Jackman,
Johannes Weiner, Zi Yan, Oscar Salvador, Qi Zheng, Shakeel Butt,
linux-kernel, linux-mm, linux-trace-kernel, linux-pm,
"linux-cxl
In-Reply-To: <849dee9c47df1e6fba97c9933af0d5a08b8e15d3.1772206930.git.d@ilvokhin.com>
On Fri, 27 Feb 2026 16:00:23 +0000 Dmitry Ilvokhin <d@ilvokhin.com> wrote:
> Add thin wrappers around zone lock acquire/release operations. This
> prepares the code for future tracepoint instrumentation without
> modifying individual call sites.
>
> Centralizing zone lock operations behind wrappers allows future
> instrumentation or debugging hooks to be added without touching
> all users.
>
> No functional change intended. The wrappers are introduced in
> preparation for subsequent patches and are not yet used.
>
> Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
> Acked-by: Shakeel Butt <shakeel.butt@linux.dev>
Reviewed-by: SeongJae Park <sj@kernel.org>
Thanks,
SJ
[...]
^ permalink raw reply
* Re: [PATCH v4 3/5] mm: convert compaction to zone lock wrappers
From: SeongJae Park @ 2026-02-28 16:31 UTC (permalink / raw)
To: Dmitry Ilvokhin
Cc: SeongJae Park, Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Axel Rasmussen, Yuanchu Xie,
Wei Xu, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Rafael J. Wysocki, Pavel Machek, Len Brown, Brendan Jackman,
Johannes Weiner, Zi Yan, Oscar Salvador, Qi Zheng, Shakeel Butt,
linux-kernel, linux-mm, linux-trace-kernel, linux-pm,
"linux-cxl
In-Reply-To: <3a09e46f52cf9f709b0725bc2b648cc5212843b2.1772206930.git.d@ilvokhin.com>
On Fri, 27 Feb 2026 16:00:25 +0000 Dmitry Ilvokhin <d@ilvokhin.com> wrote:
> Compaction uses compact_lock_irqsave(), which currently operates
> on a raw spinlock_t pointer so it can be used for both zone->lock
> and lruvec->lru_lock. Since zone lock operations are now wrapped,
> compact_lock_irqsave() can no longer directly operate on a
> spinlock_t when the lock belongs to a zone.
>
> Split the helper into compact_zone_lock_irqsave() and
> compact_lruvec_lock_irqsave(), duplicating the small amount of
> shared logic. As there are only two call sites and both statically
> know the lock type, this avoids introducing additional abstraction
> or runtime dispatch in the compaction path.
>
> No functional change intended.
>
> Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
> Acked-by: Shakeel Butt <shakeel.butt@linux.dev>
Reviewed-by: SeongJae Park <sj@kernel.org>
Thanks,
SJ
[...]
^ permalink raw reply
* Re: [PATCHv6 bpf-next 9/9] bpf,x86: Use single ftrace_ops for direct calls
From: Steven Rostedt @ 2026-02-28 20:39 UTC (permalink / raw)
To: Jiri Olsa
Cc: Ihor Solodrai, Florent Revest, Mark Rutland, bpf, linux-kernel,
linux-trace-kernel, linux-arm-kernel, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Menglong Dong, Song Liu,
Kumar Kartikeya Dwivedi
In-Reply-To: <aaILlSuEgaYDq41r@krava>
On Fri, 27 Feb 2026 22:24:37 +0100
Jiri Olsa <olsajiri@gmail.com> wrote:
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 827fb9a0bf0d..e333749a5896 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -6404,7 +6404,9 @@ int update_ftrace_direct_add(struct ftrace_ops *ops, struct ftrace_hash *hash)
> new_filter_hash = old_filter_hash;
> }
> } else {
As this looks to fix the issue, just add:
guard(mutex)(&ftrace_lock);
> + mutex_lock(&ftrace_lock);
> err = ftrace_update_ops(ops, new_filter_hash, EMPTY_HASH);
> + mutex_unlock(&ftrace_lock);
> /*
> * new_filter_hash is dup-ed, so we need to release it anyway,
> * old_filter_hash either stays on error or is already released
> @@ -6530,7 +6532,9 @@ int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash)
> ops->func_hash->filter_hash = NULL;
> }
> } else {
And here too.
As there's nothing after the comment and before the end of the block.
-- Steve
> + mutex_lock(&ftrace_lock);
> err = ftrace_update_ops(ops, new_filter_hash, EMPTY_HASH);
> + mutex_unlock(&ftrace_lock);
> /*
> * new_filter_hash is dup-ed, so we need to release it anyway,
> * old_filter_hash either stays on error or is already released
-- Steve
^ permalink raw reply
* Re: [PATCH net-next v2 04/10] devlink: allow to use devlink index as a command handle
From: Jakub Kicinski @ 2026-02-28 22:48 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, edumazet, pabeni, horms, donald.hunter, corbet,
skhan, saeedm, leon, tariqt, mbloch, przemyslaw.kitszel, mschmidt,
andrew+netdev, rostedt, mhiramat, mathieu.desnoyers, chuck.lever,
matttbe, cjubran, daniel.zahka, linux-doc, linux-rdma,
linux-trace-kernel
In-Reply-To: <20260225133422.290965-5-jiri@resnulli.us>
On Wed, 25 Feb 2026 14:34:16 +0100 Jiri Pirko wrote:
> + if (attrs[DEVLINK_ATTR_INDEX]) {
> + index = nla_get_uint(attrs[DEVLINK_ATTR_INDEX]);
> + devlink = devlinks_xa_lookup_get(net, index);
> + if (!devlink)
> + return ERR_PTR(-ENODEV);
> + goto found;
> + }
> +
> if (!attrs[DEVLINK_ATTR_BUS_NAME] || !attrs[DEVLINK_ATTR_DEV_NAME])
> return ERR_PTR(-EINVAL);
If both INDEX and BUS_NAME + DEV_NAME are provided we should check
that they point to the same device? Or reject user space passing both?
^ permalink raw reply
* Re: [PATCH net-next v2 06/10] devlink: add devlink_dev_driver_name() helper and use it in trace events
From: Jakub Kicinski @ 2026-02-28 22:58 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, edumazet, pabeni, horms, donald.hunter, corbet,
skhan, saeedm, leon, tariqt, mbloch, przemyslaw.kitszel, mschmidt,
andrew+netdev, rostedt, mhiramat, mathieu.desnoyers, chuck.lever,
matttbe, cjubran, daniel.zahka, linux-doc, linux-rdma,
linux-trace-kernel
In-Reply-To: <20260225133422.290965-7-jiri@resnulli.us>
On Wed, 25 Feb 2026 14:34:18 +0100 Jiri Pirko wrote:
> +const char *devlink_dev_driver_name(const struct devlink *devlink)
> +{
> + struct device *dev = devlink->dev;
> +
> + return dev ? dev->driver->name : NULL;
> +}
> +EXPORT_SYMBOL_GPL(devlink_dev_driver_name);
You say we need this in prep for shared instances, which is fair, but
shared instances should presumably share across the same driver, most
of the time? So perhaps we should do a similar thing here as you did to
the bus/dev name? Maybe when shared instance is allocated:
devlink->driver_name = kasprintf("%s+", dev->driver);
And then:
+const char *devlink_dev_driver_name(const struct devlink *devlink)
+{
+ struct device *dev = devlink->dev;
+
+ return dev ? dev->driver->name : devlink->driver_name;
+}
+EXPORT_SYMBOL_GPL(devlink_dev_driver_name);
?
^ 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