linux-kernel - Re: [PATCH] driver core: Make deferred_probe

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] [day] [month] [year] [list]

Message-ID: <mf64xq54gxo5qkjg5c44gd2bhd6ktivo7dwuas7wfiafgzjf3o@xxjhgl3utkpx>
Date: Thu, 5 Feb 2026 07:15:21 -0600
From: Bjorn Andersson <andersson@...nel.org>
To: Hans de Goede <johannes.goede@....qualcomm.com>
Cc: Saravana Kannan <saravanak@...nel.org>, Rob Herring <robh@...nel.org>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, "Rafael J . Wysocki" <rafael@...nel.org>, 
	Danilo Krummrich <dakr@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] driver core: Make deferred_probe_timeout default a
 Kconfig option

On Thu, Feb 05, 2026 at 10:17:40AM +0100, Hans de Goede wrote:
> On 4-Feb-26 22:52, Bjorn Andersson wrote:
> > On Wed, Feb 04, 2026 at 04:00:45PM +0100, Hans de Goede wrote:
[..]
> >> Make the default timeout configurable from Kconfig to allow distro kernel
> >> configs where many of the supplier drivers are modules to set the default
> >> through Kconfig and allow using a value of -1 to disable the timeout
> >> (wait indefinitely).
> >>
> > 
> > The timeout mechanism was introduced to handle those exceptional cases
> > where distro-kernels are missing specific provider drivers but still
> > want to roll the dice and try to reach a functional user space to allow
> > the user to correct the issue.
> > 
> > There's clearly many situations where that will not work in today's
> > kernel - and as we evolve sync_state, this problem is going to grow.
> > 
> > 
> > I therefor would, once again, like to see the default value to be "no
> > timeout". We can keep the option for the user to opt-in to the
> > alternative (riskier) path. For this the command line option would
> > suffice, but with a new default.
> > 
> > 
> > The added Kconfig option of course would allow distributions to set the
> > default to -1, but I'd prefer to provide a sane default value.
> 
> AFAICT when this was discussed before opinions on this were divided.
> 
> Which is why I've chosen to just make the default configurable so
> that distros/people can chose.
> 
> I'm not necessarily against making -1 the default, but I think that
> might be a hard to sell to some people.
> 
> Note that if this lands you can always make the default -1 for
> qcom specific defconfigs.
> 

There's no such thing as "qcom specific defconfig", people should use
the one defconfig. But as you say, I will now have the possibility of
trying to take this argument to the distributions instead...

And for anyone booting the upstream kernel on a Qualcomm board
(including developers as well as e.g. kernelci.org), we just need to
make sure they are aware that they must pass deferred_probe_timeout= on
their command line, if they want a reliable outcome.


In other words, I remain convinced that having broken-by-default
settings upstream is bad.

Regards,
Bjorn