Herbert Xu wrote:

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 :)

I agree, it really looks like slight overkill.

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.

Looks good to me.

Regards
Patrick