Evgeniy Polyakov, on 12/20/2008 01:32 PM wrote:
On Sat, Dec 20, 2008 at 07:10:45PM +1100, Herbert Xu (herbert@xxxxxxxxxxxxxxxxxxx) wrote:
Hm. So if I get a destructor call from the shared_info, can I go an
inspect the page refcounts to see if its really the last use?
The pages that were originally in the shared_info at creation
time may no longer be there by the time it's freed because of
pskb_pull_tail.
Things should work fine, since pskb_expand_head() copies whole shared
info structure (and thus will copy destructor), get all pages and then
copy all pointers into the new skb, and then release old skb's data.
So destructor for the pages should not rely on which skb it is called on
and check if pages are about to be really freed (i.e. check theirs
reference counter).
__pskb_pull_tail() is tricky, it just puts some pages it does not want
to be present in the skb, but it could be possible to add there
destructor callback from the original skb with partial flag (or just
having destructor with two parameters: skb and page, and if page is not
NULL, then actually only given page is freed, otherwise the whole skb).
Actually, there's another way, which seems to be a lot simpler. Alexey
Kuznetsov privately suggested it to me.
In skb_shared_info new pointer transaction_token would be added, which
would point on:
struct sk_transaction_token
{
atomic_t io_count;
struct sk_transaction_token *next;
unsigned long token;
unsigned long private;
void (*finish_callback)(struct sk_transaction_token *);
};
When skb is translated, transaction_token inherited. If 2 skb are merged
(the same places where I put net_get_page's in my patch), the *older*
token is inherited. This is the main point of this idea.
Before starting new asynchronous send a client would open a new token.
Everything sent then would receive that token. Finish_callback() would
be called and the corresponding token freed, when io_count == 0 *AND*
all previous tokens closed.
This idea seems to be simpler, than even what Rusty implemented. Correct
me, if I wrong. But, unfortunately, in the near future I will have no
time to develop it.. :-(
Vlad
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
