From: Ivo van Doorn <ivdoorn@gmail.com>
To: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: John Linville <linville@tuxdriver.com>, linux-wireless@vger.kernel.org
Subject: Re: [PATCH 4/4] rfkill: mutex fixes
Date: Sat, 19 Jul 2008 14:47:25 +0200 [thread overview]
Message-ID: <200807191447.25603.IvDoorn@gmail.com> (raw)
In-Reply-To: <1216150327-10904-5-git-send-email-hmh@hmh.eng.br>
On Tuesday 15 July 2008, Henrique de Moraes Holschuh wrote:
> There are two mutexes in rfkill:
>
> rfkill->mutex, which protects some of the fields of a rfkill struct, and is
> also used for callback serialization.
>
> rfkill_mutex, which protects the global state, the list of registered
> rfkill structs and rfkill->claim.
>
> Make sure to use the correct mutex, and to not miss locking rfkill->mutex
> even when we already took rfkill_mutex.
>
> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
> Cc: Ivo van Doorn <IvDoorn@gmail.com>
> ---
> net/rfkill/rfkill.c | 29 +++++++++++++++++++----------
> 1 files changed, 19 insertions(+), 10 deletions(-)
>
> diff --git a/net/rfkill/rfkill.c b/net/rfkill/rfkill.c
> index fc3a4fd..ac205ec 100644
> --- a/net/rfkill/rfkill.c
> +++ b/net/rfkill/rfkill.c
> @@ -150,7 +150,7 @@ static void update_rfkill_state(struct rfkill *rfkill)
> * even if the radio is in RFKILL_STATE_HARD_BLOCKED state, so as to
> * give the driver a hint that it should double-BLOCK the transmitter.
> *
> - * Caller must have aquired rfkill_mutex.
> + * Caller must have acquired rfkill->mutex.
Should rfkill_toggle_radio() not grab the rfkill->mutex itself?
At the moment every caller to rfkill_toggle_radio() does:
mutex_lock(&rfkill->mutex);
rfkill_toggle_radio(rfkill, state, 0);
mutex_unlock(&rfkill->mutex);
without anything in between, so perhaps the safest way would be moving
the locking requirement into the function.
> */
> static int rfkill_toggle_radio(struct rfkill *rfkill,
> enum rfkill_state state,
> @@ -216,8 +216,11 @@ void rfkill_switch_all(enum rfkill_type type, enum rfkill_state state)
> rfkill_states[type] = state;
>
> list_for_each_entry(rfkill, &rfkill_list, node) {
> - if ((!rfkill->user_claim) && (rfkill->type == type))
> + if ((!rfkill->user_claim) && (rfkill->type == type)) {
> + mutex_lock(&rfkill->mutex);
> rfkill_toggle_radio(rfkill, state, 0);
> + mutex_unlock(&rfkill->mutex);
> + }
> }
>
> mutex_unlock(&rfkill_mutex);
> @@ -228,7 +231,7 @@ EXPORT_SYMBOL(rfkill_switch_all);
> * rfkill_epo - emergency power off all transmitters
> *
> * This kicks all rfkill devices to RFKILL_STATE_SOFT_BLOCKED, ignoring
> - * everything in its path but rfkill_mutex.
> + * everything in its path but rfkill_mutex and rfkill->mutex.
> */
> void rfkill_epo(void)
> {
> @@ -236,7 +239,9 @@ void rfkill_epo(void)
>
> mutex_lock(&rfkill_mutex);
> list_for_each_entry(rfkill, &rfkill_list, node) {
> + mutex_lock(&rfkill->mutex);
> rfkill_toggle_radio(rfkill, RFKILL_STATE_SOFT_BLOCKED, 1);
> + mutex_unlock(&rfkill->mutex);
> }
> mutex_unlock(&rfkill_mutex);
> }
> @@ -372,6 +377,9 @@ static ssize_t rfkill_claim_store(struct device *dev,
> if (!capable(CAP_NET_ADMIN))
> return -EPERM;
>
> + if (rfkill->user_claim_unsupported)
> + return -EOPNOTSUPP;
> +
> /*
> * Take the global lock to make sure the kernel is not in
> * the middle of rfkill_switch_all
> @@ -380,19 +388,17 @@ static ssize_t rfkill_claim_store(struct device *dev,
> if (error)
> return error;
>
> - if (rfkill->user_claim_unsupported) {
> - error = -EOPNOTSUPP;
> - goto out_unlock;
> - }
> if (rfkill->user_claim != claim) {
> - if (!claim)
> + if (!claim) {
> + mutex_lock(&rfkill->mutex);
> rfkill_toggle_radio(rfkill,
> rfkill_states[rfkill->type],
> 0);
> + mutex_unlock(&rfkill->mutex);
> + }
> rfkill->user_claim = claim;
> }
>
> -out_unlock:
> mutex_unlock(&rfkill_mutex);
>
> return error ? error : count;
> @@ -521,8 +527,11 @@ static void rfkill_remove_switch(struct rfkill *rfkill)
> {
> mutex_lock(&rfkill_mutex);
> list_del_init(&rfkill->node);
> - rfkill_toggle_radio(rfkill, RFKILL_STATE_SOFT_BLOCKED, 1);
> mutex_unlock(&rfkill_mutex);
> +
> + mutex_lock(&rfkill->mutex);
> + rfkill_toggle_radio(rfkill, RFKILL_STATE_SOFT_BLOCKED, 1);
> + mutex_unlock(&rfkill->mutex);
Not sure about this one, something tells me it should be something like:
mutex_lock(&rfkill_mutex);
list_del_init(&rfkill->node);
mutex_lock(&rfkill->mutex);
rfkill_toggle_radio(rfkill, RFKILL_STATE_SOFT_BLOCKED, 1);
mutex_unlock(&rfkill->mutex);
mutex_unlock(&rfkill_mutex);
Ivo
next prev parent reply other threads:[~2008-07-19 12:32 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-15 19:32 [GIT PATCH] rfkill fixes, set 2 Henrique de Moraes Holschuh
2008-07-15 19:32 ` [PATCH 1/4] rfkill: document rfkill_force_state as required Henrique de Moraes Holschuh
2008-07-19 12:34 ` Ivo van Doorn
2008-07-19 13:42 ` Henrique de Moraes Holschuh
2008-07-15 19:32 ` [PATCH 2/4] rfkill: fix led-trigger unregister order in error unwind Henrique de Moraes Holschuh
2008-07-19 12:35 ` Ivo van Doorn
2008-07-15 19:32 ` [PATCH 3/4] rfkill: document the rfkill struct locking Henrique de Moraes Holschuh
2008-07-19 12:39 ` Ivo van Doorn
2008-07-19 13:43 ` Henrique de Moraes Holschuh
2008-07-15 19:32 ` [PATCH 4/4] rfkill: mutex fixes Henrique de Moraes Holschuh
2008-07-17 4:56 ` Michael Buesch
2008-07-17 11:33 ` drago01
2008-07-17 12:10 ` Henrique de Moraes Holschuh
2008-07-19 12:47 ` Ivo van Doorn [this message]
2008-07-19 14:19 ` Henrique de Moraes Holschuh
2008-07-19 14:50 ` Ivo van Doorn
2008-07-19 14:51 ` Ivo van Doorn
2008-07-16 16:29 ` [GIT PATCH] rfkill fixes, set 2 Dan Williams
2008-07-17 11:54 ` Henrique de Moraes Holschuh
2008-07-17 21:56 ` [PATCH 5/4] rfkill: query EV_SW states when rfkill-input connects to a input device Henrique de Moraes Holschuh
2008-07-19 4:01 ` Dmitry Torokhov
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=200807191447.25603.IvDoorn@gmail.com \
--to=ivdoorn@gmail.com \
--cc=hmh@hmh.eng.br \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
/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.