On Tue, Nov 11, 2008 at 08:19:09PM +0100, Johann Baudy (johaahn@gmail.com) wrote:
quoted text
> > I think you should be almost 200% sure that skb is not allowed to grow up :)
> Well! I'm lost :)
> 
> How can we forward a pointer from skb allocation to skb destructor
> without adding a kind of destructor argument in sk_buff struct?

There are several possibilities:
* update destructor with your own data and put old one behind the data
	in skb
* update destructor, but put your own data into some storage which can
	be accessed from your callback, storage entry may contain
	whatever data you want and of course old destructor
* put your data into socket pointer (there still may be issues with
	destructor)
* if you fully own the skb, reuse whatever members there you like
	(except those which may be used by lower layer)
* find why do you need to have callback at destruction time and
	eliminate this problem.
	Btw, netchannels do this way, since they are very similar to
	packet socket, but compared to your approach they have a copy.

At the first place I do not understand, why do you want to change the
skb, since you can mmap whatever area you need and provide those pages
into skb, which at free time will drop the reference counter. Skb lives
in socket queue, so until it is empty you can sleep not allowing mapped
buffer to shrink.

-- 
	Evgeniy Polyakov
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html