| To: | jamal <hadi@xxxxxxxxxx> |
|---|---|
| Subject: | Re: [NET] Fix neighbour tbl->entries race |
| From: | Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> |
| Date: | Wed, 3 Nov 2004 07:37:20 +1100 |
| Cc: | "David S. Miller" <davem@xxxxxxxxxxxxx>, netdev@xxxxxxxxxxx |
| In-reply-to: | <1099404823.1021.15.camel@jzny.localdomain> |
| References: | <20041102112651.GA8633@gondor.apana.org.au> <1099404823.1021.15.camel@jzny.localdomain> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
| User-agent: | Mutt/1.5.6+20040722i |
On Tue, Nov 02, 2004 at 09:13:43AM -0500, jamal wrote: > > Is this still the same logic: > > ------------- > - if (!neigh_forced_gc(tbl) && > - tbl->entries > tbl->gc_thresh3) > - goto out; > + neigh_forced_gc(tbl); > + if (atomic_read(&tbl->entries) > tbl->gc_thresh3) > + goto out_entries; > > ------- > > In previous code it seems you should short-circuit if > neigh_forced_gc(tbl) returns non-zero. why do you have to break that > if statement? The previous logic is slightly incorrect in that even if neigh_forced_gc succeeded in removing some entries, the total number of entries may still be above the threshold 3. 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 |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH 2.6] e100, e1000, ixgb: add MODULE_VERSION tags, John W. Linville |
|---|---|
| Next by Date: | [PATCH 2.6] ixgb: fix ixgb_intr looping checks, Jesse Brandeburg |
| Previous by Thread: | Re: [NET] Fix neighbour tbl->entries race, jamal |
| Next by Thread: | Re: [NET] Fix neighbour tbl->entries race, Herbert Xu |
| Indexes: | [Date] [Thread] [Top] [All Lists] |