But if you don't update the socket counters for cloned skb's, could
you get a situation where the counter appears to be back to zero,
but there's still a clone skb being processed? This could possibly
lead to a socket being destroyed to early, as the memory counters
determine when to delay destruction.
So it seems that a clone skb should be counted for some non-zero
amount, if not the full data size.
Interesting... I think you're right on this one. And this is probably
why things act the way they currently do (charing the full skb size
even for cloned copies).
Ho hum, we have to think about this some more I suppose.
I've considered for right now to charge for a clone sizeof(struct
sk_buff) bytes to the sock. But then a special destructor is still
needed so the wakeup is avoided. And actually as Linus pointed out
this cannot happen (avoid the wakeup when some bytes are charged) so
as to avoid deadlock situations when the sock owner sleeps because it
needs some write space....
More pondering on this is needed...
Later,
David S. Miller
davem@dm.cobaltmicro.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu