[DTrace-devel] [PATCH 5/5] pid, uprobes: improve horrendously inefficient uprobe scanning

[Nick Alcock]

On 15 May 2023, Kris Van Hees stated:

> On Mon, Apr 24, 2023 at 08:08:16PM +0100, Nick Alcock via DTrace-devel wrote:
>>  /*
>> - * Rescan the PID uprobe list and create suitable underlying probes.
>> - *
>> - * If dpr is set, just set up probes relating to mappings found in that one
>> - * process.  (dpr must in this case be locked.)
>> + * Rescan the uprobe list and remember its contents.
>>   *
>> - * If pdp is set, create overlying USDT probes for the specified probe
>> - * description.
>> - *
>> - * Return 0 on success or -1 on error.  (Failure to create specific underlying
>> - * probes is not an error.)
>> + * This avoids us having to rescan the whole thing every time we create every
>> + * single probe in turn.
>>   */
>>  static int
>> -dt_pid_create_usdt_probes(dtrace_hdl_t *dtp, dt_proc_t *dpr,
>> -			  dtrace_probedesc_t *pdp, dt_pcb_t *pcb)
>> +dt_pid_rescan_uprobes(dtrace_hdl_t *dtp, dt_pcb_t *pcb)
>
> This function name is confusing...  the "rescan" seems to imply that we scan
> it more than once, but there is only one place where this is called from, and
> there the scan is done only if we have not yet instantiated the usdt provider,
> with a conditional that ensures dt_pid_rescan_uprobes() is only called once
> (the first time we call dt_pid_create_usdt_probes() because that is when we
> instantiate the usdt provider).

Oh yes that name is terrible isn't it. It wasn't very good to start with
and now it's much worse.

But what to replace it with? dt_pid_scan_uprobes() maybe? I don't much
like that either, 'scan' what? dt_pid_find_uprobes()?
dt_pid_bikeshed_uprobes()? :P

-- 
NULL && (void)