From: Lorenzo Colitti <lorenzo@google.com>
To: netdev@vger.kernel.org
Cc: steffen.klassert@secunet.com, subashab@codeaurora.org,
nharold@google.com, davem@davemloft.net,
Lorenzo Colitti <lorenzo@google.com>
Subject: [PATCH ipsec-next 1/7] net: xfrm: Don't check for TUNNEL_KEY when hashing VTI tunnels.
Date: Thu, 21 Dec 2017 02:06:01 +0900 [thread overview]
Message-ID: <20171220170607.41516-2-lorenzo@google.com> (raw)
In-Reply-To: <20171220170607.41516-1-lorenzo@google.com>
Currently, ip_bucket sets the lookup i_key to 0 if the tunnel's
i_flags have VTI_ISVTI flag set but not TUNNEL_KEY. However, it
can can never happen that TUNNEL_KEY is set if VTI_ISVTI is also
set (see below). Therefore, just drop the check for TUNNEL_KEY
and only set i_key to 0 on VTI_ISVTI.
This will allow the VTI code to set TUNNEL_KEY on certain
tunnels in a future change.
None of the callers of ip_bucket pass in TUNNEL_KEY | VTI_ISVTI.
The call graph is as follows:
- ip_tunnel_add
- ip_tunnel_create
- ip_tunnel_ioctl
- ipgre_tunnel_ioctl: can set TUNNEL_KEY but not VTI_ISVTI
- ipip_tunnel_ioctl: hardcodes i_flags to 0
- vti_tunnel_ioctl: hardcodes i_flags to VTI_ISVTI
- ip_tunnel_update: doesn't touch i_flags
- ip_tunnel_init_net: memsets flags to 0
- ip_tunnel_newlink
- ipgre_newlink
- ipgre_netlink_parms: can set TUNNEL_KEY but not VTI_ISVTI
- vti_newlink: hardcodes i_flags to VTI_ISVTI
- ip_tunnel_changelink: doesn't set flags
- ip_tunnel_find
- ip_tunnel_ioctl (see above)
- ip_tunnel_newlink (see above)
- ip_tunnel_changelink (see above)
VTI_ISVTI has the same value as TUNNEL_DONT_FRAGMENT, but that
is never set into tunnel parameters.
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
---
net/ipv4/ip_tunnel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index 5ddb1cb52b..539c8f22c4 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -198,7 +198,7 @@ static struct hlist_head *ip_bucket(struct ip_tunnel_net *itn,
else
remote = 0;
- if (!(parms->i_flags & TUNNEL_KEY) && (parms->i_flags & VTI_ISVTI))
+ if (parms->i_flags & VTI_ISVTI)
i_key = 0;
h = ip_tunnel_hash(i_key, remote);
--
2.15.1.620.gb9897f4670-goog
next prev parent reply other threads:[~2017-12-20 17:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-20 17:06 [PATCH ipsec-next 0/7]: Support multiple VTIs with the same src+dst pair Lorenzo Colitti
2017-12-20 17:06 ` Lorenzo Colitti [this message]
2017-12-20 17:06 ` [PATCH ipsec-next 2/7] net: ipv4: Add new flags to tunnel lookup Lorenzo Colitti
2017-12-20 17:06 ` [PATCH ipsec-next 3/7] net: xfrm: Add an xfrm lookup that ignores the mark Lorenzo Colitti
2017-12-20 17:06 ` [PATCH ipsec-next 4/7] net: xfrm: Find VTI interfaces from xfrm_input Lorenzo Colitti
2017-12-20 17:06 ` [PATCH ipsec-next 5/7] net: xfrm: Deliver packets to keyed VTI tunnels Lorenzo Colitti
2017-12-20 17:06 ` [PATCH ipsec-next 6/7] net: xfrm: Allow userspace to configure " Lorenzo Colitti
2017-12-20 17:06 ` [PATCH ipsec-next 7/7] net: xfrm: Don't pass tunnel objects to xfrm6_rcv_spi Lorenzo Colitti
2018-01-03 12:10 ` [PATCH ipsec-next 0/7]: Support multiple VTIs with the same src+dst pair Steffen Klassert
2018-01-04 16:41 ` Lorenzo Colitti
2018-01-05 7:16 ` Steffen Klassert
2018-01-05 14:32 ` [ipsec-next,0/7] : " Antony Antony
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171220170607.41516-2-lorenzo@google.com \
--to=lorenzo@google.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=nharold@google.com \
--cc=steffen.klassert@secunet.com \
--cc=subashab@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.