Re: what a probe-induced kernel fault looks like

[fche at redhat dot com (Frank Ch. Eigler)]

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