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: 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