Daniel Phillips wrote:
Hi,
The way I read this, __kfree_skb will sometimes be called with ->users = 1 and
sometimes with ->users = 0, is that right?
Yes.
static inline void kfree_skb(struct sk_buff *skb)
{
if (likely(atomic_read(&skb->users) == 1))
smp_rmb();
else if (likely(!atomic_dec_and_test(&skb->users)))
return;
__kfree_skb(skb);
}
If so, then why not just:
static inline void kfree_skb(struct sk_buff *skb)
{
if (likely(atomic_read(&skb->users) == 1))
smp_rmb();
if (likely(!atomic_dec_and_test(&skb->users)))
return;
__kfree_skb(skb);
}
so __kfree_skb can BUG_ON(atomic_read(&skb->users))? Perhaps this has
something to do with the smp_rmb, could somebody please explain to me why it
is necessary here, and for which architectures?
The atomic_read is used as an optimization under the assumption that
an atomic_read is cheaper than an atomic_dec_and_test. The smp_rmb
is (was) needed to make sure the CPU didn't reorder things because
we used to have a BUG check in __kfree_skb which triggered if
skb->list was non-NULL.
Anyway, do we not want BUG_ON(!atomic_read(&skb->users)) at the beginning of
kfree_skb, since we rely on it?
Why do you care if skb->users is 0 or 1 in __kfree_skb()?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
