On Mon, Mar 2, 2020 at 2:45 PM Kees Cook <keescook@xxxxxxxxxxxx> wrote: Sorry it took so long to respond. I am reviving this patchset now, about to send out a new revision and I just saw this comment. > On 2/27/20 7:20 PM, Brendan Higgins wrote: > > Remove KUnit from init calls entirely, instead call directly from > > kernel_init(). > > > > Co-developed-by: Alan Maguire <alan.maguire@xxxxxxxxxx> > > Signed-off-by: Alan Maguire <alan.maguire@xxxxxxxxxx> > > Signed-off-by: Brendan Higgins <brendanhiggins@xxxxxxxxxx> > > Reviewed-by: Stephen Boyd <sboyd@xxxxxxxxxx> > > [...] > > diff --git a/init/main.c b/init/main.c > > index ee4947af823f3..7875a5c486dc4 100644 > > --- a/init/main.c > > +++ b/init/main.c > > @@ -104,6 +104,8 @@ > > #define CREATE_TRACE_POINTS > > #include <trace/events/initcall.h> > > > > +#include <kunit/test.h> > > + > > static int kernel_init(void *); > > > > extern void init_IRQ(void); > > @@ -1444,6 +1446,8 @@ static noinline void __init kernel_init_freeable(void) > > > > do_basic_setup(); > > > > + kunit_run_all_tests(); > > + > > console_on_rootfs(); > > > > /* > > I'm nervous about this happening before two key pieces of the kernel > setup, which might lead to weird timing-sensitive bugs or false > positives: > async_synchronize_full() > mark_readonly() > > Now, I realize kunit tests _should_ be self-contained, but this seems > like a possible robustness problem. Is there any reason this can't be > moved after rcu_end_inkernel_boot() in kernel_init() instead? I tried that, but it doesn't work without an initramfs. We could add an initramfs for KUnit at some point if highly desired, but I think that is outside the scope of this patchset. Additionally, this patch actually moves running tests to later in the init process, which is still an improvement over the way KUnit works today. There are some other reasons I wouldn't want to make that change right now, which will become apparent in a patch that I will send out in short order. Cheers
