On Tue, Aug 19, 2008 at 01:32:05AM -0700, David Miller wrote:
I had a look and it seems to be OK to me. Essentially we have
two sides in all this, the read side which is the path that
transmits packets, and the write side which is the control path.
As with a qdisc_destroy, u32_destroy can only be called once all
read sides have exited so we won't be racing against that. In
fact if we were able to race against it then holding the lock is
no good anyway because this implies the u32 object is still
referenced by a qdisc tree and as such once we release the lock
the read side can get back to a destroyed u32 object.
Right, all other writers have been excluded by RTNL so we should
be the only thread with a reference to the u32 and we can decrement
the ref count non-atomically.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html