Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755989AbdDPO5u (ORCPT ); Sun, 16 Apr 2017 10:57:50 -0400 Received: from chaos.universe-factory.net ([37.72.148.22]:39654 "EHLO chaos.universe-factory.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753963AbdDPO5t (ORCPT ); Sun, 16 Apr 2017 10:57:49 -0400 Subject: Re: [PATCH net-next v2 4/6] vxlan: check valid combinations of address scopes To: Sergei Shtylyov Cc: davem@davemloft.net, jbenc@redhat.com, hannes@stressinduktion.org, pshelar@ovn.org, aduyck@mirantis.com, roopa@cumulusnetworks.com, netdev@vger.kernel.org, dev@openvswitch.org, linux-kernel@vger.kernel.org References: <49cd788f13c2cd3f6a42f34c219c9511cc1f9cec.1492187126.git.mschiffer@universe-factory.net> <0dd0812f-41d7-f4d8-2b40-0ff5b4553cf5@cogentembedded.com> From: Matthias Schiffer Message-ID: Date: Sun, 16 Apr 2017 16:57:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <0dd0812f-41d7-f4d8-2b40-0ff5b4553cf5@cogentembedded.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="EkaWXiH3ekGngIcIsdf2F77k0c7QVA7AT" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4903 Lines: 122 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EkaWXiH3ekGngIcIsdf2F77k0c7QVA7AT Content-Type: multipart/mixed; boundary="jmA7PEKdSuTJLNReH16wKg5jVo5V2OT4t"; protected-headers="v1" From: Matthias Schiffer To: Sergei Shtylyov Cc: davem@davemloft.net, jbenc@redhat.com, hannes@stressinduktion.org, pshelar@ovn.org, aduyck@mirantis.com, roopa@cumulusnetworks.com, netdev@vger.kernel.org, dev@openvswitch.org, linux-kernel@vger.kernel.org Message-ID: Subject: Re: [PATCH net-next v2 4/6] vxlan: check valid combinations of address scopes References: <49cd788f13c2cd3f6a42f34c219c9511cc1f9cec.1492187126.git.mschiffer@universe-factory.net> <0dd0812f-41d7-f4d8-2b40-0ff5b4553cf5@cogentembedded.com> In-Reply-To: <0dd0812f-41d7-f4d8-2b40-0ff5b4553cf5@cogentembedded.com> --jmA7PEKdSuTJLNReH16wKg5jVo5V2OT4t Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04/14/2017 07:27 PM, Sergei Shtylyov wrote: > On 04/14/2017 07:44 PM, Matthias Schiffer wrote: >=20 >> * Multicast addresses are never valid as local address >> * Link-local IPv6 unicast addresses may only be used as remote when th= e >> local address is link-local as well >> * Don't allow link-local IPv6 local/remote addresses without interface= >> >> We also store in the flags field if link-local addresses are used for = the >> follow-up patches that actually make VXLAN over link-local IPv6 work. >> >> Signed-off-by: Matthias Schiffer >> --- >> >> v2: was "vxlan: don't allow link-local IPv6 local/remote addresses wit= hout >> interface" before. v2 does a lot more checks and adds the >> VXLAN_F_IPV6_LINKLOCAL flag. >> >> drivers/net/vxlan.c | 35 +++++++++++++++++++++++++++++++++++ >> include/net/vxlan.h | 2 ++ >> 2 files changed, 37 insertions(+) >> >> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c >> index 07f89b037681..95a71546e8f2 100644 >> --- a/drivers/net/vxlan.c >> +++ b/drivers/net/vxlan.c >> @@ -2881,11 +2881,39 @@ static int vxlan_config_validate(struct net >> *src_net, struct vxlan_config *conf, >> if (conf->saddr.sa.sa_family !=3D conf->remote_ip.sa.sa_family) >> return -EINVAL; >> >> + if (vxlan_addr_multicast(&conf->saddr)) >> + return -EINVAL; >> + >> if (conf->saddr.sa.sa_family =3D=3D AF_INET6) { >> if (!IS_ENABLED(CONFIG_IPV6)) >> return -EPFNOSUPPORT; >> use_ipv6 =3D true; >> conf->flags |=3D VXLAN_F_IPV6; >> + >> + if (!(conf->flags & VXLAN_F_COLLECT_METADATA)) { >> + int local_type =3D >> + ipv6_addr_type(&conf->saddr.sin6.sin6_addr); >> + int remote_type =3D >> + ipv6_addr_type(&conf->remote_ip.sin6.sin6_addr); >> + >> + if (local_type & IPV6_ADDR_LINKLOCAL) { >> + if (!(remote_type & IPV6_ADDR_LINKLOCAL) && >> + (remote_type !=3D IPV6_ADDR_ANY)) { >> + pr_info("invalid combination of address scopes\n"= ); >=20 > Maybe pr_err()? Hmm, I mostly followed the style of the existing code, which uses pr_info= for such messages. Also, these messages can be triggered by userspace, as= they're diagnostics for the newlink/changelink operations; I'm not convinced that their importance justifies pr_err(). Generally, it seems unusual to me to use the kernel log for configuration= diagnostics at all; just removing the messages would be another option. Stephen also mentioned "extended netlink error reporting", but I guess th= at can be done in another patchset. Matthias --jmA7PEKdSuTJLNReH16wKg5jVo5V2OT4t-- --EkaWXiH3ekGngIcIsdf2F77k0c7QVA7AT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEZmTnvaa2aYgexS51Fu8/ZMsgHZwFAljzhmgACgkQFu8/ZMsg HZz3bxAAw+FqgalVccQ6uh4NRDy7xii174JkEAxFk0b6dlBDf88CzGJEdoWcls/O QNPwGvBmuwneYLGmTxQL1IIL4+oW+BOhYwZh2V/cp+1somSEuAQBzbrZIp3xgI9+ pYBnOuvvhriUIwQuiFp7fo9D5J1h/zhIgvinVQ+6Pp5AjJveLVFd4LbpBq8CYKIN QOqsLv1rvm5SxNrWf2X00lOhRAIDDiVk49MyOHHhPOd5DYGdPKjP2OC81ruyBmAW zSC+YL4EiD9Z7M54oZ7QEgGuWcpI2MqW3NxVsXKdjnBxHoPixRrSZPOkPGe4pTDN Ncfev0jNTb0HI7oduJaU5F8av12w0bd73QP3TWkuvF9rHRwTuCW+kQC5tRrJpYO/ 5D3kRv6gyHonNMRY21SpZvv1Ojj3dEl0fmRR+eEyUHBqycg0cxiAOczxBOrsvX72 zhMu+51URCmomO97tqA1fMhEnL5CfnKQ5u9bSAIqEJtfGrvw1/G0UalOKW/Vh5Rs f411HrapiwaWvx+qiN5Fm/Xgq5TNvIQuAPAZ59d2dFc4suSCeF6jMlUbUg1Ub9ES SgHulycQKq7fYOX9X0ToPKpUDIZl/99A+6RKoEiQ6ewnqcjOTVXMzaMgrBg5TYs1 WltkC0TG6NkLIWS1tiWS0+Wo5GFIf4EMq/vFrDRJCmXAEHFaINo= =lnZC -----END PGP SIGNATURE----- --EkaWXiH3ekGngIcIsdf2F77k0c7QVA7AT--