[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120605121510.GD27795@secunet.com>
Date: Tue, 5 Jun 2012 14:15:10 +0200
From: Steffen Klassert <steffen.klassert@...unet.com>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: Gao feng <gaofeng@...fujitsu.com>, serge.hallyn@...onical.com,
ebiederm@...ssion.com, herbert@...dor.apana.org.au,
davem@...emloft.net, netdev@...r.kernel.org,
containers@...ts.linux-foundation.org
Subject: Re: [PATCH net-next v2 1/2] inetpeer: add namespace support for
inetpeer
On Tue, Jun 05, 2012 at 02:00:30PM +0200, Eric Dumazet wrote:
> On Tue, 2012-06-05 at 13:27 +0200, Steffen Klassert wrote:
>
> > >
> > > By the way, I think we have a bug in inetpeer_gc_worker()
> > >
> > > Steffen ?
> > >
> > > We have no rcu grace period to make sure the following is safe :
> > >
> > > if (!atomic_read(&p->refcnt)) {
> > > list_del(&p->gc_list);
> > > kmem_cache_free(peer_cachep, p);
> > > }
> >
> > I think this is ok as it is. inetpeer_invalidate_tree()
> > unlinks the whole inetpeer tree from the inetpeer base and
> > adds it to a gc_list. These intetpeer entries are stale,
> > they can't be looked up again. So noone should increment the
> > refcount, they just wait until the refcount get zero.
> >
>
> Its not OK, lookups are done under rcu.
>
> Since there is no RCU grace period, the worker free the entries while
> another cpus are doing their lookups.
>
Lookups are done under rcu, yes. But a lookup will not find
these stale entries because the whole interpeer tree is removed
from the inetpeer base before the worker is scheduled. A lookup
would have to cerate a new inetpeer entry in this case.
--
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
Powered by blists - more mailing lists