I do not see any synchronization however commit dbd2915ce87e811165da0717f8e159276ebb803e by Andrew justifies the use of raw_smp_processor_id() here because "we do not care"
So lets use raw_cpu ops here and hope for the best. The use of __this_cpu op improves the situation already from what commit dbd2915ce87e811165da0717f8e159276ebb803e did since the single instruction emitted on x86 does not allow the race to occur anymore. However, non x86 platforms could still experience a race here. Cc: Eric Dumazet <[email protected]> Signed-off-by: Christoph Lameter <[email protected]> Index: linux/net/ipv4/route.c =================================================================== --- linux.orig/net/ipv4/route.c 2013-10-07 10:27:25.000000000 -0500 +++ linux/net/ipv4/route.c 2013-10-07 12:41:23.993823743 -0500 @@ -197,7 +197,7 @@ const __u8 ip_tos2prio[16] = { EXPORT_SYMBOL(ip_tos2prio); static DEFINE_PER_CPU(struct rt_cache_stat, rt_cache_stat); -#define RT_CACHE_STAT_INC(field) __this_cpu_inc(rt_cache_stat.field) +#define RT_CACHE_STAT_INC(field) raw_cpu_inc(rt_cache_stat.field) #ifdef CONFIG_PROC_FS static void *rt_cache_seq_start(struct seq_file *seq, loff_t *pos) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
