* [PATCH] remoteproc: sysfs: fix race while updating recovery flag
@ 2023-01-29 22:51 Satya Durga Srinivasu Prabhala
2023-01-30 8:03 ` Mukesh Ojha
0 siblings, 1 reply; 3+ messages in thread
From: Satya Durga Srinivasu Prabhala @ 2023-01-29 22:51 UTC (permalink / raw)
To: andersson, mathieu.poirier
Cc: Satya Durga Srinivasu Prabhala, linux-remoteproc, linux-kernel,
linux-arm-msm
When multiple clients try to update the recovery flag, it is
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.
Signed-off-by: Satya Durga Srinivasu Prabhala <quic_satyap@quicinc.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);
rproc_trigger_recovery(rproc);
} else {
+ mutex_unlock(&rproc->lock);
return -EINVAL;
}
--
2.38.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] remoteproc: sysfs: fix race while updating recovery flag
2023-01-29 22:51 [PATCH] remoteproc: sysfs: fix race while updating recovery flag Satya Durga Srinivasu Prabhala
@ 2023-01-30 8:03 ` Mukesh Ojha
2023-01-30 17:43 ` Satya Durga Srinivasu Prabhala
0 siblings, 1 reply; 3+ messages in thread
From: Mukesh Ojha @ 2023-01-30 8:03 UTC (permalink / raw)
To: Satya Durga Srinivasu Prabhala, andersson, mathieu.poirier
Cc: linux-remoteproc, linux-kernel, linux-arm-msm
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@quicinc.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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] remoteproc: sysfs: fix race while updating recovery flag
2023-01-30 8:03 ` Mukesh Ojha
@ 2023-01-30 17:43 ` Satya Durga Srinivasu Prabhala
0 siblings, 0 replies; 3+ messages in thread
From: Satya Durga Srinivasu Prabhala @ 2023-01-30 17:43 UTC (permalink / raw)
To: Mukesh Ojha, andersson, mathieu.poirier
Cc: linux-remoteproc, linux-kernel, linux-arm-msm
On 1/30/23 12:03 AM, Mukesh Ojha wrote:
>
> 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 ?
>
Yes, on SMP systems, it is possible that there can be multiple user
space clients (can simply be fuzzing kind of scripts) which could be
updating the recovery flag.
>> 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..
Yes, was trying to cover entire function, can be restricted to only when
recovery flag is being updated as well.
>>
>> Signed-off-by: Satya Durga Srinivasu Prabhala <quic_satyap@quicinc.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?
As mentioned above, was trying to cover entire function. Not really
needed in this case as such.
>
>> 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 ?
>
Thanks, yes. Debug FS needs to be updated too.
> -Mukesh
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-01-30 17:43 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-29 22:51 [PATCH] remoteproc: sysfs: fix race while updating recovery flag Satya Durga Srinivasu Prabhala
2023-01-30 8:03 ` Mukesh Ojha
2023-01-30 17:43 ` Satya Durga Srinivasu Prabhala
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.