<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/tools/testing/selftests/net, branch linux-5.13.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.13.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.13.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2021-07-28T12:37:23Z</updated>
<entry>
<title>selftests: mptcp: fix case multiple subflows limited by server</title>
<updated>2021-07-28T12:37:23Z</updated>
<author>
<name>Jianguo Wu</name>
</author>
<published>2021-07-10T00:20:50Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c888aa8632185b5e03f09921c4c79ea0225d7cda'/>
<id>urn:sha1:c888aa8632185b5e03f09921c4c79ea0225d7cda</id>
<content type='text'>
[ Upstream commit a7da441621c7945fbfd43ed239c93b8073cda502 ]

After patch "mptcp: fix syncookie process if mptcp can not_accept new
subflow", if subflow is limited, MP_JOIN SYN is dropped, and no SYN/ACK
will be replied.

So in case "multiple subflows limited by server", the expected SYN/ACK
number should be 1.

Fixes: 00587187ad30 ("selftests: mptcp: add test cases for mptcp join tests with syn cookies")
Reported-by: kernel test robot &lt;oliver.sang@intel.com&gt;
Signed-off-by: Jianguo Wu &lt;wujianguo@chinatelecom.cn&gt;
Signed-off-by: Mat Martineau &lt;mathew.j.martineau@linux.intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>selftests: icmp_redirect: IPv6 PMTU info should be cleared after redirect</title>
<updated>2021-07-28T12:37:22Z</updated>
<author>
<name>Hangbin Liu</name>
</author>
<published>2021-07-07T08:15:30Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6c75b21b2aab0eb604c827d3fc846f2ddb3890fb'/>
<id>urn:sha1:6c75b21b2aab0eb604c827d3fc846f2ddb3890fb</id>
<content type='text'>
[ Upstream commit 0e02bf5de46ae30074a2e1a8194a422a84482a1a ]

After redirecting, it's already a new path. So the old PMTU info should
be cleared. The IPv6 test "mtu exception plus redirect" should only
has redirect info without old PMTU.

The IPv4 test can not be changed because of legacy.

Fixes: ec8105352869 ("selftests: Add redirect tests")
Signed-off-by: Hangbin Liu &lt;liuhangbin@gmail.com&gt;
Reviewed-by: David Ahern &lt;dsahern@kernel.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>selftests: icmp_redirect: remove from checking for IPv6 route get</title>
<updated>2021-07-28T12:37:22Z</updated>
<author>
<name>Hangbin Liu</name>
</author>
<published>2021-07-07T08:15:29Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=84d37878814b0a4ab4faf7fc1f3394cf37e2a5ba'/>
<id>urn:sha1:84d37878814b0a4ab4faf7fc1f3394cf37e2a5ba</id>
<content type='text'>
[ Upstream commit 24b671aad4eae423e1abf5b7f08d9a5235458b8d ]

If the kernel doesn't enable option CONFIG_IPV6_SUBTREES, the RTA_SRC
info will not be exported to userspace in rt6_fill_node(). And ip cmd will
not print "from ::" to the route output. So remove this check.

Fixes: ec8105352869 ("selftests: Add redirect tests")
Signed-off-by: Hangbin Liu &lt;liuhangbin@gmail.com&gt;
Reviewed-by: David Ahern &lt;dsahern@kernel.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>selftests: Clean forgotten resources as part of cleanup()</title>
<updated>2021-07-19T08:04:38Z</updated>
<author>
<name>Amit Cohen</name>
</author>
<published>2021-06-08T12:44:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=42b8412dc12309c3050b38818e478e24e186c647'/>
<id>urn:sha1:42b8412dc12309c3050b38818e478e24e186c647</id>
<content type='text'>
[ Upstream commit e67dfb8d15deb33c425d0b0ee22f2e5eef54c162 ]

Several tests do not set some ports down as part of their cleanup(),
resulting in IPv6 link-local addresses and associated routes not being
deleted.

These leaks were found using a BPF tool that monitors ASIC resources.

Solve this by setting the ports down at the end of the tests.

Signed-off-by: Amit Cohen &lt;amcohen@nvidia.com&gt;
Reviewed-by: Petr Machata &lt;petrm@nvidia.com&gt;
Signed-off-by: Ido Schimmel &lt;idosch@nvidia.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>selftests: tls: fix chacha+bidir tests</title>
<updated>2021-07-14T15:07:13Z</updated>
<author>
<name>Jakub Kicinski</name>
</author>
<published>2021-06-18T20:25:04Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6f26c4e638cd20e5c46f37e86be0f03351471ec8'/>
<id>urn:sha1:6f26c4e638cd20e5c46f37e86be0f03351471ec8</id>
<content type='text'>
[ Upstream commit 291c53e4dacd3a2cc3152d8af37f07f8496c594a ]

ChaCha support did not adjust the bidirectional test.
We need to set up KTLS in reverse direction correctly,
otherwise these two cases will fail:

  tls.12_chacha.bidir
  tls.13_chacha.bidir

