| Message ID | 20230622160501.40666-1-nbd@nbd.name (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Johannes Berg |
| Headers | show |
| Series | cfg80211: fix sband iftype data lookup for AP_VLAN | expand |
On Thu, 2023-06-22 at 18:05 +0200, Felix Fietkau wrote: > Since AP_VLAN interfaces are not pushed to the driver, > That's a mac80211 thing though. > the driver should not > be expected to register iftype data for them. > Map them to the regular AP iftype on lookup. And this is in cfg80211 - not sure that seems right? OTOH I'd expect no callers with VLAN here, it doesn't really make sense since they're not a standalone mode that actually has HE/EHT, but still, seems odd this way? What's actually calling it? I'm guessing somewhere in mac80211? johannes
On 22.06.23 18:07, Johannes Berg wrote: > On Thu, 2023-06-22 at 18:05 +0200, Felix Fietkau wrote: >> Since AP_VLAN interfaces are not pushed to the driver, >> > That's a mac80211 thing though. > >> the driver should not >> be expected to register iftype data for them. >> Map them to the regular AP iftype on lookup. > > And this is in cfg80211 - not sure that seems right? > > OTOH I'd expect no callers with VLAN here, it doesn't really make sense > since they're not a standalone mode that actually has HE/EHT, but still, > seems odd this way? > > What's actually calling it? I'm guessing somewhere in mac80211? Yes, I guess only mac80211 is affected. I put in the cfg80211 prefix because that's what the header file belongs to. I made the patch in response to this: https://patchwork.kernel.org/project/linux-wireless/patch/20230605152141.17434-4-shayne.chen@mediatek.com/ I found that there are several calls to ieee80211_get_he_iftype_cap and ieee80211_get_eht_iftype_cap, which could be affected by this issue. I thought dealing with this in a single place would be better than playing whac-a-mole by fixing it at the call sites. - Felix
On Thu, 2023-06-22 at 18:25 +0200, Felix Fietkau wrote: > On 22.06.23 18:07, Johannes Berg wrote: > > On Thu, 2023-06-22 at 18:05 +0200, Felix Fietkau wrote: > > > Since AP_VLAN interfaces are not pushed to the driver, > > > > > That's a mac80211 thing though. > > > > > the driver should not > > > be expected to register iftype data for them. > > > Map them to the regular AP iftype on lookup. > > > > And this is in cfg80211 - not sure that seems right? > > > > OTOH I'd expect no callers with VLAN here, it doesn't really make sense > > since they're not a standalone mode that actually has HE/EHT, but still, > > seems odd this way? > > > > What's actually calling it? I'm guessing somewhere in mac80211? > > Yes, I guess only mac80211 is affected. I put in the cfg80211 prefix > because that's what the header file belongs to. > > I made the patch in response to this: > https://patchwork.kernel.org/project/linux-wireless/patch/20230605152141.17434-4-shayne.chen@mediatek.com/ OK, sure, that also doesn't really make sense. > I found that there are several calls to ieee80211_get_he_iftype_cap and > ieee80211_get_eht_iftype_cap, which could be affected by this issue. > I thought dealing with this in a single place would be better than playing > whac-a-mole by fixing it at the call sites. > I replaced almost all of them with ieee80211_get_he_iftype_cap_vif() so it shouldn't be that bad? Looks like I forgot some though. johannes
On 22.06.23 18:41, Johannes Berg wrote: > On Thu, 2023-06-22 at 18:25 +0200, Felix Fietkau wrote: >> On 22.06.23 18:07, Johannes Berg wrote: >> > On Thu, 2023-06-22 at 18:05 +0200, Felix Fietkau wrote: >> > > Since AP_VLAN interfaces are not pushed to the driver, >> > > >> > That's a mac80211 thing though. >> > >> > > the driver should not >> > > be expected to register iftype data for them. >> > > Map them to the regular AP iftype on lookup. >> > >> > And this is in cfg80211 - not sure that seems right? >> > >> > OTOH I'd expect no callers with VLAN here, it doesn't really make sense >> > since they're not a standalone mode that actually has HE/EHT, but still, >> > seems odd this way? >> > >> > What's actually calling it? I'm guessing somewhere in mac80211? >> >> Yes, I guess only mac80211 is affected. I put in the cfg80211 prefix >> because that's what the header file belongs to. >> >> I made the patch in response to this: >> https://patchwork.kernel.org/project/linux-wireless/patch/20230605152141.17434-4-shayne.chen@mediatek.com/ > > OK, sure, that also doesn't really make sense. > >> I found that there are several calls to ieee80211_get_he_iftype_cap and >> ieee80211_get_eht_iftype_cap, which could be affected by this issue. >> I thought dealing with this in a single place would be better than playing >> whac-a-mole by fixing it at the call sites. >> > > I replaced almost all of them with ieee80211_get_he_iftype_cap_vif() so > it shouldn't be that bad? Looks like I forgot some though. I guess one advantage in using my fix would be that it's way easier to backport. How about using my fix initially (with a changed prefix if you prefer), and then replace it once the call sites have been switched over to ieee80211_get_he_iftype_cap_vif? - Felix
On Thu, 2023-06-22 at 18:50 +0200, Felix Fietkau wrote: > On 22.06.23 18:41, Johannes Berg wrote: > > On Thu, 2023-06-22 at 18:25 +0200, Felix Fietkau wrote: > > > On 22.06.23 18:07, Johannes Berg wrote: > > > > On Thu, 2023-06-22 at 18:05 +0200, Felix Fietkau wrote: > > > > > Since AP_VLAN interfaces are not pushed to the driver, > > > > > > > > > That's a mac80211 thing though. > > > > > > > > > the driver should not > > > > > be expected to register iftype data for them. > > > > > Map them to the regular AP iftype on lookup. > > > > > > > > And this is in cfg80211 - not sure that seems right? > > > > > > > > OTOH I'd expect no callers with VLAN here, it doesn't really make sense > > > > since they're not a standalone mode that actually has HE/EHT, but still, > > > > seems odd this way? > > > > > > > > What's actually calling it? I'm guessing somewhere in mac80211? > > > > > > Yes, I guess only mac80211 is affected. I put in the cfg80211 prefix > > > because that's what the header file belongs to. > > > > > > I made the patch in response to this: > > > https://patchwork.kernel.org/project/linux-wireless/patch/20230605152141.17434-4-shayne.chen@mediatek.com/ > > > > OK, sure, that also doesn't really make sense. > > > > > I found that there are several calls to ieee80211_get_he_iftype_cap and > > > ieee80211_get_eht_iftype_cap, which could be affected by this issue. > > > I thought dealing with this in a single place would be better than playing > > > whac-a-mole by fixing it at the call sites. > > > > > > > I replaced almost all of them with ieee80211_get_he_iftype_cap_vif() so > > it shouldn't be that bad? Looks like I forgot some though. > > I guess one advantage in using my fix would be that it's way easier to > backport. > How about using my fix initially (with a changed prefix if you prefer), > and then replace it once the call sites have been switched over to > ieee80211_get_he_iftype_cap_vif? > Actually, I don't even mind the fix itself that much, I just think the description is a bit misleading :-) How about just describing it as something like "AP_VLAN is virtual so it doesn't really exist as a type for capabilities; surely AP was intended"? I can kind of see how this might happen too, you have a STA, check the interface, etc. johannes
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index 7c7d03aa9d06..d6fa7c8767ad 100644 --- a/include/net/cfg80211.h +++ b/include/net/cfg80211.h @@ -562,6 +562,9 @@ ieee80211_get_sband_iftype_data(const struct ieee80211_supported_band *sband, if (WARN_ON(iftype >= NL80211_IFTYPE_MAX)) return NULL; + if (iftype == NL80211_IFTYPE_AP_VLAN) + iftype = NL80211_IFTYPE_AP; + for (i = 0; i < sband->n_iftype_data; i++) { const struct ieee80211_sband_iftype_data *data = &sband->iftype_data[i];
Since AP_VLAN interfaces are not pushed to the driver, the driver should not be expected to register iftype data for them. Map them to the regular AP iftype on lookup. Fixes: c4cbaf7973a7 ("cfg80211: Add support for HE") Signed-off-by: Felix Fietkau <nbd@nbd.name> --- include/net/cfg80211.h | 3 +++ 1 file changed, 3 insertions(+)