[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |