netdev - Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080819085504.GB29038@gondor.apana.org.au>
Date:	Tue, 19 Aug 2008 18:55:04 +1000
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Jarek Poplawski <jarkao2@...il.com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	denys@...p.net.lb
Subject: Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock().

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.

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.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html