netdev - Re: [PATCH v1 1/1] veth: Do not drop packets larger then the mtu set on the receiving side

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

Date:   Thu, 10 Jan 2019 15:21:19 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Fredrik Gustavsson <gustfred@...il.com>
Cc:     netdev@...r.kernel.org, davem@...emloft.net,
        makita.toshiaki@....ntt.co.jp, daniel@...earbox.net
Subject: Re: [PATCH v1 1/1] veth: Do not drop packets larger then the mtu set
 on the receiving side

On Thu, Jan 10, 2019 at 02:26:55PM +0100, Fredrik Gustavsson wrote:
> commit affede4a779420bd8510ab937251a3796d3228df
> Author: Fredrik Gustavsson <gustfred@...il.com>
> Date:   Tue Jan 8 11:21:39 2019 +0100
> 
> veth: Do not drop packets larger then the mtu set on the receiving side
> 
> Currently veth drops all packets larger then the mtu set on the receiving
> end of the pair. This is inconsistent with most hardware ethernet drivers
> that happily receives packets up the the ethernet MTU independent of the
> configured MTU.

I agree with your argument, but i wonder if there could be a better
implementation.

____dev_forward_skb() is on the hot path, so your additional check is
going to slow down packet forwarding for everybody, not just veth.
is_skb_forwardable() also does some additional checks which you are
now skipping. Is that O.K?

Since we are talking about a veth pair here, you have access to both
ends of the link. Maybe consider if the mtu is changed on one end, you
also change it on the other?

Lets see what others think of that.

     Andrew