Re: [Xen-devel] [PATCH] xen-netfront: drop skb when skb->len > 65535

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Wed, 2013-03-06 at 17:57 +0000, Jacek Milewicz wrote:
> > 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@xxxxxxxxxx) 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?
> 

Actually I'm replying to your other email now. :-)

The root cause of your problem is a bit different than the one I
discovered, but they ended up the same error path anyway.

My kernel should be 3.9-rc or something. I use it for both Dom0 and
DomU.


Wei.

> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel