[DTrace-devel] [PATCH v3 12/20] usdt: daemon

[Nick Alcock]

On 6 Oct 2022, Nick Alcock via DTrace-devel uttered the following:

> On 29 Sep 2022, Kris Van Hees stated:
>> This validate_emit_probe() function implements functionality that is not at all
>> part of the DOF parser but rather comes from the fasttrap provider in the
>> legacy version.  I don't think it should be here - this has to do with the
>> specific implementation details of the probing mechanism and thus should be
>> more appropriately part of the dtprobed proper.  I.e. have the DOF parser emit
>> what is in the DOF it processes and have dtprobed proper deal with that data.
>
> So you're suggesting what... that we emit the tracepoints, whatever they
> are, and then have dtprobed.c check them for uniqueness?
>
> I tried to do this but it is actually really quite difficult and makes
> dtprobed noticeably more complex for more or less no benefit.
>
> As it is, dtprobed's probe processing is basically stream-based: it
> accepts a probe followed by a stream of tracepoints from the parser
> child and inserts each tracepoint one by one. Because we can rely on
> them all to have unique addresses we can trust that they won't collide
> with each other, so we can forget all about each one after we insert it.
> If we do things the way you suggest, we have to slurp them all in and
> store them somewhere just in order to do the uniqueness checking we
> could more easily have done right here!
>
> It's much easier just to have the parser child check everything it can:
> if we're lucky (i.e. that checking never requires verification of state
> in the victim process) we can rely on doing all this verification in the
> here, which is *exactly* the sort of thing the child should be doing in
> its nice safe jail, and can just stream it out in the fully-privileged
> parent.
>
> I'm happy to split this function in two, though: it's doing two
> unrelated jobs, validation and emission. That's an unambiguous
> improvement.

OK, I was thinking about this overnight and I think that when the next
pile of development hits I can fix this. The first thing I'm doing then
is having the daemon write out a bunch of stuff for DTrace proper to
read into a state-transfer directory in the filesystem: this will
definitely include at least a parsed representation of the DOF, likely
in one file per received pile of DOF. There's no reason we can't use
this to do duplicate detection for free, by having one of the filenames
we write the DOF to be in the form dev_ino_offset, and complaining if
this dev_ino_offset triplet already exists. And once that's there, the
kernel is doing the work for us and we can drop the validation code from
the parser :)

(But this is all not happening quite yet.)