From: Daniel Axtens <dja-Yfaxwxk/+vWsTnJN9+BGXg@public•gmane.org>
To: Pravin Shelar <pshelar-LZ6Gd1LRuIk@public•gmane.org>
Cc: ovs dev <dev-yBygre7rU0TnMu66kgdUjQ@public•gmane.org>,
Linux Kernel Network Developers
<netdev-u79uwXL29TY76Z2rM5mHXA@public•gmane.org>,
Manish.Chopra-YGCgFSpz5w/QT0dZR+AlfA@public•gmane.org
Subject: Re: [PATCH 0/3] Check gso_size of packets when forwarding
Date: Fri, 19 Jan 2018 12:28:06 +1100 [thread overview]
Message-ID: <87a7xa63ix.fsf@linkitivity.dja.id.au> (raw)
In-Reply-To: <CAOrHB_CyTg4iZ38T0WeNkC6ng3iznXKk+0Qr-rA2rs7ivSSf+w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Pravin Shelar <pshelar-LZ6Gd1LRuIk@public•gmane.org> writes:
> On Thu, Jan 18, 2018 at 5:08 AM, Daniel Axtens <dja-Yfaxwxk/+vWsTnJN9+BGXg@public•gmane.org> wrote:
>> Pravin Shelar <pshelar-LZ6Gd1LRuIk@public•gmane.org> writes:
>>
>>> On Mon, Jan 15, 2018 at 6:09 PM, Daniel Axtens <dja-Yfaxwxk/+vWsTnJN9+BGXg@public•gmane.org> wrote:
>>>> When regular packets are forwarded, we validate their size against the
>>>> MTU of the destination device. However, when GSO packets are
>>>> forwarded, we do not validate their size against the MTU. We
>>>> implicitly assume that when they are segmented, the resultant packets
>>>> will be correctly sized.
>>>>
>>>> This is not always the case.
>>>>
>>>> We observed a case where a packet received on an ibmveth device had a
>>>> GSO size of around 10kB. This was forwarded by Open vSwitch to a bnx2x
>>>> device, where it caused a firmware assert. This is described in detail
>>>> at [0] and was the genesis of this series. Rather than fixing it in
>>>> the driver, this series fixes the forwarding path.
>>>>
>>> Are there any other possible forwarding path in networking stack? TC
>>> is one subsystem that could forward such a packet to the bnx2x device,
>>> how is that handled ?
>>
>> So far I have only looked at bridges, openvswitch and macvlan. In
>> general, if the code uses dev_forward_skb() it should automatically be
>> fine as that invokes is_skb_forwardable(), which we patch.
>>
> But there are other ways to forward packets, e.g tc-mirred or bpf
> redirect. We need to handle all these cases rather than fixing one at
> a time. As Jason suggested netif_needs_gso() looks like good function
> to validate if a device is capable of handling given GSO packet.
I am not entirely sure this is a better solution.
The biggest reason I am uncomfortable with this is that if
netif_needs_gso() returns true, the skb will be segmented. The segment
sizes will be based on gso_size. Since gso_size is greater than the MTU,
the resulting segments will themselves be over-MTU. Those over-MTU
segments will then be passed to the network card. I think we should not
be creating over-MTU segments; we should instead be dropping the packet
and logging.
I do take the point that you and Jason are making: a more generic
fix would be good. I'm just not sure where to put it.
Regards,
Daniel
next prev parent reply other threads:[~2018-01-19 1:28 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-16 2:09 [PATCH 0/3] Check gso_size of packets when forwarding Daniel Axtens
2018-01-16 2:09 ` [PATCH 1/3] net: move skb_gso_mac_seglen to skbuff.h Daniel Axtens
2018-01-16 2:09 ` [PATCH 2/3] net: is_skb_forwardable: validate length of GSO packet segments Daniel Axtens
2018-01-18 23:47 ` Marcelo Ricardo Leitner
2018-01-16 2:09 ` [PATCH 3/3] openvswitch: drop GSO packets that are too large Daniel Axtens
[not found] ` <20180116020920.20232-1-dja-Yfaxwxk/+vWsTnJN9+BGXg@public.gmane.org>
2018-01-17 20:20 ` [PATCH 0/3] Check gso_size of packets when forwarding David Miller
2018-01-18 8:28 ` Pravin Shelar
2018-01-18 9:49 ` Jason Wang
2018-01-18 13:17 ` Daniel Axtens
[not found] ` <87fu735ms5.fsf-hbezLPf06/Fz8PszVLmxdVaj5H9X9Tb+@public.gmane.org>
2018-01-18 14:05 ` Daniel Axtens
[not found] ` <CAOrHB_AAMzYCLsFe6+3ODSqYUe79vYtP5jSxK=GDj5rKeQXyDA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-01-18 13:08 ` Daniel Axtens
2018-01-18 21:57 ` Pravin Shelar
[not found] ` <CAOrHB_CyTg4iZ38T0WeNkC6ng3iznXKk+0Qr-rA2rs7ivSSf+w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-01-19 1:28 ` Daniel Axtens [this message]
[not found] ` <87a7xa63ix.fsf-hbezLPf06/Fz8PszVLmxdVaj5H9X9Tb+@public.gmane.org>
2018-01-19 6:11 ` Daniel Axtens
2018-01-19 7:08 ` Pravin Shelar
2018-01-19 11:58 ` Daniel Axtens
[not found] ` <871sim5abx.fsf-hbezLPf06/Fz8PszVLmxdVaj5H9X9Tb+@public.gmane.org>
2018-01-19 21:54 ` Pravin Shelar
2018-01-22 20:14 ` David Miller
2018-01-22 21:31 ` Stephen Hemminger
2018-01-23 5:47 ` Pravin Shelar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a7xa63ix.fsf@linkitivity.dja.id.au \
--to=dja-yfaxwxk/+vwstnjn9+bgxg@public$(echo .)gmane.org \
--cc=Manish.Chopra-YGCgFSpz5w/QT0dZR+AlfA@public$(echo .)gmane.org \
--cc=dev-yBygre7rU0TnMu66kgdUjQ@public$(echo .)gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public$(echo .)gmane.org \
--cc=pshelar-LZ6Gd1LRuIk@public$(echo .)gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox