[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCHv1 net-next] xen-netback: remove unconditional pull_skb_tail in guest Tx path



On Tue, 2014-11-04 at 16:17 -0500, David Miller wrote:
> From: Zoltan Kiss <zoltan.kiss@xxxxxxxxxx>
> Date: Mon, 03 Nov 2014 18:23:03 +0000
> 
> > 
> > 
> > On 03/11/14 17:46, David Vrabel wrote:
> >> On 03/11/14 17:39, Ian Campbell wrote:
> >>> On Mon, 2014-11-03 at 17:23 +0000, David Vrabel wrote:
> >>>> From: Malcolm Crossley <malcolm.crossley@xxxxxxxxxx>
> >>>>
> >>>> Unconditionally pulling 128 bytes into the linear buffer is not
> >>>> required. Netback has already grant copied up-to 128 bytes from the
> >>>> first slot of a packet into the linear buffer. The first slot normally
> >>>> contain all the IPv4/IPv6 and TCP/UDP headers.
> >>>
> >>> What about when it doesn't? It sounds as if we now won't pull up,
> >>> which
> >>> would be bad.
> >>
> >> The network stack will always pull any headers it needs to inspect
> >> (the
> >> frag may be a userspace page which has the same security issues as a
> >> frag with a foreign page).
> > I wouldn't bet my life on this, but indeed it should always happen.
> 
> I would bet my life on it.
> 
> Every protocol demux starts with pskb_may_pull() to pull frag data
> into the linear area, if necessary, before looking at headers.

Then I stand corrected, I was sure this wasn't the case (but my
information could well be a decade out of date...).

Is this also true for things which hit the iptables paths? I suppose
they must necessarily have already been through the protocol demux stage
before iptables would even be able to interpret them as e.g. an IP
packet.

Ian.


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.