linux-kernel - Re: [PATCH v3] driver core: Don't set a deferred probe timeout if modules are disabled

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: <2024030722-explicit-juror-9ba7@gregkh>
Date: Thu, 7 Mar 2024 21:39:27 +0000
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Javier Martinez Canillas <javierm@...hat.com>
Cc: linux-kernel@...r.kernel.org, javier@...hile0.org,
	Andrew Halaney <ahalaney@...hat.com>,
	"Rafael J. Wysocki" <rafael@...nel.org>
Subject: Re: [PATCH v3] driver core: Don't set a deferred probe timeout if
 modules are disabled

On Wed, Feb 28, 2024 at 12:09:02AM +0100, Javier Martinez Canillas wrote:
> There is no point to schedule the workqueue to timeout the deferred probe,
> if all the initcalls are done and modules are not enabled. The default for
> this case is already 0 but can be overridden by the deferred_probe_timeout
> parameter. Let's just skip this and avoid queuing work that is not needed.

As the option is already there to set the timeout to 0, why confuse
things by trying to tie this to if modules are enabled or not?  And even
if you do want to do that, where did you now document this new system
behavior?

thanks,

greg k-h