Re: Default async probing for DT based systems

[Saravana Kannan]

On Fri, Jun 17, 2022 at 11:04 AM Saravana Kannan <saravanak@xxxxxxxxxx> wrote:
>
> On Fri, Jun 17, 2022 at 2:04 AM Marek Szyprowski
> <m.szyprowski@xxxxxxxxxxx> 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?

Thanks,
Saravana