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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 5 May 2020 19:05:40 -0700 From: Bjorn Andersson <bjorn.andersson@...aro.org> To: Loic Pallardy <loic.pallardy@...com> Cc: ohad@...ery.com, mathieu.poirier@...aro.org, linux-remoteproc@...r.kernel.org, linux-kernel@...r.kernel.org, arnaud.pouliquen@...com, benjamin.gaignard@...aro.org, fabien.dessenne@...com, s-anna@...com Subject: Re: [RFC 2/2] remoteproc: core: keep rproc in crash state in case of recovery failure On Wed 11 Mar 03:54 PDT 2020, Loic Pallardy wrote: > When an error occurs during recovery procedure, internal rproc > variables may be unaligned: > - state is set to RPROC_OFFLINE > - power atomic not equal to 0 > which is normal as only rproc_stop() has been executed and not > rproc_shutdown() > > In such case, rproc_boot() can be re-executed by client to > reboot co-processor. > > This patch proposes to keep rproc in RPROC_CRASHED state in case > of recovery failure to be coherent with recovery disabled mode. > > Signed-off-by: Loic Pallardy <loic.pallardy@...com> > --- > drivers/remoteproc/remoteproc_core.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c > index 7ac87a75cd1b..def4f9fc881d 100644 > --- a/drivers/remoteproc/remoteproc_core.c > +++ b/drivers/remoteproc/remoteproc_core.c > @@ -1679,6 +1679,12 @@ int rproc_trigger_recovery(struct rproc *rproc) > release_firmware(firmware_p); > > unlock_mutex: > + /* > + * In case of error during recovery sequence restore rproc > + * state in CRASHED > + */ > + if (ret) > + rproc->state = RPROC_CRASHED; Got back to this after looking at Mathieu's synchronization series, I think it would be cleaner if we move the rproc->state update out of rproc_start() and rproc_stop(). That way we would leave the state in CRASHED state throughout the recovery process, which I think makes it easier to reason about the various states and their transitions. Regards, Bjorn > mutex_unlock(&rproc->lock); > return ret; > } > -- > 2.7.4 >
Powered by blists - more mailing lists