From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shannon Nelson Subject: Re: [PATCH] macvlan: verify MTU before lowerdev xmit Date: Tue, 14 Nov 2017 11:06:09 -0800 Message-ID: <5745f546-25d1-2778-1894-159fc026cadf@oracle.com> References: <20171114103251.5495-1-dja@axtens.net> <88bbd758-4f19-381d-2479-d3e52a1259cd@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit To: Daniel Axtens , netdev@vger.kernel.org Return-path: Received: from aserp1040.oracle.com ([141.146.126.69]:27091 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753115AbdKNTGN (ORCPT ); Tue, 14 Nov 2017 14:06:13 -0500 In-Reply-To: <88bbd758-4f19-381d-2479-d3e52a1259cd@oracle.com> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 11/14/2017 9:03 AM, Shannon Nelson wrote: > On 11/14/2017 2:32 AM, Daniel Axtens wrote: >> If a macvlan device which is not in bridge mode receives a packet, >> it is sent straight to the lowerdev without checking against the >> device's MTU. This also happens for multicast traffic. >> >> Add an is_skb_forwardable() check against the lowerdev before >> sending the packet out through it. I think this is the simplest >> and best way to do it, and is consistent with the use of >> dev_forward_skb() in the bridge path. >> >> This is easy to replicate: >>   - create a VM with a macvtap connection in private mode >>   - set the lowerdev MTU to something low in the host (e.g. 1480) >>   - do not set the MTU lower in the guest (e.g. keep at 1500) >>   - netperf to a different host with the same high MTU >>   - observe that currently, the driver will forward too-big packets >>   - observe that with this patch the packets are dropped >> >> Cc: Shannon Nelson >> Signed-off-by: Daniel Axtens >> >> --- >> >> After hearing Shannon's lightning talk on macvlan at netdev I >> figured I'd strike while the iron is hot and get this out of my >> patch queue where it has been languishing. >> --- >>   drivers/net/macvlan.c | 4 ++++ >>   1 file changed, 4 insertions(+) >> >> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c >> index a178c5efd33e..8adcad6798c5 100644 >> --- a/drivers/net/macvlan.c >> +++ b/drivers/net/macvlan.c >> @@ -534,6 +534,10 @@ static int macvlan_queue_xmit(struct sk_buff >> *skb, struct net_device *dev) >>       } >>   xmit_world: >> +    /* verify MTU */ >> +    if (!is_skb_forwardable(vlan->lowerdev, skb)) >> +        return NET_XMIT_DROP; >> + > > Good catch.  I remember your comment on this last week, but hadn't had a > chance to look it up yet. > > As for the other paths, I see that the call to dev_forward_skb() already > has this protection in it, but does the call to dev_queue_xmit_accel() > in macvlan_start_xmit() need similar protection? > Now that I think about this a little more, why is this not already getting handled by the NETDEV_CHANGEMTU notifier? In what case are you running into this, and why is it not triggering the notifier? sln > > >>       skb->dev = vlan->lowerdev; >>       return dev_queue_xmit(skb); >>   } >>