linux-kernel - Re: Default async probing for DT based systems

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 22 Jun 2022 19:36:24 -0700
From:   Saravana Kannan <saravanak@...gle.com>
To:     Marek Szyprowski <m.szyprowski@...sung.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Kevin Hilman <khilman@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Marc Zyngier <maz@...nel.org>, Will Deacon <will@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Android Kernel Team <kernel-team@...roid.com>,
        Linux PM <linux-pm@...r.kernel.org>
Subject: Re: Default async probing for DT based systems

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