четверг

[Bug 2055473] Re: pmtu.sh net selftest fail with PMTU exception wasn't created after exceeding MTU

** Description changed: + SRU Justification + + [Impact] + + During ubuntu_kselftests_net/net:pmtu.sh on 5.15 and 6.8 kernels, if the network + interface in use has rp_filter=1, 4 test cases fail unexpectedly: + + # TEST: ICMPv4 with DSCP and ECN: PMTU exceptions [FAIL] + # PMTU exception wasn't created after exceeding MTU + # TEST: ICMPv4 with DSCP and ECN: PMTU exceptions - nexthop objects [FAIL] + # PMTU exception wasn't created after exceeding MTU + # TEST: UDPv4 with DSCP and ECN: PMTU exceptions [FAIL] + # PMTU exception wasn't created after exceeding MTU + # TEST: UDPv4 with DSCP and ECN: PMTU exceptions - nexthop objects [FAIL] + # PMTU exception wasn't created after exceeding MTU + + This happens because the exception is being filtered by the strict rp_filter + setting, so the test believes one was not received. Because this is dependent + on the test environment's configuration, this failure would only happen on some + clouds, particularly GCE. Clouds which set rp_filter=2 (loose) are not affected. + + This issue was fixed upstream by always disabling rp_filter during the test, + to improve consistency. With this upstream fix, 7.0 kernels are unaffected. + The affected tests were added after 5.4 so kernels earlier than 5.15 are also + unaffected. + + [Fix] + + Backport the fix commit: + ce17831f8e970 ("selftests: net: disable rp_filter after namespace initialization") + to 5.15 and 6.8, as well as any needed dependencies. + + Backport notes in the commits should explain any conflict resolutions, but I + should particularly note that in jammy, net/lib.sh was added in our backport of + d83a580675927 ("selftests: net: use slowwait to stabilize vrf_route_leaking test") + by including some parts of + 25ae948b44788 ("selftests/net: add lib.sh") + which we then finish backporting in this patchset. + + [Test plan] + + Ran the pmtu.sh ubuntu_kselftests_net test through autotest on jammy and noble, + then applied the patchsets to the kernel source and reran the tests. The failure + is resolved after applying. For jammy I also ran unicast_extensions.sh because + it was also touched during the backport. + + [Where problems could occur] + + All changes are within the selftests code, so problems should only show up as + invalid test results after applying the fix. + + ---- ORIGINAL BUG REPORT ---- + Issue found on J-gcp-6.5.0-1015.15~22.04.1 and M-gcp-6.5.0-1015.15 in cycle sru-20240205 And can be reproduced with generic kernel on GCP cloud. This is not a regression but something emerges after the pmtu.sh result parsing logic update, which landed via stable update in sru-20240205 cycle (bug 2043198) Dive into test history, we can see this failure all the way back to sru-20231030 with M-6.5.0-1010.10 on GCP cloud. 19:48:21 DEBUG| [stdout] # selftests: net: pmtu.sh 19:48:21 DEBUG| [stdout] # TEST: ipv4: PMTU exceptions [ OK ] 19:48:21 DEBUG| [stdout] # TEST: ipv4: PMTU exceptions - nexthop objects [ OK ] 19:48:22 DEBUG| [stdout] # TEST: ipv6: PMTU exceptions [ OK ] 19:48:22 DEBUG| [stdout] # TEST: ipv6: PMTU exceptions - nexthop objects [ OK ] 19:48:23 DEBUG| [stdout] # TEST: ICMPv4 with DSCP and ECN: PMTU exceptions [FAIL] 19:48:23 DEBUG| [stdout] # PMTU exception wasn't created after exceeding MTU 19:48:24 DEBUG| [stdout] # TEST: ICMPv4 with DSCP and ECN: PMTU exceptions - nexthop objects [FAIL] 19:48:24 DEBUG| [stdout] # PMTU exception wasn't created after exceeding MTU 19:48:25 DEBUG| [stdout] # TEST: UDPv4 with DSCP and ECN: PMTU exceptions [FAIL] 19:48:25 DEBUG| [stdout] # PMTU exception wasn't created after exceeding MTU 19:48:25 DEBUG| [stdout] # TEST: UDPv4 with DSCP and ECN: PMTU exceptions - nexthop objects [FAIL] 19:48:25 DEBUG| [stdout] # PMTU exception wasn't created after exceeding MTU .... Logfile also attached (rt.log) -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2055473 Title: pmtu.sh net selftest fail with PMTU exception wasn't created after exceeding MTU Status in ubuntu-kernel-tests: New Status in linux package in Ubuntu: New Status in linux source package in Jammy: New Status in linux source package in Mantic: Won't Fix Status in linux source package in Noble: New Bug description: SRU Justification [Impact] During ubuntu_kselftests_net/net:pmtu.sh on 5.15 and 6.8 kernels, if the network interface in use has rp_filter=1, 4 test cases fail unexpectedly: # TEST: ICMPv4 with DSCP and ECN: PMTU exceptions [FAIL] # PMTU exception wasn't created after exceeding MTU # TEST: ICMPv4 with DSCP and ECN: PMTU exceptions - nexthop objects [FAIL] # PMTU exception wasn't created after exceeding MTU # TEST: UDPv4 with DSCP and ECN: PMTU exceptions [FAIL] # PMTU exception wasn't created after exceeding MTU # TEST: UDPv4 with DSCP and ECN: PMTU exceptions - nexthop objects [FAIL] # PMTU exception wasn't created after exceeding MTU This happens because the exception is being filtered by the strict rp_filter setting, so the test believes one was not received. Because this is dependent on the test environment's configuration, this failure would only happen on some clouds, particularly GCE. Clouds which set rp_filter=2 (loose) are not affected. This issue was fixed upstream by always disabling rp_filter during the test, to improve consistency. With this upstream fix, 7.0 kernels are unaffected. The affected tests were added after 5.4 so kernels earlier than 5.15 are also unaffected. [Fix] Backport the fix commit: ce17831f8e970 ("selftests: net: disable rp_filter after namespace initialization") to 5.15 and 6.8, as well as any needed dependencies. Backport notes in the commits should explain any conflict resolutions, but I should particularly note that in jammy, net/lib.sh was added in our backport of d83a580675927 ("selftests: net: use slowwait to stabilize vrf_route_leaking test") by including some parts of 25ae948b44788 ("selftests/net: add lib.sh") which we then finish backporting in this patchset. [Test plan] Ran the pmtu.sh ubuntu_kselftests_net test through autotest on jammy and noble, then applied the patchsets to the kernel source and reran the tests. The failure is resolved after applying. For jammy I also ran unicast_extensions.sh because it was also touched during the backport. [Where problems could occur] All changes are within the selftests code, so problems should only show up as invalid test results after applying the fix. ---- ORIGINAL BUG REPORT ---- Issue found on J-gcp-6.5.0-1015.15~22.04.1 and M-gcp-6.5.0-1015.15 in cycle sru-20240205 And can be reproduced with generic kernel on GCP cloud. This is not a regression but something emerges after the pmtu.sh result parsing logic update, which landed via stable update in sru-20240205 cycle (bug 2043198) Dive into test history, we can see this failure all the way back to sru-20231030 with M-6.5.0-1010.10 on GCP cloud. 19:48:21 DEBUG| [stdout] # selftests: net: pmtu.sh 19:48:21 DEBUG| [stdout] # TEST: ipv4: PMTU exceptions [ OK ] 19:48:21 DEBUG| [stdout] # TEST: ipv4: PMTU exceptions - nexthop objects [ OK ] 19:48:22 DEBUG| [stdout] # TEST: ipv6: PMTU exceptions [ OK ] 19:48:22 DEBUG| [stdout] # TEST: ipv6: PMTU exceptions - nexthop objects [ OK ] 19:48:23 DEBUG| [stdout] # TEST: ICMPv4 with DSCP and ECN: PMTU exceptions [FAIL] 19:48:23 DEBUG| [stdout] # PMTU exception wasn't created after exceeding MTU 19:48:24 DEBUG| [stdout] # TEST: ICMPv4 with DSCP and ECN: PMTU exceptions - nexthop objects [FAIL] 19:48:24 DEBUG| [stdout] # PMTU exception wasn't created after exceeding MTU 19:48:25 DEBUG| [stdout] # TEST: UDPv4 with DSCP and ECN: PMTU exceptions [FAIL] 19:48:25 DEBUG| [stdout] # PMTU exception wasn't created after exceeding MTU 19:48:25 DEBUG| [stdout] # TEST: UDPv4 with DSCP and ECN: PMTU exceptions - nexthop objects [FAIL] 19:48:25 DEBUG| [stdout] # PMTU exception wasn't created after exceeding MTU .... Logfile also attached (rt.log) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/2055473/+subscriptions

Комментариев нет:

Отправить комментарий