On Mon, 22 Apr 2024 at 21:36, Guenter Roeck wrote: > > On 4/22/24 06:08, Mickaël Salaün wrote: > > On Fri, Apr 19, 2024 at 04:38:01PM -0700, Guenter Roeck wrote: > >> On Fri, Apr 19, 2024 at 03:33:49PM -0700, Guenter Roeck wrote: > >>> Hi, > >>> > >>> On Tue, Mar 19, 2024 at 11:48:57AM +0100, Mickaël Salaün wrote: > >>>> Add a test case to check NULL pointer dereference and make sure it would > >>>> result as a failed test. > >>>> > >>>> The full kunit_fault test suite is marked as skipped when run on UML > >>>> because it would result to a kernel panic. > >>>> > >>>> Tested with: > >>>> ./tools/testing/kunit/kunit.py run --arch x86_64 kunit_fault > >>>> ./tools/testing/kunit/kunit.py run --arch arm64 \ > >>>> --cross_compile=aarch64-linux-gnu- kunit_fault > >>>> > >>> > >>> What is the rationale for adding those tests unconditionally whenever > >>> CONFIG_KUNIT_TEST is enabled ? This completely messes up my test system > >>> because it concludes that it is pointless to continue testing > >>> after the "Unable to handle kernel NULL pointer dereference" backtrace. > >>> At the same time, it is all or nothing, meaning I can not disable > >>> it but still run other kunit tests. > >>> > > > > CONFIG_KUNIT_TEST is to test KUnit itself. Why does this messes up your > > test system, and what is your test system? Is it related to the kernel > > warning and then the message you previously sent? > > It is not a warning, it is a BUG which terminates the affected kernel thread. > NULL pointer dereferences are normally fatal, which is why I abort tests > if one is encountered. I am not going to start introducing code into my > scripts to ignore such warnings (or BUG messages) on a case by case basis; > this would be unmaintainable. > > > https://lore.kernel.org/r/fd604ae0-5630-4745-acf2-1e51c69cf0c0@roeck-us.net > > It seems David has a solution to suppress such warning. > > > > I don't think so. My series tried to suppress warning backtraces, not BUG > messages. BUG messages can not easily be suppressed since the reaction is > architecture specific and typically fatal. > > As I said below, never mind, I just disabled CONFIG_KUNIT_TEST in my testing. > > Guenter > I think it probably makes sense to permit disabling the fault tests independently, at least until we have a way of suppressing the warnings. I've sent out a patch to add a CONFIG_KUNIT_FAULT_TEST option to disable these tests. Would that help? https://lore.kernel.org/linux-kselftest/20240423090808.242389-1-davidgow@google.com/ (The other option is to split the tests out into a totally separate file / module. I think that's an option (and would make the config option more consistent with other test options) but since they're otherwise part of the KUnit tests, I think I prefer to keep them together.) Cheers, -- David