Re: [PATCH 02/20] libdtrace: retain module metadata across incremental discovery

[Nick Alcock <nix@esperi.org.uk>]

On 30 Oct 2026, Kris Van Hees spake thusly:

> Stop unloading cached modules in dtrace_update(), including vmlinux. Keep
> discovered symbol tables, ranges, types, and BTF IDs for the handle lifetime
> while collecting newly loaded modules. Module disappearance or reloading no
> longer replaces cached metadata.

Hm. Interesting. I considered doing this back in the day but more or
less immediately hit problems with wanting to remove dtrace.ko and
loading a modified one.

I guess we don't care about replacement of modules with bugfixed ones
any more? (What happens if someone does it?)

> Separate failed ELF-load cleanup from module destruction, retaining the
> existing handle ownership of shared CTF and BTF. Document the new lifetime
> contract and cover incremental discovery with both kernel symbol formats.

(I don't really know what this series is for, or why you're doing this.
Is the point of this incremental discovery? Or is it just that the
compiler resolves these things to addresses, so having them change just
causes trouble because the resolution is already done? If so, this seems
reasonable -- one hopes that the verifier would trap cases where the
addresses used now resolve to something else.)

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

Reviewed-by: Nick Alcock <nix@esperi.org.uk> # given the above

(I suspect there are more simplifications one could make, given this,
but the below seems like it should work.)

-- 
NULL && (void)