[PATCH v5 1/2] firmware_loader: use -ETIMEDOUT instead of -EAGAIN in fw_load_sysfs_fallback

Luis Chamberlain mcgrof at kernel.org
Wed Jul 21 19:14:37 UTC 2021


But the patch still keeps it, please remove the -EAGAIN setting completely.

On Wed, Jul 21, 2021, 12:01 PM Anirudh Rayabharam <mail at anirudhrb.com>
wrote:

> The only motivation for using -EAGAIN in commit 0542ad88fbdd81bb
> ("firmware loader: Fix _request_firmware_load() return val for fw load
> abort") was to distinguish the error from -ENOMEM, and so there is no
> real reason in keeping it. Keeping -ETIMEDOU is much telling of what the
> reason for a failure is, so just use that.
>
> The rest is just trying to document a bit more of the motivations for the
> error codes, as otherwise we'd lose this information easily.
>
> Suggested-by: Luis Chamberlain <mcgrof at kernel.org>
> Signed-off-by: Anirudh Rayabharam <mail at anirudhrb.com>
> ---
>  drivers/base/firmware_loader/fallback.c | 36 ++++++++++++++++++-------
>  1 file changed, 26 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/base/firmware_loader/fallback.c
> b/drivers/base/firmware_loader/fallback.c
> index 91899d185e31..bc25bb5d1ed6 100644
> --- a/drivers/base/firmware_loader/fallback.c
> +++ b/drivers/base/firmware_loader/fallback.c
> @@ -70,7 +70,31 @@ static inline bool fw_sysfs_loading(struct fw_priv
> *fw_priv)
>
>  static inline int fw_sysfs_wait_timeout(struct fw_priv *fw_priv,  long
> timeout)
>  {
> -       return __fw_state_wait_common(fw_priv, timeout);
> +       int ret = __fw_state_wait_common(fw_priv, timeout);
> +
> +       /*
> +        * A signal could be sent to abort a wait. Consider Android's init
> +        * gettting a SIGCHLD, which in turn was the same process issuing
> the
> +        * sysfs store call for the fallback. In such cases we want to be
> able
> +        * to tell apart in userspace when a signal caused a failure on the
> +        * wait. In such cases we'd get -ERESTARTSYS.
> +        *
> +        * Likewise though another race can happen and abort the load
> earlier.
> +        *
> +        * In either case the situation is interrupted so we just inform
> +        * userspace of that and we end things right away.
> +        *
> +        * When we really time out just tell userspace it should try again,
> +        * perhaps later.
> +        */
> +       if (ret == -ERESTARTSYS || fw_state_is_aborted(fw_priv))
> +               ret = -EINTR;
> +       else if (ret == -ETIMEDOUT)
> +               ret = -EAGAIN;
> +       else if (fw_priv->is_paged_buf && !fw_priv->data)
> +               ret = -ENOMEM;
> +
> +       return ret;
>  }
>
>  struct fw_sysfs {
> @@ -526,20 +550,12 @@ static int fw_load_sysfs_fallback(struct fw_sysfs
> *fw_sysfs, long timeout)
>         }
>
>         retval = fw_sysfs_wait_timeout(fw_priv, timeout);
> -       if (retval < 0 && retval != -ENOENT) {
> +       if (retval < 0) {
>                 mutex_lock(&fw_lock);
>                 fw_load_abort(fw_sysfs);
>                 mutex_unlock(&fw_lock);
>         }
>
> -       if (fw_state_is_aborted(fw_priv)) {
> -               if (retval == -ERESTARTSYS)
> -                       retval = -EINTR;
> -               else
> -                       retval = -EAGAIN;
> -       } else if (fw_priv->is_paged_buf && !fw_priv->data)
> -               retval = -ENOMEM;
> -
>         device_del(f_dev);
>  err_put_dev:
>         put_device(f_dev);
> --
> 2.26.2
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/linux-kernel-mentees/attachments/20210721/b2f49dde/attachment.html>


More information about the Linux-kernel-mentees mailing list