[GIT PULL] rv fixes for v7.1

[GIT PULL] rv fixes for v7.1

[Gabriele Monaco]

Steve,

The following changes since commit e43ffb69e0438cddd72aaa30898b4dc446f664f8:

  Linux 7.1-rc6 (2026-05-31 15:14:24 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gmonaco/linux.git rv-fixes-7.1

for you to fetch changes up to 44c2e91a684132ff0e47dc1f792bbdb42d64bd64:

  verification/rvgen: Fix ltl2k writing True as a literal (2026-06-03 13:20:58 +0200)

----------------------------------------------------------------
rv fixes for v7.1

Summary of changes:

- Fix reset ordering on per-task destruction

  Reset the task before dropping the slot instead of after, which was
  causing out-of-bound memory accesses.

- Fix HA monitor synchronization and cleanup

  Ensure synchronous cleanup for HA monitors by running timer callbacks
  in RCU read-side critical sections and using synchronize_rcu() during
  destruction.

- Avoid armed timers after tasks exit

  Add automatic cleanup for per-task HA monitors to prevent timers from
  firing after task exit.

- Fix memory ordering for DA/HA monitors

  Fix race conditions during monitor start by using release-acquire
  semantics for the monitoring flag.

- Fix initialization for DA/HA monitors

  Ensure monitors are not initialized relying on potentially corrupted
  state like the monitoring flag, that is not reset by all monitors type
  and may have an unknown state in monitors reusing the storage
  (per-task).

- Fix memory safety in per-task and per-object monitors

  Prevent use-after-free and out-of-bounds access by synchronizing with
  in-flight tracepoint probes using tracepoint_synchronize_unregister()
  before freeing monitor storage or releasing task slots.

- Adjust monitors for preemptible tracepoints

  Fix monitors that relied on tracepoints disabling preemption.
  Explicitly disable task migration when per-CPU monitors handle events
  to avoid accessing the wrong state and update the opid monitor logic.

- Fix incorrect __user specifier usage

  Remove __user from a non-pointer variable in the extract_params()
  helper.

- Fix bugs in the rv tool

  Ensure strings are NUL-terminated, fix substring matching in monitor
  searches, and improve cleanup and exit status handling.

- Fix several bugs in rvgen

  Fix LTL literal stringification, subparsers' options handling, and
  suffix stripping in dot2k.

----------------------------------------------------------------
Gabriele Monaco (15):
      rv: Fix __user specifier usage in extract_params()
      rv: Reset per-task DA monitors before releasing the slot
      rv: Prevent in-flight per-task handlers from using invalid slots
      rv: Ensure all pending probes terminate on per-obj monitor destroy
      rv: Do not rely on clean monitor when initialising HA
      rv: Add automatic cleanup handlers for per-task HA monitors
      rv: Ensure synchronous cleanup for HA monitors
      rv: Prevent task migration while handling per-CPU events
      rv: Use 0 to check preemption enabled in opid
      tools/rv: Fix substring match bug in monitor name search
      tools/rv: Fix substring match when listing container monitors
      tools/rv: Fix cleanup after failed trace setup
      verification/rvgen: Fix suffix strip in dot2k
      verification/rvgen: Fix options shared among commands
      verification/rvgen: Fix ltl2k writing True as a literal

Wen Yang (1):
      rv: Fix monitor start ordering and memory ordering for monitoring flag

unknownbbqrx (1):
      tools/rv: Ensure monitor name and desc are NUL-terminated

 include/rv/da_monitor.h                            | 139 +++++++++++++++++----
 include/rv/ha_monitor.h                            |  91 +++++++++++++-
 include/rv/ltl_monitor.h                           |   1 +
 kernel/trace/rv/monitors/deadline/deadline.h       |   3 +-
 kernel/trace/rv/monitors/nomiss/nomiss.c           |   4 +-
 kernel/trace/rv/monitors/opid/opid.c               |  12 +-
 kernel/trace/rv/monitors/stall/stall.c             |   4 +-
 tools/verification/rv/src/in_kernel.c              |  65 +++++-----
 tools/verification/rvgen/__main__.py               |  10 +-
 tools/verification/rvgen/rvgen/dot2k.py            |   4 +-
 tools/verification/rvgen/rvgen/ltl2ba.py           |   9 +-
 .../rvgen/rvgen/templates/dot2k/main.c             |   4 +-
 12 files changed, 263 insertions(+), 83 deletions(-)

To: Steven Rostedt <rostedt@goodmis.org>
Cc: Gabriele Monaco <gmonaco@redhat.com>
Cc: unknownbbqrx <dev@unknownbbqr.xyz>
Cc: Wen Yang <wen.yang@linux.dev>

Re: [GIT PULL] rv fixes for v7.1

[Steven Rostedt]

On Wed,  3 Jun 2026 14:50:56 +0200
Gabriele Monaco <gmonaco@redhat.com> wrote:

> unknownbbqrx (1):
>       tools/rv: Ensure monitor name and desc are NUL-terminated

Hi Gabriele,

What is this? All commits need to be authored by and signed off by from
a real person with their official name.

 https://docs.kernel.org/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin

-- Steve

Re: [GIT PULL] rv fixes for v7.1

[Tomas Glozar]

Hi Steven,

čt 4. 6. 2026 v 1:19 odesílatel Steven Rostedt <rostedt@goodmis.org> napsal:
> Hi Gabriele,
>
> What is this? All commits need to be authored by and signed off by from
> a real person with their official name.
>
>  https://docs.kernel.org/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
>
> -- Steve
>

Is this really still the case? Note that the document says:

"using a known identity (sorry, no anonymous contributions.)"

It really used to say "real name", but it was changed by Linus in 2023
[1]. Note especially this section by Linus:

" It was 2006, and nobody reacted to the wording, the whole Facebook 'real
   name' controversy was a decade in the future, and nobody even thought
   about it.  And despite the language, we've always accepted nicknames and
   that language was never meant to be any kind of exclusionary wording."

The wording sounds quite clear to me. And I'm certain that there were
contributions under pseudonymous identity that have been accepted
since then, most famously by Asahi Lina, a vtuber persona [2]. I don't
really see a difference between that and "unknownbbqrx", other than
the latter doesn't sound like a real name.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d4563201f33a022fc0353033d9dfeb1606a88330
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2e2f6b0ef8551bf3bd8255729d27e3ad9451e562

Tomas

Re: [GIT PULL] rv fixes for v7.1

[Gabriele Monaco]

On Thu, 2026-06-04 at 13:32 +0200, Tomas Glozar wrote:
> Hi Steven,
> 
> čt 4. 6. 2026 v 1:19 odesílatel Steven Rostedt <rostedt@goodmis.org>
> napsal:
> > Hi Gabriele,
> > 
> > What is this? All commits need to be authored by and signed off by
> > from
> > a real person with their official name.
> > 
> >  https://docs.kernel.org/process/submitting-patches.html#sign-your-
> > work-the-developer-s-certificate-of-origin
> > 
> > -- Steve
> > 
> 
> Is this really still the case? Note that the document says:
> 
> "using a known identity (sorry, no anonymous contributions.)"

Thanks Tomas for chipping in!

Just adding some information, the username unknownbbqr is in fact a
valid username for a Github account.

The user already sent a patch and updated it with a real name [1].

All this to say that, in my opinion unknownbbqrx <dev@unknownbbqr.xyz>
is NOT an anonymous contribution, just a nickname that differs from the
legal name of this person (which we wouldn't validate anyway), so I
would say it complies with the rules.

Thanks,
Gabriele

[1] -
https://lore.kernel.org/lkml/20260426150928.870914-1-srinivas.pandruvada@linux.intel.com/

> 
> It really used to say "real name", but it was changed by Linus in
> 2023
> [1]. Note especially this section by Linus:
> 
> " It was 2006, and nobody reacted to the wording, the whole Facebook
> 'real
>    name' controversy was a decade in the future, and nobody even
> thought
>    about it.  And despite the language, we've always accepted
> nicknames and
>    that language was never meant to be any kind of exclusionary
> wording."
> 
> The wording sounds quite clear to me. And I'm certain that there were
> contributions under pseudonymous identity that have been accepted
> since then, most famously by Asahi Lina, a vtuber persona [2]. I
> don't
> really see a difference between that and "unknownbbqrx", other than
> the latter doesn't sound like a real name.
> 
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d4563201f33a022fc0353033d9dfeb1606a88330
> [2]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2e2f6b0ef8551bf3bd8255729d27e3ad9451e562
> 
> Tomas

Re: [GIT PULL] rv fixes for v7.1

[Steven Rostedt]

On Thu, 4 Jun 2026 13:32:46 +0200
Tomas Glozar <tglozar@redhat.com> wrote:

> Is this really still the case? Note that the document says:
> 
> "using a known identity (sorry, no anonymous contributions.)"
> 
> It really used to say "real name", but it was changed by Linus in 2023
> [1]. Note especially this section by Linus:
> 
> " It was 2006, and nobody reacted to the wording, the whole Facebook 'real
>    name' controversy was a decade in the future, and nobody even thought
>    about it.  And despite the language, we've always accepted nicknames and
>    that language was never meant to be any kind of exclusionary wording."
> 
> The wording sounds quite clear to me. And I'm certain that there were
> contributions under pseudonymous identity that have been accepted
> since then, most famously by Asahi Lina, a vtuber persona [2]. I don't
> really see a difference between that and "unknownbbqrx", other than
> the latter doesn't sound like a real name.

It specifically says "using a known identity (sorry, no anonymous contributions.)"

As you said, Asahi Lina is well known and a very "known identity".
"unknownbbqrx" is unknown and even states it in the name.

I will not personally accept such a submission, as the Signed-off-by is
a legal statement that states you have the right to submit that code
and take all responsibility for it.

-- Steve

Re: [GIT PULL] rv fixes for v7.1

[Steven Rostedt]

On Thu, 04 Jun 2026 14:42:02 +0200
Gabriele Monaco <gmonaco@redhat.com> wrote:

> All this to say that, in my opinion unknownbbqrx <dev@unknownbbqr.xyz>
> is NOT an anonymous contribution, just a nickname that differs from the
> legal name of this person (which we wouldn't validate anyway), so I
> would say it complies with the rules.

It's a username on github and not a nickname. I did a search for
"unknownbbqr" and it doesn't come up anywhere but Google tries to find
similar matches which brings me to an OnlyFans account :-p

It *DOES NOT* qualify because there's no accountability for this. For
people who have a nickname as their entire internet persona, sure, I'll
take patches from them as there's an entity that exists behind it. But
I'm not going to take some username on github as a persona. To me,
that's still anonymous.

-- Steve

Re: [GIT PULL] rv fixes for v7.1

[Gabriele Monaco]

On Thu, 2026-06-04 at 08:54 -0400, Steven Rostedt wrote:
> On Thu, 04 Jun 2026 14:42:02 +0200
> Gabriele Monaco <gmonaco@redhat.com> wrote:
> 
> > All this to say that, in my opinion unknownbbqrx
> > <dev@unknownbbqr.xyz>
> > is NOT an anonymous contribution, just a nickname that differs from
> > the legal name of this person (which we wouldn't validate anyway),
> > so I would say it complies with the rules.
> 
> It's a username on github and not a nickname. I did a search for
> "unknownbbqr" and it doesn't come up anywhere but Google tries to
> find similar matches which brings me to an OnlyFans account :-p
> 
> It *DOES NOT* qualify because there's no accountability for this. For
> people who have a nickname as their entire internet persona, sure,
> I'll take patches from them as there's an entity that exists behind
> it.
> But I'm not going to take some username on github as a persona. To
> me, that's still anonymous.

Alright, fair. In the link I sent, the signoff got changed to Ali Ahmet
MEMIS <dev@unknownbbqr.xyz>, but I believe we cannot use that unless
the user themselves adds it (and they seem unreachable).

I posted the re-authored patch in [1], I'm not sure that's the proper
way though (the patch is so simple that is unmodified). But if you give
me a green light I can send you a pull request with that patch instead.

Thanks,
Gabriele

[1] -
https://lore.kernel.org/lkml/20260604120946.90302-2-gmonaco@redhat.com/

> 
> -- Steve