[GIT PULL] probes: Update for v6.18

[GIT PULL] probes: Update for v6.18

[Masami Hiramatsu]

Hi Linus,

Probes for v6.18:

- fprobe: Performance enhancement of the fprobe using rhltable
  . fprobe: use rhltable for fprobe_ip_table. The fprobe IP table has
    been converted to use an rhltable for improved performance when
    dealing with a large number of probed functions.
  . Fix a suspicious RCU usage warning of the above change in the
    fprobe entry handler.
  . Remove an unused local variable of the above change.
  . Fix to initialize fprobe_ip_table in core_initcall().

- wprobe: Introduce a watchpoint probe event based on hw_breakpoint.
  . Add a new watchpoint probe that uses hardware breakpoints to
    monitor memory accesses. This allows for tracing memory reads
    and writes at specified addresses.
  . Add a basic add/remove test case for wprobe.
  . Add a syntax test case for wprobe.

- probes: Cleanup probe event subsystems.
  . uprobe/eprobe: Allocate traceprobe_parse_context per probe instead
    of each probe argument parsing. This reduce memory allocation/free
    of temporary working memory.
  . uprobes: Cleanup code using __free().
  . eprobes: Cleanup code using __free().
  . probes: Cleanup code using __free(trace_probe_log_clear) to clear
    error log automatically.
  . probes: Replace strcpy() with memcpy() in __trace_probe_log_err().


Please pull the latest probes-v6.18-2 tree, which can be found at:


  git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git
probes-v6.18-2

Tag SHA1: c9699ea9d31215b01384fc3ce3a8c7cb3c8671f9
Head SHA1: 764d1ce2ccf0377dd81a0f199f267703918588da


Masami Hiramatsu (Google) (9):
      tracing: probes: Use __free() for trace_probe_log
      tracing: eprobe: Cleanup eprobe event using __free()
      tracing: uprobes: Cleanup __trace_uprobe_create() with __free()
      tracing: uprobe: eprobes: Allocate traceprobe_parse_context per probe
      tracing: fprobe: Remove unused local variable
      tracing: wprobe: Add watchpoint probe event based on hardware breakpoint
      selftests: tracing: Add a basic testcase for wprobe
      selftests: tracing: Add syntax testcase for wprobe
      tracing: fprobe: Fix to init fprobe_ip_table earlier

Menglong Dong (2):
      tracing: fprobe: use rhltable for fprobe_ip_table
      tracing: fprobe: fix suspicious rcu usage in fprobe_entry

Thorsten Blum (1):
      tracing: probes: Replace strcpy() with memcpy() in __trace_probe_log_err()

----
 Documentation/trace/index.rst                      |   1 +
 Documentation/trace/wprobetrace.rst                |  69 +++
 include/linux/fprobe.h                             |   3 +-
 include/linux/trace_events.h                       |   2 +
 kernel/trace/Kconfig                               |  13 +
 kernel/trace/Makefile                              |   1 +
 kernel/trace/fprobe.c                              | 159 +++--
 kernel/trace/trace.c                               |   9 +-
 kernel/trace/trace.h                               |   5 +
 kernel/trace/trace_eprobe.c                        | 108 ++--
 kernel/trace/trace_probe.c                         |  27 +-
 kernel/trace/trace_probe.h                         |  12 +-
 kernel/trace/trace_uprobe.c                        |  82 +--
 kernel/trace/trace_wprobe.c                        | 685 +++++++++++++++++++++
 tools/testing/selftests/ftrace/config              |   1 +
 .../ftrace/test.d/dynevent/add_remove_wprobe.tc    |  68 ++
 .../test.d/dynevent/wprobes_syntax_errors.tc       |  20 +
 17 files changed, 1076 insertions(+), 189 deletions(-)
 create mode 100644 Documentation/trace/wprobetrace.rst
 create mode 100644 kernel/trace/trace_wprobe.c
 create mode 100644 tools/testing/selftests/ftrace/test.d/dynevent/add_remove_wprobe.tc
 create mode 100644 tools/testing/selftests/ftrace/test.d/dynevent/wprobes_syntax_errors.tc
