[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <202006241345.43D22CB261@keescook>
Date: Wed, 24 Jun 2020 13:48:13 -0700
From: Kees Cook <keescook@...omium.org>
To: Brendan Higgins <brendanhiggins@...gle.com>
Cc: Frank Rowand <frowand.list@...il.com>,
Jeff Dike <jdike@...toit.com>,
Richard Weinberger <richard@....at>,
Anton Ivanov <anton.ivanov@...bridgegreys.com>,
Arnd Bergmann <arnd@...db.de>,
Shuah Khan <skhan@...uxfoundation.org>,
Alan Maguire <alan.maguire@...cle.com>,
Iurii Zaikin <yzaikin@...gle.com>,
David Gow <davidgow@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>, rppt@...ux.ibm.com,
Greg KH <gregkh@...uxfoundation.org>,
Stephen Boyd <sboyd@...nel.org>,
Logan Gunthorpe <logang@...tatee.com>,
Luis Chamberlain <mcgrof@...nel.org>,
linux-um <linux-um@...ts.infradead.org>,
linux-arch@...r.kernel.org,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@...r.kernel.org>,
KUnit Development <kunit-dev@...glegroups.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>
Subject: Re: [PATCH v3 4/7] init: main: add KUnit to kernel init
On Wed, Jun 24, 2020 at 01:20:35PM -0700, Brendan Higgins wrote:
> On Mon, Mar 2, 2020 at 2:45 PM Kees Cook <keescook@...omium.org> wrote:
> > 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
I'm curious to know what happened. To me it looks like it would be
possible to do it in here:
system_state = SYSTEM_RUNNING;
numa_default_policy();
rcu_end_inkernel_boot();
do_sysctl_args();
put it here?
if (ramdisk_execute_command) {
ret = run_init_process(ramdisk_execute_command);
That should be before anything happens with an initramfs. (i.e. boot the
kernel without an initrd and it won't be required...)
> 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.
Later is better! :)
> 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.
Cool; I'll look for it.
--
Kees Cook
Powered by blists - more mailing lists