netdev - Re: [PATCH ipsec-next] xfrm: state: do not acquire lock in get

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: <20170106113529.GC3541@gauss.secunet.com>
Date:   Fri, 6 Jan 2017 12:35:29 +0100
From:   Steffen Klassert <steffen.klassert@...unet.com>
To:     Florian Westphal <fw@...len.de>
CC:     <netdev@...r.kernel.org>
Subject: Re: [PATCH ipsec-next] xfrm: state: do not acquire lock in get_mtu
 helpers

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@...len.de>

Applied to ipsec-next, thanks Florian!