On Mon, Jun 07, 2021 at 09:55:46PM -0300, Jason Gunthorpe wrote:
> EPROBE_DEFER is an internal kernel error code and it should not be leaked
> to userspace via the bind_store() sysfs. Userspace doesn't have this
> constant and cannot understand it.
>
> Further, it doesn't really make sense to have userspace trigger a deferred
> probe via bind_store(), which could eventually succeed, while
> simultaneously returning an error back.
>
> Resolve this by preventing EPROBE_DEFER from triggering a deferred probe
> and simply relay the whole situation back to userspace as a normal -EAGAIN
> code.
>
> Put this in the device_driver_attach() so the EPROBE_DEFER remains
> contained to dd.c and the probe() implementations.
>
> Signed-off-by: Jason Gunthorpe <jgg@xxxxxxxxxx>
> ---
> drivers/base/dd.c | 39 ++++++++++++++++++++++++++++-----------
> 1 file changed, 28 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index 7fb58e6219b255..edda7aad43a3f7 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -516,12 +516,17 @@ static DEVICE_ATTR_RO(state_synced);
> enum {
> /* Set on output if the -ERR has come from a probe() function */
> PROBEF_DRV_FAILED = 1 << 0,
> + /*
> + * Set on input to call driver_deferred_probe_add() if -EPROBE_DEFER
> + * is returned
> + */
> + PROBEF_SCHEDULE_DEFER = 1 << 1,
I don't understand what "PROBEF" means. Not good for something that I
am going to be forced to maintain...
Again, "flags" are horrible, but if you do have them, then they should
at least be understandable.
Please try to do this without random flag values.
thanks,
greg k-h
