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]

Date:	Tue, 19 Aug 2008 01:48:38 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	jarkao2@...il.com
Cc:	herbert@...dor.apana.org.au, netdev@...r.kernel.org,
	denys@...p.net.lb
Subject: Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock().

From: Jarek Poplawski <jarkao2@...il.com>
Date: Tue, 19 Aug 2008 08:41:48 +0000

> On Tue, Aug 19, 2008 at 01:32:05AM -0700, David Miller wrote:
> > Jarek may have a point about the u32 classifier.  So we
> > should think about it.
> > 
> > The hash tables and tp_u_common objects are shared, and
> > it does non-atomic refcounting during destruction, see
> > u32_destroy().
> > 
> > However, this all might be OK because all of this management
> > is performed only under the RTNL semaphore.
> 
> Sure, this all should be write protected. I'm concerned only about
> the read side here.

If reference count hits zero, nobody can reference the object.
Reference counts only change under RTNL, which is my point.

The old qdisc object is taken away from global visibility inside of
the cops->graft() call done by qdisc_graft().  This handler already
must do whatever locking is necessary while removing the qdisc from
visibility from the packet path.

And by virtue of that, the old qdisc and anything it references will
no longer be visible to the packet processing path after cops->graft()
returns.
--
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