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

[Kris Van Hees <kris.van.hees@oracle.com>]

On Thu, Nov 05, 2026 at 04:53:53PM +0000, Nick Alcock wrote:
> 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.

Since we no longer have a dtrace.ko, that is not an issue.

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

Well, is a module is unloaded and reloaded with a different content, then an
active tracing session already will face trouble because there is e.g. a
potential that addresses were put in the trace buffer based on the old version
of the module, but symbol resolution takes place in the consumer using the new
version, and thus you get wrong results.  Of ocurse, that would be (possibly)
of short duration - but either way, the system changing underneath us is just
not a case that we can really deal with.  That was something we could deal with
much better when dtrace had an important piece living in the kernel because we
could (in a pretty seamless way) re-enable probes based on the enablings that
were stored in the kernel.  Now we would have to react to a module unloading
and reloading from userspace which means there would be delays and all kinds of
side effects that would disrupt ongoing tracing anyway.

> > 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.)

Combination of all the above :)  The main purpose is remove complexity that is
no longer really beneficial to the operation of DTrace, and also to makes it
easier to simply and streamline the code that handles modules symbol and type
data - the extra complexity was lowering performance without really offering
much of a benefit.

> > 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)
>