linux-kernel - Re: [PATCH v4 00/14] rv: Add monitors to validate task switch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <374df509738db8314aa45971ba8b5469fa4e673e.camel@redhat.com>
Date: Wed, 23 Jul 2025 11:55:50 +0200
From: Gabriele Monaco <gmonaco@...hat.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>, Peter
 Zijlstra <peterz@...radead.org>, Nam Cao <namcao@...utronix.de>, Tomas
 Glozar <tglozar@...hat.com>,  Juri Lelli <jlelli@...hat.com>, Clark
 Williams <williams@...hat.com>, John Kacur <jkacur@...hat.com>
Subject: Re: [PATCH v4 00/14] rv: Add monitors to validate task switch

On Tue, 2025-07-22 at 20:50 -0400, Steven Rostedt wrote:
> 
> Can you break this up into two patch series? One that modifies the
> kernel and one that modifies the tools directory. Linus prefers
> changes to tools come in separately to changes in the kernel. So do I
> as I test them differently.

Mmh, I see. The problem with splitting those patches that strictly is
that patches changing the generating tools also include the adaptation
of kernel files, I could create something like:

  verification/rvgen: Organise Kconfig entries for nested monitors

  Do the tools/ stuff...
  The kernel changes are required to test this!

  rv: Organise Kconfig entries for nested monitors

  As introduced in commit XYZ, adapt the Kconfig...

And send them in separate series, but it doesn't look too clean to me
as the tool change requires the kernel change or, in general (see the
other patch about line length), the two things belong with each other.

Likewise, patches about monitors touch the dot models in tools/ but
those definitely belong in the same patch, otherwise we lose context.

What about keeping the patches as they are right now and send them
separately like this:

kernel series:

    rv: Add opid per-cpu monitor
     tools/verification/models/sched/opid.dot   |  35 ++++++
    rv: Add nrp and sssw per-task monitors
     tools/verification/models/sched/nrp.dot    |  29 +++++
     tools/verification/models/sched/sssw.dot   |  30 ++++++
    rv: Replace tss and sncid monitors with more complete sts
     tools/verification/models/sched/sncid.dot          |  18 ---
     tools/verification/models/sched/sts.dot            |  38 +++++
     tools/verification/models/sched/tss.dot            |  18 ---
    sched: Adapt sched tracepoints for RV task model
    rv: Retry when da monitor detects race conditions
    rv: Adjust monitor dependencies
    rv: Use strings in da monitors tracepoints
    rv: Remove trailing whitespace from tracepoint string
    rv: Add da_handle_start_run_event_ to per-task monitors

tools series:

    tools/dot2c: Fix generated files going over 100 column limit
     kernel/trace/rv/monitors/snep/snep.h    | 14 ++++++++++++--
    verification/rvgen: Organise Kconfig entries for nested monitors
     kernel/trace/rv/Kconfig                     |  5 +++++
    rv: Return init error when registering monitors
     tools/verification/rvgen/rvgen/templates/container/main.c | 3 +--
     tools/verification/rvgen/rvgen/templates/dot2k/main.c     | 3 +--
     kernel/trace/rv/monitors/sched/sched.c | 3 +--
     kernel/trace/rv/monitors/sco/sco.c     | 3 +--
     ...
     kernel/trace/rv/monitors/wwnr/wwnr.c   | 3 +--
    tools/rv: Stop gracefully also on SIGTERM
    tools/rv: Do not skip idle in trace

The rationale is that tools files changed in the kernel patches are not
really tool stuff (dot models). And kernel stuff changed in the tools
are something that the tools generate, and to test them a build should
suffice (kernel robot would do that). Having them together eases
testing the tool, I believe.

Note: I missed the tools templates from "rv: Return init error when
registering monitors" (now in the tools series with added files), I
believe that belongs more to tools but I could also move it or split
them in two if you prefer.

Does it make sense to you?

Thanks,
Gabriele