Messages in this thread | | | From | Saravana Kannan <> | Date | Wed, 22 Jun 2022 19:36:24 -0700 | Subject | Re: Default async probing for DT based systems |
| |
On Fri, Jun 17, 2022 at 11:04 AM Saravana Kannan <saravanak@google.com> wrote: > > On Fri, Jun 17, 2022 at 2:04 AM Marek Szyprowski > <m.szyprowski@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?
Thanks, Saravana
| |