linux-kernel - Re: [PATCH 18/26] rv/rvgen: add fill_tracepoint_args

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: <ed5ffb1045a5d0734947019ad31b9bf46bdca3ab.camel@redhat.com>
Date: Thu, 22 Jan 2026 14:49:59 +0100
From: Gabriele Monaco <gmonaco@...hat.com>
To: Wander Lairson Costa <wander@...hat.com>
Cc: Steven Rostedt <rostedt@...dmis.org>, Nam Cao <namcao@...utronix.de>, 
 open list <linux-kernel@...r.kernel.org>, "open list:RUNTIME VERIFICATION
 (RV)"	 <linux-trace-kernel@...r.kernel.org>
Subject: Re: [PATCH 18/26] rv/rvgen: add fill_tracepoint_args_skel stub to
 ltl2k

On Thu, 2026-01-22 at 10:10 -0300, Wander Lairson Costa wrote:
> On Wed, Jan 21, 2026 at 02:53:03PM -0300, Wander Lairson Costa wrote:
> > On Wed, Jan 21, 2026 at 02:57:02PM +0100, Gabriele Monaco wrote:
> > > Mmh, this is a bit fishy though.
> > > We the patch using the decorator seems fine, but highlights how this
> > > method
> > > isn't meant to be in Monitor if not all monitors use it..
> > > Adding a stub here is just sweeping dust under the carpet.
> > > 
> > > Here should probably keep the common part of fill_trace_h() in Monitor
> > > (e.g.
> > > replacing MODEL_NAME and other common things) and create specific
> > > implementations in dot2k and ltl2k for what is not common while calling
> > > the
> > > super() counterpart for the rest.
> > > 
> > > Does it make sense to you?
> > 
> > Yes, that is exactly my idea. Since the patch series were getting too
> > long and my brain too rot, I thought would be better addressing this in
> > a following up patch series. But I can work in the next version if you
> > are not ok with that approach.

Good point, that can be a separate series so that we don't mix too many things,
but I'd also separate the initial patch introducing the @not_implemented .

> I gave more thought on this matter yesterday before bed. Maybe this
> isn't a issue on the design. Some methods on Monitor might just have a
> harmless default behavior. I look into it more closely for next the
> round.

Well, I believe that if a bunch of methods from the parent class don't need to
be called and we have to create stubs just to avoid errors, those methods
probably shouldn't be there in the first place.

That's particularly valid for the Container class, that won't ever need to fill
tracepoints and other stuff.

Why fill_tracepoint_args_skel() is not required by LTL is an implementation
detail, so that stub could even stay, in case future monitors are going to need
the entire thing.
Though I still find it cleaner to move that away too until there's a need for it
shared in Monitor.

What do you think?

Thanks,
Gabriele