summaryrefslogtreecommitdiffstats
path: root/tools/spi
diff options
context:
space:
mode:
authorStefano Brivio <sbrivio@redhat.com>2019-05-27 19:42:23 +0200
committerDavid S. Miller <davem@davemloft.net>2019-05-28 17:15:06 -0700
commit73f51d151e6c760d74d7d4bde75337ebe5693b3e (patch)
tree0a76e0e4a4ed9f582687903544ffa7babcf9d20f /tools/spi
parent7aae703f8096d21e34ce5f34f16715587bc30902 (diff)
downloadlinux-73f51d151e6c760d74d7d4bde75337ebe5693b3e.tar.gz
linux-73f51d151e6c760d74d7d4bde75337ebe5693b3e.tar.bz2
linux-73f51d151e6c760d74d7d4bde75337ebe5693b3e.zip
selftests: pmtu: Fix encapsulating device in pmtu_vti6_link_change_mtu
In the pmtu_vti6_link_change_mtu test, both local and remote addresses for the vti6 tunnel are assigned to the same address given to the dummy interface that we use as encapsulating device with a known MTU. This works as long as the dummy interface is actually selected, via rt6_lookup(), as encapsulating device. But if the remote address of the tunnel is a local address too, the loopback interface could also be selected, and there's nothing wrong with it. This is what some older -stable kernels do (3.18.z, at least), and nothing prevents us from subtly changing FIB implementation to revert back to that behaviour in the future. Define an IPv6 prefix instead, and use two separate addresses as local and remote for vti6, so that the encapsulating device can't be a loopback interface. Reported-by: Xiumei Mu <xmu@redhat.com> Fixes: 1fad59ea1c34 ("selftests: pmtu: Add pmtu_vti6_link_change_mtu test") Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'tools/spi')
0 files changed, 0 insertions, 0 deletions