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]
Message-ID: <Y1gHKwPnw+vQ/irX@bombadil.infradead.org>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