On 08/29/2014 03:42 PM, Christophe Gouault wrote:

2014-08-29 8:11 GMT+02:00 Steffen Klassert [off-list ref]:

quoted

Ccing Christophe Gouault as he currently reworks the policy
hashing.

Thanks.

quoted

One of Christophes patches will use this mutex in a worker of
another work queue, so this mutex is really needed if I apply
his patchset. See http://patchwork.ozlabs.org/patch/383486/

Yes right, the mutex is actually needed after this patch.

quoted

I tend to apply Christophes patchset after some further testing,
so we can't remove this mutex now.

quoted

quoted

 /* Generate new index... KAME seems to generate them ordered by cost

diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 0ab5413..de971b6 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c

@@ -97,8 +97,6 @@ static unsigned long xfrm_hash_new_size(unsigned int state_hmask)
      return ((state_hmask + 1) << 1) * sizeof(struct hlist_head);
 }

-static DEFINE_MUTEX(hash_resize_mutex);
-

This one is still redundant, so we can remove it if there
are no plans to do something similar to the xfrm_state
hashing soon. Christophe?

I have no plans to work on the xfrm_state hashing soon. I think this
mutex can be removed.

OK, I will resubmit the patch again to just remove the hash_resize_mutex
lock guarding xfrm_state.

Thanks,
Ying

Best Regards,
Christophe