>I don't like your fix though. skb_queue_lock is far too fundamental to
>be taken that long, especially over a kfree_skb(). e.g. if the skb destructor
>does any skb list operations it'll deadlock. so it would be better to enforce
>the ordering in skb_queue_tail.
The path where we take the spinlock that long is definetly not a
fast-path. During production the performance would be the same as now. And
more important my patch is more efficient than an ordered-write solution
as I avoid lots of additional SMP lock on the bus on i386 to do the
ordered writes for each skb_queue_tail.
Also using the clever way is not suggested at least by Linus as last time
I posted a patch to Linus to do things like that he rejected the patch
saying it was too much clever programming and I should use the simpler way
to use a spinlock.
So unless a skb destructor is really using the spinlock itself, I still
think my fix is fine for 2.2.x.
I checked all the usage of the destructor and none seems to recurse on the
spinlock.
Andrea
-
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/