netdev - Re: [PATCH ipsec-next] xfrm: Remove xfrmi interface ID from flowi

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20180723054517.mddmq2powuem3zdg@gauss3.secunet.de>
Date:   Mon, 23 Jul 2018 07:45:17 +0200
From:   Steffen Klassert <steffen.klassert@...unet.com>
To:     Benedict Wong <benedictwong@...gle.com>
CC:     <netdev@...r.kernel.org>, <nharold@...gle.com>,
        <lorenzo@...gle.com>
Subject: Re: [PATCH ipsec-next] xfrm: Remove xfrmi interface ID from flowi

On Thu, Jul 19, 2018 at 10:50:44AM -0700, Benedict Wong wrote:
> In order to remove performance impact of having the extra u32 in every
> single flowi, this change removes the flowi_xfrm struct, prefering to
> take the if_id as a method parameter where needed.
> 
> In the inbound direction, if_id is only needed during the
> __xfrm_check_policy() function, and the if_id can be determined at that
> point based on the skb. As such, xfrmi_decode_session() is only called
> with the skb in __xfrm_check_policy().
> 
> In the outbound direction, the only place where if_id is needed is the
> xfrm_lookup() call in xfrmi_xmit2(). With this change, the if_id is
> directly passed into the xfrm_lookup_with_ifid() call. All existing
> callers can still call xfrm_lookup(), which uses a default if_id of 0.
> 
> This change does not change any behavior of XFRMIs except for improving
> overall system performance via flowi size reduction.
> 
> This change has been tested against the Android Kernel Networking Tests:
> 
> https://android.googlesource.com/kernel/tests/+/master/net/test
> 
> Signed-off-by: Benedict Wong <benedictwong@...gle.com>

Nice improvement. Applied to ipsec-next, thanks a lot!