Hi Linus,
Probes updates for v6.10:
- tracing/probes: Adding new pseudo-types %pd and %pD support for dumping
dentry name from 'struct dentry *' and file name from 'struct file *'.
- uprobes: Some performance optimizations have been done.
. Speed up the BPF uprobe event by delaying the fetching of the uprobe
event arguments that are not used in BPF.
. Avoid locking by speculatively checking whether uprobe event is valid.
. Reduce lock contention by using read/write_lock instead of spinlock for
uprobe list operation. This improved BPF uprobe benchmark result 43% on
average.
- rethook: Removes non-fatal warning messages when tracing stack from BPF
and skip rcu_is_watching() validation in rethook if possible.
- objpool: Optimizing objpool (which is used by kretprobes and fprobe as
rethook backend storage) by inlining functions and avoid caching nr_cpu_ids
because it is a const value.
- fprobe: Add entry/exit callbacks types (code cleanup)
- kprobes: Check ftrace was killed in kprobes if it uses ftrace.
Please pull the latest probes-v6.10 tree, which can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git
probes-v6.10
Tag SHA1: 9c42dca969de36a7aaa9573844a863bb306dcafc
Head SHA1: 1a7d0890dd4a502a202aaec792a6c04e6e049547
Andrii Nakryiko (7):
uprobes: encapsulate preparation of uprobe args buffer
uprobes: prepare uprobe args buffer lazily
uprobes: add speculative lockless system-wide uprobe filter check
ftrace: make extra rcu_is_watching() validation check optional
rethook: honor CONFIG_FTRACE_VALIDATE_RCU_IS_WATCHING in rethook_try_get()
objpool: enable inlining objpool_push() and objpool_pop() operations
objpool: cache nr_possible_cpus() and avoid caching nr_cpu_ids
Jiri Olsa (1):
fprobe: Add entry/exit callbacks types
Jonathan Haslam (1):
uprobes: reduce contention on uprobes_tree access
Kui-Feng Lee (1):
rethook: Remove warning messages printed for finding return address of a frame.
Masami Hiramatsu (Google) (1):
selftests/ftrace: Fix required features for VFS type test case
Stephen Brennan (1):
kprobe/ftrace: bail out if ftrace was killed
Ye Bin (5):
tracing/probes: support '%pd' type for print struct dentry's name
tracing/probes: support '%pD' type for print struct file's name
Documentation: tracing: add new type '%pd' and '%pD' for kprobe
selftests/ftrace: add kprobe test cases for VFS type "%pd" and "%pD"
selftests/ftrace: add fprobe test cases for VFS type "%pd" and "%pD"
----
Documentation/trace/kprobetrace.rst | 8 +-
arch/csky/kernel/probes/ftrace.c | 3 +
arch/loongarch/kernel/ftrace_dyn.c | 3 +
arch/parisc/kernel/ftrace.c | 3 +
arch/powerpc/kernel/kprobes-ftrace.c | 3 +
arch/riscv/kernel/probes/ftrace.c | 3 +
arch/s390/kernel/ftrace.c | 3 +
arch/x86/kernel/kprobes/ftrace.c | 3 +
include/linux/fprobe.h | 18 ++--
include/linux/kprobes.h | 7 ++
include/linux/objpool.h | 105 ++++++++++++++++++-
include/linux/trace_recursion.h | 2 +-
kernel/events/uprobes.c | 22 ++--
kernel/kprobes.c | 6 ++
kernel/trace/Kconfig | 13 +++
kernel/trace/ftrace.c | 1 +
kernel/trace/rethook.c | 4 +-
kernel/trace/trace.c | 2 +-
kernel/trace/trace_fprobe.c | 6 ++
kernel/trace/trace_kprobe.c | 6 ++
kernel/trace/trace_probe.c | 63 ++++++++++++
kernel/trace/trace_probe.h | 2 +
kernel/trace/trace_uprobe.c | 103 +++++++++++--------
lib/objpool.c | 112 ++-------------------
.../ftrace/test.d/dynevent/fprobe_args_vfs.tc | 41 ++++++++
.../ftrace/test.d/kprobe/kprobe_args_vfs.tc | 40 ++++++++
26 files changed, 406 insertions(+), 176 deletions(-)
create mode 100644 tools/testing/selftests/ftrace/test.d/dynevent/fprobe_args_vfs.tc
create mode 100644 tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_vfs.tc
--
Masami Hiramatsu (Google) <[email protected]>
The pull request you sent on Thu, 16 May 2024 09:52:16 +0900:
> git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git probes-v6.10
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/70a663205d5085f1d82f7058e9419ff7612e9396
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
On Wed, 15 May 2024 at 17:52, Masami Hiramatsu <[email protected]> wrote:
>
> Probes updates for v6.10:
Grr,
This doesn't even build right.
Yes, it builds cleanly in an allmoconfig build, which is what I did
before I pushed out.
But after pushing out, I notice that it doesn't build in more limited
configurations and with clang, because:
> Stephen Brennan (1):
> kprobe/ftrace: bail out if ftrace was killed
This is no longer valid C code, and hasn't been for a long long while:
void kprobe_ftrace_kill()
{
kprobe_ftrace_disabled = true;
}
we require proper prototypes, not some ancient per-ANSI K&R syntax.
It turns out that gcc apparently still accepts these things, but it
really shouldn't. But with a clang build, you get a big error:
kernel/kprobes.c:1140:24: error: a function declaration without a
prototype is deprecated in all versions of C
[-Werror,-Wstrict-prototypes]
and the reason it didn't get noticed in -next is that this commit had
apparently not *been* in linux-next.
Dammit, that's now how any of this is supposed to work.
Why was this untested crap sent to me?
Linus
Linus Torvalds <[email protected]> writes:
> On Wed, 15 May 2024 at 17:52, Masami Hiramatsu <[email protected]> wrote:
>>
>> Probes updates for v6.10:
>
> Grr,
>
> This doesn't even build right.
>
> Yes, it builds cleanly in an allmoconfig build, which is what I did
> before I pushed out.
>
> But after pushing out, I notice that it doesn't build in more limited
> configurations and with clang, because:
>
>> Stephen Brennan (1):
>> kprobe/ftrace: bail out if ftrace was killed
>
> This is no longer valid C code, and hasn't been for a long long while:
>
> void kprobe_ftrace_kill()
> {
> kprobe_ftrace_disabled = true;
> }
>
> we require proper prototypes, not some ancient per-ANSI K&R syntax.
>
> It turns out that gcc apparently still accepts these things, but it
> really shouldn't. But with a clang build, you get a big error:
>
> kernel/kprobes.c:1140:24: error: a function declaration without a
> prototype is deprecated in all versions of C
> [-Werror,-Wstrict-prototypes]
>
> and the reason it didn't get noticed in -next is that this commit had
> apparently not *been* in linux-next.
>
> Dammit, that's now how any of this is supposed to work.
>
> Why was this untested crap sent to me?
Hi Linus,
Yes, this was may fault for missing "(void)", that's basic and shouldn't
have gone out. I was too focused on getting a prototype for each
possible configuration that I couldn't see the forest for the trees!
My GCC builds were not W=1, which I will do next time. I would have seen
this with a W=1 build. I can't speak for why it wasn't in -next, but it
did get caught yesterday and I sent a fix:
https://lore.kernel.org/oe-kbuild-all/[email protected]/
My apologies.
-Stephen
On Fri, 17 May 2024 19:12:04 -0700
Linus Torvalds <[email protected]> wrote:
> On Wed, 15 May 2024 at 17:52, Masami Hiramatsu <[email protected]> wrote:
> >
> > Probes updates for v6.10:
>
> Grr,
>
> This doesn't even build right.
>
> Yes, it builds cleanly in an allmoconfig build, which is what I did
> before I pushed out.
>
> But after pushing out, I notice that it doesn't build in more limited
> configurations and with clang, because:
>
> > Stephen Brennan (1):
> > kprobe/ftrace: bail out if ftrace was killed
>
> This is no longer valid C code, and hasn't been for a long long while:
>
> void kprobe_ftrace_kill()
> {
> kprobe_ftrace_disabled = true;
> }
>
> we require proper prototypes, not some ancient per-ANSI K&R syntax.
>
> It turns out that gcc apparently still accepts these things, but it
> really shouldn't. But with a clang build, you get a big error:
>
> kernel/kprobes.c:1140:24: error: a function declaration without a
> prototype is deprecated in all versions of C
> [-Werror,-Wstrict-prototypes]
>
> and the reason it didn't get noticed in -next is that this commit had
> apparently not *been* in linux-next.
>
> Dammit, that's now how any of this is supposed to work.
>
> Why was this untested crap sent to me?
Oops, sorry, I missed when I built it in local.
Ah, and I missed to build it with W=1.
I appologies that and built in W=1 build test.
>
> Linus
--
Masami Hiramatsu (Google) <[email protected]>
On Sat, 18 May 2024 at 07:38, Masami Hiramatsu <[email protected]> wrote:
>
> Ah, and I missed to build it with W=1.
Note that I do *not* at all expect people to build with W=1. It gets
very noisy depending on your compiler version etc, and a lot of the
W=1 errors are not at all worth worrying about.
But what I do expect is for merge window pull requests to have been
in linux-next, which will give it at least reasonable build coverage
from the bots,
I'm not sure whether it was because I built witch clang (which gives
some warnings that gcc does not, and vice versa) or whether it was
just that my clang build has a different Kconfig. Regardless, if this
had been in linux-next, I'm pretty sure that it would have been found
before I hit it.
Linus
On Sat, 18 May 2024 08:55:55 -0700
Linus Torvalds <[email protected]> wrote:
> On Sat, 18 May 2024 at 07:38, Masami Hiramatsu <[email protected]> wrote:
> >
> > Ah, and I missed to build it with W=1.
>
> Note that I do *not* at all expect people to build with W=1. It gets
> very noisy depending on your compiler version etc, and a lot of the
> W=1 errors are not at all worth worrying about.
>
> But what I do expect is for merge window pull requests to have been
> in linux-next, which will give it at least reasonable build coverage
> from the bots,
This is completely my fault that I forgot to push my probes/for-next
and made a pull request to you. I will push the for-next before -rc6 and
if I forgot it I will defer it to next for-next.
>
> I'm not sure whether it was because I built witch clang (which gives
> some warnings that gcc does not, and vice versa) or whether it was
> just that my clang build has a different Kconfig. Regardless, if this
> had been in linux-next, I'm pretty sure that it would have been found
> before I hit it.
Yes, I missed to build check with clang. I'll make sure to check with
both clang and gcc for release.
I'm sorry for causing you trouble and thanks for fixing the it.
Thank you,
--
Masami Hiramatsu (Google) <[email protected]>