On Fri, Jan 07, 2022 at 01:09:04AM IST, Andrii Nakryiko wrote: > On Thu, Jan 6, 2022 at 1:04 AM Kumar Kartikeya Dwivedi <memxor@xxxxxxxxx> wrote: > > > > On Wed, Jan 05, 2022 at 11:50:33AM IST, Alexei Starovoitov wrote: > > > On Sun, Jan 02, 2022 at 09:51:15PM +0530, Kumar Kartikeya Dwivedi wrote: > > > > 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! > 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? -- Kartikeya
