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
From: Sowmini Varadhan
Date: Tue, 30 May 2017 16:52:26 -0700
Just as a side note in the future, if you could fix the date
and time on your computer, that would be awesome :-)
Hello,
On Wed, 31 May 2017, Sowmini Varadhan wrote:
> On (06/01/17 00:41), Julian Anastasov wrote:
> >
> > So, we do not hold reference to neigh while accessing
> > its fields. I suspect we need to move the table lock from
> > neigh_remove_one here, for example:
>
> good point,
On (06/01/17 00:41), Julian Anastasov wrote:
>
> So, we do not hold reference to neigh while accessing
> its fields. I suspect we need to move the table lock from
> neigh_remove_one here, for example:
Another thought is to have neigh_remove_one to remove
a neigh only if it is NUD_FAILED -
On (06/01/17 00:41), Julian Anastasov wrote:
>
> So, we do not hold reference to neigh while accessing
> its fields. I suspect we need to move the table lock from
> neigh_remove_one here, for example:
good point, let me think over your suggestion carefully (it sounds
right, I want to make
Hello,
On Tue, 30 May 2017, Sowmini Varadhan wrote:
> @@ -1650,6 +1689,7 @@ static int neigh_delete(struct sk_buff *skb, struct
> nlmsghdr *nlh,
> NEIGH_UPDATE_F_ADMIN,
> NETLINK_CB(skb).portid);
> neigh_release(neigh);
> +
The command
# arp -s 62.2.0.1 a:b:c:d:e:f dev eth2
adds an entry like the following (listed by "arp -an")
? (62.2.0.1) at 0a:0b:0c:0d:0e:0f [ether] PERM on eth2
but the symmetric deletion command
# arp -i eth2 -d 62.2.0.1
does not remove the PERM entry from the table, and instead leaves