linux-kernel - Re: [PATCH] kernel/params.c: defer most of param_sysfs_init() to late

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 for Android: free password hash cracker in your pocket

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

Date:   Tue, 25 Oct 2022 08:56:27 -0700
From:   Luis Chamberlain <mcgrof@...nel.org>
To:     Rasmus Villemoes <linux@...musvillemoes.dk>
Cc:     Miroslav Benes <mbenes@...e.cz>,
        Christophe Leroy <christophe.leroy@...roup.eu>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] kernel/params.c: defer most of param_sysfs_init() to
 late_initcall time

On Tue, Oct 25, 2022 at 03:00:02PM +0200, Rasmus Villemoes wrote:
> param_sysfs_init(), and in particular param_sysfs_builtin() is rather
> time-consuming; for my board, it currently takes about 30ms.
> 
> That amounts to about 3% of the time budget I have from U-Boot hands
> over control to linux and linux must assume responsibility for keeping
> the external watchdog happy.
> 
> We must still continue to initialize module_kset at subsys_initcall
> time, since otherwise any request_module() would fail in
> mod_sysfs_init().

It would be good to document this through a comment.

> However, the bulk of the work in
> param_sysfs_builtin(), namely populating /sys/module/*/version and/or
> /sys/module/*/parameters/ for builtin modules, can be deferred to
> late_initcall time - there's no userspace yet anyway to observe
> contents of /sys or the lack thereof.
> 

Other than that, this looks good and looks cautious enough.

Acked-by: Luis Chamberlain <mcgrof@...nel.org>

Happy to take this in through moduels and give this a spin on linux-next
to see what blows up early. Can you send a v2 with a small code comment for
the above?

  Luis