All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
To: Johannes Berg <johannes@sipsolutions.net>, pkshih@realtek.com
Cc: linux-wireless@vger.kernel.org, tony0620emma@gmail.com,
	kvalo@codeaurora.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, Neo Jou <neojou@gmail.com>,
	Jernej Skrabec <jernej.skrabec@gmail.com>
Subject: Re: [PATCH RFC v1 3/7] rtw88: Use rtw_iterate_stas where the iterator reads or writes registers
Date: Sun, 25 Jul 2021 23:51:09 +0200	[thread overview]
Message-ID: <CAFBinCAzoPmtvH1Wn9dY4pFsERQ5N+0xXRG=UB1eEGe_qTf+6w@mail.gmail.com> (raw)
In-Reply-To: <27d8246ef3c9755b3e6e908188ca36f7b0fab3fc.camel@sipsolutions.net>

[-- Attachment #1: Type: text/plain, Size: 2308 bytes --]

Hi Johannes, Hi Ping-Ke,

On Mon, Jul 19, 2021 at 8:36 AM Johannes Berg <johannes@sipsolutions.net> wrote:
>
> On Sat, 2021-07-17 at 22:40 +0200, Martin Blumenstingl wrote:
> >
> > --- a/drivers/net/wireless/realtek/rtw88/mac80211.c
> > +++ b/drivers/net/wireless/realtek/rtw88/mac80211.c
> > @@ -721,7 +721,7 @@ static void rtw_ra_mask_info_update(struct rtw_dev *rtwdev,
> >       br_data.rtwdev = rtwdev;
> >       br_data.vif = vif;
> >       br_data.mask = mask;
> > -     rtw_iterate_stas_atomic(rtwdev, rtw_ra_mask_info_update_iter, &br_data);
> > +     rtw_iterate_stas(rtwdev, rtw_ra_mask_info_update_iter, &br_data);
>
> And then you pretty much immediately break that invariant here, namely
> that you're calling this within the set_bitrate_mask() method called by
> mac80211.
you are right, I was not aware of this

> That's not actually fundamentally broken today, but it does *severely*
> restrict what we can do in mac80211 wrt. locking, and I really don't
> want to keep the dozen or so locks forever, this needs simplification
> because clearly we don't even know what should be under what lock.
To me it's also not clear what the goal of the whole locking is.
The lock in ieee80211_iterate_stations_atomic is obviously for the
mac80211-internal state-machine
But I *believe* that there's a second purpose (rtw88 specific) -
here's my understanding of that part:
- rtw_sta_info contains a "mac_id" which is an identifier for a
specific station used by the rtw88 driver and is shared with the
firmware
- rtw_ops_sta_{add,remove} uses rtwdev->mutex to protect the rtw88
side of this "mac_id" identifier
- (for some reason rtw_update_sta_info doesn't use rtwdev->mutex)

So now I am wondering if the ieee80211_iterate_stations_atomic lock is
also used to protect any modifications to rtw_sta_info.
Ping-Ke, I am wondering if the attached patch (untested - to better
demonstrate what I want to say) would:
- allow us to move the register write outside of
ieee80211_iterate_stations_atomic
- mean we can keep ieee80211_iterate_stations_atomic (instead of the
non-atomic variant)
- protect the code managing the "mac_id" with rtwdev->mutex consistently

> The other cases look OK, it's being called from outside contexts
> (wowlan, etc.)
Thanks for reviewing this Johannes!


Best regards,
Martin

[-- Attachment #2: rtw_update_sta_info-outside-rtw_iterate_stas_atomic.patch --]
[-- Type: text/x-patch, Size: 1505 bytes --]

diff --git a/drivers/net/wireless/realtek/rtw88/mac80211.c b/drivers/net/wireless/realtek/rtw88/mac80211.c
index 7650a1ca0e9e..be39c6d0ee31 100644
--- a/drivers/net/wireless/realtek/rtw88/mac80211.c
+++ b/drivers/net/wireless/realtek/rtw88/mac80211.c
@@ -689,6 +689,8 @@ struct rtw_iter_bitrate_mask_data {
 	struct rtw_dev *rtwdev;
 	struct ieee80211_vif *vif;
 	const struct cfg80211_bitrate_mask *mask;
+	unsigned int num_si;
+	struct rtw_sta_info *si[RTW_MAX_MAC_ID_NUM];
 };
 
 static void rtw_ra_mask_info_update_iter(void *data, struct ieee80211_sta *sta)
@@ -709,7 +711,8 @@ static void rtw_ra_mask_info_update_iter(void *data, struct ieee80211_sta *sta)
 	}
 
 	si->use_cfg_mask = true;
-	rtw_update_sta_info(br_data->rtwdev, si);
+
+	br_data->si[br_data->num_si++] = si;
 }
 
 static void rtw_ra_mask_info_update(struct rtw_dev *rtwdev,
@@ -717,11 +720,20 @@ static void rtw_ra_mask_info_update(struct rtw_dev *rtwdev,
 				    const struct cfg80211_bitrate_mask *mask)
 {
 	struct rtw_iter_bitrate_mask_data br_data;
+	unsigned int i;
+
+	mutex_lock(&rtwdev->mutex);
 
 	br_data.rtwdev = rtwdev;
 	br_data.vif = vif;
 	br_data.mask = mask;
-	rtw_iterate_stas(rtwdev, rtw_ra_mask_info_update_iter, &br_data);
+	br_data.num_si = 0;
+	rtw_iterate_stas_atomic(rtwdev, rtw_ra_mask_info_update_iter, &br_data);
+
+	for (i = 0; i < br_data.num_si; i++)
+		rtw_update_sta_info(rtwdev, br_data.si[i]);
+
+	mutex_unlock(&rtwdev->mutex);
 }
 
 static int rtw_ops_set_bitrate_mask(struct ieee80211_hw *hw,

  reply	other threads:[~2021-07-25 21:51 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-17 20:40 [PATCH RFC v1 0/7] rtw88: prepare locking for SDIO support Martin Blumenstingl
2021-07-17 20:40 ` [PATCH RFC v1 1/7] mac80211: Add stations iterator where the iterator function may sleep Martin Blumenstingl
2021-07-19  5:46   ` Pkshih
2021-07-19  6:30   ` Johannes Berg
2021-07-17 20:40 ` [PATCH RFC v1 2/7] rtw88: Use rtw_iterate_vifs where the iterator reads or writes registers Martin Blumenstingl
2021-07-19  5:47   ` Pkshih
2021-07-25 21:31     ` Martin Blumenstingl
2021-07-26  7:22       ` Pkshih
2021-07-17 20:40 ` [PATCH RFC v1 3/7] rtw88: Use rtw_iterate_stas " Martin Blumenstingl
2021-07-19  6:36   ` Johannes Berg
2021-07-25 21:51     ` Martin Blumenstingl [this message]
2021-07-26  7:22       ` Pkshih
2021-08-09 20:00         ` Johannes Berg
2021-07-17 20:40 ` [PATCH RFC v1 4/7] rtw88: Replace usage of rtw_iterate_keys_rcu() with rtw_iterate_keys() Martin Blumenstingl
2021-07-17 20:40 ` [PATCH RFC v1 5/7] rtw88: Configure the registers from rtw_bf_assoc() outside the RCU lock Martin Blumenstingl
2021-07-19  5:47   ` Pkshih
2021-07-25 21:36     ` Martin Blumenstingl
2021-07-26  7:22       ` Pkshih
2021-07-17 20:40 ` [PATCH RFC v1 6/7] rtw88: hci: Convert rf_lock from a spinlock to a mutex Martin Blumenstingl
2021-07-17 20:40 ` [PATCH RFC v1 7/7] rtw88: fw: Convert h2c.lock " Martin Blumenstingl
2021-07-19  5:52 ` [PATCH RFC v1 0/7] rtw88: prepare locking for SDIO support Pkshih

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='CAFBinCAzoPmtvH1Wn9dY4pFsERQ5N+0xXRG=UB1eEGe_qTf+6w@mail.gmail.com' \
    --to=martin.blumenstingl@googlemail.com \
    --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=neojou@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pkshih@realtek.com \
    --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 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.