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

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, [email protected] wrote:
>>>> From: Eugene Loh <[email protected]>
>>>>
>>>> [...]
>>>>
>>>> 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 <[email protected]>
>>>>
>>>> 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.