Messages in this thread |  | | From | Pkshih <> | Subject | RE: [PATCH RFC v1 5/7] rtw88: Configure the registers from rtw_bf_assoc() outside the RCU lock | Date | Mon, 26 Jul 2021 07:22:30 +0000 |
| |
> -----Original Message----- > From: Martin Blumenstingl [mailto:martin.blumenstingl@googlemail.com] > Sent: Monday, July 26, 2021 5:36 AM > To: Pkshih > Cc: linux-wireless@vger.kernel.org; tony0620emma@gmail.com; kvalo@codeaurora.org; > johannes@sipsolutions.net; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Neo Jou; Jernej > Skrabec > Subject: Re: [PATCH RFC v1 5/7] rtw88: Configure the registers from rtw_bf_assoc() outside the RCU lock > > Hi Ping-Ke, > > On Mon, Jul 19, 2021 at 7:47 AM Pkshih <pkshih@realtek.com> wrote: > [...] > > The rcu_read_lock() in this function is used to access ieee80211_find_sta() and protect 'sta'. > > A simple way is to shrink the critical section, like: > > > > rcu_read_lock(); > > > > sta = ieee80211_find_sta(vif, bssid); > > if (!sta) { > > rtw_warn(rtwdev, "failed to find station entry for bss %pM\n", > > bssid); > > rcu_read_unlock(); > > } > > > > vht_cap = &sta->vht_cap; > > > > rcu_read_unlock(); > I agree that reducing the amount of code under the lock will help my > use-case as well > in your code-example I am wondering if we should change > struct ieee80211_sta_vht_cap *vht_cap; > vht_cap = &sta->vht_cap; > to > struct ieee80211_sta_vht_cap vht_cap; > vht_cap = sta->vht_cap; > > My thinking is that ieee80211_sta may be freed in parallel to this code running. > If that cannot happen then your code will be fine. > > So I am hoping that you can also share your thoughts on this one. >
When we enter rtw_bf_assoc(), the mutex rtwdev->mutex is held; as well as rtw_sta_add()/rtw_sta_remove(). So, I think it cannot happen that ieee80211_sta was freed in parallel.
-- Ping-Ke
|  |