Re: [PATCH net-next] xfrm: remove useless hash_resize_mutex locks

[Ying Xue <ying.xue@windriver.com>]

On 08/29/2014 03:42 PM, Christophe Gouault wrote:
> 2014-08-29 8:11 GMT+02:00 Steffen Klassert <steffen.klassert@secunet.com>:
>> Ccing Christophe Gouault as he currently reworks the policy
>> hashing.
> 
> Thanks.
> 
>> 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.
> 
>> I tend to apply Christophes patchset after some further testing,
>> so we can't remove this mutex now.
> 
>>>  /* 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
> 
>