On 05/01/17(Thu) 16:09, 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.
No, that's not to fix the recursions. That's to know where they are. Nobody came up with a solution for the recursions so far. I doubt there's a common solution to all the code paths. That's something I'd like to think about in a second step. The current problem is still unknown, we just know that using chrome hang the machine with either flavor of the NET_LOCK(). ajacoutot@ reported additional information, he cannot reproduce the hang when he uses my scheduler diff with a single process queue. > 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. It is possible but I don't think it helps. Because not everything need to be protected by the NET_LOCK(). > Does this outweigh the desire not to use recursive rwlocks > anywhere else? It's, in my opinion, too soon to answer this question. Let's wait until recursions are the only problems left.
