On Tue, Aug 19, 2008 at 05:23:16PM +1000, Herbert Xu wrote:
quoted text
> On Tue, Aug 19, 2008 at 06:46:09AM +0000, Jarek Poplawski wrote:
> >
> > Actually, I, and earlier Herbert, have written about destroying root
> > qdiscs without sch_tree_lock(). I don't know how Herbert, but I'd
> > prefer to leave here this lock for child qdiscs: they can remove some
> > common structures, so this needs more checking, and even if they don't
> > do this currently, there is no need to remove this possibility here.
> > Similarly, I'm not sure if removing BH protection is really needed
> > here.
> 
> Qdiscs can die in two ways, when the underlying device dies or
> when the user removes/replaces the qdisc.  In the first case the
> we're being called from dev_shutdown so all users of the qdisc
> should have ceased or dev_deactivate is buggy.  The other case
> is again divided into two subcases.  First of all if we're removing
> the root qdisc then again dev_deactivate gets called and the same
> reasoning applies.

This case is quite clear.

quoted text
> 
> If we're removing a non-root qdisc, then we will first grab the
> root qdisc's lock, kill the child, and release the root lock.  By
> convention, any user of a child qdisc must have acquired the root
> qdisc's lock because the child is only reachable through the root.
> Therefore once we have released the root qdisc lock after killing
> the child, we're guaranteed that no further references to that
> child can be made.

By convention, there was always this comment that destroy is under
sch_tree_lock(), so it was legal to depend on this. I'm not afraid
of somebody using such an under destroy qdisc - it's about a code
inside this qdisc could refer to not destroyed part.

quoted text
> If for whatever reason the code does not reflect the reasoning
> above, please feel free to fix the code :)

Sure, I'll try to look for such problems.

Cheers,
Jarek P.
--
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