| To: | "Paul E. McKenney" <paulmck@xxxxxxxxxx> |
|---|---|
| Subject: | Re: [RFC][PATCH] identify in_dev_get rcu read-side critical sections |
| From: | Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> |
| Date: | Thu, 29 Sep 2005 08:11:10 +1000 |
| Cc: | "David S. Miller" <davem@xxxxxxxxxxxxx>, suzannew@xxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, Robert.Olsson@xxxxxxxxxxx, walpole@xxxxxxxxxx, netdev@xxxxxxxxxxx |
| In-reply-to: | <20050928145110.GA4925@xxxxxxxxxx> |
| References: | <20050927.135626.88296134.davem@xxxxxxxxxxxxx> <E1EKS6j-0006s4-00@xxxxxxxxxxxxxxxxxxxxxxxx> <20050928145110.GA4925@xxxxxxxxxx> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
| User-agent: | Mutt/1.5.9i |
On Wed, Sep 28, 2005 at 07:51:10AM -0700, Paul E. McKenney wrote: > > The reference-count approach is only guaranteed to work if the kernel > thread that did the reference-count increment is later referencing that > same data element. Otherwise, one has the following possible situation > on DEC Alpha: You're quite right. Without the rcu_dereference users of in_dev_get() may see pre-initialisation contents of in_dev. So these barriers are definitely needed. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt |
| Previous by Date: | Re: rwlock recursion on CPU#0, netfilter related?, Pekka Pietikainen |
|---|---|
| Next by Date: | Re: ipvs_syncmaster brings cpu to 100%, Julian Anastasov |
| Previous by Thread: | Re: [RFC][PATCH] identify in_dev_get rcu read-side critical sections, Paul E. McKenney |
| Next by Thread: | Re: [RFC][PATCH] identify in_dev_get rcu read-side critical sections, Suzanne Wood |
| Indexes: | [Date] [Thread] [Top] [All Lists] |