Hi Linus: On Sun, Apr 20, 2008 at 02:31:48PM -0700, Linus Torvalds wrote: > > Talking about RCU I also think that whoever did those "rcu_dereference()" > macros in <linux/list.h> was insane. It's totally pointless to do > "rcu_dereference()" on a local variable. It simply *cannot* make sense. > Herbert, Paul, you guys should look at it. Since I made the macros look this way I'm obliged to defend it :) > #define list_for_each_rcu(pos, head) \ > - for (pos = (head)->next; \ > - prefetch(rcu_dereference(pos)->next), pos != (head); \ > - pos = pos->next) > + for (pos = rcu_dereference((head)->next); \ > + prefetch(pos->next), pos != (head); \ > + pos = rcu_dereference(pos->next)) Semantically there should be no difference between the two versions. The purpose of rcu_dereference is really similar to smp_rmb, i.e., it adds a (conditional) read barrier between what has been read so far (including its argument), and what will be read subsequently. So if we expand out the current code it would look like fetch (head)->next store into pos again: smp_read_barrier_depends() prefetch(pos->next) pos != (head) ...loop body... fetch pos->next store into pos goto again Yours looks like fetch (head)->next smp_read_barrier_depends() store into pos again: prefetch(pos->next) pos != (head) ...loop body... fetch pos->next smp_read_barrier_depends() store into pos goto again As the objective here is to insert a barrier before dereferencing pos (e.g., reading pos->next or using it in the loop body), these two should be identical. But I do concede that your version looks clearer, and has the benefit that should prefetch ever be optimised out with no side- effects, yours would still be correct while the current one will lose the barrier completely. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
