On (06/01/17 01:41), Julian Anastasov wrote: > Another problem is that neigh_update() changes the > state but before we go and unlink the entry another CPU > can reactivate the entry, i.e. NUD_INCOMPLETE entered > in __neigh_event_send(). So, there will be always some > small window where surprises can happen and the entry is > not really deleted.
but that would be ok- it's the same as if I did arp -d <addr> ping <addr> I think the only danger is that, once we drop the ref with neigh_release(), we are relying on the table's lock for the neigh to not disappear under us. Thus as you correctly pointed out, we need the tbl->lock to make sure we sync with all paths that can pull the neigh out of the table (and release the table's ref along the way). Thanks for catching that, patch v4 (with correct smtp timestamp!) will be sent out shortly. --Sowmini
