From: "Jacek Milewicz" <jacekowski@jacekowski.org>
To: 'Wei Liu' <wei.liu2@citrix.com>, 'Nick Pegg' <npegg@linode.com>
Cc: ij@2013.bluespice.org, 'Ian Campbell' <Ian.Campbell@citrix.com>,
konrad.wilk@oracle.com, xen-devel@lists.xen.org,
annie.li@oracle.com, 'Jan Beulich' <JBeulich@suse.com>
Subject: Re: [PATCH] xen-netfront: drop skb when skb->len > 65535
Date: Wed, 6 Mar 2013 18:57:59 +0100 (CET) [thread overview]
Message-ID: <023e01ce1a94$21358280$63a08780$@jacekowski.org> (raw)
In-Reply-To: <1362591119.29093.12.camel@zion.uk.xensource.com>
> On Wed, 2013-03-06 at 17:20 +0000, Nick Pegg wrote:
> > On 3/2/13 8:32 AM, Wei Liu wrote:
> > >
> > > As Nick (npegg@linode.com) pointed out in his email, he saw size
65538.
> > > I can reproduce this as well by setting vif's mtu to 100 then run
iperf.
> > > 100 was just a random number I came up with when I played with
> > > fragmentation.
> > >
> >
> > Wei: How exactly did you set the MTU on the vif and what were your
> > arguments to iperf? I tried this on a test host and was unable to
> > trigger the XSA-39 protection.
> >
>
> Sorry I didn't state this clearly. I tend to call the interface inside
VM as vif as
> well. I did this inside a VM, ifconfig eth0 mtu 100.
> Nothing fancy added to iperf command line, just `iperf -c XXX` in VM and
> `iperf -s` in host (I limited the test time with -t though).
We have recently hit the same problem (however in our case, larger NFS
transfer was enough to trigger it) and I've found that it only happens if
when MAX_SKB_FRAGS is different on domU and dom0 (as in, domU using older
kernel (without this change
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commi
t/drivers/net/xen-netback/netback.c?id=48856286b64e4b66ec62b94e504d0b29c1a
de664 )) can you confirm your domU kernel version?
next prev parent reply other threads:[~2013-03-06 17:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-01 16:31 [PATCH] xen-netfront: drop skb when skb->len > 65535 Wei Liu
2013-03-01 16:34 ` Wei Liu
2013-03-01 16:48 ` Jan Beulich
2013-03-01 17:00 ` Wei Liu
2013-03-02 2:54 ` Ian Campbell
2013-03-02 13:32 ` Wei Liu
2013-03-03 5:02 ` annie li
2013-03-06 17:20 ` Nick Pegg
2013-03-06 17:31 ` Wei Liu
2013-03-06 17:57 ` Jacek Milewicz [this message]
2013-03-06 18:04 ` Wei Liu
2013-03-03 4:13 ` annie li
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='023e01ce1a94$21358280$63a08780$@jacekowski.org' \
--to=jacekowski@jacekowski.org \
--cc=Ian.Campbell@citrix.com \
--cc=JBeulich@suse.com \
--cc=annie.li@oracle.com \
--cc=ij@2013.bluespice.org \
--cc=konrad.wilk@oracle.com \
--cc=npegg@linode.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.