On Tue, Jul 12, 2022 at 5:52 PM David Gow <davidgow@xxxxxxxxxx> 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