---------------------------

-- 
Masami Hiramatsu (Google) <mhiramat@kernel.org>

Re: [GIT PULL] probes: Update for v6.18

[Linus Torvalds]

On Thu, 2 Oct 2025 at 16:44, Masami Hiramatsu <mhiramat@kernel.org> wrote:
>
> - wprobe: Introduce a watchpoint probe event based on hw_breakpoint.

This doesn't even build.

  kernel/trace/trace_wprobe.c: In function ‘__register_trace_wprobe’:
  kernel/trace/trace_wprobe.c:176:20: error: cast to generic address
space pointer from disjoint ‘__seg_gs’ address space pointer [-Werror]

and I see from the code that it has tried to brute-force it with an
ugly cast, and it still is horribly horribly wrong.

The fix for compiler errors is basically never to just add a random
cast. That will just make things worse, and in this case that
'IS_ERR()' function literally exists to find bad users like this.

I wondered why this hadn't been reported in linux-next, and the reason
appears simple: none of this has BEEN in linux-next.

So no. I'm not pulling this. This violates all the regular rules for
sending me new development, and then it doesn't even compile.

Since the pointer is a percpu pointer, the trivial fix is ato use the
per-cpu specific functions (IS_ERR_PCPU(), PTR_ERR_PCPU(), etc).

However, since this wasn't in linux-next, that's not what I'm doing.

This is not getting pulled for 6.18 AT ALL, and for 6.19 it had better
be in linux-next for a LOONG time.

           Linus

Re: [GIT PULL] probes: Update for v6.18

[Masami Hiramatsu]

On Sun, 5 Oct 2025 09:20:29 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Thu, 2 Oct 2025 at 16:44, Masami Hiramatsu <mhiramat@kernel.org> wrote:
> >
> > - wprobe: Introduce a watchpoint probe event based on hw_breakpoint.
> 
> This doesn't even build.
> 
>   kernel/trace/trace_wprobe.c: In function ‘__register_trace_wprobe’:
>   kernel/trace/trace_wprobe.c:176:20: error: cast to generic address
> space pointer from disjoint ‘__seg_gs’ address space pointer [-Werror]
> 
> and I see from the code that it has tried to brute-force it with an
> ugly cast, and it still is horribly horribly wrong.

Hmm, I applogise this error. I locally ran build tests and it passed.
But I might missed something.

> 
> The fix for compiler errors is basically never to just add a random
> cast. That will just make things worse, and in this case that
> 'IS_ERR()' function literally exists to find bad users like this.

OK.

> 
> I wondered why this hadn't been reported in linux-next, and the reason
> appears simple: none of this has BEEN in linux-next.
> 
> So no. I'm not pulling this. This violates all the regular rules for
> sending me new development, and then it doesn't even compile.
> 
> Since the pointer is a percpu pointer, the trivial fix is ato use the
> per-cpu specific functions (IS_ERR_PCPU(), PTR_ERR_PCPU(), etc).

OK.

> 
> However, since this wasn't in linux-next, that's not what I'm doing.
> 
> This is not getting pulled for 6.18 AT ALL, and for 6.19 it had better
> be in linux-next for a LOONG time.

Got it. Sorry about my mistake. Let me fix it on for-next, and
keep checking it is in linux-next and tested well.

Thank you,

> 
>            Linus


-- 
Masami Hiramatsu (Google) <mhiramat@kernel.org>

Re: [GIT PULL] probes: Update for v6.18

[Masami Hiramatsu]

On Mon, 6 Oct 2025 09:27:43 +0900
Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:

> On Sun, 5 Oct 2025 09:20:29 -0700
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> > 
> > I wondered why this hadn't been reported in linux-next, and the reason
> > appears simple: none of this has BEEN in linux-next.
> > 
> > So no. I'm not pulling this. This violates all the regular rules for
> > sending me new development, and then it doesn't even compile.

