Linux ARM-MSM sub-architecture
 help / color / mirror / Atom feed
From: Satya Durga Srinivasu Prabhala <quic_satyap@quicinc.com>
To: <andersson@kernel.org>, <mathieu.poirier@linaro.org>
Cc: Satya Durga Srinivasu Prabhala <quic_satyap@quicinc.com>,
	<linux-remoteproc@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>
Subject: [PATCH v2] remoteproc: sysfs/debugfs: fix race while updating recovery flag
Date: Tue, 31 Jan 2023 21:46:08 -0800	[thread overview]
Message-ID: <20230201054609.14575-1-quic_satyap@quicinc.com> (raw)

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>
---
v1 -> v2:
- addressed comments from Mukesh Ojha
  1. take & release lock only while updating recovery flag
  2. update debugfs

 drivers/remoteproc/remoteproc_debugfs.c | 4 ++++
 drivers/remoteproc/remoteproc_sysfs.c   | 4 ++++
 2 files changed, 8 insertions(+)

diff --git a/drivers/remoteproc/remoteproc_debugfs.c b/drivers/remoteproc/remoteproc_debugfs.c
index b86c1d09c70c..2c44d375024e 100644
--- a/drivers/remoteproc/remoteproc_debugfs.c
+++ b/drivers/remoteproc/remoteproc_debugfs.c
@@ -226,10 +226,14 @@ rproc_recovery_write(struct file *filp, const char __user *user_buf,
 
 	if (!strncmp(buf, "enabled", count)) {
 		/* change the flag and begin the recovery process if needed */
+		mutex_lock(&rproc->lock);
 		rproc->recovery_disabled = false;
+		mutex_unlock(&rproc->lock);
 		rproc_trigger_recovery(rproc);
 	} else if (!strncmp(buf, "disabled", count)) {
+		mutex_lock(&rproc->lock);
 		rproc->recovery_disabled = true;
+		mutex_unlock(&rproc->lock);
 	} else if (!strncmp(buf, "recover", count)) {
 		/* begin the recovery process without changing the flag */
 		rproc_trigger_recovery(rproc);
diff --git a/drivers/remoteproc/remoteproc_sysfs.c b/drivers/remoteproc/remoteproc_sysfs.c
index 8c7ea8922638..628e0de9a132 100644
--- a/drivers/remoteproc/remoteproc_sysfs.c
+++ b/drivers/remoteproc/remoteproc_sysfs.c
@@ -50,10 +50,14 @@ static ssize_t recovery_store(struct device *dev,
 
 	if (sysfs_streq(buf, "enabled")) {
 		/* change the flag and begin the recovery process if needed */
+		mutex_lock(&rproc->lock);
 		rproc->recovery_disabled = false;
+		mutex_unlock(&rproc->lock);
 		rproc_trigger_recovery(rproc);
 	} else if (sysfs_streq(buf, "disabled")) {
+		mutex_lock(&rproc->lock);
 		rproc->recovery_disabled = true;
+		mutex_unlock(&rproc->lock);
 	} else if (sysfs_streq(buf, "recover")) {
 		/* begin the recovery process without changing the flag */
 		rproc_trigger_recovery(rproc);
-- 
2.38.1


             reply	other threads:[~2023-02-01  5:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-01  5:46 Satya Durga Srinivasu Prabhala [this message]
2023-02-01 12:05 ` [PATCH v2] remoteproc: sysfs/debugfs: fix race while updating recovery flag Mukesh Ojha
2023-02-07  2:12   ` Satya Durga Srinivasu Prabhala
2023-02-14 16:50 ` Bjorn Andersson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230201054609.14575-1-quic_satyap@quicinc.com \
    --to=quic_satyap@quicinc.com \
    --cc=andersson@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox