From: Pkshih <pkshih@realtek.com>
To: Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Cc: "tony0620emma@gmail.com" <tony0620emma@gmail.com>,
"kvalo@codeaurora.org" <kvalo@codeaurora.org>,
"johannes@sipsolutions.net" <johannes@sipsolutions.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Neo Jou <neojou@gmail.com>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Ed Swierk <eswierk@gh.st>
Subject: RE: [PATCH v3 0/8] rtw88: prepare locking for SDIO support
Date: Fri, 21 Jan 2022 08:10:07 +0000 [thread overview]
Message-ID: <423f474e15c948eda4db5bc9a50fd391@realtek.com> (raw)
In-Reply-To: 20220108005533.947787-1-martin.blumenstingl@googlemail.com
[-- Attachment #1: Type: text/plain, Size: 2284 bytes --]
> -----Original Message-----
> From: Pkshih
> Sent: Wednesday, January 19, 2022 5:38 PM
> To: 'Martin Blumenstingl' <martin.blumenstingl@googlemail.com>; linux-wireless@vger.kernel.org
> Cc: tony0620emma@gmail.com; kvalo@codeaurora.org; johannes@sipsolutions.net; netdev@vger.kernel.org;
> linux-kernel@vger.kernel.org; Neo Jou <neojou@gmail.com>; Jernej Skrabec <jernej.skrabec@gmail.com>; Ed
> Swierk <eswierk@gh.st>
> Subject: RE: [PATCH v3 0/8] rtw88: prepare locking for SDIO support
>
> Hi,
>
> > -----Original Message-----
> > From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> > Sent: Saturday, January 8, 2022 8:55 AM
> > To: linux-wireless@vger.kernel.org
> > Cc: tony0620emma@gmail.com; kvalo@codeaurora.org; johannes@sipsolutions.net; netdev@vger.kernel.org;
> > linux-kernel@vger.kernel.org; Neo Jou <neojou@gmail.com>; Jernej Skrabec <jernej.skrabec@gmail.com>;
> > Pkshih <pkshih@realtek.com>; Ed Swierk <eswierk@gh.st>; Martin Blumenstingl
> > <martin.blumenstingl@googlemail.com>
> > Subject: [PATCH v3 0/8] rtw88: prepare locking for SDIO support
> >
>
> [...]
>
> I do stressed test of connection and suspend, and it get stuck after about
> 4 hours but no useful messages. I will re-build my kernel and turn on lockdep debug
> to see if it can tell me what is wrong.
>
I found some deadlock:
[ 4891.169653] CPU0 CPU1
[ 4891.169732] ---- ----
[ 4891.169799] lock(&rtwdev->mutex);
[ 4891.169874] lock(&local->sta_mtx);
[ 4891.169948] lock(&rtwdev->mutex);
[ 4891.170050] lock(&local->sta_mtx);
[ 4919.598630] CPU0 CPU1
[ 4919.598715] ---- ----
[ 4919.598779] lock(&local->iflist_mtx);
[ 4919.598900] lock(&rtwdev->mutex);
[ 4919.598995] lock(&local->iflist_mtx);
[ 4919.599092] lock(&rtwdev->mutex);
So, I add wrappers to iterate rtw_iterate_stas() and rtw_iterate_vifs() that
use _atomic version to collect sta and vif, and use list_for_each() to iterate.
Reference code is attached, and I'm still thinking if we can have better method.
--
Ping-Ke
[-- Attachment #2: 0001-rtw88-use-atomic-to-collect-stas-and-does-iterators.patch --]
[-- Type: application/octet-stream, Size: 4314 bytes --]
From c9539ea5fbbd692030381a42ad31e08490f5b804 Mon Sep 17 00:00:00 2001
From: Ping-Ke Shih <pkshih@realtek.com>
Date: Fri, 21 Jan 2022 11:09:45 +0800
Subject: [PATCH] rtw88: use atomic to collect stas and does iterators
Change-Id: I7665268d0ca859d4e3c3a60b1f15b76f5444f0ab
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
util.c | 92 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
util.h | 13 +++++----
2 files changed, 100 insertions(+), 5 deletions(-)
diff --git a/util.c b/util.c
index 2c515af2..1835968f 100644
--- a/util.c
+++ b/util.c
@@ -105,3 +105,95 @@ void rtw_desc_to_mcsrate(u16 rate, u8 *mcs, u8 *nss)
*mcs = rate - DESC_RATEMCS0;
}
}
+
+struct rtw_stas_entry {
+ struct list_head list;
+ struct ieee80211_sta *sta;
+};
+
+struct rtw_iter_stas_data {
+ struct rtw_dev *rtwdev;
+ struct list_head list;
+};
+
+void rtw_collect_sta_iter(void *data, struct ieee80211_sta *sta)
+{
+ struct rtw_iter_stas_data *iter_stas = (struct rtw_iter_stas_data *)data;
+ struct rtw_stas_entry *stas_entry;
+
+ stas_entry = kmalloc(sizeof(*stas_entry), GFP_ATOMIC);
+ if (!stas_entry)
+ return;
+
+ stas_entry->sta = sta;
+ list_add_tail(&stas_entry->list, &iter_stas->list);
+}
+
+void rtw_iterate_stas(struct rtw_dev *rtwdev,
+ void (*iterator)(void *data,
+ struct ieee80211_sta *sta),
+ void *data)
+{
+ struct rtw_iter_stas_data iter_data;
+ struct rtw_stas_entry *sta_entry, *tmp;
+
+ iter_data.rtwdev = rtwdev;
+ INIT_LIST_HEAD(&iter_data.list);
+
+ ieee80211_iterate_stations_atomic(rtwdev->hw, rtw_collect_sta_iter,
+ &iter_data);
+
+ list_for_each_entry_safe(sta_entry, tmp, &iter_data.list,
+ list) {
+ list_del_init(&sta_entry->list);
+ iterator(data, sta_entry->sta);
+ kfree(sta_entry);
+ }
+}
+
+struct rtw_vifs_entry {
+ struct list_head list;
+ struct ieee80211_vif *vif;
+ u8 mac[ETH_ALEN];
+};
+
+struct rtw_iter_vifs_data {
+ struct rtw_dev *rtwdev;
+ struct list_head list;
+};
+
+void rtw_collect_vif_iter(void *data, u8 *mac, struct ieee80211_vif *vif)
+{
+ struct rtw_iter_vifs_data *iter_stas = (struct rtw_iter_vifs_data *)data;
+ struct rtw_vifs_entry *vifs_entry;
+
+ vifs_entry = kmalloc(sizeof(*vifs_entry), GFP_ATOMIC);
+ if (!vifs_entry)
+ return;
+
+ vifs_entry->vif = vif;
+ ether_addr_copy(vifs_entry->mac, mac);
+ list_add_tail(&vifs_entry->list, &iter_stas->list);
+}
+
+void rtw_iterate_vifs(struct rtw_dev *rtwdev,
+ void (*iterator)(void *data, u8 *mac,
+ struct ieee80211_vif *vif),
+ void *data)
+{
+ struct rtw_iter_vifs_data iter_data;
+ struct rtw_vifs_entry *vif_entry, *tmp;
+
+ iter_data.rtwdev = rtwdev;
+ INIT_LIST_HEAD(&iter_data.list);
+
+ ieee80211_iterate_active_interfaces_atomic(rtwdev->hw,
+ IEEE80211_IFACE_ITER_NORMAL, rtw_collect_vif_iter, &iter_data);
+
+ list_for_each_entry_safe(vif_entry, tmp, &iter_data.list,
+ list) {
+ list_del_init(&vif_entry->list);
+ iterator(data, vif_entry->mac, vif_entry->vif);
+ kfree(vif_entry);
+ }
+}
diff --git a/util.h b/util.h
index 06a5b4c4..e4995dba 100644
--- a/util.h
+++ b/util.h
@@ -7,18 +7,21 @@
struct rtw_dev;
-#define rtw_iterate_vifs(rtwdev, iterator, data) \
- ieee80211_iterate_active_interfaces(rtwdev->hw, \
- IEEE80211_IFACE_ITER_NORMAL, iterator, data)
#define rtw_iterate_vifs_atomic(rtwdev, iterator, data) \
ieee80211_iterate_active_interfaces_atomic(rtwdev->hw, \
IEEE80211_IFACE_ITER_NORMAL, iterator, data)
-#define rtw_iterate_stas(rtwdev, iterator, data) \
- ieee80211_iterate_stations(rtwdev->hw, iterator, data)
#define rtw_iterate_stas_atomic(rtwdev, iterator, data) \
ieee80211_iterate_stations_atomic(rtwdev->hw, iterator, data)
#define rtw_iterate_keys(rtwdev, vif, iterator, data) \
ieee80211_iter_keys(rtwdev->hw, vif, iterator, data)
+void rtw_iterate_vifs(struct rtw_dev *rtwdev,
+ void (*iterator)(void *data, u8 *mac,
+ struct ieee80211_vif *vif),
+ void *data);
+void rtw_iterate_stas(struct rtw_dev *rtwdev,
+ void (*iterator)(void *data,
+ struct ieee80211_sta *sta),
+ void *data);
static inline u8 *get_hdr_bssid(struct ieee80211_hdr *hdr)
{
--
2.25.1
next prev parent reply other threads:[~2022-01-21 8:12 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-08 0:55 [PATCH v3 0/8] rtw88: prepare locking for SDIO support Martin Blumenstingl
2022-01-08 0:55 ` [PATCH v3 1/8] rtw88: Move rtw_chip_cfg_csi_rate() out of rtw_vif_watch_dog_iter() Martin Blumenstingl
2022-01-08 0:55 ` [PATCH v3 2/8] rtw88: Move rtw_update_sta_info() out of rtw_ra_mask_info_update_iter() Martin Blumenstingl
2022-01-08 0:55 ` [PATCH v3 3/8] rtw88: Use rtw_iterate_vifs where the iterator reads or writes registers Martin Blumenstingl
2022-01-08 0:55 ` [PATCH v3 4/8] rtw88: Use rtw_iterate_stas " Martin Blumenstingl
2022-01-08 0:55 ` [PATCH v3 5/8] rtw88: Replace usage of rtw_iterate_keys_rcu() with rtw_iterate_keys() Martin Blumenstingl
2022-01-08 0:55 ` [PATCH v3 6/8] rtw88: Configure the registers from rtw_bf_assoc() outside the RCU lock Martin Blumenstingl
2022-01-08 0:55 ` [PATCH v3 7/8] rtw88: hci: Convert rf_lock from a spinlock to a mutex Martin Blumenstingl
2022-01-08 0:55 ` [PATCH v3 8/8] rtw88: fw: Convert h2c.lock " Martin Blumenstingl
2022-01-19 9:38 ` [PATCH v3 0/8] rtw88: prepare locking for SDIO support Pkshih
2022-01-21 8:10 ` Pkshih [this message]
2022-01-23 19:03 ` Martin Blumenstingl
2022-01-24 2:59 ` Pkshih
2022-01-27 21:52 ` Martin Blumenstingl
2022-01-28 0:51 ` Pkshih
2022-01-30 21:40 ` Martin Blumenstingl
2022-01-31 3:06 ` Pkshih
2022-02-03 22:26 ` Johannes Berg
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=423f474e15c948eda4db5bc9a50fd391@realtek.com \
--to=pkshih@realtek.com \
--cc=eswierk@gh.st \
--cc=jernej.skrabec@gmail.com \
--cc=johannes@sipsolutions.net \
--cc=kvalo@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=martin.blumenstingl@googlemail.com \
--cc=neojou@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=tony0620emma@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).