netdev - Re: [Patch net-next v1 3/4] vxlan: add ipv6 support

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] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 01 Apr 2013 13:02:23 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	dlstevens@...ibm.com
Cc:	amwang@...hat.com, netdev@...r.kernel.org,
	netdev-owner@...r.kernel.org, stephen@...workplumber.org
Subject: Re: [Patch net-next v1 3/4] vxlan: add ipv6 support

From: David Stevens <dlstevens@...ibm.com>
Date: Mon, 1 Apr 2013 11:19:10 -0400

> netdev-owner@...r.kernel.org wrote on 03/31/2013 01:43:44 AM:
>  
>> +struct vxlan_ip {
>> +   union {
>> +      __be32  ip4;
>> +#if IS_ENABLED(CONFIG_IPV6)
>> +      struct in6_addr ip6;
>> +#endif
>> +   };
>> +   __be16          proto;
>> +};
>> +
> 
>         This looks suspiciously like a sockaddr. sockaddr_storage is
> much bigger than you need, but you could just make it a sockaddr_in6
> and cast it to sockaddr_in when needed, make it sockaddr_in6 and use
> V4_MAPPED addresses for v4, or make it a union of sockaddr_in and
> sockaddr_in6, or have a buffer the size of sockaddr_in6 and use it
> as a sockaddr to determine the family, then go from there.
>         I think anything along those lines is better than a new variant
> with the same functionality of sockaddr that isn't an overlay of a
> sockaddr.

People avoid using sockaddr because it gets defined both in the kernel
exported userland headers and the native libc ones with no easy
protection between the two to avoid getting a double definition error.

Once you start including kernel exported headers for things like these
network device specific interfaces, you potentially run into that issue.

Therefore I'd rather the subsystem define their own unique type both
to avoid this double definition problem and to allow easy extention
later.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html