Default async probing for DT based systems

[Greg Kroah-Hartman]

On Wed, Jun 22, 2022 at 07:36:24PM -0700, Saravana Kannan wrote:
> On Fri, Jun 17, 2022 at 11:04 AM Saravana Kannan <saravanak at google.com> wrote:
> >
> > On Fri, Jun 17, 2022 at 2:04 AM Marek Szyprowski
> > <m.szyprowski at samsung.com> wrote:
> > >
> > > Hi Saravana,
> > >
> > > On 16.06.2022 05:24, Saravana Kannan wrote:
> > > > Hi,
> > > >
> > > > TL;DR: I want to improve boot times by enabling async probing by
> > > > default for DT based systems. Can you give it a shot please?
> > >
> > > Yes, I've gave it a try on my test systems. It looks that there are a
> > > few issues. The first one, the most obvious to notice, is related to
> > > __request_module() calls from various drivers and frameworks. Here are
> > > some examples:
> > >
> > > ------------[ cut here ]------------
> > > WARNING: CPU: 3 PID: 73 at kernel/kmod.c:136 __request_module+0x230/0x600
> > > Modules linked in:
> > > CPU: 3 PID: 73 Comm: kworker/u12:5 Not tainted 5.19.0-rc2-next-20220615+
> > > #5203
> > > Hardware name: ARM Juno development board (r1) (DT)
> > > Workqueue: events_unbound async_run_entry_fn
> > > pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > > UDC core: g_ether: couldn't find an available UDC
> > > pc : __request_module+0x230/0x600
> > > lr : __request_module+0x228/0x600
> >
> > Ah, I think I know what these might be. Going by memory,
> > __request_module() from asyc thread context has some issues for module
> > loading. So I think a check was added like this. And I think the check
> > is triggering when it shouldn't (this isn't module context here).
> 
> My memory was right and this is indeed the spurious warning that was
> meant to cover a potential deadlock in a module load path. I was
> trying to disable this warning till we hit the point in the boot flow
> where request_module() can actually succeed. But I got stuck trying to
> figure it out.
> 
> It looks like the usermode helper that's used for module loading
> triggered by request_module() is enabled in populate_rootfs() that
> runs well before most of the initcalls are done. I was under the
> impression that init with pid 0 would be the first userspace thread
> that can start. But I don't see anything obvious that prevents the
> usermode helper from running and loading a module before init process
> has been exec'ed after we set system_state to SYSTEM_RUNNING.
> 
> Can someone clarify when is the earliest request_module() can succeed?

It can succeed very very early, when we have the initial ramfs mounted
before init runs as you sometimes need the modules there to be able to
load the device that init is on.

thanks,

greg k-h