[DTrace-devel] [PATCH 10/19] Remove the is-enabled provider
Eugene Loh
eugene.loh at oracle.com
Sat Oct 26 01:13:43 UTC 2024
On 10/24/24 11:18, Kris Van Hees wrote:
> On Thu, Aug 29, 2024 at 01:25:49AM -0400, eugene.loh at oracle.com wrote:
>> From: Eugene Loh <eugene.loh at 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 at 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.
More information about the DTrace-devel
mailing list