Re: DTrace, kernel loader, unknown probes, enable on load?

On Fri, Feb 11, 2022 at 09:23:47AM -0500, Mark Johnston wrote:
> On Fri, Feb 11, 2022 at 02:10:30PM +0000, Bjoern A. Zeeb wrote:
> > Hi,
> > 
> > one of the drawbacks of Dtrace (and other tracing frameworks out there
> > on various OSes) is that they do need a list of probes upfront before
> > they can enable.
> 
> The probes don't have to exist, add -Z to the dtrace(1) parameters.
> 
> > Say I want to trace a kernel module from the moment it is loaded, that
> > is currently not possible.
> 
> So something like:
> 
> # dtrace -n 'fbt::coretemp_identify:entry {stack();}' -Z
> # kldload coretemp
> 
> ought to work, I think, but it doesn't.  It's been a while since I
> looked at this code but I think it might be related to the unimplemented
> (on FreeBSD) portion of dtrace_probe_provide().  IIRC that's due to a
> lock order reversal...

I see now: the problem is that FBT registers probes after KLD SYSINITs
and module hooks are invoked.  See dtrace_module_loaded(), which
(asynchronously) calls dtrace_enabling_matchall() to see if any newly
registered probes match pending "retained enablings", in this case,
enablings created by dtrace -Z.  We could perhaps add a new eventhandler
that gets called before anything in the KLD is executed, and register
probes at that point.  Or, if the code you're interested runs after
SYSINITs are finished, then -Z might be sufficient today.

> > What I am wondering is how hard it would be to "ignore" unknown probes
> > but enable them the moment on loading matching ones.  I assume that
> > will probably need a callback through user space to complicate things
> > but it should not be impossible.
> >
> > In case anyone has some spare time to draft this up, I'll be happily a
> > first tester;  otherwise the idea is out at least for someone to find
> > it one day ...
> > 
> > Lots of health,
> > /bz
> > 
> > -- 
> > Bjoern A. Zeeb                                                     r15:7
> >