Thread (95 messages) 95 messages, 4 authors, 2008-10-01

Re: xfrm_state locking regression...

From: David Miller <davem@davemloft.net>
Date: 2008-09-03 06:10:42

From: Timo Teräs <redacted>
Date: Wed, 03 Sep 2008 08:07:33 +0300
Also alternatively the xfrm_state_all could be protected by a
different lock than xfrm_state_lock.
Before your changes the state destroy was protected by no central
locks at all.  There was no need.

Since the reference goes to zero, there are no external references
to this object.

But this is exactly what you added, an external references that is
not reference counted.

This is yet another reason all of Herbert's objections to your
location for ->all list add and removal are sound.

So we now have to take a centralized lock twice when getting rid of an
XFRM state object.  Which is potentially a scalability performance
regression.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help