Eric Dumazet <[EMAIL PROTECTED]> wrote:
>
> Very good question, but honestly I really dont see why it was there at the
> first place :
It was there because someone went through this file and robotically
replaced all conditional read barriers with rcu_dereference, even when
it made zero sense.
Basically you can add a conditional barrier either at the point where
the pointer gets read, or where it gets derferenced. Previously we
did the latter (except that the show function didn't have a barrier
at all which is technically a bug though harmless in pratice). This
patch moves it to the spot where it gets read which is also OK.
> static struct rtable *rt_cache_get_next(struct seq_file *seq, struct rtable
> *r)
> {
> - struct rt_cache_iter_state *st = rcu_dereference(seq->private);
> + struct rt_cache_iter_state *st = seq->private;
>
> - r = r->u.dst.rt_next;
> + r = rcu_dereference(r->u.dst.rt_next);
> while (!r) {
> rcu_read_unlock_bh();
> if (--st->bucket < 0)
> break;
> rcu_read_lock_bh();
> - r = rt_hash_table[st->bucket].chain;
> + r = rcu_dereference(rt_hash_table[st->bucket].chain);
> }
> return r;
Slight optimisation: please move both barriers onto the return statement,
i.e.,
return rcu_dereference(r);
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
