Mike Belopuhov wrote: > The big problem with the non-recursive netlock is that to fix > recursions in many cases we have to release the netlock in one > of the callers up the chain which makes the interim code run > without any protection and we don't have a way of assessing > the situation short of code inspection which is fallible. > > Sprinkling NET_ASSERT_LOCKED() everywhere is possible, however > we still end up with NET_LOCK/UNLOCK chains in the code that > was previously running uninterrupted. > > Does this outweigh the desire not to use recursive rwlocks > anywhere else?
I can see the danger of breaking atomic sections into two parts. However, having these long critical sections increases the chance of introducing lock ordering bugs. Code A calls code B calls code C. A and C need the netlock, but code B requires some other lock?
