Update rtsock_l3 test after 2fe5a79425c79f7b828acd91da66d97230925fc8

[arichardson]

Summary

It appears that we now get a different errno. Looking at Jenkins to find
the first commit where this test starting failing indicates that
2fe5a79425c79f7b828acd91da66d97230925fc8 is the most likely cause.

Test Plan

test now passes

[melifaro]

tests/sys/net/routing/test_rtsock_l3.c

398–399

In reality, EEXIST is a previous value from some of the system calls, and the real errno result is 0.
This test should be renamed to something like rtm_get_v4_hostbits_success - didn't have cycles to do so yet.

[arichardson]

Update to make them success tests

[arichardson]

tests/sys/net/routing/test_rtsock_l3.c

452

I'm not sure if this one should actually be a success test, but it does succeed right now.

[arichardson]

ping? This test has been failing for the past 208 Jenkins test runs and I'd really like to get CI back to green, so we can actually catch regressions.

[arichardson]

ping? This will fix two of the last 5 test failures in CI.

[melifaro]

Sorry for the belated reply, will look into it today/tomorrow

[arichardson]

In D28886#656319, @melifaro wrote:

Sorry for the belated reply, will look into it today/tomorrow

No problem at all. Thanks for looking.

[arichardson]

Weekly ping.

[arichardson]

@melifaro any chance you could have a look at this patch this week?

[arichardson]

I've posted D29528 to get CI green again and allow for more time for this patch to be reviewed.

[donner]

I do not understand enough from the testing infrastructure to help.

[emaste]

I've posted D29528 to get CI green again and allow for more time for this patch to be reviewed.

IMO this is the generally correct approach - once we have a failing test issue identified and a PR open or review in progress it makes sense to XFAIL the test

[arichardson]

Rebase after D29528

[arichardson]

@melifaro should I split the change to rtm_add_v4_no_rtf_host_failure into a separate review?

[melifaro]

In D28886#669858, @arichardson wrote:

@melifaro should I split the change to rtm_add_v4_no_rtf_host_failure into a separate review?

Sorry for taking that long! No, that's totally fine!

[arichardson]

In D28886#670565, @melifaro wrote:

In D28886#669858, @arichardson wrote:

@melifaro should I split the change to rtm_add_v4_no_rtf_host_failure into a separate review?

Sorry for taking that long! No, that's totally fine!

Just to confirm, rtm_add_v4_no_rtf_host_failure is actually supposed to succeed now?

[melifaro]

In D28886#670581, @arichardson wrote:

In D28886#670565, @melifaro wrote:

In D28886#669858, @arichardson wrote:

@melifaro should I split the change to rtm_add_v4_no_rtf_host_failure into a separate review?

Sorry for taking that long! No, that's totally fine!

Just to confirm, rtm_add_v4_no_rtf_host_failure is actually supposed to succeed now?

Yes

[arichardson]

In D28886#670585, @melifaro wrote:

In D28886#670581, @arichardson wrote:

In D28886#670565, @melifaro wrote:

In D28886#669858, @arichardson wrote:

@melifaro should I split the change to rtm_add_v4_no_rtf_host_failure into a separate review?

Sorry for taking that long! No, that's totally fine!

Just to confirm, rtm_add_v4_no_rtf_host_failure is actually supposed to succeed now?

Yes

Thanks for the review and confirming!

[olivier]

In case of system builded without epair, previously those tests were skipped because the line 'ATF_REQUIRE_KERNEL_MODULE("if_epair");'.
But now it seems they are failing in place of being skipped if epair not builded with message like:

/tests/sys/net/routing/rtsock_config.h:134: Expected errno 17, got 2, in true

[arichardson]

In D28886#671757, @olivier wrote:

In case of system builded without epair, previously those tests were skipped because the line 'ATF_REQUIRE_KERNEL_MODULE("if_epair");'.
But now it seems they are failing in place of being skipped if epair not builded with message like:

/tests/sys/net/routing/rtsock_config.h:134: Expected errno 17, got 2, in true

Sorry about that, will commit a fix shortly.