Hi Vitali.

On Wed, Nov 05, 2008 at 04:47:03PM -0800, Lovich, Vitali (vlovich@qualcomm.com) wrote:

In either case, the skb given to the destructor will still have the correct values for fragments we specified.  Of course, this is based on 2 assumptions:

1.  Nothing further down the line won't add fragments, thereby overwriting frags[0]
2.  No-one writes to frags[0].page & frags[0].page_offset

1 is reasonable because since the only reason we would be linearizing in the first place is if the device doesn't support scatter/gather, so it would be strange for something down the line to add more fragments that would have to be linearized anyways.

2 is reasonable since it would only make sense if something down the line used this as a temporary variable storage, which again should be unlikely.

What if skb was queued in hardware or qdisk and userspace rewrites
mapped page placed in fraglist?

Another approach may be to store it in the cb as we had done so originally, except with skb_clone to ensure no other layers overwrite it, although I'm not 100% sure of the implications of skb_clone has for things like the cb & users fields and kfree_skb.

It is not allowed to store something in cb block which is intended to
live while skb is processed on different layers. In this particular case
qdisk engine will overwrite skb's cb.

-- 
	Evgeniy Polyakov