* [PATCH 5.10.y] x86/uprobes: Fix XOL allocation failure for 32-bit tasks
From: Oleg Nesterov @ 2026-03-02 15:51 UTC (permalink / raw)
To: Sasha Levin
Cc: stable, Paulo Andrade, Peter Zijlstra (Intel), linux-trace-kernel,
linux-perf-users
In-Reply-To: <20260301020027.1726538-1-sashal@kernel.org>
[ Upstream commit d55c571e4333fac71826e8db3b9753fadfbead6a ]
This script
#!/usr/bin/bash
echo 0 > /proc/sys/kernel/randomize_va_space
echo 'void main(void) {}' > TEST.c
# -fcf-protection to ensure that the 1st endbr32 insn can't be emulated
gcc -m32 -fcf-protection=branch TEST.c -o test
bpftrace -e 'uprobe:./test:main {}' -c ./test
"hangs", the probed ./test task enters an endless loop.
The problem is that with randomize_va_space == 0
get_unmapped_area(TASK_SIZE - PAGE_SIZE) called by xol_add_vma() can not
just return the "addr == TASK_SIZE - PAGE_SIZE" hint, this addr is used
by the stack vma.
arch_get_unmapped_area_topdown() doesn't take TIF_ADDR32 into account and
in_32bit_syscall() is false, this leads to info.high_limit > TASK_SIZE.
vm_unmapped_area() happily returns the high address > TASK_SIZE and then
get_unmapped_area() returns -ENOMEM after the "if (addr > TASK_SIZE - len)"
check.
handle_swbp() doesn't report this failure (probably it should) and silently
restarts the probed insn. Endless loop.
I think that the right fix should change the x86 get_unmapped_area() paths
to rely on TIF_ADDR32 rather than in_32bit_syscall(). Note also that if
CONFIG_X86_X32_ABI=y, in_x32_syscall() falsely returns true in this case
because ->orig_ax = -1.
But we need a simple fix for -stable, so this patch just sets TS_COMPAT if
the probed task is 32-bit to make in_ia32_syscall() true.
Fixes: 1b028f784e8c ("x86/mm: Introduce mmap_compat_base() for 32-bit mmap()")
Reported-by: Paulo Andrade <pandrade@redhat.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/all/aV5uldEvV7pb4RA8@redhat.com/
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/aWO7Fdxn39piQnxu@redhat.com
---
arch/x86/kernel/uprobes.c | 24 ++++++++++++++++++++++++
include/linux/uprobes.h | 1 +
kernel/events/uprobes.c | 10 +++++++---
3 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
index 9f948b2d26f6..099ca674e3de 100644
--- a/arch/x86/kernel/uprobes.c
+++ b/arch/x86/kernel/uprobes.c
@@ -1095,3 +1095,27 @@ bool arch_uretprobe_is_alive(struct return_instance *ret, enum rp_check ctx,
else
return regs->sp <= ret->stack;
}
+
+#ifdef CONFIG_IA32_EMULATION
+unsigned long arch_uprobe_get_xol_area(void)
+{
+ struct thread_info *ti = current_thread_info();
+ unsigned long vaddr;
+
+ /*
+ * HACK: we are not in a syscall, but x86 get_unmapped_area() paths
+ * ignore TIF_ADDR32 and rely on in_32bit_syscall() to calculate
+ * vm_unmapped_area_info.high_limit.
+ *
+ * The #ifdef above doesn't cover the CONFIG_X86_X32_ABI=y case,
+ * but in this case in_32bit_syscall() -> in_x32_syscall() always
+ * (falsely) returns true because ->orig_ax == -1.
+ */
+ if (test_thread_flag(TIF_ADDR32))
+ ti->status |= TS_COMPAT;
+ vaddr = get_unmapped_area(NULL, TASK_SIZE - PAGE_SIZE, PAGE_SIZE, 0, 0);
+ ti->status &= ~TS_COMPAT;
+
+ return vaddr;
+}
+#endif
diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
index f46e0ca0169c..3461199c4ec0 100644
--- a/include/linux/uprobes.h
+++ b/include/linux/uprobes.h
@@ -138,6 +138,7 @@ extern bool arch_uretprobe_is_alive(struct return_instance *ret, enum rp_check c
extern bool arch_uprobe_ignore(struct arch_uprobe *aup, struct pt_regs *regs);
extern void arch_uprobe_copy_ixol(struct page *page, unsigned long vaddr,
void *src, unsigned long len);
+extern unsigned long arch_uprobe_get_xol_area(void);
#else /* !CONFIG_UPROBES */
struct uprobes_state {
};
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 4f2a9fab8ae8..f3bc64c4fa78 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1438,6 +1438,12 @@ void uprobe_munmap(struct vm_area_struct *vma, unsigned long start, unsigned lon
set_bit(MMF_RECALC_UPROBES, &vma->vm_mm->flags);
}
+unsigned long __weak arch_uprobe_get_xol_area(void)
+{
+ /* Try to map as high as possible, this is only a hint. */
+ return get_unmapped_area(NULL, TASK_SIZE - PAGE_SIZE, PAGE_SIZE, 0, 0);
+}
+
/* Slot allocation for XOL */
static int xol_add_vma(struct mm_struct *mm, struct xol_area *area)
{
@@ -1453,9 +1459,7 @@ static int xol_add_vma(struct mm_struct *mm, struct xol_area *area)
}
if (!area->vaddr) {
- /* Try to map as high as possible, this is only a hint. */
- area->vaddr = get_unmapped_area(NULL, TASK_SIZE - PAGE_SIZE,
- PAGE_SIZE, 0, 0);
+ area->vaddr = arch_uprobe_get_xol_area();
if (IS_ERR_VALUE(area->vaddr)) {
ret = area->vaddr;
goto fail;
--
2.52.0
^ permalink raw reply related
* Re: [PATCH bpf] ftrace: Add missing ftrace_lock to update_ftrace_direct_add/del
From: Alexei Starovoitov @ 2026-03-02 15:58 UTC (permalink / raw)
To: Jiri Olsa
Cc: Steven Rostedt, Alexei Starovoitov, Ihor Solodrai,
Kumar Kartikeya Dwivedi, bpf, LKML, linux-trace-kernel,
Daniel Borkmann, Andrii Nakryiko, Menglong Dong, Song Liu
In-Reply-To: <20260302081622.165713-1-jolsa@kernel.org>
On Mon, Mar 2, 2026 at 12:16 AM Jiri Olsa <jolsa@kernel.org> wrote:
>
> Ihor and Kumar reported splat from ftrace_get_addr_curr [1], which happened
> because of the missing ftrace_lock in update_ftrace_direct_add/del functions
> allowing concurrent access to ftrace internals.
>
> The ftrace_update_ops function must be guarded by ftrace_lock, adding that.
>
> Fixes: 05dc5e9c1fe1 ("ftrace: Add update_ftrace_direct_add function")
> Fixes: 8d2c1233f371 ("ftrace: Add update_ftrace_direct_del function")
> Reported-by: Ihor Solodrai <ihor.solodrai@linux.dev>
> Reported-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
> Closes: https://lore.kernel.org/bpf/1b58ffb2-92ae-433a-ba46-95294d6edea2@linux.dev/
> Tested-by: Ihor Solodrai <ihor.solodrai@linux.dev>
> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
lgtm.
Steven,
should it land through ftrace tree?
^ permalink raw reply
* Re: [PATCH V2] blktrace: fix __this_cpu_read/write in preemptible context
From: Steven Rostedt @ 2026-03-02 15:59 UTC (permalink / raw)
To: Chaitanya Kulkarni
Cc: axboe, mhiramat, mathieu.desnoyers, shinichiro.kawasaki,
linux-block, linux-trace-kernel
In-Reply-To: <20260302002207.12165-1-kch@nvidia.com>
On Sun, 1 Mar 2026 16:22:07 -0800
Chaitanya Kulkarni <kch@nvidia.com> wrote:
> With this fix blktests for blktrace 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
>
> Fixes: 7ffbd48d5cab ("tracing: Cache comms only after an event occurred")
> Reported-by: Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>
> Suggested-by: Steven Rostedt <rostedt@goodmis.org>
> Signed-off-by: Chaitanya Kulkarni <kch@nvidia.com>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
-- Steve
^ permalink raw reply
* Re: [PATCH V2] blktrace: fix __this_cpu_read/write in preemptible context
From: Steven Rostedt @ 2026-03-02 16:08 UTC (permalink / raw)
To: Chaitanya Kulkarni
Cc: Jens Axboe, shinichiro.kawasaki@wdc.com,
linux-block@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
mathieu.desnoyers@efficios.com, mhiramat@kernel.org
In-Reply-To: <84f1e52c-7e70-4b98-8302-ca1f1e3db9fc@nvidia.com>
On Mon, 2 Mar 2026 08:41:58 +0000
Chaitanya Kulkarni <chaitanyak@nvidia.com> wrote:
> I totally failed to understand why this bug is appearing right now
> than before.
I wonder if it is because it was never tested under PREEMPT_FULL, which
would be the only config that would trigger the warning, as
PREEMPT_VOLUNTARY has rcu_read_lock() not allow preemption.
Today, the default is now the new PREEMPT_LAZY and not PREEMPT_VOLUNTARY,
where it can preempt within rcu_read_lock(). It could be that this bug
existed since 2012 but was never triggered as most users use
PREEMPT_VOLUNTARY where it would not trigger. But if they used PREEMPT_FULL
back then, it may have.
Today we now use PREEMPT_LAZY where this does trigger.
-- Steve
^ permalink raw reply
* Re: [PATCH bpf] ftrace: Add missing ftrace_lock to update_ftrace_direct_add/del
From: Steven Rostedt @ 2026-03-02 16:12 UTC (permalink / raw)
To: Jiri Olsa
Cc: Alexei Starovoitov, Ihor Solodrai, Kumar Kartikeya Dwivedi, bpf,
linux-kernel, linux-trace-kernel, Daniel Borkmann,
Andrii Nakryiko, Menglong Dong, Song Liu
In-Reply-To: <20260302081622.165713-1-jolsa@kernel.org>
On Mon, 2 Mar 2026 09:16:22 +0100
Jiri Olsa <jolsa@kernel.org> wrote:
> Ihor and Kumar reported splat from ftrace_get_addr_curr [1], which happened
> because of the missing ftrace_lock in update_ftrace_direct_add/del functions
> allowing concurrent access to ftrace internals.
>
> The ftrace_update_ops function must be guarded by ftrace_lock, adding that.
>
> Fixes: 05dc5e9c1fe1 ("ftrace: Add update_ftrace_direct_add function")
> Fixes: 8d2c1233f371 ("ftrace: Add update_ftrace_direct_del function")
> Reported-by: Ihor Solodrai <ihor.solodrai@linux.dev>
> Reported-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
> Closes: https://lore.kernel.org/bpf/1b58ffb2-92ae-433a-ba46-95294d6edea2@linux.dev/
> Tested-by: Ihor Solodrai <ihor.solodrai@linux.dev>
> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
-- Steve
> ---
> kernel/trace/ftrace.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 827fb9a0bf0d..8baf61c9be6d 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -6404,6 +6404,7 @@ int update_ftrace_direct_add(struct ftrace_ops *ops, struct ftrace_hash *hash)
> new_filter_hash = old_filter_hash;
> }
> } else {
> + guard(mutex)(&ftrace_lock);
> err = ftrace_update_ops(ops, new_filter_hash, EMPTY_HASH);
> /*
> * new_filter_hash is dup-ed, so we need to release it anyway,
> @@ -6530,6 +6531,7 @@ int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash)
> ops->func_hash->filter_hash = NULL;
> }
> } else {
> + guard(mutex)(&ftrace_lock);
> err = ftrace_update_ops(ops, new_filter_hash, EMPTY_HASH);
> /*
> * new_filter_hash is dup-ed, so we need to release it anyway,
^ permalink raw reply
* Re: [PATCH V2] blktrace: fix __this_cpu_read/write in preemptible context
From: Jens Axboe @ 2026-03-02 16:16 UTC (permalink / raw)
To: rostedt, mhiramat, mathieu.desnoyers, Chaitanya Kulkarni
Cc: shinichiro.kawasaki, linux-block, linux-trace-kernel
In-Reply-To: <20260302002207.12165-1-kch@nvidia.com>
On Sun, 01 Mar 2026 16:22:07 -0800, Chaitanya Kulkarni wrote:
> tracing_record_cmdline() internally uses __this_cpu_read() and
> __this_cpu_write() on the per-CPU variable trace_cmdline_save, and
> trace_save_cmdline() explicitly asserts preemption is disabled via
> lockdep_assert_preemption_disabled(). These operations are only safe
> when preemption is off, as they were designed to be called from the
> scheduler context (probe_wakeup_sched_switch() / probe_wakeup()).
>
> [...]
Applied, thanks!
[1/1] blktrace: fix __this_cpu_read/write in preemptible context
commit: da46b5dfef48658d03347cda21532bcdbb521e67
Best regards,
--
Jens Axboe
^ permalink raw reply
* Re: [BUG] RCU stall / hung rcu_gp: process_srcu blocked in synchronize_rcu_normal triggered by perf trace teardown on 7.0.0-rc1
From: Steven Rostedt @ 2026-03-02 16:25 UTC (permalink / raw)
To: Sasha Levin
Cc: Zw Tang, paulmck, peterz, mhiramat, jiangshanlai, mingo, acme,
namhyung, rcu, linux-perf-users, linux-trace-kernel, linux-kernel,
mathieu.desnoyers, josh, bigeasy, ast, boqun.feng, mark.rutland
In-Reply-To: <20260302133615.2304836-1-sashal@kernel.org>
On Mon, 2 Mar 2026 08:36:13 -0500
Sasha Levin <sashal@kernel.org> wrote:
> This response was AI-generated by bug-bot. The analysis may contain errors — please verify independently.
>
> ## Bug Summary
>
> This is an RCU stall and hung task deadlock on 7.0.0-rc1, triggered by perf trace teardown under perf interrupt storm conditions. The perf subsystem's tracepoint unregistration path now blocks on SRCU (tracepoint_srcu), which in turn blocks on RCU grace period completion, creating a cascading stall when RCU progress is delayed by perf NMI interrupt storms. Severity: system hang (multiple tasks blocked >143s, eventual complete stall).
Hmm, this analysis corresponds nicely to what I was thinking when looking
at the stack dumps, but it gives a bit more details than I would have.
> ## Root Cause Analysis
>
> This is a regression introduced by commit a46023d5616ed ("tracing: Guard __DECLARE_TRACE() use of __DO_TRACE_CALL() with SRCU-fast"), which switched tracepoint read-side protection from preempt_disable()+RCU to SRCU-fast via DEFINE_SRCU_FAST(tracepoint_srcu).
Yes, as soon as I saw the report, I knew it had to do with this commit.
>
> The root cause is a new coupling between SRCU grace period processing and RCU grace period completion that did not exist before. The deadlock chain is:
>
> 1. The reproducer creates perf events using tracepoints, then closes them while generating heavy perf interrupt load. The perf NMI interrupt storms ("perf: interrupt took too long" messages escalating from 69ms to 336ms) consume most CPU time, starving RCU quiescent state detection.
The real bug is the NMI interrupt storms. The commit above only makes it
more of an issue, but that commit itself is not the bug.
> ## Suggested Actions
>
> 1. Confirm the regression by testing with the parent commit a77cb6a867667 (immediately before a46023d5616ed). If the issue disappears, this confirms the SRCU-fast tracepoint switch as the cause.
>
> 2. As a quick workaround, reverting a46023d5616ed (and its preparatory commits a77cb6a867667, f7d327654b886, 16718274ee75d if needed) should eliminate the deadlock, at the cost of losing preemptible BPF tracepoint support.
That is not the answer, as the above only made the current bug (interrupt
storms) visible.
>
> 3. The fundamental issue is that process_srcu() for SRCU-fast structures calls synchronize_rcu() synchronously from workqueue context. Possible fixes include:
> - Using an asynchronous mechanism (e.g., call_rcu() with a callback to resume SRCU GP processing) instead of blocking synchronize_rcu() within the SRCU state machine.
> - Having srcu_readers_active_idx_check() use poll_state_synchronize_rcu() and defer retrying instead of blocking.
> - Bounding the perf interrupt rate escalation to prevent the RCU stall in the first place (though this would only mask the underlying SRCU↔RCU coupling issue).
>
> 4. If you can reproduce reliably, adding the following debug options would provide more information: CONFIG_RCU_TRACE=y, CONFIG_PROVE_RCU=y, and booting with rcutree.rcu_kick_kthreads=1 to see if kicking the RCU threads helps break the stall.
The real fix is to find a way to disable the perf interrupt storms *before*
unregistering the tracepoint.
-- Steve
^ permalink raw reply
* Re: [PATCH] tracing: Fix WARN_ON in tracing_buffers_mmap_close
From: Steven Rostedt @ 2026-03-02 16:52 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Vincent Donnefort, Qing Wang, Masami Hiramatsu, Mathieu Desnoyers,
linux-kernel, linux-trace-kernel, syzbot+3b5dd2030fe08afdf65d,
linux-mm, Andrew Morton, Vlastimil Babka, David Hildenbrand
In-Reply-To: <e4deff21-2fb5-4f37-a7d3-ede5f69a4489@lucifer.local>
On Mon, 2 Mar 2026 12:13:24 +0000
Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
Hi Lorenzo,
Thanks for looking into this.
> > But looking at the various flags, I see there's a VM_SPECIAL. I'm wondering
> > if that is what we should use?
>
> VM_SPECIAL is not a VMA flag, it's a bitmask of all the flags which cause us not
> to permit things like splitting/merging of VMAs (because we can't safely do
> them), i.e. that are one or more of:
Yep, I knew it wasn't a flag, and actually picked it because it looked to
have the flags we may have wanted.
>
> VM_IO - Memory-mapped I/O range.
>
> VM_PFNMAP - A mapping without struct folio's/page's backing them, e.g. perhaps a
> raw kernel mapping.
>
> VM_MIXEDMAP - A combination of page/folio-backed memory and/or PFN-backed memory.
>
> VM_DONTEXPAND - Disallow expansion of memory in mremap().
>
> You already set VM_DONTEXPAND so you get these semantics already.
>
> Setting VM_IO just to trigger a failure case in madvise() feels like a hack? I
> guess it'd do the trick though, but you're not going to be able to reclaim that
> memory, and you might get some unexpected behaviour in code paths that assume
> VM_IO means it's memory-mapped I/O... (for instance GUP will stop working, if
> you need that).
Well, we don't reclaim that memory anyway.
>
> I'd take a step back and wonder why you are wanting to not allow copying on
> fork? Is this kernel-allocated memory? In which case you should set VM_MIXEDMAP
> or VM_PFNMAP as appropriate... If not and it has a folio etc. then it seems like
> strange semantics.
>
> Are you really bothered also by users doing strange things? Maybe the solution
> is to tolerate a fork-copy even if it's broken? I presume somethings straight up
> breaks right now?
Yeah, right now the accounting gets screwed up as the mappings get out of
sync when it is forked.
>
> Without more context that I don't really have much time to acquire it's hard to
> know what to advise.
Fair enough, let me explain everything then ;-)
This is a mapping of the ftrace ring buffer to user space. Until recently,
the only way user space could get access to the ftrace ring buffer was to
either read it, or splice() it to a file/pipe/whatever.
The way the ftrace ring buffer works is that it is made up of a bunch of
sub-buffers (must be multiple of PAGE_SIZE and usually is a single page).
There is one sub-buffer called the "reader-page" which writers never write
to (with an exception out of scope for understanding the mappings).
The "reader-page" is a sub-buffer that belongs to the reader. When the
reader is finish with it and wants to read more of the buffer, an operation
is performed to swap the current reader-page with one of the pages that the
writers have. The new page is now owned by the reader and writers will
leave it alone. This allows readers to do a zero copy splice of the data in
the ring buffer.
Now we added a feature to memory map this buffer to user space. The
reader-page and writer sub-buffers are all mapped read-only into the user's
memory address.
Another page is mapped called the "meta page" which tells user space how to
read the buffer (which sub-buffer is the current reader-page and the order
of the write sub-buffers).
The read-page is what user space will read directly, and when it is done,
it does an ioctl() on the file descriptor for the buffer:
/sys/kernel/tracing/per_cpu/cpu*/trace_pipe_raw
One command of the ioctl() will tell the kernel to swap the reader-page with
a writer sub-buffer. The meta page is updated and the user space
application can read that.
Now the meta page is unique per ring buffer and not per process. If there's
a fork, any change to the meta page will affect all processes that have
this mapped.
If two processes map the same buffer, one process will see any updates in
its meta page that another process does to it.
Now there is nothing wrong with doing that, accept the user space processes
will likely get confused. And we currently allow two separate tasks to mmap
it at the same time (maybe we shouldn't have!).
What we didn't allow was forking, as the code didn't update the proper
accounting. It needs to know that the buffer is mapped because it handles
splice differently. As the pages are mapped to user space, the kernel can't
just allow splice to steal a page and send it off to whatever pipe. Instead
it makes a copy of the page (basically killing the performance splice()
gives it in the first place).
We originally added the DONTFORK so that we didn't need to handle the fork
case, but I'm guessing that you are suggesting that we should do that
instead of preventing it from being duplicated on fork. Am I correct?
-- Steve
^ permalink raw reply
* Re: [PATCH] mm: add Adaptive Memory Pressure Signaling (AMPRESS)
From: David Hildenbrand (Arm) @ 2026-03-02 17:00 UTC (permalink / raw)
To: Andre Ramos, akpm, hannes
Cc: linux-mm, linux-kernel, linux-trace-kernel, rostedt
In-Reply-To: <CALXtAv3u1hgLkBEbEgR3=r_iz3=KrnHB8B-=tg8Q3CEOWAPFiA@mail.gmail.com>
> +/**
> + * ampress_notify - dispatch a memory pressure event to all subscribers
> + * @urgency: AMPRESS_URGENCY_* level
> + * @numa_node: NUMA node of the pressure source (0xFF = system-wide)
> + * @requested_kb: Suggested reclaim target in KiB (0 = unspecified)
> + *
> + * Must be safe to call from any context including IRQ / reclaim paths:
> + * - no sleeping allocations
> + * - only spin_lock_irqsave and wake_up_interruptible
> + */
> +void ampress_notify(int urgency, int numa_node, unsigned long requested_kb)
> +{
> + struct ampress_subscriber *sub;
> + unsigned long rflags, flags;
> + int notified = 0;
> +
> + /*
> + * Use irqsave variants: ampress_notify() may be called from a context
> + * where interrupts are disabled (e.g. a future direct-reclaim hook).
> + */
> + read_lock_irqsave(&ress_subscribers_lock, rflags);
> + list_for_each_entry(sub, &ress_subscribers, list) {
> + if (!sub->subscribed)
> + continue;
> +
> + /*
> + * Check if the urgency meets or exceeds the subscriber's
> + * configured threshold for this urgency level.
> + *
> + * Default config has all thresholds at 0, meaning any
> + * urgency >= 0 passes — i.e. everything is delivered.
> + */
> + spin_lock_irqsave(&sub->lock, flags);
> + sub->pending_event.urgency = (__u8)urgency;
> + sub->pending_event.numa_node = (__u8)(numa_node & 0xFF);
> + sub->pending_event.reserved = 0;
> + sub->pending_event.requested_kb =
> + (__u32)min_t(unsigned long, requested_kb, U32_MAX);
I didn't take a detailed look, but this one confused me while skimming
over some bits: Which value does exposing requested_kb really have if
there are multiply subscribers to notify? Doesn't quite make sense to
even expose that.
Assume it's 2 MiB and you notify 1024 processes. Are you suddenly
getting 2 GiB back?
On a bigger picture, I don't think the whole idea of having multiple
subscribers is really thought through.
What are some arbitrary processes supposed to do if the receive one of
the notifications? How much memory are they supposed to reclaim (given
that requested_kb is questionable)? How are they supposed to reclaim the
memory (MADV_DONTNEED? MADV_PAGEOUT? or what else?). There is a lot of
information missing from the patch description to understand the bigger
picture.
If apps have droppable caches, a better solution might be to use
something like MAP_DROPPABLE where possible, still leaving the kernel in
charge of when and how much memory to reclaim.
--
Cheers,
David
^ permalink raw reply
* Re: [BUG] kprobes: WARNING in __arm_kprobe_ftrace when kprobe-ftrace arming fails with -ENOMEM under fault injection
From: Sasha Levin @ 2026-03-02 17:35 UTC (permalink / raw)
To: Zw Tang, Naveen N Rao, Masami Hiramatsu, Steven Rostedt
Cc: Sasha Levin, linux-kernel, linux-trace-kernel, linux-perf-users,
Arnaldo Carvalho de Melo, David S . Miller
In-Reply-To: <CAPHJ_V+J6YDb_wX2nhXU6kh466Dt_nyDSas-1i_Y8s7tqY-Mzw@mail.gmail.com>
https://lore.kernel.org/all/CAPHJ_V+J6YDb_wX2nhXU6kh466Dt_nyDSas-1i_Y8s7tqY-Mzw@mail.gmail.com/
## 1. Bug Summary
A WARNING is triggered in `__arm_kprobe_ftrace()` at `kernel/kprobes.c:1147` when fault injection causes `ftrace_set_filter_ip()` to return `-ENOMEM` during kprobe arming via `perf_event_open()`. This is a false-positive warning — the error path itself is correct and the error propagates cleanly to userspace, but the `WARN_ONCE()` macro fires a kernel warning splat that is inappropriate for a recoverable allocation failure. The affected subsystem is kprobes/ftrace. Severity: warning only (no crash, hang, or data corruption).
## 2. Stack Trace Analysis
```
WARNING: kernel/kprobes.c:1147 at arm_kprobe+0x563/0x620, CPU#0
Call Trace:
<TASK>
enable_kprobe+0x1fc/0x2c0
enable_trace_kprobe+0x227/0x4b0
kprobe_register+0x84/0xc0
perf_trace_event_init+0x527/0xa20
perf_kprobe_init+0x156/0x200
perf_kprobe_event_init+0x101/0x1c0
perf_try_init_event+0x145/0xa10
perf_event_alloc+0x1f91/0x5390
__do_sys_perf_event_open+0x557/0x2d50
do_syscall_64+0x129/0x1160
entry_SYSCALL_64_after_hwframe+0x4b/0x53
</TASK>
```
The crash point is `__arm_kprobe_ftrace()` at `kernel/kprobes.c:1147`, inlined into `arm_kprobe()`. The calling chain is process context: `perf_event_open()` syscall -> `perf_kprobe_event_init()` -> `enable_trace_kprobe()` -> `enable_kprobe()` -> `arm_kprobe()` -> `__arm_kprobe_ftrace()`. R12 holds `0xfffffff4` which is `-12` (`-ENOMEM`), confirming the allocation failure injected by fault injection.
## 3. Root Cause Analysis
The root cause is an overly aggressive `WARN_ONCE()` in `__arm_kprobe_ftrace()` at `kernel/kprobes.c:1147`:
```c
ret = ftrace_set_filter_ip(ops, (unsigned long)p->addr, 0, 0);
if (WARN_ONCE(ret < 0, "Failed to arm kprobe-ftrace at %pS (error %d)\n", p->addr, ret))
return ret;
```
Prior to commit 9c89bb8e3272 ("kprobes: treewide: Cleanup the error messages for kprobes"), this was a simple `pr_debug()`. That commit promoted it to `WARN_ONCE()` as part of a treewide message cleanup, under the rationale that failures here indicate unexpected conditions. However, `ftrace_set_filter_ip()` calls into memory allocation paths (e.g., `ftrace_hash_move_and_update_ops()` -> `__ftrace_hash_update_ipmodify()` or `ftrace_hash` allocation), and those allocations can legitimately fail under memory pressure or fault injection.
The error handling is actually correct — the `-ENOMEM` propagates back through `arm_kprobe()` -> `enable_kprobe()` and ultimately causes the `perf_event_open()` syscall to return an error to userspace. The only problem is the spurious `WARN_ONCE()` which triggers a kernel warning splat and stack trace for what is a recoverable, non-buggy situation.
The same issue also applies to the `WARN()` on line 1152 for `register_ftrace_function()`, which can also fail with `-ENOMEM`.
## 4. Affected Versions
This issue was introduced by commit 9c89bb8e3272 ("kprobes: treewide: Cleanup the error messages for kprobes"), which first appeared in v5.16-rc1. All kernel versions from v5.16 onward are affected, including the reporter's v7.0.0-rc1.
This is a regression from v5.15, where the same failure path used `pr_debug()` and did not emit any warning.
## 5. Relevant Commits and Fixes
Introducing commit:
9c89bb8e3272 ("kprobes: treewide: Cleanup the error messages for kprobes")
Author: Masami Hiramatsu <mhiramat@kernel.org>
Merged in v5.16-rc1
This commit changed `pr_debug()` to `WARN_ONCE()` in `__arm_kprobe_ftrace()` for the `ftrace_set_filter_ip()` failure path, and changed a `pr_debug()` to `WARN()` for the `register_ftrace_function()` failure path.
No fix for this issue exists in mainline or stable as of the reporter's kernel version.
The suggested fix is to downgrade both `WARN_ONCE()` (line 1147) and `WARN()` (line 1152) in `__arm_kprobe_ftrace()` back to `pr_warn_once()` / `pr_warn()` respectively. This preserves the improved error messages from 9c89bb8e3272 while avoiding spurious warning splats on recoverable failures. The error code is already propagated correctly to the caller.
## 6. Prior Discussions
No prior reports of this specific issue were found on lore.kernel.org. No related mailing list discussions or proposed patches addressing the WARN severity in `__arm_kprobe_ftrace()` were found.
## 7. Suggested Actions
1. The fix is to downgrade the WARN_ONCE/WARN in __arm_kprobe_ftrace()
(kernel/kprobes.c lines 1147 and 1152) to pr_warn_once/pr_warn.
Specifically:
- Line 1147: Change WARN_ONCE(ret < 0, ...) to a simple
if (ret < 0) { pr_warn_once(...); return ret; }
- Line 1152: Change WARN(ret < 0, ...) to a simple
if (ret < 0) { pr_warn(...); goto err_ftrace; }
2. This is a low-severity issue that only manifests with fault injection
enabled. No data corruption or crash occurs — the error is correctly
propagated to userspace. The warning is cosmetic but noisy and can
cause false-positive syzbot/syzkaller reports.
^ permalink raw reply
* Re: [BUG] RCU stall / hung rcu_gp: process_srcu blocked in synchronize_rcu_normal triggered by perf trace teardown on 7.0.0-rc1
From: Sasha Levin @ 2026-03-02 17:37 UTC (permalink / raw)
To: Steven Rostedt
Cc: Zw Tang, paulmck, peterz, mhiramat, jiangshanlai, mingo, acme,
namhyung, rcu, linux-perf-users, linux-trace-kernel, linux-kernel,
mathieu.desnoyers, josh, bigeasy, ast, boqun.feng, mark.rutland
In-Reply-To: <20260302112545.51f7e100@gandalf.local.home>
On Mon, Mar 02, 2026 at 11:25:45AM -0500, Steven Rostedt wrote:
>On Mon, 2 Mar 2026 08:36:13 -0500
>Sasha Levin <sashal@kernel.org> wrote:
>
>> This response was AI-generated by bug-bot. The analysis may contain errors — please verify independently.
>>
>> ## Bug Summary
>>
>> This is an RCU stall and hung task deadlock on 7.0.0-rc1, triggered by perf trace teardown under perf interrupt storm conditions. The perf subsystem's tracepoint unregistration path now blocks on SRCU (tracepoint_srcu), which in turn blocks on RCU grace period completion, creating a cascading stall when RCU progress is delayed by perf NMI interrupt storms. Severity: system hang (multiple tasks blocked >143s, eventual complete stall).
>
>Hmm, this analysis corresponds nicely to what I was thinking when looking
>at the stack dumps, but it gives a bit more details than I would have.
Thanks for the feedback!
I'll finish fine-tuning this script, and publish it in a day or two :)
--
Thanks,
Sasha
^ 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-03-02 17:37 UTC (permalink / raw)
To: Jiri Olsa
Cc: bot+bpf-ci, yonghong.song, bpf, linux-open-source, ast, daniel,
andrii, rostedt, linux-trace-kernel, martin.lau, eddyz87, clm,
ihor.solodrai
In-Reply-To: <aaVtarHiOYPfe9Tu@krava>
On Mon, Mar 2, 2026 at 5:58 AM Jiri Olsa <olsajiri@gmail.com> wrote:
>
> On Fri, Feb 27, 2026 at 05:28:05PM -0500, Andrey Grodzovsky wrote:
> > 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.
>
> I think the problem is that it could now pass for cases where
> function name has multiple instances in kallsyms .. while before
> it would be caught in libbpf_available_kallsyms_parse and fail
>
> jirka
Got you, you (and CI BOT originally) proposed with the unique_match guard:
fall back to slow path, preserving old behavior for this case.
Wiil do.
Andrey
>
>
> >
> > Andrii, Yonghong - any suggestions ?
> >
> > [1] - https://urldefense.com/v3/__https://lore.kernel.org/bpf/20241218225246.3170300-1-yonghong.song@linux.dev/__;!!BmdzS3_lV9HdKG8!xk626jLDdORTgQmachiRbRK_5oayjcFYNRm-SQS9q7EujjYI3PbN1x1jUehjPM_wsz6h8r0p9z39vc_VotgANU2nr_H3$
> >
> > 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 bpf] ftrace: Add missing ftrace_lock to update_ftrace_direct_add/del
From: Steven Rostedt @ 2026-03-02 17:47 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Jiri Olsa, Alexei Starovoitov, Ihor Solodrai,
Kumar Kartikeya Dwivedi, bpf, LKML, linux-trace-kernel,
Daniel Borkmann, Andrii Nakryiko, Menglong Dong, Song Liu
In-Reply-To: <CAADnVQKBx71HOwVcRFj7ja+y_NL83rpKQ0BRcismOwdCNx6pbA@mail.gmail.com>
On Mon, 2 Mar 2026 07:58:11 -0800
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> Steven,
> should it land through ftrace tree?
I added my review by tag. It's small enough that you can take it through
your tree.
Thanks,
-- Steve
^ permalink raw reply
* Re: [PATCH bpf] ftrace: Add missing ftrace_lock to update_ftrace_direct_add/del
From: Alexei Starovoitov @ 2026-03-02 17:53 UTC (permalink / raw)
To: Steven Rostedt
Cc: Jiri Olsa, Alexei Starovoitov, Ihor Solodrai,
Kumar Kartikeya Dwivedi, bpf, LKML, linux-trace-kernel,
Daniel Borkmann, Andrii Nakryiko, Menglong Dong, Song Liu
In-Reply-To: <20260302124755.4ff16264@gandalf.local.home>
On Mon, Mar 2, 2026 at 9:47 AM Steven Rostedt <rostedt@kernel.org> wrote:
>
> On Mon, 2 Mar 2026 07:58:11 -0800
> Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>
> > Steven,
> > should it land through ftrace tree?
>
> I added my review by tag. It's small enough that you can take it through
> your tree.
Ok. Applied.
^ permalink raw reply
* Re: [External] Re: [RFC PATCH bpf-next v3 0/3] Optimize kprobe.session attachment for exact function names
From: Andrey Grodzovsky @ 2026-03-02 18:00 UTC (permalink / raw)
To: Jakub Sitnicki
Cc: bpf, linux-open-source, ast, daniel, andrii, jolsa, rostedt,
linux-trace-kernel, kernel-team
In-Reply-To: <87o6l6e6td.fsf@cloudflare.com>
On Mon, Mar 2, 2026 at 7:48 AM Jakub Sitnicki <jakub@cloudflare.com> wrote:
>
> On Fri, Feb 27, 2026 at 03:40 PM -05, Andrey Grodzovsky wrote:
> > - Patch 1: libbpf detects exact function names (no wildcards) in
> > bpf_program__attach_kprobe_multi_opts() and bypasses kallsyms parsing,
> > passing the symbol directly to the kernel via syms[] array.
> > ESRCH is normalized to ENOENT for API consistency.
>
> FWIW, Ivan was also trying to make it faster from the kernel side:
>
> https://urldefense.com/v3/__https://lore.kernel.org/bpf/20260129-ivan-bpf-ksym-cache-v1-1-ca503070dcc0@cloudflare.com/__;!!BmdzS3_lV9HdKG8!zla5HijIg6Vbdu0M8yoWocdwUD_o1-XyD5HUD7ZHbjKt9D846oT35Srz6_uXjkfS4eSc_i-lOw6IllBHvfaZgPHdXrKp$
>
> But, IIUC, with this change we're not hitting get_ksymbol_bpf at all.
Exactly. Also, note plz that patch [2/3] includes an extra
optimisation in the kernel ftrace path too.
Andrey
^ permalink raw reply
* Re: [PATCH bpf] ftrace: Add missing ftrace_lock to update_ftrace_direct_add/del
From: patchwork-bot+netdevbpf @ 2026-03-02 18:00 UTC (permalink / raw)
To: Jiri Olsa
Cc: rostedt, ast, ihor.solodrai, memxor, bpf, linux-kernel,
linux-trace-kernel, daniel, andrii, menglong8.dong, song
In-Reply-To: <20260302081622.165713-1-jolsa@kernel.org>
Hello:
This patch was applied to bpf/bpf.git (master)
by Alexei Starovoitov <ast@kernel.org>:
On Mon, 2 Mar 2026 09:16:22 +0100 you wrote:
> Ihor and Kumar reported splat from ftrace_get_addr_curr [1], which happened
> because of the missing ftrace_lock in update_ftrace_direct_add/del functions
> allowing concurrent access to ftrace internals.
>
> The ftrace_update_ops function must be guarded by ftrace_lock, adding that.
>
> Fixes: 05dc5e9c1fe1 ("ftrace: Add update_ftrace_direct_add function")
> Fixes: 8d2c1233f371 ("ftrace: Add update_ftrace_direct_del function")
> Reported-by: Ihor Solodrai <ihor.solodrai@linux.dev>
> Reported-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
> Closes: https://lore.kernel.org/bpf/1b58ffb2-92ae-433a-ba46-95294d6edea2@linux.dev/
> Tested-by: Ihor Solodrai <ihor.solodrai@linux.dev>
> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
>
> [...]
Here is the summary with links:
- [bpf] ftrace: Add missing ftrace_lock to update_ftrace_direct_add/del
https://git.kernel.org/bpf/bpf/c/3ebc98c1ae7e
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [External] Re: [RFC PATCH bpf-next v3 0/3] Optimize kprobe.session attachment for exact function names
From: Jakub Sitnicki @ 2026-03-02 19:25 UTC (permalink / raw)
To: Andrey Grodzovsky
Cc: Alexei Starovoitov, bpf, DL Linux Open Source Team,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, Jiri Olsa,
Steven Rostedt, linux-trace-kernel
In-Reply-To: <CAOu3gNhBcW-JQ_VQ00GnLd8iB6xu7Ew80Bs4VHoXOct5g-wr4g@mail.gmail.com>
On Fri, Feb 27, 2026 at 04:15 PM -05, Andrey Grodzovsky wrote:
> 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 ?
The prefix, not the cover letter.
Although I think swapping the word order might also work ("PATCH RFC").
I've seen CI run for my patch set when it was titled like that.
Kind reminder to not top-post :-)
^ permalink raw reply
* Re: [External] Re: [RFC PATCH bpf-next v3 0/3] Optimize kprobe.session attachment for exact function names
From: Andrey Grodzovsky @ 2026-03-02 19:47 UTC (permalink / raw)
To: Jakub Sitnicki
Cc: Alexei Starovoitov, bpf, DL Linux Open Source Team,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, Jiri Olsa,
Steven Rostedt, linux-trace-kernel
In-Reply-To: <87fr6idoek.fsf@cloudflare.com>
On Mon, Mar 2, 2026 at 2:25 PM Jakub Sitnicki <jakub@cloudflare.com> wrote:
>
> On Fri, Feb 27, 2026 at 04:15 PM -05, Andrey Grodzovsky wrote:
> > 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 ?
>
> The prefix, not the cover letter.
>
> Although I think swapping the word order might also work ("PATCH RFC").
> I've seen CI run for my patch set when it was titled like that.
>
> Kind reminder to not top-post :-)
Yea, it actually did run for me anyway and your comment explains it.
Anyway, i am dropping the RFC prefix and sending V4 soon.
Andrey
^ permalink raw reply
* [PATCH bpf-next v4 2/3] ftrace: Use kallsyms binary search for single-symbol lookup
From: Andrey Grodzovsky @ 2026-03-02 20:08 UTC (permalink / raw)
To: bpf, linux-trace-kernel
Cc: ast, daniel, andrii, jolsa, rostedt, linux-open-source
In-Reply-To: <20260302200837.317907-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
* [PATCH bpf-next v4 0/3] Optimize kprobe.session attachment for exact function names
From: Andrey Grodzovsky @ 2026-03-02 20:08 UTC (permalink / raw)
To: bpf, linux-trace-kernel
Cc: ast, daniel, andrii, jolsa, rostedt, linux-open-source
When libbpf attaches kprobe.session programs with exact function names
(the common case: SEC("kprobe.session/vfs_read")), the current code path
has two independent performance bottlenecks:
1. Userspace (libbpf): attach_kprobe_session() always parses
/proc/kallsyms to resolve function names, even when the name is exact
(no wildcards). This takes ~150ms per function.
2. Kernel (ftrace): ftrace_lookup_symbols() does a full O(N) linear scan
over ~200K kernel symbols via kallsyms_on_each_symbol(), decompressing
every symbol name, even when resolving a single symbol (cnt == 1).
This series optimizes both layers:
- Patch 1: libbpf detects exact function names (no wildcards) in
bpf_program__attach_kprobe_multi_opts() and bypasses kallsyms parsing,
passing the symbol directly to the kernel via syms[] array.
ESRCH is normalized to ENOENT for API consistency.
- Patch 2: ftrace_lookup_symbols() uses kallsyms_lookup_name() for
O(log N) binary search when cnt == 1, with fallback to linear scan for
duplicate symbols. Included here for context; this patch is destined
for the tracing tree via linux-trace-kernel (Steven Rostedt).
- Patch 3: Selftests validating exact-name attachment via
kprobe_multi_session.c and error consistency between wildcard and exact
paths in test_attach_api_fails.
Changes since v3 [3]:
- Skip fast path when unique_match is set (Jiri Olsa, CI bot)
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)
Changes since v1 [1]:
- Move optimization into attach_kprobe_multi_opts (Jiri Olsa)
- Use ftrace_location as boolean check only (Jiri Olsa)
- Remove verbose perf rationale from comment (Steven Rostedt)
- Consolidate tests into existing subtests (Jiri Olsa)
- Delete standalone _syms.c and _errors.c files
[1] https://lore.kernel.org/bpf/20260223215113.924599-1-andrey.grodzovsky@crowdstrike.com/
[2] https://lore.kernel.org/bpf/20260226173342.3565919-1-andrey.grodzovsky@crowdstrike.com/
[3] https://lore.kernel.org/bpf/20260227204052.725813-1-andrey.grodzovsky@crowdstrike.com/
Andrey Grodzovsky (3):
libbpf: Optimize kprobe.session attachment for exact function names
ftrace: Use kallsyms binary search for single-symbol lookup
selftests/bpf: add tests for kprobe.session optimization
kernel/trace/ftrace.c | 22 +++++++++++++
tools/lib/bpf/libbpf.c | 19 ++++++++++-
.../bpf/prog_tests/kprobe_multi_test.c | 33 +++++++++++++++++--
.../bpf/progs/kprobe_multi_session.c | 10 ++++++
4 files changed, 81 insertions(+), 3 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH bpf-next v4 1/3] libbpf: Optimize kprobe.session attachment for exact function names
From: Andrey Grodzovsky @ 2026-03-02 20:08 UTC (permalink / raw)
To: bpf, linux-trace-kernel
Cc: ast, daniel, andrii, jolsa, rostedt, linux-open-source
In-Reply-To: <20260302200837.317907-1-andrey.grodzovsky@crowdstrike.com>
Detect exact function names (no wildcards) in
bpf_program__attach_kprobe_multi_opts() and bypass kallsyms parsing,
passing the symbol directly to the kernel via syms[] array. This
benefits all callers, not just kprobe.session.
When the pattern contains no '*' or '?' characters, set syms to point
directly at the pattern string and cnt to 1, skipping the expensive
/proc/kallsyms or available_filter_functions parsing (~150ms per
function).
Error code normalization: the fast path returns ESRCH from kernel's
ftrace_lookup_symbols(), while the slow path returns ENOENT from
userspace kallsyms parsing. Convert ESRCH to ENOENT in the
bpf_link_create error path to maintain API consistency - both paths
now return identical error codes for "symbol not found".
Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@crowdstrike.com>
---
tools/lib/bpf/libbpf.c | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 0be7017800fe..0662d72bad20 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -12041,7 +12041,16 @@ bpf_program__attach_kprobe_multi_opts(const struct bpf_program *prog,
if (addrs && syms)
return libbpf_err_ptr(-EINVAL);
- if (pattern) {
+ /*
+ * Exact function name (no wildcards) without unique_match:
+ * bypass kallsyms parsing and pass the symbol directly to the
+ * kernel via syms[] array. When unique_match is set, fall
+ * through to the slow path which detects duplicate symbols.
+ */
+ if (pattern && !strpbrk(pattern, "*?") && !unique_match) {
+ syms = &pattern;
+ cnt = 1;
+ } else if (pattern) {
if (has_available_filter_functions_addrs())
err = libbpf_available_kprobes_parse(&res);
else
@@ -12084,6 +12093,14 @@ bpf_program__attach_kprobe_multi_opts(const struct bpf_program *prog,
link_fd = bpf_link_create(prog_fd, 0, attach_type, &lopts);
if (link_fd < 0) {
err = -errno;
+ /*
+ * Normalize error code: when exact name bypasses kallsyms
+ * parsing, kernel returns ESRCH from ftrace_lookup_symbols().
+ * Convert to ENOENT for API consistency with the pattern
+ * matching path which returns ENOENT from userspace.
+ */
+ if (err == -ESRCH)
+ err = -ENOENT;
pr_warn("prog '%s': failed to attach: %s\n",
prog->name, errstr(err));
goto error;
--
2.34.1
^ permalink raw reply related
* [PATCH bpf-next v4 3/3] selftests/bpf: add tests for kprobe.session optimization
From: Andrey Grodzovsky @ 2026-03-02 20:08 UTC (permalink / raw)
To: bpf, linux-trace-kernel
Cc: ast, daniel, andrii, jolsa, rostedt, linux-open-source
In-Reply-To: <20260302200837.317907-1-andrey.grodzovsky@crowdstrike.com>
Extend existing kprobe_multi_test subtests to validate the
kprobe.session exact function name optimization:
In kprobe_multi_session.c, add test_kprobe_syms which attaches a
kprobe.session program to an exact function name (bpf_fentry_test1)
exercising the fast syms[] path that bypasses kallsyms parsing. It
calls session_check() so bpf_fentry_test1 is hit by both the wildcard
and exact probes, and test_session_skel_api validates
kprobe_session_result[0] == 4 (entry + return from each probe).
In test_attach_api_fails, add fail_7 and fail_8 verifying error code
consistency between the wildcard pattern path (slow, parses kallsyms)
and the exact function name path (fast, uses syms[] array). Both
paths must return -ENOENT for non-existent functions.
Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@crowdstrike.com>
---
.../bpf/prog_tests/kprobe_multi_test.c | 33 +++++++++++++++++--
.../bpf/progs/kprobe_multi_session.c | 10 ++++++
2 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/bpf/prog_tests/kprobe_multi_test.c b/tools/testing/selftests/bpf/prog_tests/kprobe_multi_test.c
index f81dcd609ee9..78c974d4ea33 100644
--- a/tools/testing/selftests/bpf/prog_tests/kprobe_multi_test.c
+++ b/tools/testing/selftests/bpf/prog_tests/kprobe_multi_test.c
@@ -327,6 +327,30 @@ static void test_attach_api_fails(void)
if (!ASSERT_EQ(saved_error, -E2BIG, "fail_6_error"))
goto cleanup;
+ /* fail_7 - non-existent wildcard pattern (slow path) */
+ LIBBPF_OPTS_RESET(opts);
+
+ link = bpf_program__attach_kprobe_multi_opts(skel->progs.test_kprobe_manual,
+ "__nonexistent_func_xyz_*",
+ &opts);
+ saved_error = -errno;
+ if (!ASSERT_ERR_PTR(link, "fail_7"))
+ goto cleanup;
+
+ if (!ASSERT_EQ(saved_error, -ENOENT, "fail_7_error"))
+ goto cleanup;
+
+ /* fail_8 - non-existent exact name (fast path), same error as wildcard */
+ link = bpf_program__attach_kprobe_multi_opts(skel->progs.test_kprobe_manual,
+ "__nonexistent_func_xyz_123",
+ &opts);
+ saved_error = -errno;
+ if (!ASSERT_ERR_PTR(link, "fail_8"))
+ goto cleanup;
+
+ if (!ASSERT_EQ(saved_error, -ENOENT, "fail_8_error"))
+ goto cleanup;
+
cleanup:
bpf_link__destroy(link);
kprobe_multi__destroy(skel);
@@ -355,8 +379,13 @@ static void test_session_skel_api(void)
ASSERT_OK(err, "test_run");
ASSERT_EQ(topts.retval, 0, "test_run");
- /* bpf_fentry_test1-4 trigger return probe, result is 2 */
- for (i = 0; i < 4; i++)
+ /*
+ * bpf_fentry_test1 is hit by both the wildcard probe and the exact
+ * name probe (test_kprobe_syms), so entry + return fires twice: 4.
+ * bpf_fentry_test2-4 are hit only by the wildcard probe: 2.
+ */
+ ASSERT_EQ(skel->bss->kprobe_session_result[0], 4, "kprobe_session_result");
+ for (i = 1; i < 4; i++)
ASSERT_EQ(skel->bss->kprobe_session_result[i], 2, "kprobe_session_result");
/* bpf_fentry_test5-8 trigger only entry probe, result is 1 */
diff --git a/tools/testing/selftests/bpf/progs/kprobe_multi_session.c b/tools/testing/selftests/bpf/progs/kprobe_multi_session.c
index bd8b7fb7061e..d52a65b40bbf 100644
--- a/tools/testing/selftests/bpf/progs/kprobe_multi_session.c
+++ b/tools/testing/selftests/bpf/progs/kprobe_multi_session.c
@@ -76,3 +76,13 @@ int test_kprobe(struct pt_regs *ctx)
{
return session_check(ctx);
}
+
+/*
+ * Exact function name (no wildcards) - exercises the fast syms[] path
+ * in bpf_program__attach_kprobe_multi_opts() which bypasses kallsyms parsing.
+ */
+SEC("kprobe.session/bpf_fentry_test1")
+int test_kprobe_syms(struct pt_regs *ctx)
+{
+ return session_check(ctx);
+}
--
2.34.1
^ permalink raw reply related
* [PATCH v2 000/110] vfs: change inode->i_ino from unsigned long to u64
From: Jeff Layton @ 2026-03-02 20:23 UTC (permalink / raw)
To: Alexander Viro, Christian Brauner, Jan Kara, Steven Rostedt,
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, Eric Paris, Joerg Reuter, Marcel Holtmann,
Johan Hedberg, Luiz Augusto von Dentz, Oliver Hartkopp,
Marc Kleine-Budde, David Ahern, Neal Cardwell, Steffen Klassert,
Herbert Xu, Remi Denis-Courmont, Marcelo Ricardo Leitner,
Xin Long, Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend
Cc: 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, audit,
linux-bluetooth, linux-can, linux-sctp, bpf, Jeff Layton
This version splits the change up to be more bisectable. It first adds a
new kino_t typedef and a new "PRIino" macro to hold the width specifier
for format strings. The conversion is done, and then everything is
changed to remove the new macro and typedef.
I also missed a few places in the earlier set. This one hopefully does a
bit more thorough job.
My thanks and apologies to everyone who sent R-b/A-b for the v1 series.
v2 breaks a lot of the changes up into two patches so many of those
didn't carry over. Please resend those if you're still OK with it.
The entire pile is in the "iino-u64" branch of my tree, if anyone is
interested in testing this:
https://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux.git/
Original cover letter follows:
----------------------8<-----------------------
Christian said [1] to "just do it" when I proposed this, so here we are!
For historical reasons, the inode->i_ino field is an unsigned long,
which means that it's 32 bits on 32 bit architectures. This has caused a
number of filesystems to implement hacks to hash a 64-bit identifier
into a 32-bit field, and deprives us of a universal identifier field for
an inode.
This patchset changes the inode->i_ino field from an unsigned long to a
u64. This shouldn't make any material difference on 64-bit hosts, but
32-bit hosts will see struct inode grow by at least 4 bytes. This could
have effects on slabcache sizes and field alignment.
The bulk of the changes are to format strings and tracepoints, since the
kernel itself doesn't care that much about the i_ino field. The first
patch changes some vfs function arguments, so check that one out
carefully.
With this change, we may be able to shrink some inode structures. For
instance, struct nfs_inode has a fileid field that holds the 64-bit
inode number. With this set of changes, that field could be eliminated.
I'd rather leave that sort of cleanups for later just to keep this
simple.
Much of this set was generated by LLM, but I attributed it to myself
since I consider this to be in the "menial tasks" category of LLM usage.
[1]: https://lore.kernel.org/linux-fsdevel/20260219-portrait-winkt-959070cee42f@brauner/
Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
Changes in v2:
- Use a typedef and macro and do the change in two steps to make it cleanly bisectable
- Fix check_for_busy_inodes() in fscrypt
- Added patch to reorganize tracepoint structs for better packing
- Added patch to change sock.sk_ino to u64
- Added patch to clean up internal handling of inode numbers in audit subsystem
- Drop some unnecessary casts
- Link to v1: https://lore.kernel.org/r/20260226-iino-u64-v1-0-ccceff366db9@kernel.org
---
Jeff Layton (110):
vfs: introduce kino_t typedef and PRIino format macro
vfs: widen inode hash/lookup functions to u64
audit: widen ino fields to u64
net: change sock.sk_ino and sock_i_ino() to u64
trace: store i_ino as u64 instead of ino_t/unsigned long
trace: reorder TP_STRUCT__entry fields for better packing on 32-bit
ext4: use PRIino format for i_ino
jbd2: use PRIino format for i_ino
f2fs: use PRIino format for i_ino
lockd: use PRIino format for i_ino
nfs: use PRIino format for i_ino
nfsd: use PRIino format for i_ino
locks: use PRIino format for i_ino
proc: use PRIino format for i_ino
nilfs2: use PRIino format for i_ino
9p: use PRIino format for i_ino
affs: use PRIino format for i_ino
afs: use PRIino format for i_ino
autofs: use PRIino format for i_ino
befs: use PRIino format for i_ino
bfs: use PRIino format for i_ino
cachefiles: use PRIino format for i_ino
ceph: use PRIino format for i_ino
coda: use PRIino format for i_ino
cramfs: use PRIino format for i_ino
ecryptfs: use PRIino format for i_ino
efs: use PRIino format for i_ino
exportfs: use PRIino format for i_ino
ext2: use PRIino format for i_ino
freevxfs: use PRIino format for i_ino
hfs: use PRIino format for i_ino
hfsplus: use PRIino format for i_ino
hpfs: use PRIino format for i_ino
isofs: use PRIino format for i_ino
jffs2: use PRIino format for i_ino
jfs: use PRIino format for i_ino
minix: use PRIino format for i_ino
nsfs: use PRIino format for i_ino
ntfs3: use PRIino format for i_ino
ocfs2: use PRIino format for i_ino
orangefs: use PRIino format for i_ino
overlayfs: use PRIino format for i_ino
qnx4: use PRIino format for i_ino
qnx6: use PRIino format for i_ino
ubifs: use PRIino format for i_ino
udf: use PRIino format for i_ino
ufs: use PRIino format for i_ino
zonefs: use PRIino format for i_ino
security: use PRIino format for i_ino
drm/amdgpu: use PRIino format for i_ino
fsnotify: use PRIino format for i_ino
net: use PRIino format for i_ino
uprobes: use PRIino format for i_ino
dma-buf: use PRIino format for i_ino
fscrypt: use PRIino format for i_ino
fsverity: use PRIino format for i_ino
iomap: use PRIino format for i_ino
net: use PRIino format for i_ino
vfs: use PRIino format for i_ino
vfs: change kino_t from unsigned long to u64
ext4: replace PRIino with %llu/%llx format strings
jbd2: replace PRIino with %llu/%llx format strings
f2fs: replace PRIino with %llu/%llx format strings
lockd: replace PRIino with %llu/%llx format strings
nfs: replace PRIino with %llu/%llx format strings
nfsd: replace PRIino with %llu/%llx format strings
proc: replace PRIino with %llu/%llx format strings
nilfs2: replace PRIino with %llu/%llx format strings
9p: replace PRIino with %llu/%llx format strings
affs: replace PRIino with %llu/%llx format strings
afs: replace PRIino with %llu/%llx format strings
autofs: replace PRIino with %llu/%llx format strings
befs: replace PRIino with %llu/%llx format strings
bfs: replace PRIino with %llu/%llx format strings
cachefiles: replace PRIino with %llu/%llx format strings
ceph: replace PRIino with %llu/%llx format strings
coda: replace PRIino with %llu/%llx format strings
cramfs: replace PRIino with %llu/%llx format strings
ecryptfs: replace PRIino with %llu/%llx format strings
efs: replace PRIino with %llu/%llx format strings
exportfs: replace PRIino with %llu/%llx format strings
ext2: replace PRIino with %llu/%llx format strings
freevxfs: replace PRIino with %llu/%llx format strings
hfs: replace PRIino with %llu/%llx format strings
hfsplus: replace PRIino with %llu/%llx format strings
hpfs: replace PRIino with %llu/%llx format strings
isofs: replace PRIino with %llu/%llx format strings
jffs2: replace PRIino with %llu/%llx format strings
jfs: replace PRIino with %llu/%llx format strings
minix: replace PRIino with %llu/%llx format strings
ntfs3: replace PRIino with %llu/%llx format strings
ocfs2: replace PRIino with %llu/%llx format strings
orangefs: replace PRIino with %llu/%llx format strings
overlayfs: replace PRIino with %llu/%llx format strings
qnx4: replace PRIino with %llu/%llx format strings
qnx6: replace PRIino with %llu/%llx format strings
ubifs: replace PRIino with %llu/%llx format strings
udf: replace PRIino with %llu/%llx format strings
ufs: replace PRIino with %llu/%llx format strings
zonefs: replace PRIino with %llu/%llx format strings
fscrypt: replace PRIino with %llu/%llx format strings
fsverity: replace PRIino with %llu/%llx format strings
iomap: replace PRIino with %llu/%llx format strings
fsnotify: replace PRIino with %llu/%llx format strings
security: replace PRIino with %llu/%llx format strings
drm/amdgpu: replace PRIino with %llu/%llx format strings
dma-buf: replace PRIino with %llu/%llx format strings
net: replace PRIino with %llu/%llx format strings
uprobes: replace PRIino with %llu/%llx format strings
vfs: remove kino_t typedef and PRIino format macro
drivers/dma-buf/dma-buf.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 +-
fs/9p/vfs_addr.c | 4 +-
fs/9p/vfs_inode.c | 6 +-
fs/9p/vfs_inode_dotl.c | 6 +-
fs/affs/amigaffs.c | 8 +-
fs/affs/bitmap.c | 2 +-
fs/affs/dir.c | 2 +-
fs/affs/file.c | 20 +-
fs/affs/inode.c | 12 +-
fs/affs/namei.c | 14 +-
fs/affs/symlink.c | 2 +-
fs/afs/dir.c | 10 +-
fs/afs/dir_search.c | 2 +-
fs/afs/dynroot.c | 2 +-
fs/afs/inode.c | 2 +-
fs/autofs/inode.c | 2 +-
fs/befs/linuxvfs.c | 28 +-
fs/bfs/dir.c | 4 +-
fs/cachefiles/io.c | 6 +-
fs/cachefiles/namei.c | 12 +-
fs/cachefiles/xattr.c | 2 +-
fs/ceph/crypto.c | 4 +-
fs/coda/dir.c | 2 +-
fs/coda/inode.c | 2 +-
fs/cramfs/inode.c | 2 +-
fs/crypto/crypto.c | 2 +-
fs/crypto/hooks.c | 2 +-
fs/crypto/keyring.c | 4 +-
fs/crypto/keysetup.c | 2 +-
fs/dcache.c | 4 +-
fs/ecryptfs/crypto.c | 6 +-
fs/ecryptfs/file.c | 2 +-
fs/efs/inode.c | 6 +-
fs/eventpoll.c | 2 +-
fs/exportfs/expfs.c | 4 +-
fs/ext2/dir.c | 10 +-
fs/ext2/ialloc.c | 9 +-
fs/ext2/inode.c | 2 +-
fs/ext2/trace.h | 8 +-
fs/ext2/xattr.c | 14 +-
fs/ext4/dir.c | 2 +-
fs/ext4/ext4.h | 4 +-
fs/ext4/extents.c | 8 +-
fs/ext4/extents_status.c | 28 +-
fs/ext4/fast_commit.c | 8 +-
fs/ext4/ialloc.c | 10 +-
fs/ext4/indirect.c | 2 +-
fs/ext4/inline.c | 14 +-
fs/ext4/inode.c | 22 +-
fs/ext4/ioctl.c | 4 +-
fs/ext4/mballoc.c | 6 +-
fs/ext4/migrate.c | 2 +-
fs/ext4/move_extent.c | 20 +-
fs/ext4/namei.c | 10 +-
fs/ext4/orphan.c | 16 +-
fs/ext4/page-io.c | 10 +-
fs/ext4/super.c | 22 +-
fs/ext4/xattr.c | 10 +-
fs/f2fs/compress.c | 4 +-
fs/f2fs/dir.c | 2 +-
fs/f2fs/extent_cache.c | 8 +-
fs/f2fs/f2fs.h | 6 +-
fs/f2fs/file.c | 12 +-
fs/f2fs/gc.c | 2 +-
fs/f2fs/inline.c | 4 +-
fs/f2fs/inode.c | 48 ++--
fs/f2fs/namei.c | 8 +-
fs/f2fs/node.c | 12 +-
fs/f2fs/recovery.c | 10 +-
fs/f2fs/xattr.c | 10 +-
fs/freevxfs/vxfs_bmap.c | 4 +-
fs/fserror.c | 2 +-
fs/hfs/catalog.c | 2 +-
fs/hfs/extent.c | 4 +-
fs/hfs/inode.c | 4 +-
fs/hfsplus/attributes.c | 10 +-
fs/hfsplus/catalog.c | 2 +-
fs/hfsplus/dir.c | 6 +-
fs/hfsplus/extents.c | 6 +-
fs/hfsplus/inode.c | 8 +-
fs/hfsplus/super.c | 6 +-
fs/hfsplus/xattr.c | 10 +-
fs/hpfs/dir.c | 4 +-
fs/hpfs/dnode.c | 4 +-
fs/hpfs/ea.c | 4 +-
fs/hpfs/inode.c | 4 +-
fs/inode.c | 49 ++--
fs/iomap/ioend.c | 2 +-
fs/iomap/trace.h | 8 +-
fs/isofs/compress.c | 2 +-
fs/isofs/dir.c | 2 +-
fs/isofs/inode.c | 6 +-
fs/isofs/namei.c | 2 +-
fs/jbd2/journal.c | 4 +-
fs/jbd2/transaction.c | 2 +-
fs/jffs2/dir.c | 4 +-
fs/jffs2/file.c | 4 +-
fs/jffs2/fs.c | 18 +-
fs/jfs/inode.c | 2 +-
fs/jfs/jfs_imap.c | 2 +-
fs/jfs/jfs_metapage.c | 2 +-
fs/lockd/svclock.c | 8 +-
fs/lockd/svcsubs.c | 2 +-
fs/locks.c | 6 +-
fs/minix/inode.c | 10 +-
fs/nfs/dir.c | 20 +-
fs/nfs/file.c | 8 +-
fs/nfs/filelayout/filelayout.c | 8 +-
fs/nfs/flexfilelayout/flexfilelayout.c | 8 +-
fs/nfs/inode.c | 6 +-
fs/nfs/nfs4proc.c | 4 +-
fs/nfs/pnfs.c | 12 +-
fs/nfsd/export.c | 2 +-
fs/nfsd/nfs4state.c | 4 +-
fs/nfsd/nfsfh.c | 4 +-
fs/nfsd/vfs.c | 2 +-
fs/nilfs2/alloc.c | 10 +-
fs/nilfs2/bmap.c | 2 +-
fs/nilfs2/btnode.c | 2 +-
fs/nilfs2/btree.c | 12 +-
fs/nilfs2/dir.c | 12 +-
fs/nilfs2/direct.c | 4 +-
fs/nilfs2/gcinode.c | 2 +-
fs/nilfs2/inode.c | 8 +-
fs/nilfs2/mdt.c | 2 +-
fs/nilfs2/namei.c | 2 +-
fs/nilfs2/segment.c | 2 +-
fs/notify/fdinfo.c | 4 +-
fs/nsfs.c | 4 +-
fs/ntfs3/super.c | 2 +-
fs/ocfs2/alloc.c | 2 +-
fs/ocfs2/aops.c | 4 +-
fs/ocfs2/dir.c | 8 +-
fs/ocfs2/dlmfs/dlmfs.c | 10 +-
fs/ocfs2/extent_map.c | 12 +-
fs/ocfs2/inode.c | 2 +-
fs/ocfs2/quota_local.c | 2 +-
fs/ocfs2/refcounttree.c | 10 +-
fs/ocfs2/xattr.c | 4 +-
fs/orangefs/inode.c | 2 +-
fs/overlayfs/export.c | 2 +-
fs/overlayfs/namei.c | 4 +-
fs/overlayfs/util.c | 2 +-
fs/pipe.c | 2 +-
fs/proc/fd.c | 2 +-
fs/proc/task_mmu.c | 4 +-
fs/qnx4/inode.c | 4 +-
fs/qnx6/inode.c | 2 +-
fs/ubifs/debug.c | 8 +-
fs/ubifs/dir.c | 28 +-
fs/ubifs/file.c | 28 +-
fs/ubifs/journal.c | 6 +-
fs/ubifs/super.c | 16 +-
fs/ubifs/tnc.c | 4 +-
fs/ubifs/xattr.c | 14 +-
fs/udf/directory.c | 18 +-
fs/udf/file.c | 2 +-
fs/udf/inode.c | 12 +-
fs/udf/namei.c | 8 +-
fs/udf/super.c | 2 +-
fs/ufs/balloc.c | 6 +-
fs/ufs/dir.c | 10 +-
fs/ufs/ialloc.c | 6 +-
fs/ufs/inode.c | 18 +-
fs/ufs/ufs_fs.h | 6 +-
fs/ufs/util.c | 2 +-
fs/verity/init.c | 2 +-
fs/zonefs/super.c | 8 +-
fs/zonefs/trace.h | 18 +-
include/linux/audit.h | 2 +-
include/linux/fs.h | 28 +-
include/net/sock.h | 4 +-
include/trace/events/cachefiles.h | 18 +-
include/trace/events/ext4.h | 423 +++++++++++++++--------------
include/trace/events/f2fs.h | 172 ++++++------
include/trace/events/filelock.h | 34 +--
include/trace/events/filemap.h | 20 +-
include/trace/events/fs_dax.h | 20 +-
include/trace/events/fsverity.h | 30 +-
include/trace/events/hugetlbfs.h | 42 +--
include/trace/events/netfs.h | 8 +-
include/trace/events/nilfs2.h | 12 +-
include/trace/events/readahead.h | 18 +-
include/trace/events/timestamp.h | 16 +-
include/trace/events/writeback.h | 162 +++++------
kernel/audit.h | 9 +-
kernel/audit_fsnotify.c | 4 +-
kernel/audit_watch.c | 8 +-
kernel/auditsc.c | 2 +-
kernel/events/uprobes.c | 4 +-
net/ax25/af_ax25.c | 2 +-
net/bluetooth/af_bluetooth.c | 4 +-
net/can/bcm.c | 2 +-
net/ipv4/ping.c | 2 +-
net/ipv4/raw.c | 2 +-
net/ipv4/tcp_ipv4.c | 2 +-
net/ipv4/udp.c | 2 +-
net/ipv6/datagram.c | 2 +-
net/ipv6/tcp_ipv6.c | 2 +-
net/key/af_key.c | 2 +-
net/netlink/af_netlink.c | 2 +-
net/netlink/diag.c | 2 +-
net/netrom/af_netrom.c | 4 +-
net/packet/af_packet.c | 2 +-
net/packet/diag.c | 2 +-
net/phonet/socket.c | 4 +-
net/rose/af_rose.c | 4 +-
net/sctp/proc.c | 4 +-
net/socket.c | 2 +-
net/unix/af_unix.c | 2 +-
net/unix/diag.c | 6 +-
net/x25/x25_proc.c | 4 +-
net/xdp/xsk_diag.c | 2 +-
security/apparmor/apparmorfs.c | 4 +-
security/integrity/integrity_audit.c | 2 +-
security/ipe/audit.c | 2 +-
security/lsm_audit.c | 10 +-
security/selinux/hooks.c | 10 +-
security/smack/smack_lsm.c | 12 +-
220 files changed, 1181 insertions(+), 1181 deletions(-)
---
base-commit: 842cfe0733c5a03982a7ae496de6fdc0dd661a41
change-id: 20260224-iino-u64-b44a3a72543c
Best regards,
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* [PATCH v2 001/110] vfs: introduce kino_t typedef and PRIino format macro
From: Jeff Layton @ 2026-03-02 20:23 UTC (permalink / raw)
To: Alexander Viro, Christian Brauner, Jan Kara, Steven Rostedt,
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, Eric Paris, Joerg Reuter, Marcel Holtmann,
Johan Hedberg, Luiz Augusto von Dentz, Oliver Hartkopp,
Marc Kleine-Budde, David Ahern, Neal Cardwell, Steffen Klassert,
Herbert Xu, Remi Denis-Courmont, Marcelo Ricardo Leitner,
Xin Long, Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend
Cc: 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, audit,
linux-bluetooth, linux-can, linux-sctp, bpf, Jeff Layton
In-Reply-To: <20260302-iino-u64-v2-0-e5388800dae0@kernel.org>
Introduce a kino_t typedef and PRIino format macro to enable a
bisect-clean transition of i_ino from unsigned long to u64.
kino_t is initially defined as unsigned long (matching the original
i_ino type), and PRIino is "l" (the format length modifier for
unsigned long). A later patch will change these to u64 and "ll"
respectively once all format strings have been updated to use PRIino.
The PRIino macro is a length modifier, not a complete format specifier.
It is used as: "%" PRIino "u" for decimal, "%" PRIino "x" for hex, etc.
This follows the pattern used by userspace PRIu64/PRIx64 macros.
Format strings using i_ino should be updated to use PRIino instead of
a hard-coded length modifier to ensure warning-free compilation on
both 32-bit and 64-bit architectures throughout the transition.
Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
include/linux/fs.h | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 8b3dd145b25ec12b00ac1df17a952d9116b88047..e38bc5ece1f360d679a8f30b8171292f7a65c218 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -758,6 +758,9 @@ struct inode_state_flags {
enum inode_state_flags_enum __state;
};
+typedef unsigned long kino_t;
+#define PRIino "l"
+
/*
* Keep mostly read-only and often accessed (especially for
* the RCU path lookup and 'stat' data) fields at the beginning
@@ -783,7 +786,7 @@ struct inode {
#endif
/* Stat data, not accessed from path walking */
- unsigned long i_ino;
+ kino_t i_ino;
/*
* Filesystems may only read i_nlink directly. They shall use the
* following functions for modification:
--
2.53.0
^ permalink raw reply related
* [PATCH v2 002/110] vfs: widen inode hash/lookup functions to u64
From: Jeff Layton @ 2026-03-02 20:23 UTC (permalink / raw)
To: Alexander Viro, Christian Brauner, Jan Kara, Steven Rostedt,
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, Eric Paris, Joerg Reuter, Marcel Holtmann,
Johan Hedberg, Luiz Augusto von Dentz, Oliver Hartkopp,
Marc Kleine-Budde, David Ahern, Neal Cardwell, Steffen Klassert,
Herbert Xu, Remi Denis-Courmont, Marcelo Ricardo Leitner,
Xin Long, Magnus Karlsson, Maciej Fijalkowski, Stanislav Fomichev,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend
Cc: 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, audit,
linux-bluetooth, linux-can, linux-sctp, bpf, Jeff Layton
In-Reply-To: <20260302-iino-u64-v2-0-e5388800dae0@kernel.org>
Change the inode hash/lookup VFS API functions to accept u64 parameters
instead of unsigned long for inode numbers and hash values. This is
preparation for widening i_ino itself to u64, which will allow
filesystems to store full 64-bit inode numbers on 32-bit architectures.
Since unsigned long implicitly widens to u64 on all architectures, this
change is backward-compatible with all existing callers.
In dump_mapping(), change the local ino variable to kino_t and use the
PRIino format macro, since this variable holds an i_ino value. In
init_special_inode(), also switch to PRIino.
Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
fs/inode.c | 49 ++++++++++++++++++++++++-------------------------
include/linux/fs.h | 26 +++++++++++++-------------
2 files changed, 37 insertions(+), 38 deletions(-)
diff --git a/fs/inode.c b/fs/inode.c
index cc12b68e021b2c97cc88a46ddc736334ecb8edfa..24ab9fa10baf7c885244f23bfccd731efe4a14cc 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -672,7 +672,7 @@ static inline void inode_sb_list_del(struct inode *inode)
}
}
-static unsigned long hash(struct super_block *sb, unsigned long hashval)
+static unsigned long hash(struct super_block *sb, u64 hashval)
{
unsigned long tmp;
@@ -685,12 +685,12 @@ static unsigned long hash(struct super_block *sb, unsigned long hashval)
/**
* __insert_inode_hash - hash an inode
* @inode: unhashed inode
- * @hashval: unsigned long value used to locate this object in the
+ * @hashval: u64 value used to locate this object in the
* inode_hashtable.
*
* Add an inode to the inode hash for this superblock.
*/
-void __insert_inode_hash(struct inode *inode, unsigned long hashval)
+void __insert_inode_hash(struct inode *inode, u64 hashval)
{
struct hlist_head *b = inode_hashtable + hash(inode->i_sb, hashval);
@@ -726,7 +726,7 @@ void dump_mapping(const struct address_space *mapping)
struct dentry *dentry_ptr;
struct dentry dentry;
char fname[64] = {};
- unsigned long ino;
+ kino_t ino;
/*
* If mapping is an invalid pointer, we don't want to crash
@@ -750,14 +750,14 @@ void dump_mapping(const struct address_space *mapping)
}
if (!dentry_first) {
- pr_warn("aops:%ps ino:%lx\n", a_ops, ino);
+ pr_warn("aops:%ps ino:%" PRIino "x\n", a_ops, ino);
return;
}
dentry_ptr = container_of(dentry_first, struct dentry, d_u.d_alias);
if (get_kernel_nofault(dentry, dentry_ptr) ||
!dentry.d_parent || !dentry.d_name.name) {
- pr_warn("aops:%ps ino:%lx invalid dentry:%px\n",
+ pr_warn("aops:%ps ino:%" PRIino "x invalid dentry:%px\n",
a_ops, ino, dentry_ptr);
return;
}
@@ -768,7 +768,7 @@ void dump_mapping(const struct address_space *mapping)
* Even if strncpy_from_kernel_nofault() succeeded,
* the fname could be unreliable
*/
- pr_warn("aops:%ps ino:%lx dentry name(?):\"%s\"\n",
+ pr_warn("aops:%ps ino:%" PRIino "x dentry name(?):\"%s\"\n",
a_ops, ino, fname);
}
@@ -1087,7 +1087,7 @@ static struct inode *find_inode(struct super_block *sb,
* iget_locked for details.
*/
static struct inode *find_inode_fast(struct super_block *sb,
- struct hlist_head *head, unsigned long ino,
+ struct hlist_head *head, u64 ino,
bool hash_locked, bool *isnew)
{
struct inode *inode = NULL;
@@ -1301,7 +1301,7 @@ EXPORT_SYMBOL(unlock_two_nondirectories);
* Note that both @test and @set are called with the inode_hash_lock held, so
* they can't sleep.
*/
-struct inode *inode_insert5(struct inode *inode, unsigned long hashval,
+struct inode *inode_insert5(struct inode *inode, u64 hashval,
int (*test)(struct inode *, void *),
int (*set)(struct inode *, void *), void *data)
{
@@ -1378,7 +1378,7 @@ EXPORT_SYMBOL(inode_insert5);
* Note that both @test and @set are called with the inode_hash_lock held, so
* they can't sleep.
*/
-struct inode *iget5_locked(struct super_block *sb, unsigned long hashval,
+struct inode *iget5_locked(struct super_block *sb, u64 hashval,
int (*test)(struct inode *, void *),
int (*set)(struct inode *, void *), void *data)
{
@@ -1408,7 +1408,7 @@ EXPORT_SYMBOL(iget5_locked);
* This is equivalent to iget5_locked, except the @test callback must
* tolerate the inode not being stable, including being mid-teardown.
*/
-struct inode *iget5_locked_rcu(struct super_block *sb, unsigned long hashval,
+struct inode *iget5_locked_rcu(struct super_block *sb, u64 hashval,
int (*test)(struct inode *, void *),
int (*set)(struct inode *, void *), void *data)
{
@@ -1455,7 +1455,7 @@ EXPORT_SYMBOL_GPL(iget5_locked_rcu);
* hashed, and with the I_NEW flag set. The file system gets to fill it in
* before unlocking it via unlock_new_inode().
*/
-struct inode *iget_locked(struct super_block *sb, unsigned long ino)
+struct inode *iget_locked(struct super_block *sb, u64 ino)
{
struct hlist_head *head = inode_hashtable + hash(sb, ino);
struct inode *inode;
@@ -1527,7 +1527,7 @@ EXPORT_SYMBOL(iget_locked);
*
* Returns 1 if the inode number is unique, 0 if it is not.
*/
-static int test_inode_iunique(struct super_block *sb, unsigned long ino)
+static int test_inode_iunique(struct super_block *sb, u64 ino)
{
struct hlist_head *b = inode_hashtable + hash(sb, ino);
struct inode *inode;
@@ -1616,7 +1616,7 @@ EXPORT_SYMBOL(igrab);
*
* Note2: @test is called with the inode_hash_lock held, so can't sleep.
*/
-struct inode *ilookup5_nowait(struct super_block *sb, unsigned long hashval,
+struct inode *ilookup5_nowait(struct super_block *sb, u64 hashval,
int (*test)(struct inode *, void *), void *data, bool *isnew)
{
struct hlist_head *head = inode_hashtable + hash(sb, hashval);
@@ -1647,7 +1647,7 @@ EXPORT_SYMBOL(ilookup5_nowait);
*
* Note: @test is called with the inode_hash_lock held, so can't sleep.
*/
-struct inode *ilookup5(struct super_block *sb, unsigned long hashval,
+struct inode *ilookup5(struct super_block *sb, u64 hashval,
int (*test)(struct inode *, void *), void *data)
{
struct inode *inode;
@@ -1677,7 +1677,7 @@ EXPORT_SYMBOL(ilookup5);
* Search for the inode @ino in the inode cache, and if the inode is in the
* cache, the inode is returned with an incremented reference count.
*/
-struct inode *ilookup(struct super_block *sb, unsigned long ino)
+struct inode *ilookup(struct super_block *sb, u64 ino)
{
struct hlist_head *head = inode_hashtable + hash(sb, ino);
struct inode *inode;
@@ -1726,8 +1726,8 @@ EXPORT_SYMBOL(ilookup);
* very carefully implemented.
*/
struct inode *find_inode_nowait(struct super_block *sb,
- unsigned long hashval,
- int (*match)(struct inode *, unsigned long,
+ u64 hashval,
+ int (*match)(struct inode *, u64,
void *),
void *data)
{
@@ -1773,7 +1773,7 @@ EXPORT_SYMBOL(find_inode_nowait);
*
* The caller must hold the RCU read lock.
*/
-struct inode *find_inode_rcu(struct super_block *sb, unsigned long hashval,
+struct inode *find_inode_rcu(struct super_block *sb, u64 hashval,
int (*test)(struct inode *, void *), void *data)
{
struct hlist_head *head = inode_hashtable + hash(sb, hashval);
@@ -1812,7 +1812,7 @@ EXPORT_SYMBOL(find_inode_rcu);
* The caller must hold the RCU read lock.
*/
struct inode *find_inode_by_ino_rcu(struct super_block *sb,
- unsigned long ino)
+ u64 ino)
{
struct hlist_head *head = inode_hashtable + hash(sb, ino);
struct inode *inode;
@@ -1833,7 +1833,7 @@ EXPORT_SYMBOL(find_inode_by_ino_rcu);
int insert_inode_locked(struct inode *inode)
{
struct super_block *sb = inode->i_sb;
- ino_t ino = inode->i_ino;
+ u64 ino = inode->i_ino;
struct hlist_head *head = inode_hashtable + hash(sb, ino);
bool isnew;
@@ -1884,7 +1884,7 @@ int insert_inode_locked(struct inode *inode)
}
EXPORT_SYMBOL(insert_inode_locked);
-int insert_inode_locked4(struct inode *inode, unsigned long hashval,
+int insert_inode_locked4(struct inode *inode, u64 hashval,
int (*test)(struct inode *, void *), void *data)
{
struct inode *old;
@@ -2641,9 +2641,8 @@ void init_special_inode(struct inode *inode, umode_t mode, dev_t rdev)
/* leave it no_open_fops */
break;
default:
- printk(KERN_DEBUG "init_special_inode: bogus i_mode (%o) for"
- " inode %s:%lu\n", mode, inode->i_sb->s_id,
- inode->i_ino);
+ pr_debug("init_special_inode: bogus i_mode (%o) for inode %s:%" PRIino "u\n",
+ mode, inode->i_sb->s_id, inode->i_ino);
break;
}
}
diff --git a/include/linux/fs.h b/include/linux/fs.h
index e38bc5ece1f360d679a8f30b8171292f7a65c218..d0c4789838b5852111583a3e4cced88999496e68 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2938,32 +2938,32 @@ static inline int inode_generic_drop(struct inode *inode)
extern void d_mark_dontcache(struct inode *inode);
extern struct inode *ilookup5_nowait(struct super_block *sb,
- unsigned long hashval, int (*test)(struct inode *, void *),
+ u64 hashval, int (*test)(struct inode *, void *),
void *data, bool *isnew);
-extern struct inode *ilookup5(struct super_block *sb, unsigned long hashval,
+extern struct inode *ilookup5(struct super_block *sb, u64 hashval,
int (*test)(struct inode *, void *), void *data);
-extern struct inode *ilookup(struct super_block *sb, unsigned long ino);
+extern struct inode *ilookup(struct super_block *sb, u64 ino);
-extern struct inode *inode_insert5(struct inode *inode, unsigned long hashval,
+extern struct inode *inode_insert5(struct inode *inode, u64 hashval,
int (*test)(struct inode *, void *),
int (*set)(struct inode *, void *),
void *data);
-struct inode *iget5_locked(struct super_block *, unsigned long,
+struct inode *iget5_locked(struct super_block *, u64,
int (*test)(struct inode *, void *),
int (*set)(struct inode *, void *), void *);
-struct inode *iget5_locked_rcu(struct super_block *, unsigned long,
+struct inode *iget5_locked_rcu(struct super_block *, u64,
int (*test)(struct inode *, void *),
int (*set)(struct inode *, void *), void *);
-extern struct inode * iget_locked(struct super_block *, unsigned long);
+extern struct inode *iget_locked(struct super_block *, u64);
extern struct inode *find_inode_nowait(struct super_block *,
- unsigned long,
+ u64,
int (*match)(struct inode *,
- unsigned long, void *),
+ u64, void *),
void *data);
-extern struct inode *find_inode_rcu(struct super_block *, unsigned long,
+extern struct inode *find_inode_rcu(struct super_block *, u64,
int (*)(struct inode *, void *), void *);
-extern struct inode *find_inode_by_ino_rcu(struct super_block *, unsigned long);
-extern int insert_inode_locked4(struct inode *, unsigned long, int (*test)(struct inode *, void *), void *);
+extern struct inode *find_inode_by_ino_rcu(struct super_block *, u64);
+extern int insert_inode_locked4(struct inode *, u64, int (*test)(struct inode *, void *), void *);
extern int insert_inode_locked(struct inode *);
#ifdef CONFIG_DEBUG_LOCK_ALLOC
extern void lockdep_annotate_inode_mutex_key(struct inode *inode);
@@ -3018,7 +3018,7 @@ int setattr_should_drop_sgid(struct mnt_idmap *idmap,
*/
#define alloc_inode_sb(_sb, _cache, _gfp) kmem_cache_alloc_lru(_cache, &_sb->s_inode_lru, _gfp)
-extern void __insert_inode_hash(struct inode *, unsigned long hashval);
+extern void __insert_inode_hash(struct inode *, u64 hashval);
static inline void insert_inode_hash(struct inode *inode)
{
__insert_inode_hash(inode, inode->i_ino);
--
2.53.0
^ permalink raw reply related
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