Hi Patrick:
On Mon, Mar 28, 2005 at 10:10:54PM +0200, Patrick McHardy wrote:
>
> I haven't though of a way to avoid this yet. It would be nice though
> if we could keep the rule that xfrm_policy_lock and policy->lock nest
> with x->lock.
Thanks for catching this.
The locking in xfrm_state/xfrm_policy has always struck me as being
an overkill. A lot of the locks should be replaced by rules that
ensure the validity of most operations while a ref count is held.
Now I have an excuse to do just that :)
For 2.6.12 let's go for a simpler fix that breaks the dead lock.
__xfrm_state_delete does not need to flush the bundles immediately.
In fact, it is more efficient if we delay the flush to the GC worker
since the flush is not dependent on any particular xfrm state. By
delaying it we can do one single flush even when you're deleteing
the entire xfrm state list.
Signed-off-by: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
p
Description: Text document
|