linux-kernel - Re: [PATCH 1/6] remoteproc: Introduce rproc_detach

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]

Date:   Thu, 27 May 2021 23:17:57 -0500
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Suman Anna <s-anna@...com>
Cc:     Mathieu Poirier <mathieu.poirier@...aro.org>,
        Lokesh Vutla <lokeshvutla@...com>,
        Tero Kristo <kristo@...nel.org>,
        linux-remoteproc@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/6] remoteproc: Introduce rproc_detach_device() wrapper

On Fri 21 May 19:03 CDT 2021, Suman Anna wrote:

> The .attach() rproc ops is invoked through the helper
> rproc_attach_device(), but the .detach() ops is invoked
> directly at present. Introduce a similar wrapper function
> rproc_detach_device() for .detach() ops so that the code
> is symmetric.
> 
> Signed-off-by: Suman Anna <s-anna@...com>
> ---
>  drivers/remoteproc/remoteproc_core.c     | 2 +-
>  drivers/remoteproc/remoteproc_internal.h | 8 ++++++++
>  2 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> index 6348aaa42bbb..6019f46001c8 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1869,7 +1869,7 @@ static int __rproc_detach(struct rproc *rproc)
>  	}
>  
>  	/* Tell the remote processor the core isn't available anymore */
> -	ret = rproc->ops->detach(rproc);
> +	ret = rproc_detach_device(rproc);
>  	if (ret) {
>  		dev_err(dev, "can't detach from rproc: %d\n", ret);
>  		return ret;
> diff --git a/drivers/remoteproc/remoteproc_internal.h b/drivers/remoteproc/remoteproc_internal.h
> index a328e634b1de..931d50b6a0d1 100644
> --- a/drivers/remoteproc/remoteproc_internal.h
> +++ b/drivers/remoteproc/remoteproc_internal.h
> @@ -121,6 +121,14 @@ static inline int rproc_attach_device(struct rproc *rproc)
>  	return 0;
>  }
>  
> +static inline int rproc_detach_device(struct rproc *rproc)
> +{
> +	if (rproc->ops->detach)
> +		return rproc->ops->detach(rproc);
> +
> +	return 0;

I was going to complain that this will silently succeed to detach a
remoteproc when the driver doesn't implement detach, but then I realized
that in the current code path we just failed if it wasn't set.

So this only becomes a problem if we're out of sync between the wish to
detach and the implementation of detach, in the later patch.


But based on this, why do we allow rproc_attach_device() to succeed even
though a driver doesn't implement attach? Could we achieve the symmetry
by going the other way?

Regards,
Bjorn

> +}
> +
>  static inline
>  int rproc_fw_sanity_check(struct rproc *rproc, const struct firmware *fw)
>  {
> -- 
> 2.30.1
>