Thread (4 messages) 4 messages, 3 authors, 2014-08-29

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

From: Christophe Gouault <hidden>
Date: 2014-08-29 07:42:11

2014-08-29 8:11 GMT+02:00 Steffen Klassert [off-list ref]:
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.
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.

Best Regards,
Christophe
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help