On Wed, Jul 13, 2022 at 08:24:32AM -0700, Daniel Latypov wrote: > 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? Let's please address these considerations. Luis
