From: Daniel Scheller <d.scheller.oss@gmail.com>
To: linux-media@vger.kernel.org, mchehab@kernel.org,
mchehab@s-opensource.com
Cc: jasmin@anw.at, rjkm@metzlerbros.de
Subject: [PATCH v2] [media] dvb-frontends/stv0910: prevent consecutive mutex_unlock()'s
Date: Thu, 26 Oct 2017 20:37:37 +0200 [thread overview]
Message-ID: <20171026183737.10655-1-d.scheller.oss@gmail.com> (raw)
From: Daniel Scheller <d.scheller@gmx.net>
When calling gate_ctrl() with enable=0 if previously the mutex wasn't
locked (ie. on enable=1 failure and subdrivers not handling this properly,
or by otherwise badly behaving drivers), the i2c_lock could be unlocked
consecutively which isn't allowed. Prevent this by checking the lock
state, and actually call mutex_unlock() only when certain the lock
is actually held.
Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
Tested-by: Jasmin Jessich <jasmin@anw.at>
Cc: Ralph Metzler <rjkm@metzlerbros.de>
---
Changes from v1 to v2:
- use mutex_is_locked() instead of tracking the lock state in a separate
variable
- print message to KERN_DEBUG after a double unlock was prevented
drivers/media/dvb-frontends/stv0910.c | 24 ++++++++++++++++++++----
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb-frontends/stv0910.c b/drivers/media/dvb-frontends/stv0910.c
index 73f6df0abbfe..5d0146782488 100644
--- a/drivers/media/dvb-frontends/stv0910.c
+++ b/drivers/media/dvb-frontends/stv0910.c
@@ -1240,8 +1240,17 @@ static int gate_ctrl(struct dvb_frontend *fe, int enable)
if (write_reg(state, state->nr ? RSTV0910_P2_I2CRPT :
RSTV0910_P1_I2CRPT, i2crpt) < 0) {
- /* don't hold the I2C bus lock on failure */
- mutex_unlock(&state->base->i2c_lock);
+ /*
+ * don't hold the I2C bus lock on failure while preventing
+ * consecutive and disallowed calls to mutex_unlock()
+ */
+ if (mutex_is_locked(&state->base->i2c_lock))
+ mutex_unlock(&state->base->i2c_lock);
+ else
+ dev_dbg(&state->base->i2c->dev,
+ "%s(): prevented consecutive mutex_unlock\n",
+ __func__);
+
dev_err(&state->base->i2c->dev,
"%s() write_reg failure (enable=%d)\n",
__func__, enable);
@@ -1250,8 +1259,15 @@ static int gate_ctrl(struct dvb_frontend *fe, int enable)
state->i2crpt = i2crpt;
- if (!enable)
- mutex_unlock(&state->base->i2c_lock);
+ if (!enable) {
+ if (mutex_is_locked(&state->base->i2c_lock))
+ mutex_unlock(&state->base->i2c_lock);
+ else
+ dev_dbg(&state->base->i2c->dev,
+ "%s(): prevented consecutive mutex_unlock\n",
+ __func__);
+ }
+
return 0;
}
--
2.13.6
reply other threads:[~2017-10-26 18:37 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20171026183737.10655-1-d.scheller.oss@gmail.com \
--to=d.scheller.oss@gmail.com \
--cc=jasmin@anw.at \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=mchehab@s-opensource.com \
--cc=rjkm@metzlerbros.de \
/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 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.