netdev - Re: [PATCH net-next] xfrm: remove useless hash_resize

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <54003202.1060606@windriver.com>
Date:	Fri, 29 Aug 2014 15:55:46 +0800
From:	Ying Xue <ying.xue@...driver.com>
To:	Christophe Gouault <christophe.gouault@...nd.com>,
	Steffen Klassert <steffen.klassert@...unet.com>
CC:	"David S. Miller" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] xfrm: remove useless hash_resize_mutex locks

On 08/29/2014 03:42 PM, Christophe Gouault wrote:
> 2014-08-29 8:11 GMT+02:00 Steffen Klassert <steffen.klassert@...unet.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
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html