Re: [PATCH 3/3] remoteproc: Force shutdown during device removal

[Bjorn Andersson <andersson@kernel.org>]

On Thu, Jul 23, 2026 at 12:54:58PM +0200, Konrad Dybcio wrote:
> On 7/23/26 5:52 AM, Bjorn Andersson wrote:
> > rproc_del() is subjected to the reference counted shutdown path, as such
> > a remoteproc with more than one reference will be left running as its
> > resources are released underneath it.
> > 
> > Refactor the shutdown path such that the reference count value is
> > ignored when called from rproc_del().
> > 
> > Assisted-by: OpenCode:GPT-5.5
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
> > ---
> 
> [...]
> 
> > +static int __rproc_shutdown(struct rproc *rproc, bool force)
> >  {
> >  	struct device *dev = &rproc->dev;
> >  	bool crashed;
> > @@ -2029,9 +2008,10 @@ int rproc_shutdown(struct rproc *rproc)
> >  	}
> >  	crashed = rproc->state == RPROC_CRASHED;
> >  
> > -	/* if the remote proc is still needed, bail out */
> > -	if (!atomic_dec_and_test(&rproc->power))
> > +	if (!atomic_dec_and_test(&rproc->power) && !force) {
> > +		/* The remote processor is still needed by another user. */
> >  		goto out;
> > +	}
> 
> GPT makes some unclear suggestions, effectively saying that rproc_shutdown(),
> unlike other paths, seems not to first check whether the rproc is deleting
> if the shutdown isn't forced. I think it's a valid concern.
> 

I believe you're saying that there's nothing preventing a call to
rproc_shutdown() from racing with rproc_del()?

As far as I can tell, it's possible that while rproc_del() has set
`deleting` but hasn't yet called __rproc_shutdown() another reference
holder calls rproc_shutdown().

In the event that state is RUNNING or CRASHED that caller will stop the
remoteproc under mutual exclusion and leave it in OFFLINE, then let
the rproc_del() context proceed to find that the rproc is not RUNNING or
CRASHED and will as such return an error which is ignored.

If the contexts arrives to the mutual exclusion zone in opposite order,
the secondary caller will find the rproc in OFFLINE and fail the
rproc_shutdown() call.

So, I'm not able to see why we'd need to also guard against `deleting`.


That said, and as I stated in the cover-letter, there's more dragons
hidden in these code paths.

Regards,
Bjorn

> Konrad