On Thu, Jan 6, 2022 at 11:22 PM Kumar Kartikeya Dwivedi
[off-list ref] wrote:

On Fri, Jan 07, 2022 at 01:09:04AM IST, Andrii Nakryiko wrote:

quoted

On Thu, Jan 6, 2022 at 1:04 AM Kumar Kartikeya Dwivedi [off-list ref] wrote:

quoted

On Wed, Jan 05, 2022 at 11:50:33AM IST, Alexei Starovoitov wrote:

quoted

On Sun, Jan 02, 2022 at 09:51:15PM +0530, Kumar Kartikeya Dwivedi wrote:

quoted

This adds a complete test case to ensure we never take references to
modules not in MODULE_STATE_LIVE, which can lead to UAF, and it also
ensures we never access btf->kfunc_set_tab in an inconsistent state.

The test uses userfaultfd to artifically widen the race.

Fancy!
Does it have to use a different module?
Can it be part of bpf_testmod somehow?

I was thinking of doing it with bpf_testmod, but then I realised it would be a
problem with parallel mode of test_progs, where another selftest in parallel may
rely on bpf_testmod (which this test would unload, load and make it fault, and
then fail the load before restoring it by loading again), so I went with
bpf_testmod.

Maybe we can hardcode a list of tests to be executed serially in --workers=n > 1
mode? All serial tests are then executed in the beginning (or end), and then it
starts invoking others in parallel as usual.

you can mark test as serial with "serial_" prefix, grep for that, we

Thanks for pointing that out!

quoted

have a bunch of tests like this. But if you are going to unload and
reload bpf_testmod, you will be forcing any bpf_testmod-using test to
be serial, which I'm not sure is such a great idea.

Didn't get the last part, based on my reading it will execute serial tests one
by one (after finishing parallel tests), so if my serial test restores the
loaded bpf_testmod after completing, it shouldn't really impact other tests,
right? Did I miss something?

No, sorry, my bad. You are right, we'll run all serial tests after (or
maybe before, don't remember) all the parallel tests completed. So
yeah, just mark this one serial.

--
Kartikeya