netdev
[Top] [All Lists]

Re: neigh_create/inetdev_destroy race?

To: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Subject: Re: neigh_create/inetdev_destroy race?
From: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Mon, 30 Aug 2004 23:08:20 -0700
Cc: shemminger@xxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <20040829065031.GA786@xxxxxxxxxxxxxxxxxxx>
References: <20040814003428.GA17760@xxxxxxxxxxxxxxxxxxx> <20040813173924.6d05be15.davem@xxxxxxxxxx> <20040814005411.GA18350@xxxxxxxxxxxxxxxxxxx> <20040814012513.GA721@xxxxxxxxxxxxxxxxxxx> <20040814013030.GA2042@xxxxxxxxxxxxxxxxxxx> <20040814050848.GA11874@xxxxxxxxxxxxxxxxxxx> <20040814062703.GA4806@xxxxxxxxxxxxxxxxxxx> <20040815191450.77532d5d.davem@xxxxxxxxxx> <20040816105131.GA11299@xxxxxxxxxxxxxxxxxxx> <20040828234201.79556f6e.davem@xxxxxxxxxxxxx> <20040829065031.GA786@xxxxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
On Sun, 29 Aug 2004 16:50:31 +1000
Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote:

> > Secondly, until neigh_create() takes the tbl lock, it is not in
> > the hash tables and therefore neigh_ifdown() could not see it.
> 
> That part I agree with :) That's in fact what this race is about:
> neigh_ifdown does not guarantee that the hash table will be without
> references to idev.

I think we can clear this by putting neigh_parms_release() into an
RCU handler.  It can't be in in_dev_rcu_put.

I also now believe that these sorts of races you are mentioning percolate
out into ip_mc_destroy_dev().

<Prev in Thread] Current Thread [Next in Thread>