It no longer serves any purpose, as evidenced by the fact that we never
take it without ifnet_sxlock.
Sponsored by: Modirum MDPay
Differential D27278
if: Remove ifnet_rwlock kp on Nov 19 2020, 1:53 PM. Authored by Tags None Referenced Files
Details
It no longer serves any purpose, as evidenced by the fact that we never Sponsored by: Modirum MDPay
Diff Detail
Event TimelineComment Actions 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. Comment Actions 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.
Comment Actions How about the lock order in subr_witness.c for IPv4 and Ipv6 multicast. Is it still required in the lock order? |