On Tue, Jun 05, 2012 at 10:57:06AM +0200, Eric Dumazet wrote:
> On Tue, 2012-06-05 at 15:52 +0800, Gao feng wrote:
>
> > +static void __net_exit inetpeer_net_exit(struct net *net)
> > +{
> > + inetpeer_invalidate_tree(net, AF_INET);
> > + kfree(net->ipv4.peers);
> > +
> > + inetpeer_invalidate_tree(net, AF_INET6);
> > + kfree(net->ipv6.peers);
> > +}
> > +
>
> Are we 1000% sure no code ever run in inetpeer land after this call ?
>
> I would add
> net->ipv4.peers = NULL;
> net->ipv6.peers = NULL;
>
> to catch NULL deref instead of strange errors, just in case.
I thought about that too, and I'm not absolutely sure.
The rest of this patch looks ok to me.
>
> 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.
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/containers
