It no longer serves any purpose, as evidenced by the fact that we never
take it without ifnet_sxlock.
Sponsored by: Modirum MDPay
kp on Thu, Nov 19, 1:53 PM.Authored by
I'd like to be able to MFC D27279. I didn't expect it to rely on this patch, and I suspect this one can't be safely merged to stable/12 because it might break kernel ABI compatibility.
I wonder if we should MFC only the IFNET_WLOCK, IFNET_WUNLOCK and IFNET_WLOCK_ASSERT changes, leaving the ifnet_rwlock struct around for any out-of-tree user that may want to take it.
Unfortunately I'm not sure that you can MFC this, but hopefully someone else will chime in -- it's perhaps unlikely, but if we call into any out-of-tree module that wants to IFNET_WLOCK_ASSERT(), then we must have grabbed it.
That said, I'm not immediately seeing a path into if_vmove() from an external driver where it could have possibly been holding the wlock. Both callers that aren't vnet_if_return will take the allprison_lock immediately. You could probably get away with MFC'ing the other one and just dropping the rwlock if it's held around if_reassign() then picking it back up after for stable/12. The lock order here seems to be in your favor.