linux-kernel - RE: [PATCH RFC v1 5/7] rtw88: Configure the registers from rtw_bf

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c60c9877f491411c915c64d1fc7a797a@realtek.com>
Date:   Mon, 26 Jul 2021 07:22:30 +0000
From:   Pkshih <pkshih@...ltek.com>
To:     Martin Blumenstingl <martin.blumenstingl@...glemail.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


> -----Original Message-----
> From: Martin Blumenstingl [mailto:martin.blumenstingl@...glemail.com]
> Sent: Monday, July 26, 2021 5:36 AM
> To: Pkshih
> Cc: linux-wireless@...r.kernel.org; tony0620emma@...il.com; kvalo@...eaurora.org;
> johannes@...solutions.net; netdev@...r.kernel.org; linux-kernel@...r.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@...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.
> 

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