LKML Archive on
help / color / mirror / Atom feed
From: Pierre-Louis Bossart <>
	Andy Shevchenko <>,
	Dan Williams <>,
	Jason Gunthorpe <>, Christoph Hellwig <>,
	Greg Kroah-Hartman <>,
	"Rafael J . Wysocki" <>,,
	Pierre-Louis Bossart <>
Subject: [RFC PATCH 0/2] driver core: kick deferred probe from delayed context
Date: Tue, 17 Aug 2021 14:00:55 -0500	[thread overview]
Message-ID: <> (raw)

The deferred probe mechanism uses a successful driver probe/attach as
a trigger to revisit the list of deferred probe devices. This works in
most cases, except when the probe success is not a valid indicator of
resources being available.

In that case, a race condition may occur, where the device/driver core
framework will attempt to probe a device that depends on resources
before those resources are available, resulting in a -EPROBE_DEFER
error and a deferred probe device that will never be initialized.

The example provided in this RFC relies on the probe workqueue used
for the HDaudio support where we simultaneously:
a) need to use request_module()
b) cannot use an async probe due to the use of request_module()
c) cannot block the probe of other drivers
In this example, the deferred probe can be kicked when the workqueue

The use of request_firmware_nowait() is another conceptual example,
where a domain-specific callback can enable resources *after* the
probe returns, for example by downloading the firmware, booting a
processor and waiting for the processor to be ready for interaction
with the Linux host. In this second example, the deferred probe could
be kicked when the 'cont' callback completes.

This patchset suggests a 7-line change to solve race conditions in
these examples with delayed work.


a) During Intel internal reviews, Andy Shevchenko pointed out another
known issue with deferred probe [1]. This patchset is unrelated and
does not claim to solve the problem raised by Andy.

b) one possible objection is that this patchset does not suppress a
possibly unnecessary round of evaluation of deferred probe devices. It
did not feel necessary to any of us to minimize the occurrences of
EPROBE_DEFER but instead to make sure the device waiting for
resources successfully probes in the end.

c) another objection might be that the driver core should know about
such dependencies. It would be desirable but in the cases we've
encountered such dependencies are highly domain-specific and not
necessarily straightforward to describe. There's been multiple
endeavors to improve the description of dependencies, this patchset
only focuses on the deferred probe framework, with an improvement when
the provider of resources makes these resources available after its
probe returns.


Pierre-Louis Bossart (2):
  driver core: export driver_deferred_probe_trigger()
  ASoC: SOF: trigger re-probing of deferred devices from workqueue

 drivers/base/dd.c             | 3 ++-
 include/linux/device/driver.h | 1 +
 sound/soc/sof/core.c          | 3 +++
 3 files changed, 6 insertions(+), 1 deletion(-)

base-commit: 8d1998893cd5e3488cd95529f60a187e3009d14b

             reply	other threads:[~2021-08-17 19:01 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-17 19:00 Pierre-Louis Bossart [this message]
2021-08-17 19:00 ` [RFC PATCH 1/2] driver core: export driver_deferred_probe_trigger() Pierre-Louis Bossart
2021-08-18  5:44   ` Greg Kroah-Hartman
2021-08-18 11:57     ` Mark Brown
2021-08-18 13:22       ` Greg Kroah-Hartman
2021-08-18 13:48         ` Mark Brown
2021-08-18 14:51           ` Pierre-Louis Bossart
2021-08-18 14:59             ` Dan Williams
2021-08-18 15:28             ` Greg Kroah-Hartman
2021-08-18 15:53               ` Pierre-Louis Bossart
2021-08-18 16:49                 ` Greg Kroah-Hartman
2021-08-18 17:52                   ` Mark Brown
2021-08-18 18:09                   ` Pierre-Louis Bossart
2021-08-18 18:28                     ` Mark Brown
2021-08-17 19:00 ` [RFC PATCH 2/2] ASoC: SOF: trigger re-probing of deferred devices from workqueue Pierre-Louis Bossart
2021-08-18 12:07   ` Mark Brown
2021-08-18 15:25     ` Pierre-Louis Bossart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [RFC PATCH 0/2] driver core: kick deferred probe from delayed context' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).