[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFBinCAJNqbpoqSSFYYBJg818KHCKx5nFzsKZdR=D+sTXQj6dg@mail.gmail.com>
Date: Sun, 25 Jul 2021 23:36:13 +0200
From: Martin Blumenstingl <martin.blumenstingl@...glemail.com>
To: Pkshih <pkshih@...ltek.com>
Cc: "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
"tony0620emma@...il.com" <tony0620emma@...il.com>,
"kvalo@...eaurora.org" <kvalo@...eaurora.org>,
"johannes@...solutions.net" <johannes@...solutions.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Neo Jou <neojou@...il.com>,
Jernej Skrabec <jernej.skrabec@...il.com>
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@...ltek.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.
Thank you and best regards,
Martin
Powered by blists - more mailing lists