I am not worried about the performance, just about the robustness.
skb_queue_lock is really an internal lock to the skb module. That dev.c plays
with it is already not nice, but holding it for longer times while calling
other subsystems (kfree_skb -> skb->destruct etc.) is just nasty and violates
the abstraction barriers. And it is dangerous because it makes every skb_*
list operation a death trap.
Maybe the fix is simple, but the implications on the rest of the code are not :)
> I checked all the usage of the destructor and none seems to recurse on the
> spinlock.
You never know, there are drivers doing clever things with it.
-Andi
-- This is like TV. I don't like TV.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/