On Tue, Jul 12, 2022 at 5:52 PM David Gow davidgow@google.com wrote:
The new KUnit module handling has KUnit test suites listed in a .kunit_test_suites section of each module. This should be loaded when the module is, but at the moment this only happens if KUnit is built-in.
Also load this when KUnit is enabled as a module: it'll not be usable unless KUnit is loaded, but such modules are likely to depend on KUnit anyway, so it's unlikely to ever be loaded needlessly.
This seems reasonable to me.
Question: what happens in this case? 1. insmod <test-module> 2. insmod kunit 3. rmmod <test-module>
I think on 3, we'll call the cleanup code, __kunit_test_suites_exit(), for <test-module>, I think? But we never called __kunit_test_suites_init(). My fear is what breaks as a result of this precondition break.
E.g. In the case that CONFIG_KUNIT_DEBUGFS is enabled, this includes a call to kunit_debugfs_destroy_suite() with no previous call to kunit_debugfs_create_suite(). That will include a call to debugfs_remove_recursive(suite->debugfs), where suite->debugfs is an uninitialized pointer.
Maybe we can treat it as "undefined behavior" for now and proceed with this patch.
In terms of long-term fixes, perhaps insmod kunit could trigger it to 1. run all built-in tests (IIUC, it doesn't right now) 2. run all the tests of currently loaded modules 3. track which modules already ran so if you rmmod + insmod kunit again, it won't rerun tests?
Daniel