On Tue, Aug 19, 2008 at 06:55:04PM +1000, Herbert Xu wrote:
quoted text
> On Tue, Aug 19, 2008 at 08:39:09AM +0000, Jarek Poplawski wrote:
> >
> > > Well I can't vouch for every single qdisc in the tree.  However,
> > > what I can say is that as long as they respect the rules I outlined
> > > earlier with regards to holding the root qdisc lock when deleting
> > > or using children, then they'll work as expected.
> > > 
> > > You're definitely welcome to audit the qdiscs to make sure that
> > > they are obeying the rules.
> > 
> > That's my point - is there really a reason do this change without such
> > an audit if we are not forced at the moment? (I'd remind this way of
> > doing things was entirely legal according to comments.) I doubt, I'm
> > the right person for auditing this but as I said I'll have a look,
> > especially when there will be lack of those fascinating oopses and
> > warnings around.
> 
> No you misunderstood my point.  I wasn't saying that I'm not confident
> that our qdiscs obey the rules, but rather that if any of them didn't,
> then they're buggy and should be fixed.

What difference does it make? You're not sure thinks will not break
after this change.

quoted text
> 
> In fact we're not really adding anything new here, the qdiscs were
> not accessed under RCU uniformly.  If you go back in the tree prior
> to the multi-qdisc stuff, you'll find that only dev_queue_xmit works
> under RCU.  qdisc_restart does not and therefore deferring the
> destruction to RCU is pointless anyway.
> 
> So in fact we've already been relying on the fact that by the time
> qdisc_destroy comes about nobody on the read side (i.e., the packet
> transmission path) should have a reference to it.

Let's not discuss using such a qdisc by others but a possibility
that some common lists could be broken for readers from upper qdiscs.
(They were not deactivated.) Of course, if it's done properly with
some references before qdisc_destroy then it's all right. I'd prefer
to check this later yet.

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