> -----Original Message----- > From: Sowmini Varadhan [mailto:sowmini.varad...@oracle.com] > Sent: 19 January 2017 11:14 > To: Paul Durrant <paul.durr...@citrix.com> > Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>; Wei Liu > <wei.l...@citrix.com>; netdev@vger.kernel.org; xen- > de...@lists.xenproject.org > Subject: Re: [Xen-devel] xennet_start_xmit assumptions > > On (01/19/17 09:36), Paul Durrant wrote: > > > > Hi Sowmini, > > > > Sounds like a straightforward bug to me... netfront should be able > > to handle an empty skb and clearly, if it's relying on skb_headlen() > > being non-zero, that's not the case. > > > > Paul > > I see. Seems like there are 2 things broken here: recovering > from skb->len = 0, and recovering from the more complex > case of (skb->len > 0 && skb_headlen(skb) == 0) > > Do you folks want to take a shot at fixing this, > since you know the code better? If you are interested, > I can share my test program to help you reproduce the > simpler skb->len == 0 case, but it's the fully non-linear > skbs that may be more interesting to reproduce/fix.
Sowmini, Yeah, it would be useful to verify any change fixes the particular issue you're seeing so please share the program. For the non-empty non-linear case I'd hope that catching this and doing a pull of some sensible amount of header (which might coincide with the least amount that netback expects to see in the first frag) would be enough. I can take a shot at a patch for this in the next few days; I'll add your 'Reported-by' so you should get cc-ed. Cheers, Paul > > I'll probably work on fixing packet_snd to return -EINVAL > or similar when the len is zero this week. > > --Sowmini
