altq: Fix panics on rmc_restart()

[kp]

Summary

rmc_restart() is called from a timer, but can trigger traffic. This
means the curvnet context will not be set.
Use the vnet associated with the interface we're currently processing to
set it. We also have to enter net_epoch here, for the same reason.

MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")

[mjg]

I think it would future-proof it to assert curvnet is not set and only set it after taking the lock.

[kp]

In D31642#713694, @mjg wrote:

I think it would future-proof it to assert curvnet is not set and only set it after taking the lock.

Agreed on the second part (setting it after taking the lock), but I'm not sure how it future proofs us to assert curvnet isn't set yet. It might prevent mistakes if rmc_restart() is ever pulled out of the callback and moved into the regular data path, but that seems unlikely. It also wouldn't break anything.

There's also no precedent that I can see for anything like 'MPASS(curvnet == NULL)'.

[kp]

• move CURVNET_SET inside the lock

[mjg]

the assumption in the patch is that vnet is not set, but i'm not going to insist on the assert

[kp]

In D31642#713750, @mjg wrote:

the assumption in the patch is that vnet is not set, but i'm not going to insist on the assert

It's true that that's assumed (in that I believe that to be the cause of a panic on pfsense), but it doesn't actually matter. We can (and do, for example in if_epair.c) set a vnet while in the context of a different vnet. CURVNET_RESTORE() will then return us to the original vnet.