linux-kernel - Re: [PATCH] drivers: core: Clarify EPROBE

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

Message-ID: <875xosqk3u.fsf@trenco.lwn.net>
Date: Tue, 12 Nov 2024 13:21:09 -0700
From: Jonathan Corbet <corbet@....net>
To: anish kumar <yesanishhere@...il.com>
Cc: linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org, anish kumar
 <yesanishhere@...il.com>
Subject: Re: [PATCH] drivers: core: Clarify EPROBE_DEFER retry mechanism

anish kumar <yesanishhere@...il.com> writes:

> The existing documentation for EPROBE_DEFER explains its purpose
> and usage, but does not specify when deferred probes are retried.
> This patch adds information about the retry mechanism to provide
> a more complete explanation of how EPROBE_DEFER works.
>
> Specifically, it clarifies that:
>
> 1. Deferred probes are added to a pending list
> 2. A successful probe of any device triggers moving all devices
>    from the pending list to an active list
> 3. A workqueue processes the active list to retry deferred probes
>
> This additional context helps developers better understand the
> behavior and implications of using EPROBE_DEFER in their drivers.
>
> Signed-off-by: anish kumar <yesanishhere@...il.com>
> ---
>  Documentation/driver-api/driver-model/driver.rst | 11 +++++++----
>  1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/driver-api/driver-model/driver.rst b/Documentation/driver-api/driver-model/driver.rst
> index 06f818b1d622..c86b948d0dfe 100644
> --- a/Documentation/driver-api/driver-model/driver.rst
> +++ b/Documentation/driver-api/driver-model/driver.rst
> @@ -171,10 +171,13 @@ released all resources it allocated.
>  Optionally, probe() may return -EPROBE_DEFER if the driver depends on
>  resources that are not yet available (e.g., supplied by a driver that
>  hasn't initialized yet).  The driver core will put the device onto the
> -deferred probe list and will try to call it again later. If a driver
> -must defer, it should return -EPROBE_DEFER as early as possible to
> -reduce the amount of time spent on setup work that will need to be
> -unwound and reexecuted at a later time.
> +deferred probe list and will retry again as and when a device or driver
> +gets added to the system. A successful probe of any device will trigger
> +moving all devices from pending list to active list. A workqueue processes
> +the active list to retry deferred probes. If a driver must defer, it
> +should return -EPROBE_DEFER as early as possible to reduce the amount
> +of time spent on setup work that will need to be unwound and reexecuted
> +at a later time.

Honestly, I don't see how this improves the situation?  How does this
improve a driver developer's work?

jon