Hi all,
Another rather vague question from me - does anyone know any reasons why we couldn't support KUNIT_EXPECT in atomic contexts?
For Address Space Isolation we have some tests that want to disable preemption. I guess this is not a totally insane thing to want to do - am I missing anything there?
You can see some examples here: https://github.com/googleprodkernel/linux-kvm/blob/asi-lpc-24/arch/x86/mm/as...
(Actually, looks like in that code we just started doing KUNIT_EXPECT in preempt-disabled regions anyway, and I never suffered any consequences until recently. Probably we just never had those assertions fail under DEBUG_ATOMIC_SLEEP).
From a very quick look, it seems like the only reason you can't KUNIT_EXPECT from atomic right now is the GFP_KERNEL allocations. So... what if we just made them GFP_ATOMIC? In general I think that's a pretty ropey approach, but maybe fine in the context of unit tests? Or, we could have variants of the assertions, or a test attribute, to just use GFP_ATOMIC in the cases where it's needed.
Is there anything else missing that would need to be done?
Alternatively, we could expose the whole context concern to the user in such a way that KUNIT_ASSERT can be used too, something like:
struct kunit_defer defer = KUNIT_INIT_DEFER(test); preempt_disable(); KUNIT_EXPECT_DEFERRED_TRUE(&defer, ...); KUNIT_ASSERT_DEFERRED_EQ(&defer, ...); preempt_enable(); // Prints failures from above, aborts if the ASSERT failed: kunit_defer_finish(&defer);
I hope that wouldn't be necessary though, it seems like a lot of API surface.
linux-kselftest-mirror@lists.linaro.org