Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210717204057.67495-1-martin.blumenstingl@googlemail.com>
 <20210717204057.67495-4-martin.blumenstingl@googlemail.com> <27d8246ef3c9755b3e6e908188ca36f7b0fab3fc.camel@sipsolutions.net>
In-Reply-To: <27d8246ef3c9755b3e6e908188ca36f7b0fab3fc.camel@sipsolutions.net>
From:   Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date:   Sun, 25 Jul 2021 23:51:09 +0200
Message-ID: <CAFBinCAzoPmtvH1Wn9dY4pFsERQ5N+0xXRG=UB1eEGe_qTf+6w@mail.gmail.com>
Subject: Re: [PATCH RFC v1 3/7] rtw88: Use rtw_iterate_stas where the iterator
 reads or writes registers
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>
Content-Type: multipart/mixed; boundary="00000000000013706305c7f9a3d5"
Precedence: bulk

--00000000000013706305c7f9a3d5
Content-Type: text/plain; charset="UTF-8"

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

--00000000000013706305c7f9a3d5
Content-Type: text/x-patch; charset="US-ASCII"; 
	name="rtw_update_sta_info-outside-rtw_iterate_stas_atomic.patch"
Content-Disposition: attachment; 
	filename="rtw_update_sta_info-outside-rtw_iterate_stas_atomic.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_krjqed3y0>
X-Attachment-Id: f_krjqed3y0

ZGlmZiAtLWdpdCBhL2RyaXZlcnMvbmV0L3dpcmVsZXNzL3JlYWx0ZWsvcnR3ODgvbWFjODAyMTEu
YyBiL2RyaXZlcnMvbmV0L3dpcmVsZXNzL3JlYWx0ZWsvcnR3ODgvbWFjODAyMTEuYwppbmRleCA3
NjUwYTFjYTBlOWUuLmJlMzljNmQwZWUzMSAxMDA2NDQKLS0tIGEvZHJpdmVycy9uZXQvd2lyZWxl
c3MvcmVhbHRlay9ydHc4OC9tYWM4MDIxMS5jCisrKyBiL2RyaXZlcnMvbmV0L3dpcmVsZXNzL3Jl
YWx0ZWsvcnR3ODgvbWFjODAyMTEuYwpAQCAtNjg5LDYgKzY4OSw4IEBAIHN0cnVjdCBydHdfaXRl
cl9iaXRyYXRlX21hc2tfZGF0YSB7CiAJc3RydWN0IHJ0d19kZXYgKnJ0d2RldjsKIAlzdHJ1Y3Qg
aWVlZTgwMjExX3ZpZiAqdmlmOwogCWNvbnN0IHN0cnVjdCBjZmc4MDIxMV9iaXRyYXRlX21hc2sg
Km1hc2s7CisJdW5zaWduZWQgaW50IG51bV9zaTsKKwlzdHJ1Y3QgcnR3X3N0YV9pbmZvICpzaVtS
VFdfTUFYX01BQ19JRF9OVU1dOwogfTsKIAogc3RhdGljIHZvaWQgcnR3X3JhX21hc2tfaW5mb191
cGRhdGVfaXRlcih2b2lkICpkYXRhLCBzdHJ1Y3QgaWVlZTgwMjExX3N0YSAqc3RhKQpAQCAtNzA5
LDcgKzcxMSw4IEBAIHN0YXRpYyB2b2lkIHJ0d19yYV9tYXNrX2luZm9fdXBkYXRlX2l0ZXIodm9p
ZCAqZGF0YSwgc3RydWN0IGllZWU4MDIxMV9zdGEgKnN0YSkKIAl9CiAKIAlzaS0+dXNlX2NmZ19t
YXNrID0gdHJ1ZTsKLQlydHdfdXBkYXRlX3N0YV9pbmZvKGJyX2RhdGEtPnJ0d2Rldiwgc2kpOwor
CisJYnJfZGF0YS0+c2lbYnJfZGF0YS0+bnVtX3NpKytdID0gc2k7CiB9CiAKIHN0YXRpYyB2b2lk
IHJ0d19yYV9tYXNrX2luZm9fdXBkYXRlKHN0cnVjdCBydHdfZGV2ICpydHdkZXYsCkBAIC03MTcs
MTEgKzcyMCwyMCBAQCBzdGF0aWMgdm9pZCBydHdfcmFfbWFza19pbmZvX3VwZGF0ZShzdHJ1Y3Qg
cnR3X2RldiAqcnR3ZGV2LAogCQkJCSAgICBjb25zdCBzdHJ1Y3QgY2ZnODAyMTFfYml0cmF0ZV9t
YXNrICptYXNrKQogewogCXN0cnVjdCBydHdfaXRlcl9iaXRyYXRlX21hc2tfZGF0YSBicl9kYXRh
OworCXVuc2lnbmVkIGludCBpOworCisJbXV0ZXhfbG9jaygmcnR3ZGV2LT5tdXRleCk7CiAKIAli
cl9kYXRhLnJ0d2RldiA9IHJ0d2RldjsKIAlicl9kYXRhLnZpZiA9IHZpZjsKIAlicl9kYXRhLm1h
c2sgPSBtYXNrOwotCXJ0d19pdGVyYXRlX3N0YXMocnR3ZGV2LCBydHdfcmFfbWFza19pbmZvX3Vw
ZGF0ZV9pdGVyLCAmYnJfZGF0YSk7CisJYnJfZGF0YS5udW1fc2kgPSAwOworCXJ0d19pdGVyYXRl
X3N0YXNfYXRvbWljKHJ0d2RldiwgcnR3X3JhX21hc2tfaW5mb191cGRhdGVfaXRlciwgJmJyX2Rh
dGEpOworCisJZm9yIChpID0gMDsgaSA8IGJyX2RhdGEubnVtX3NpOyBpKyspCisJCXJ0d191cGRh
dGVfc3RhX2luZm8ocnR3ZGV2LCBicl9kYXRhLnNpW2ldKTsKKworCW11dGV4X3VubG9jaygmcnR3
ZGV2LT5tdXRleCk7CiB9CiAKIHN0YXRpYyBpbnQgcnR3X29wc19zZXRfYml0cmF0ZV9tYXNrKHN0
cnVjdCBpZWVlODAyMTFfaHcgKmh3LAo=
--00000000000013706305c7f9a3d5--