rtnl.listener randomly dies (reopen #184)

[f00b4r0]

This is a reopen of #184, unfortunately it still affects current ucode and this causes random bugs in uspot.

The trigger conditions appear to be more complex than before (so the fix proposed in #185 did improve the situation), but it still occurs.

I'll try to figure out a reproducible test case, but is there any way to get some feedback inside the ucode script that the setup listener has died?

[f00b4r0]

@jow- my understanding of 6f71a35 is that it actually prevents detecting a failure of nl_recvmsgs_default() which was previously detectable: if I'm not mistaken, that call may fail (due to e.g. ENOBUFS), and if my understanding of the code flow in libnl's nl.c is correct, when that happens the NL_CB_VALID callback is not called.

Thus at that point the rtnl listener stops working and yet set_error() was never called (contrary to prior situation), so the failure is now undectable? Or am I missing something?

It's also unclear to me how the change achieves the intent stated in the commit message, since setting errno in cb_listener_event() doesn't change the code flow on failure anyway?

[jow-]

The change you quoted makes uc_nl_listener_cb() break out of its while(true) loop when some ucode listener callback raised an exception. It is unrelated to nl_recvmsgs_default() error detection

[f00b4r0]

Got it. I understand you want to avoid clobbering the error message set in the callback handler but unless I'm mistaken, the second hunk in that change now makes it impossible to detect failures of nl_recvmsgs_default() unrelated to callback exceptions?

[jow-]

Yes, I see what you mean. Need to figure out the best way forward

[f00b4r0]

I don't know if this helps / is even feasible, but in an ideal world we could set the listener in a try/catch block and nl_recvmsgs failures would raise an exception which could be caught to e.g. flush and restart. Just thinking out loud here.
Polling for the global error() symbol - which is what I had in mind as a workaround - is far from being foolproof/efficient.