Re: [PATCH 2/2] rawfbt: prvname is not properly set

[Kris Van Hees <kris.van.hees@oracle.com>]

On Fri, Jan 16, 2026 at 05:43:24PM -0500, Eugene Loh wrote:
> On 1/16/26 17:02, Kris Van Hees wrote:
> 
> > On Fri, Jan 16, 2026 at 12:18:51AM -0500, Eugene Loh wrote:
> > > On 1/15/26 17:18, Kris Van Hees wrote:
> > > > On Tue, Jan 13, 2026 at 04:42:05PM -0500, eugene.loh@oracle.com wrote:
> > > > > From: Eugene Loh <eugene.loh@oracle.com>
> > > > > 
> > > > > [...]
> > > > > 
> > > > > Add a test to check that a rawfbt probe can be found behind an fbt probe
> > > > > when the probe description has a wildcard provider.
> > > > > 
> > > > > Orabug: 38842114
> > > > > Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
> > > > > 
> > > > > diff --git a/test/unittest/providers/rawfbt/tst.wildcard-provider.d b/test/unittest/providers/rawfbt/tst.wildcard-provider.d
> > > > > new file mode 100644
> > > > > @@ -0,0 +1,20 @@
> > > > > +/*
> > > > > + * ASSERTION: rawfbt probes can be found even when a wildcard provider
> > > > > + * description also allows fbt probes.
> > > > > + */
> > > > > +
> > > > > +#pragma D option quiet
> > > > > +
> > > > > +BEGIN,
> > > > > +*fbt:vmlinux:do_sys_open*:entry
> > > > > +{
> > > > > +	printf("success\n");
> > > > > +	exit(0);
> > > > > +}
> > > > I am confused how this test accomplishes verification of the assertion.  If
> > > > a regular FBT probe satisfies the probe description, wouldn't this pass also?
> > > > Wouldn't a -l based test be better here, where you can test that the output
> > > > does indeed report both the fbt probe and the rawfbt probe that match?
> > > It appears that -l is not an issue;  a -l test does not show the problem.
> > > The test in the patch is derived from the user bug report that motivated
> > > this patch.
> > > 
> > > The whole prvname problem is that the bad prvname value makes GROUP_DATA
> > > bad, which makes FBT_GROUP_DATA bad, which is an issue only in kprobe_attach
> > > (and detach).  So, we need kprobe_attach() to see the problem.
> > Ok, so yes, -l is not sufficient.  But still, even if the test is derived from
> > the original reported problem, it still looks wrong to me.  Or rather, the test
> > can pass when
> > 
> > 	fbt:vmlinux:do_sys+open*:entry exists
> > 	rawfbt:vmlinux:do_sys+open*:entry does NOT exist
> > 
> > because as long as 1 probe matches the probe specification, compilation will
> > succeed (and at runtime, the probe firing will complete the success criterium).
> > 
> > But that is not a valid PASS result for the assertion that is posed for this
> > test.  If you are specifically looking for a rawfbt probe using a wildcard, you
> > might want to use r*fbt:vmlinux:do_sys+open*:entry instead perhaps?
> 
> This test is admittedly not the most stringent;  it could well pass even if
> some other bugs lurk somewhere.  The test simply reports a problem with the
> old bits and then passes with the fix.  It is a confirmation -- however weak
> -- that the fix is doing something right.
> 
> Meanwhile, I do not understand your concerns with regards to the assertion. 
> Specifically, using r*fbt would preclude any fbt probes;  so there would be
> nothing for the rawfbt probe to "hide behind."  And, fwiw, using r*fbt makes
> the test pass even without the fix.

Well, if we have a test it should validate the problem that is being fixed,
and I do not see that happening here.  If the problem occurs with the actual
attach and it requires both fbt and rawfbt to match, then you should perhaps
remove the quiet option, and make the expected output also show the number of
probes that match the probe spec.  And add a comment in the test that the
problem validation is a combination of (1) validating that both the FBT and
rawfbt probes are found to match, and (2) validating that the script executes
which means that dtrace was able to attach to the matched probes.  That seems
like it would satisfy the assertion in a way that cannot happen if either of
the *fbt probes is missing.