Fixes: 4f336e88a870 ("selftests/tls: add CHACHA20-POLY1305 to tls selftests")
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Acked-by: Vadim Fedorenko &lt;vfedorenko@novek.ru&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>selftests: tls: clean up uninitialized warnings</title>
<updated>2021-07-14T15:07:12Z</updated>
<author>
<name>Jakub Kicinski</name>
</author>
<published>2021-06-18T20:25:03Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f4b35106f13c1ebefb74a6496f794d1045973b64'/>
<id>urn:sha1:f4b35106f13c1ebefb74a6496f794d1045973b64</id>
<content type='text'>
[ Upstream commit baa00119d69e3318da8d99867fc1170ebddf09ce ]

A bunch of tests uses uninitialized stack memory as random
data to send. This is harmless but generates compiler warnings.
Explicitly init the buffers with random data.

Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Acked-by: Vadim Fedorenko &lt;vfedorenko@novek.ru&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>selftests/net: Add icmp.sh for testing ICMP dummy address responses</title>
<updated>2021-06-18T19:13:24Z</updated>
<author>
<name>Toke Høiland-Jørgensen</name>
</author>
<published>2021-06-18T11:04:36Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=7e9838b7915e29ae0dfe4a3e5f007c9dc6ab9b45'/>
<id>urn:sha1:7e9838b7915e29ae0dfe4a3e5f007c9dc6ab9b45</id>
<content type='text'>
This adds a new icmp.sh selftest for testing that the kernel will respond
correctly with an ICMP unreachable message with the dummy (192.0.0.8)
source address when there are no IPv4 addresses configured to use as source
addresses.

Signed-off-by: Toke Høiland-Jørgensen &lt;toke@redhat.com&gt;
Reviewed-by: David Ahern &lt;dsahern@kernel.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>selftests: net: use bash to run udpgro_fwd test case</title>
<updated>2021-06-16T19:56:10Z</updated>
<author>
<name>Andrea Righi</name>
</author>
<published>2021-06-16T14:57:27Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1b29df0e2e802cb15a5196c936f494161ec97502'/>
<id>urn:sha1:1b29df0e2e802cb15a5196c936f494161ec97502</id>
<content type='text'>
udpgro_fwd.sh contains many bash specific operators ("[[", "local -r"),
but it's using /bin/sh; in some distro /bin/sh is mapped to /bin/dash,
that doesn't support such operators.

Force the test to use /bin/bash explicitly and prevent false positive
test failures.

Signed-off-by: Andrea Righi &lt;andrea.righi@canonical.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>selftests: net: veth: make test compatible with dash</title>
<updated>2021-06-16T19:50:24Z</updated>
<author>
<name>Andrea Righi</name>
</author>
<published>2021-06-16T14:03:21Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0fd158b89b50b3a31c97a639ff496e1c59686e97'/>
<id>urn:sha1:0fd158b89b50b3a31c97a639ff496e1c59686e97</id>
<content type='text'>
veth.sh is a shell script that uses /bin/sh; some distro (Ubuntu for
example) use dash as /bin/sh and in this case the test reports the
following error:

 # ./veth.sh: 21: local: -r: bad variable name
 # ./veth.sh: 21: local: -r: bad variable name

This happens because dash doesn't support the option "-r" with local.

Moreover, in case of missing bpf object, the script is exiting -1, that
is an illegal number for dash:

 exit: Illegal number: -1

Change the script to be compatible both with bash and dash and prevent
the errors above.

Signed-off-by: Andrea Righi &lt;andrea.righi@canonical.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>ipv4: Fix device used for dst_alloc with local routes</title>
<updated>2021-06-14T19:30:53Z</updated>
<author>
<name>David Ahern</name>
</author>
<published>2021-06-13T00:24:59Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b87b04f5019e821c8c6c7761f258402e43500a1f'/>
<id>urn:sha1:b87b04f5019e821c8c6c7761f258402e43500a1f</id>
<content type='text'>
Oliver reported a use case where deleting a VRF device can hang
waiting for the refcnt to drop to 0. The root cause is that the dst
is allocated against the VRF device but cached on the loopback
device.

The use case (added to the selftests) has an implicit VRF crossing
due to the ordering of the FIB rules (lookup local is before the
l3mdev rule, but the problem occurs even if the FIB rules are
re-ordered with local after l3mdev because the VRF table does not
have a default route to terminate the lookup). The end result is
is that the FIB lookup returns the loopback device as the nexthop,
but the ingress device is in a VRF. The mismatch causes the dst
alloc against the VRF device but then cached on the loopback.

The fix is to bring the trick used for IPv6 (see ip6_rt_get_dev_rcu):
pick the dst alloc device based the fib lookup result but with checks
that the result has a nexthop device (e.g., not an unreachable or
prohibit entry).

Fixes: f5a0aab84b74 ("net: ipv4: dst for local input routes should use l3mdev if relevant")
Reported-by: Oliver Herms &lt;oliver.peter.herms@gmail.com&gt;
Signed-off-by: David Ahern &lt;dsahern@kernel.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
