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
| ||
|
Message-ID: <d9708f4b-e533-e400-acbf-3d8e816f242e@quicinc.com> Date: Mon, 30 Jan 2023 13:33:42 +0530 From: Mukesh Ojha <quic_mojha@...cinc.com> To: Satya Durga Srinivasu Prabhala <quic_satyap@...cinc.com>, <andersson@...nel.org>, <mathieu.poirier@...aro.org> CC: <linux-remoteproc@...r.kernel.org>, <linux-kernel@...r.kernel.org>, <linux-arm-msm@...r.kernel.org> Subject: Re: [PATCH] remoteproc: sysfs: fix race while updating recovery flag On 1/30/2023 4:21 AM, Satya Durga Srinivasu Prabhala wrote: > When multiple clients try to update the recovery flag, it is Multiple user-space clients ? > possible that, race condition would lead to undesired results > as updates to recovery flag isn't protected by any mechanism > today. To avoid such issues, take remoteproc mutex lock before > updating recovery flag and release the lock once done. But your patch also adds locks for the case which does not update recovery flag.. > > Signed-off-by: Satya Durga Srinivasu Prabhala <quic_satyap@...cinc.com> > --- > drivers/remoteproc/remoteproc_sysfs.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/drivers/remoteproc/remoteproc_sysfs.c b/drivers/remoteproc/remoteproc_sysfs.c > index 8c7ea8922638..ec37176e1589 100644 > --- a/drivers/remoteproc/remoteproc_sysfs.c > +++ b/drivers/remoteproc/remoteproc_sysfs.c > @@ -48,16 +48,21 @@ static ssize_t recovery_store(struct device *dev, > { > struct rproc *rproc = to_rproc(dev); > > + mutex_lock(&rproc->lock); > if (sysfs_streq(buf, "enabled")) { > /* change the flag and begin the recovery process if needed */ > rproc->recovery_disabled = false; > + mutex_unlock(&rproc->lock); > rproc_trigger_recovery(rproc); > } else if (sysfs_streq(buf, "disabled")) { > rproc->recovery_disabled = true; > + mutex_unlock(&rproc->lock); > } else if (sysfs_streq(buf, "recover")) { > /* begin the recovery process without changing the flag */ > + mutex_unlock(&rproc->lock); is it really needed for this case? > rproc_trigger_recovery(rproc); > } else { > + mutex_unlock(&rproc->lock); same here.. > return -EINVAL; > } > Do you also need to add lock for rproc_recovery_write in drivers/remoteproc/remoteproc_debugfs.c ? -Mukesh
Powered by blists - more mailing lists