I apologize for breaking the rules due to my impatience.
I will never again submit a PR on linux-next that hasn't been tested.
I'm very sorry for the trouble.

-- 
Masami Hiramatsu (Google) <mhiramat@kernel.org>

Re: [GIT PULL] probes: Update for v6.18

[Linus Torvalds]

On Sun, 5 Oct 2025 at 17:27, Masami Hiramatsu <mhiramat@kernel.org> wrote:
>
> Hmm, I applogise this error. I locally ran build tests and it passed.
> But I might missed something.

So this is why linux-next exists - to get testing with different
configurations, different compiler versions, different architectures
etc.

Local build tests are good, and obviously necessary for some very basic testing.

And local build test can be perfectly sufficient - if it's some small
obvious fix, it's often simply not worth it waiting for a few days for
linux-next to get it merged and tested.

And no, linux-next isn't perfect, and won't find everything anyway.

And even the most trivial small change that quite reasonably didn't go
through linux-next because it was so simple can also end up breaking
things.

So none of this is some kind of "absolute black-and-white rule", and
none of this _guarantees_ that everything always works.

Even when everybody does the best they can, something will
occasionally be missed. I definitely accept that we're not perfect.

But big new features coming in during the merge window had better be
extensively checked _some_ way.

If I find problems in my fairly limited sanity-check build tests, I get unhappy.

It's one thing if it's some little mistake that I feel reasonably
missed testing for some understandable reason.

But if I get the feeling that the problem was that there just wasn't
enough care to begin with, that's when I go "nope, this will need to
wait for another release and be done properly".

And that's what happened this time around. That wasn't some trivial
little change, and it clearly didn't get a lot of coverage testing.

It should have gone through linux-next, and the problem would have
been found there instead of when I tried to merge it.

               Linus

Re: [GIT PULL] probes: Update for v6.18

[Masami Hiramatsu]

On Sun, 5 Oct 2025 20:09:02 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Sun, 5 Oct 2025 at 17:27, Masami Hiramatsu <mhiramat@kernel.org> wrote:
> >
> > Hmm, I applogise this error. I locally ran build tests and it passed.
> > But I might missed something.
> 
> So this is why linux-next exists - to get testing with different
> configurations, different compiler versions, different architectures
> etc.

Yes, I have noticed the limitations of creating a local test environment,
and I would like to utilize linux-next.

> 
> Local build tests are good, and obviously necessary for some very basic testing.
> 
> And local build test can be perfectly sufficient - if it's some small
> obvious fix, it's often simply not worth it waiting for a few days for
> linux-next to get it merged and tested.
> 
> And no, linux-next isn't perfect, and won't find everything anyway.
> 
> And even the most trivial small change that quite reasonably didn't go
> through linux-next because it was so simple can also end up breaking
> things.
> 
> So none of this is some kind of "absolute black-and-white rule", and
> none of this _guarantees_ that everything always works.
> 
> Even when everybody does the best they can, something will
> occasionally be missed. I definitely accept that we're not perfect.
> 
> But big new features coming in during the merge window had better be
> extensively checked _some_ way.

Yes, that was my fault.

> 
> If I find problems in my fairly limited sanity-check build tests, I get unhappy.
> 
> It's one thing if it's some little mistake that I feel reasonably
> missed testing for some understandable reason.
> 
> But if I get the feeling that the problem was that there just wasn't
> enough care to begin with, that's when I go "nope, this will need to
> wait for another release and be done properly".
> 
> And that's what happened this time around. That wasn't some trivial
> little change, and it clearly didn't get a lot of coverage testing.

I'm very sorry about causing this.

> 
> It should have gone through linux-next, and the problem would have
> been found there instead of when I tried to merge it.

Next time I'm sure the features are at least tested on linux-next.
I'm trying to update my PR checker to check it too.

> 
>                Linus


-- 
Masami Hiramatsu (Google) <mhiramat@kernel.org>