This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: what a probe-induced kernel fault looks like
hunt wrote:
> Unfortunately due to the complexity of setting up communications and
> exchanging parameters, it is not practical to run begin probes at
> module loading time.
Could you elaborate how much of this is essential two-way exchange?
That is, could the module-load-time code set up the transmit-side
buffers etc., and post a message to stpd describing them, but not
actually wait for stpd to check in?
> So how is this a problem?
It's not a big problem, it was just unexpected. In particular, it
spells out that with the status quo, these probe startups/shutdowns
can occur at odd times. In particular, there may not be a firm
guarantee that startup or shutdown logic will only be invoked *once*.
> > [...] Martin, how does shutdown happen in your model?
>
> Depends on how it is initiated. In the normal case, stpd sends an exit
> message to the module. The module runs the exit probes and flushes the
> transport. Then stpd rmmods the module.
>
> If stpd dies for some reason, You just rmmod the module. It attempts to
> send an informational message to stpd that it is exiting, then goes
> ahead and unloads.
It seems like the second mechanism is all that's really needed: to
trigger all kernel-side cleanup by an attempted module unload. Then
whether it's stpd or a user performing the rmmod, it'll still work the
same way.
> [...] And that would work fine except for all the complexity
> involving setting up either netlink or relayfs communications, which
> is why we have stpd. Because something needs to manage the
> kernel-to-userspace communications.
All this complexity is another reason I've been attracted to simple
handshake- and intermediary-free procfs all this time.
- FChE