Linux DTrace development list
 help / color / mirror / Atom feed
From: Nick Alcock <nick.alcock@oracle.com>
To: Kris Van Hees <kris.van.hees@oracle.com>
Cc: dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com
Subject: Re: [PATCH] btf: fix symbol BTF ID lookup
Date: Fri, 25 Jul 2025 19:37:45 +0100	[thread overview]
Message-ID: <87seik3yme.fsf@esperi.org.uk> (raw)
In-Reply-To: <SJ0PR10MB56726C5DD50A9020370699DAC25EA@SJ0PR10MB5672.namprd10.prod.outlook.com> (Kris Van Hees's message of "Thu, 24 Jul 2025 14:56:20 -0400")

On 24 Jul 2025, Kris Van Hees said:

> The logic to perform a BTF ID lookup for a symbol did not guard against
> BTF data not having been loaded for the module that contains the symbol.

Oops!

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

This seems not to do what it says on the tin (though what it does
doesn't look bad).

It's not guarding against a module not being loaded: it's doing all
lookups in vmlinux rather than the shared repo if the module isn't
found. I guess this is desirable (it does increase the set of available
types), but it might be worth mentioning that we're doing this
somewhere, given that at no point does what is actually implemented
guard against BTF not having been loaded for the module that contains
the symbol :) maybe "push the code that decides which BTF to use down
next to the code that loads it" or something?

There are a few rather odd hunks in here, notably:

> -	/*
> -	 * Ensure the shared BTF is loaded, and if no BTF is given, use the
> -	 * shared one.
> -	 */
> -	 if (!dtp->dt_shared_btf) {
> -		  dt_btf_load_module(dtp, dtp->dt_exec);
> +	/* Ensure the shared BTF is loaded. */
> +	if (!dtp->dt_shared_btf)
> +		dt_btf_load_module(dtp, dtp->dt_exec);


If we don't have the dt_shared_btf... load the dt_exec? I mean yes this
will probably load dt_shared_btf as a side-effect, but why not check
dtp->dt_exec? (Hell, why not check both?)

> +	/* If the module does not have BTF data yet, try to load it. */
> +	if (!btf) {
> +		btf = dt_btf_load_module(dtp, dmp);

That looks good though.

> +		/* If no BTF momdule data was found, use the shared BTF. */
> +		if (!btf)
> +			btf = dtp->dt_shared_btf;

s/momdule/module/

>  	if (base > 0)
> -		return dt_btf_lookup_name_kind(dtp, dtp->dt_shared_btf,
> -					       name, kind);
> +		return dt_btf_lookup_name_kind(dtp, dtp->dt_exec, name, kind);

This definitely looks wrong. The intent here is seemingly to climb to
the parent (the shared BTF) if a lookup in the child fails, since you
don't have anything like libctf here to do that for you. Replacing it
with a lookup of dt_exec isn't going to do the same thing at all!

  reply	other threads:[~2025-07-25 18:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-24 18:56 [PATCH] btf: fix symbol BTF ID lookup Kris Van Hees
2025-07-25 18:37 ` Nick Alcock [this message]
2025-07-25 19:05   ` Kris Van Hees
2025-07-25 19:07     ` Nick Alcock

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87seik3yme.fsf@esperi.org.uk \
    --to=nick.alcock@oracle.com \
    --cc=dtrace-devel@oss.oracle.com \
    --cc=dtrace@lists.linux.dev \
    --cc=kris.van.hees@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox