[DTrace-devel] [PATCH 10/15] Change condition to bypass trampoline generation

[Nick Alcock]

On 23 Feb 2023, Kris Van Hees via DTrace-devel verbalised:

> Signed-off-by: Kris Van Hees <kris.van.hees at oracle.com>

What's the reason for this change? The only reasons I can see for it
make no sense: that you want to be able to generate trampolines for code
for which trampoline == NULL (which is a crash condition) or that you
want to skip trampoline generation for code that has trampolines (?! why?)

Needs more justification :)

> ---
>  libdtrace/dt_bpf.c         | 2 +-
>  libdtrace/dt_prov_uprobe.c | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libdtrace/dt_bpf.c b/libdtrace/dt_bpf.c
> index a4d5d664..23255a8d 100644
> --- a/libdtrace/dt_bpf.c
> +++ b/libdtrace/dt_bpf.c
> @@ -1092,7 +1092,7 @@ dt_bpf_load_progs(dtrace_hdl_t *dtp, uint_t cflags)
>  		 * Enabled probes with no trampoline act like they exist but
>  		 * no code is generated for them.
>  		 */
> -		if (prp->prov->impl->trampoline == NULL)
> +		if (prp->prov->impl->prog_type == BPF_PROG_TYPE_UNSPEC)
>  			continue;

This was there for a reason: if something doesn't have a trampoline we
don't want to do anything that relies on it. You're replacing this with
the implicit assumption that only UNSPEC-type providers will ever not
have a trampoline, and that's not guaranteed, it's just something that
happens to be true right now.