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.
> If for whatever reason the code does not reflect the reasoning

quoted text
> 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