netdev - Re: [PATCH RFC 2/2] veth: propagate bridge GSO to peer

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]

Message-ID: <aac2350d-3a10-c97f-939b-a32d5e300412@gmail.com>
Date:   Sun, 26 Nov 2017 20:13:39 -0700
From:   David Ahern <dsahern@...il.com>
To:     Stephen Hemminger <stephen@...workplumber.org>, davem@...emloft.net
Cc:     netdev@...r.kernel.org, Stephen Hemminger <sthemmin@...rosoft.com>
Subject: Re: [PATCH RFC 2/2] veth: propagate bridge GSO to peer

On 11/26/17 11:17 AM, Stephen Hemminger wrote:
> This allows veth device in containers to see the GSO maximum
> settings of the actual device being used for output.
> 
> Signed-off-by: Stephen Hemminger <stephen@...workplumber.org>
> ---
>  drivers/net/veth.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 72 insertions(+)
> 
> diff --git a/drivers/net/veth.c b/drivers/net/veth.c
> index f5438d0978ca..0c9ce156943b 100644
> --- a/drivers/net/veth.c
> +++ b/drivers/net/veth.c
> @@ -511,17 +511,89 @@ static struct rtnl_link_ops veth_link_ops = {
>  	.get_link_net	= veth_get_link_net,
>  };
>  
> +/* When veth device is added to a bridge or other master device
> + * then reflect the GSO max values from the upper device
> + * to the other end of veth pair.
> + */
> +static void veth_change_upper(struct net_device *dev,
> +		      const struct netdev_notifier_changeupper_info *info)
> +{
> +	struct net_device *upper = info->upper_dev;
> +	struct net_device *peer;
> +	struct veth_priv *priv;
> +
> +	if (dev->netdev_ops != &veth_netdev_ops)
> +		return;
> +
> +	priv = netdev_priv(dev);
> +	peer = rtnl_dereference(priv->peer);
> +	if (!peer)
> +		return;
> +
> +	if (upper) {
> +		peer->gso_max_segs = upper->gso_max_segs;
> +		peer->gso_max_size = upper->gso_max_size;
> +	} else {
> +		peer->gso_max_segs = GSO_MAX_SEGS;
> +		peer->gso_max_size = GSO_MAX_SIZE;
> +	}

veth devices can be added to a VRF instead of a bridge, and I do not
believe the gso propagation works for L3 master devices.

>From a quick grep, team devices do not appear to handle gso changes either.