Re: Default async probing for DT based systems

On Wed, Jun 22, 2022 at 07:36:24PM -0700, Saravana Kannan wrote:

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

quoted

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?

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

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