Hi Ping-Ke, On Fri, Jan 28, 2022 at 1:51 AM Pkshih <pkshih@xxxxxxxxxxx> wrote: [...] > > > > > > > To avoid this, we can add a flag to struct rtw_vif, and set this flag > > > when ::remove_interface. Then, only collect vif without this flag into list > > > when we use iterate_actiom(). > > > > > > As well as ieee80211_sta can do similar fix. > > > > > I would prefer my method that adds a 'bool disabled' flag to struct rtw_vif/rtw_sta > and set it when ::remove_interface/::sta_remove. Then rtw_iterate_stas() can > check this flag to decide whether does thing or not. That would indeed be a very straight forward approach and easy to read. In net/mac80211/iface.c there's some cases where after drv_remove_interface() (which internally calls our .remove_interface op) will kfree the vif (sdata). Doesn't that then result in a use-after-free if we rely on a boolean within rtw_vif? [...] > > For the interface use-case it's not clear to me how this works at all. > > rtw_ops_add_interface() has (in a simplified view): > > u8 port = 0; > > // the port variable is never changed > > rtwvif->port = port; > > rtwvif->conf = &rtw_vif_port[port]; > > rtw_info(rtwdev, "start vif %pM on port %d\n", vif->addr, rtwvif->port); > > How do multiple interfaces (vifs) work in rtw88 if the port is always > > zero? Is some kind of tracking of the used ports missing (similar to > > how we track the used station IDs - also called mac_id - in > > rtw_dev->mac_id_map)? > > The port should be allocated dynamically if we support two or more vifs. > We have internal tree that is going to support p2p by second vif. I see, thanks for clarifying this! Best regards, Martin
