Stopping a remoteproc that has entered a crash loop can be problematic, as shutdown is only allowed while the instance is in its running state.
One effect of this is that a remoteproc which has entered a crash state, with `recovery_disabled` can not be stopped, without first attempting the recovery. This becomes of particular interest if the user rmmod a remoteproc driver in such state, since the return value of rproc_shutdown() and rproc_del() are ignored, which means that the remoteproc is left running while the remoteproc driver will unmap memory and shut down critical resources under its feet. Another variant of this issue comes from the lack of synchronization between rproc_del() and the crash handler worker, which might be scheduled concurrently with the removal. Mutual exclusion does ensure that concurrent progress isn't made, but nothing prevent rproc_del() from returning to the remoteproc driver and have all the resources freed/unmapped while the worker is still running. Lastly, another way to trigger this faulty state is to bump the refcount for the remoteproc, in which case rproc_shutdown() becomes a nop, again leaving the remoteproc running while the remoteproc driver removes critical resources. There's certainly more work needed in these code paths, but this settles a few obvious issues. Signed-off-by: Bjorn Andersson <[email protected]> --- Bjorn Andersson (3): remoteproc: Allow shutdown of crashed processors remoteproc: Prevent crash handling to race with rproc_del() remoteproc: Force shutdown during device removal drivers/remoteproc/remoteproc_core.c | 104 ++++++++++++++++++++++------------ drivers/remoteproc/remoteproc_sysfs.c | 1 - include/linux/remoteproc.h | 13 +++-- 3 files changed, 76 insertions(+), 42 deletions(-) --- base-commit: 290aaf24a551d5a0dce037e3fab30820f9113a10 change-id: 20260723-rproc-rmmod-not-crashing-d92388aa47aa Best regards, -- Bjorn Andersson <[email protected]>
