netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Chan <michael.chan@broadcom.com>
To: Daniel Axtens <dja@axtens.net>
Cc: Netdev <netdev@vger.kernel.org>, David Miller <davem@davemloft.net>
Subject: Re: Stack sends oversize UDP packet to the driver
Date: Mon, 21 Jan 2019 16:59:15 -0800	[thread overview]
Message-ID: <CACKFLimE8wR-fjLCwqk7bWWgCPfRGDmXxxWFpf0-_uW3Y3Lrew@mail.gmail.com> (raw)
In-Reply-To: <874la1r0io.fsf@linkitivity.dja.id.au>

On Mon, Jan 21, 2019 at 4:36 PM Daniel Axtens <dja@axtens.net> wrote:

> I hit a similar sounding issue on a bnx2x - see commit
> 8914a595110a6eca69a5e275b323f5d09e18f4f9
>
> In that case, a GSO packet with gso_size too large for the firmware was
> coming to the bnx2x driver from an ibmveth device via Open vSwitch. I
> also toyed with a fix in the stack and ended up fixing just the driver.

Hi Daniel, yes I remember the issue that you reported at that time.
The current issue is similar but for non-TSO UDP packets.

>
> I was hoping to get a generic fix in to the stack afterwards, but didn't
> get anything finished. Looking back at old branches, it looks like I
> considered adding MTU validation to validate_xmit_skb,

MTU validation in validate_xmit_skb() would definitely prevent the
current reported issue.  Perhaps we can add a WARN() when an invalid
length is detected so that the underlying issue will be reported and
fixed.  The current issue is that somehow the dst of the SKB gets
changed to "lo" and fragmentation is not done for the proper output
device.  Thanks.

  reply	other threads:[~2019-01-22  0:59 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-20 22:26 Stack sends oversize UDP packet to the driver Michael Chan
2019-01-22  0:36 ` Daniel Axtens
2019-01-22  0:59   ` Michael Chan [this message]
2019-01-22 18:28     ` Mahesh Bandewar (महेश बंडेवार)
2019-01-22 20:09       ` David Miller
2019-01-30  9:07       ` Michael Chan
2019-01-31  1:00         ` Mahesh Bandewar (महेश बंडेवार)
2019-02-05 19:35           ` Michael Chan
2019-02-07  4:51             ` Mahesh Bandewar (महेश बंडेवार)
2019-02-08 20:26               ` Mahesh Bandewar (महेश बंडेवार)
2019-02-12  8:55                 ` Michael Chan
     [not found] ` <CAF2d9jgskHTb-nmbVo9A2CQhh9T3OnH_vbfGcMBii13oq1teCw@mail.gmail.com>
2019-01-22  0:45   ` Michael Chan

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=CACKFLimE8wR-fjLCwqk7bWWgCPfRGDmXxxWFpf0-_uW3Y3Lrew@mail.gmail.com \
    --to=michael.chan@broadcom.com \
    --cc=davem@davemloft.net \
    --cc=dja@axtens.net \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).