[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090113.232710.55011568.davem@davemloft.net>
Date: Tue, 13 Jan 2009 23:27:10 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: herbert@...dor.apana.org.au
Cc: zbr@...emap.net, dada1@...mosbay.com, w@....eu, ben@...s.com,
jarkao2@...il.com, mingo@...e.hu, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, jens.axboe@...cle.com
Subject: Re: [PATCH] tcp: splice as many packets as possible at once
From: Herbert Xu <herbert@...dor.apana.org.au>
Date: Wed, 14 Jan 2009 14:51:24 +1100
> Unfortunately this won't work, not even for network destinations.
>
> The reason is that this gets called as soon as the destination's
> splice hook returns, for networking that means when sendpage returns.
>
> So by that time we'll still be left with just a page reference
> on a page where the slab memory may already have been freed.
>
> To make this work we need to get the destination's splice hooks
> to acquire this reference.
So while trying to figure out a sane way to fix this, I found
another bug:
/*
* map the linear part
*/
if (__splice_segment(virt_to_page(skb->data),
(unsigned long) skb->data & (PAGE_SIZE - 1),
skb_headlen(skb),
offset, len, skb, spd))
return 1;
This will explode if the SLAB cache for skb->head is using compound
(ie. order > 0) pages.
For example, if this is an order-1 page being used for the skb->head
data (which would be true on most systems for jumbo MTU frames being
received into a linear SKB), the offset will be wrong and depending
upon skb_headlen() we could reference past the end of that
non-compound page we will end up grabbing a reference to.
And then we'll end up with a compound page in an skb_shinfo() frag
array, which is illegal.
Well, at least, I can list several drivers that will barf when
trying to TX that (Acenic, atlx1, cassini, jme, sungem), since
they use pci_map_page(... virt_to_page(skb->data)) or similar.
The core KMAP'ing support for SKBs will also not be able to grok
such a beastly SKB.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists