-----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 [off-list ref] wrote:
[...]

quoted

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