* [PATCH ipsec-next] xfrm: state: do not acquire lock in get_mtu helpers
@ 2017-01-05 12:23 Florian Westphal
2017-01-06 11:35 ` Steffen Klassert
0 siblings, 1 reply; 2+ messages in thread
From: Florian Westphal @ 2017-01-05 12:23 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
Once flow cache gets removed the mtu initialisation happens for every skb
that gets an xfrm attached, so this lock starts to show up in perf.
It is not obvious why this lock is required -- the caller holds
reference on the state struct, type->destructor is only called from the
state gc worker (all state structs on gc list must have refcount 0).
xfrm_init_state already has been called (else private data accessed
by type->get_mtu() would not be set up).
So just remove the lock -- the race on the state (DEAD?) doesn't
matter (could change right after dropping the lock too).
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/xfrm/xfrm_state.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 64e3c82eedf6..53877fea9316 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -2000,16 +2000,13 @@ EXPORT_SYMBOL(xfrm_state_delete_tunnel);
int xfrm_state_mtu(struct xfrm_state *x, int mtu)
{
- int res;
+ const struct xfrm_type *type = READ_ONCE(x->type);
- spin_lock_bh(&x->lock);
if (x->km.state == XFRM_STATE_VALID &&
- x->type && x->type->get_mtu)
- res = x->type->get_mtu(x, mtu);
- else
- res = mtu - x->props.header_len;
- spin_unlock_bh(&x->lock);
- return res;
+ type && type->get_mtu)
+ return type->get_mtu(x, mtu);
+
+ return mtu - x->props.header_len;
}
int __xfrm_init_state(struct xfrm_state *x, bool init_replay)
--
2.7.3
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH ipsec-next] xfrm: state: do not acquire lock in get_mtu helpers
2017-01-05 12:23 [PATCH ipsec-next] xfrm: state: do not acquire lock in get_mtu helpers Florian Westphal
@ 2017-01-06 11:35 ` Steffen Klassert
0 siblings, 0 replies; 2+ messages in thread
From: Steffen Klassert @ 2017-01-06 11:35 UTC (permalink / raw)
To: Florian Westphal; +Cc: netdev
On Thu, Jan 05, 2017 at 01:23:58PM +0100, Florian Westphal wrote:
> Once flow cache gets removed the mtu initialisation happens for every skb
> that gets an xfrm attached, so this lock starts to show up in perf.
>
> It is not obvious why this lock is required -- the caller holds
> reference on the state struct, type->destructor is only called from the
> state gc worker (all state structs on gc list must have refcount 0).
>
> xfrm_init_state already has been called (else private data accessed
> by type->get_mtu() would not be set up).
>
> So just remove the lock -- the race on the state (DEAD?) doesn't
> matter (could change right after dropping the lock too).
>
> Signed-off-by: Florian Westphal <fw@strlen.de>
Applied to ipsec-next, thanks Florian!
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2017-01-06 11:35 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-01-05 12:23 [PATCH ipsec-next] xfrm: state: do not acquire lock in get_mtu helpers Florian Westphal
2017-01-06 11:35 ` Steffen Klassert
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).