vnet tests: verify that we can load if_epair and if_bridge

[kp]

Summary

We're going to start running many of the vnet tests in nested jails (so they
can run in parallel). That means the tests won't be able to load kernel modules,
which we commonly do for if_epair and if_bridge.

Just assume that all vnet tests need this, because so many of them do that we
don't want to manually annotate all of them.
This is essentially a no-op on non-nested tests.

Do the same for the python test framework.

While here also have pflog_init actually call pft_init. While having pflog
loaded implies we have pf too pft_init also checks for vimage support, and now
for if_epair.

MFC after: 1 month
Sponsored by: Rubicon Communications, LLC ("Netgate")

[markj]

tests/sys/common/vnet.subr

25

I think checking the exit status [ $? -eq 0 ] is a more robust way to check that this succeeded.

29

Why run this in the background? If it's because it's a slow operation (I think some interface teardown routines call EPOCH_DRAIN_CALLBACKS()), I'd much rather try to fix that. At least, there should be a comment explaining why.

[zlei]

tests/sys/common/vnet.subr

24

Is this really needed ? It should be rare that the corresponding driver has been loaded but the creating of interface fails. That should be easily caught by tests incase it happens.

[kp]

I'll post an updated version sometime next week.

tests/sys/common/vnet.subr

24

This just checks if the module is loaded, it doesn't load it.

I'm thinking of doing the same here as I did for the python code and just loading the module unconditionally. It's functionally the same as creating an interface anyway. If the module can be loaded but interface can't be created (i.e. someone broke if_epair), as you say, we're going to notice in the tests anyway.

25

Yeah, I'll change that.

29

Indeed that. There's no need to wait for the interface destruction so I decided not to.
Removing a single one isn't all that slow, but I wrote this before I added the 'is the module loaded?' check. Given that check we likely will only do the create/destroy dance once.

Arguably it might even be better to do what I did for the python tests, and just load the module rather than try to create an interface.

[melifaro]

tests/atf_python/sys/net/vnet.py

338

sorry, why do we do this (in general, as it seem to be contrary to the diff description) and in _check_.. function?

[kp]

Update coming soon.

tests/atf_python/sys/net/vnet.py

338

We assume we need if_epair for all vnet tests. In the normal case (i.e. what's default right now) we just automatically load it when we create the first epair interface. That doesn't work in the kyua execenv=jail environment (because we can't load kernel modules from a jail).

We use the existing require_module() code so that we skip the test if the module is not loaded, but first we attempt to load it. That means that in the normal case we'll load the module and satisfy the require_module check. In the execenv=jail case we'll fail to load, but we ignore errors from that. When we hit the require_module check we'll either have the module (because it was loaded before the tests were started) or we'll skip the tests.

I will rename this though, to avoid the confusing _check name.

[kp]

Review remarks

[markj]

tests/sys/common/vnet.subr

18

The use of -n with kldload below makes this redundant.

37

[kp]

tests/sys/common/vnet.subr

18

It turns out that we do need it. kldload -n still fails even if the module is already loaded when it is run from inside a jail.

Arguably that's a bug in kldload(), because all it'd let jails do is figure out if a module is loaded or not, which it can already do with kldstat(). Allowing the no-op kldload() to succeed would make the jail slightly closer to an unjailed system and that can only help more software to run in a jail.

(To be clear: I'm proposing that kldload() ought to just succeed for modules which are already loaded, even when called from within a jail. It should still refuse to actually load new modules from a jail, of course.)