Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

selftests: join: "remove subflows and signal" is unstable #225

Closed
matttbe opened this issue Aug 11, 2021 · 1 comment
Closed

selftests: join: "remove subflows and signal" is unstable #225

matttbe opened this issue Aug 11, 2021 · 1 comment
Assignees
@pabeni
Labels
bug selftests

Comments

@matttbe
Copy link
Member

matttbe commented Aug 11, 2021

With a debug kernel, with and without Paolo's patches; I have this error:

# 28 remove subflows and signal           syn[ ok ] - synack[ ok ] - ack[ ok ]
#                                         add[ ok ] - echo  [ ok ]
#                                         rm [fail] got 1 RM_ADDR[s] expected 2
#  - sf    [ ok ]
# Server ns stats
# MPTcpExtMPCapableSYNRX          1                  0.0
# MPTcpExtMPCapableACKRX          1                  0.0
# MPTcpExtMPJoinSynRx             3                  0.0
# MPTcpExtMPJoinAckRx             3                  0.0
# MPTcpExtEchoAdd                 1                  0.0
# MPTcpExtRmAddr                  1                  0.0
# MPTcpExtRmSubflow               1                  0.0
# Client ns stats
# MPTcpExtMPCapableSYNTX          1                  0.0
# MPTcpExtMPCapableSYNACKRX       1                  0.0
# MPTcpExtMPJoinSynAckRx          3                  0.0
# MPTcpExtAddAddr                 1                  0.0
# MPTcpExtRmAddr                  1                  0.0
# MPTcpExtRmSubflow               2                  0.0
@matttbe matttbe added the bug label Aug 11, 2021
@matttbe matttbe mentioned this issue Aug 11, 2021
Closed
@matttbe
Copy link
Member Author

matttbe commented Feb 19, 2022

Should be fixed thanks to Paolo's patches:

@matttbe matttbe closed this as completed Feb 19, 2022
@matttbe matttbe mentioned this issue Feb 21, 2022
Closed
jenkins-tessares pushed a commit that referenced this issue Jul 20, 2023
@borkmann
selftests/bpf: Add mprog API tests for BPF tcx links
c6d479b 
Add a big batch of test coverage to assert all aspects of the tcx link API:

  # ./vmtest.sh -- ./test_progs -t tc_links
  [...]
  #225     tc_links_after:OK
  #226     tc_links_append:OK
  #227     tc_links_basic:OK
  #228     tc_links_before:OK
  #229     tc_links_chain_classic:OK
  #230     tc_links_dev_cleanup:OK
  #231     tc_links_invalid:OK
  #232     tc_links_prepend:OK
  #233     tc_links_replace:OK
  #234     tc_links_revision:OK
  Summary: 10/0 PASSED, 0 SKIPPED, 0 FAILED

Signed-off-by: Daniel Borkmann <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexei Starovoitov <[email protected]>
matttbe pushed a commit that referenced this issue Nov 24, 2023
@anakryiko
selftests/bpf: reduce verboseness of reg_bounds selftest logs
57b97ec 
Reduce verboseness of test_progs' output in reg_bounds set of tests with
two changes.

First, instead of each different operator (<, <=, >, ...) being it's own
subtest, combine all different ops for the same (x, y, init_t, cond_t)
values into single subtest. Instead of getting 6 subtests, we get one
generic one, e.g.:

  #192/53  reg_bounds_crafted/(s64)[0xffffffffffffffff; 0] (s64)<op> 0xffffffff00000000:OK

Second, for random generated test cases, treat all of them as a single
test to eliminate very verbose output with random values in them. So now
we'll just get one line per each combination of (init_t, cond_t),
instead of 6 x 25 = 150 subtests before this change:

  #225     reg_bounds_rand_consts_s32_s32:OK

Given we reduce verboseness so much, it makes sense to do a bit more
random testing, so we also bump default number of random tests to 100,
up from 25. This doesn't increase runtime significantly, especially in
parallelized mode.

With all the above changes we still make sure that we have all the
information necessary for reproducing test case if it happens to fail.
That includes reporting random seed and specific operator that is
failing. Those will only be printed to console if related test/subtest
fails, so it doesn't have any added verboseness implications.

Signed-off-by: Andrii Nakryiko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexei Starovoitov <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@pabeni pabeni

Labels
bug selftests
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@matttbe @pabeni