Hello! > Race 1: w/o RCU > Cpu 0: is in neigh_lookup > gets read_lock() > finds entry > ++refcount to 2 > updates it > Cpu 1: is in forced_gc() > waits at write_lock() > releases read_lock() > drops ref count to 1. > sees ref count is 1 > deletes it
Do you mean it is purged, though it is actually fresh? It is harmless race condition. > Why must it be hashed, it could always get zapped just after the update. Because otherwise we have to check its validity on level of dst_cache and to rebind. We do not want this. Actually dst->neighbour is supposed to be immutable. It means that if some valid dst refers to a neighbour, it must remain hashed. > Hmm.. Since this is a slow path, All the neighbour lookups are in slow path. Actually, lookup of neighbour entry for use in dst cache is the most loaded path, the rest of them are pure maintanance paths. Yes, this would work. RCU is a little spoiled, but at least global tbl->lock is replaced with per neighbour lock. Alexey - 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
