Re: [PATCH 10/19] Remove the is-enabled provider

[Eugene Loh <eugene.loh@oracle.com>]

On 10/24/24 11:18, Kris Van Hees wrote:

> On Thu, Aug 29, 2024 at 01:25:49AM -0400, eugene.loh@oracle.com wrote:
>> From: Eugene Loh <eugene.loh@oracle.com>
>>
>> The trampoline for the is-enabled provider is unnecessarily complicated.
>> We do not need dt_cg_tramp_copy_regs() since the copied values will not
>> be used.  Nor do we need the (second) copy of regs[arg0] to mst->arg[0].
>> We can inline copyout_val().
>>
>> Actually, we can simply consolidate the USDT and is-enabled providers.
>>
>> Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
> Something occured to me...  Should the is-enabled probe also be PID-based?

Yes.

> Presumably, it is OK if we allow the guarded code to execute even if the
> particular USDT pribe is not enabled for the PID

Or not.

> but it *could* lead to
> inconsistent excution because if the associated USDT probe is not enabled,
> is-enabled for thta USDT probe in that PID *should* not execute.

Right.  And I know of no rule that says that is-enabled can guard only D 
probes.

> Right?  So there should be a check to see if PID is in the usdt_prids BPF map,
> and only execute the writing of the 1 into *arg0 if the PID was found for the
> correct (prid, PID) key?

All USDT probes check pid,uprid.

But don't take my word for it.  I'm posting a v2 with a test for this stuff.