Re: Default async probing for DT based systems

On Fri, Jun 17, 2022 at 11:04 AM Saravana Kannan [off-list ref] wrote:

On Fri, Jun 17, 2022 at 2:04 AM Marek Szyprowski
[off-list ref] wrote:

quoted

Hi Saravana,

On 16.06.2022 05:24, Saravana Kannan wrote:

quoted

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel