| 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(). |
| Previous by Date: | Re: [RFC] MASQUERADE / policy routing ("Route send us somewhere else"), David S. Miller |
|---|---|
| Next by Date: | Re: [RFC] MASQUERADE / policy routing ("Route send us somewhere else"), Julian Anastasov |
| Previous by Thread: | Re: neigh_create/inetdev_destroy race?, Herbert Xu |
| Next by Thread: | Re: neigh_create/inetdev_destroy race?, Herbert Xu |
| Indexes: | [Date] [Thread] [Top] [All Lists] |