From: Kalle Valo <kvalo@kernel.org>
To: Duoming Zhou <duoming@zju.edu.cn>
Cc: linux-wireless@vger.kernel.org, pontus.fuchs@gmail.com,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH wireless] ar5523: Fix deadlock bugs caused by cancel_work_sync in ar5523_stop
Date: Mon, 30 May 2022 14:24:04 +0300 [thread overview]
Message-ID: <877d63uuuj.fsf@kernel.org> (raw)
In-Reply-To: <20220522133055.96405-1-duoming@zju.edu.cn> (Duoming Zhou's message of "Sun, 22 May 2022 21:30:55 +0800")
Duoming Zhou <duoming@zju.edu.cn> writes:
> If the work item is running, the cancel_work_sync in ar5523_stop will
> not return until work item is finished. If we hold mutex_lock and use
> cancel_work_sync to wait the work item to finish, the work item such as
> ar5523_tx_wd_work and ar5523_tx_work also require mutex_lock. As a result,
> the ar5523_stop will be blocked forever. One of the race conditions is
> shown below:
>
> (Thread 1) | (Thread 2)
> ar5523_stop |
> mutex_lock(&ar->mutex) | ar5523_tx_wd_work
> | mutex_lock(&ar->mutex)
> cancel_work_sync | ...
>
> This patch moves cancel_work_sync out of mutex_lock in order to mitigate
> deadlock bugs.
>
> Fixes: b7d572e1871d ("ar5523: Add new driver")
> Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
I assume you have found this with a static checker tool, it would be
good document what tool you are using. And if you have not tested this
with real hardware clearly mention that with "Compile tested only".
> ---
> drivers/net/wireless/ath/ar5523/ar5523.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ar5523/ar5523.c b/drivers/net/wireless/ath/ar5523/ar5523.c
> index 9cabd342d15..99d6b13ffcf 100644
> --- a/drivers/net/wireless/ath/ar5523/ar5523.c
> +++ b/drivers/net/wireless/ath/ar5523/ar5523.c
> @@ -1071,8 +1071,10 @@ static void ar5523_stop(struct ieee80211_hw *hw)
> ar5523_cmd_write(ar, WDCMSG_TARGET_STOP, NULL, 0, 0);
>
> del_timer_sync(&ar->tx_wd_timer);
> + mutex_unlock(&ar->mutex);
> cancel_work_sync(&ar->tx_wd_work);
> cancel_work_sync(&ar->rx_refill_work);
> + mutex_lock(&ar->mutex);
> ar5523_cancel_rx_bufs(ar);
> mutex_unlock(&ar->mutex);
> }
Releasing a lock and taking it again looks like a hack to me. Please
test with a real device and try to find a better solution.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
next prev parent reply other threads:[~2022-05-30 11:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-22 13:30 [PATCH wireless] ar5523: Fix deadlock bugs caused by cancel_work_sync in ar5523_stop Duoming Zhou
2022-05-30 11:24 ` Kalle Valo [this message]
2022-05-31 7:50 ` duoming
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=877d63uuuj.fsf@kernel.org \
--to=kvalo@kernel.org \
--cc=davem@davemloft.net \
--cc=duoming@zju.edu.cn \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pontus.fuchs@gmail.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.