Hello,
On Wed, 23 Nov 2016, yuehaibing wrote:
> As to my topo,HOST1 and HOST3 share one route on HOST2, tcp connection
> between HOST2 and HOST3 may call tcp_ack to set dst->pending_confirm.
>
> So dst_neigh_output may wrongly freshed n->confirmed which stands for
> HOST1,however HOST1'MAC had been changed.
>
> The possibility of this occurred Significantly increases ,when ping and
> TCP transaction are set the same processor affinity on the HOST2.
>
> It seems that the issue is brought in commit
> 5110effee8fde2edfacac9cd12a9960ab2dc39ea ("net: Do delayed neigh
> confirmation.").
Bad news. Problem is not in delayed confirmation but
in the mechanism to use same dst for different neighbours on
LAN. We don't have a dst->neighbour reference anymore.
For IPv4 this is related to rt->rt_uses_gateway but
also to DST_NOCACHE. In the other cases we can not call
dst_confirm, may be we should lookup the neigh entry instead.
But we need a way to reduce such lookups on every packet,
for example, by remembering in struct sock and checking if
some bits of jiffies (at least 4-5) are changed from
previous lookup.
Regards
--
Julian Anastasov <j...@ssi.bg>
