diff mbox series

wifi: mac80211: avoid warning of no supported legacy rate if empty rate mask for rate control

Message ID 20240726031520.7616-1-pkshih@realtek.com (mailing list archive)
State Changes Requested
Delegated to: Johannes Berg
Headers show
Series wifi: mac80211: avoid warning of no supported legacy rate if empty rate mask for rate control | expand

Commit Message

Ping-Ke Shih July 26, 2024, 3:15 a.m. UTC
The commit 9df66d5b9f45 ("cfg80211: fix default HE tx bitrate mask in 2G
band") correct bitmask of HE MCS, and settings of empty legacy rate plus
HE MCS rate are correctly recognized instead of returning -EINVAL,
so empty legacy rate propagates to __rate_control_send_low() and warn
no supported rate.

Since the rate_mask is intentionally set to empty via nl80211, change logic
to avoid warning no supported rate if rate_mask is empty.

Reported-by: syzbot+8dd98a9e98ee28dc484a@syzkaller.appspotmail.com
Fixes: 9df66d5b9f45 ("cfg80211: fix default HE tx bitrate mask in 2G band")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
 net/mac80211/rate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Johannes Berg July 26, 2024, 10:30 a.m. UTC | #1
Hi PK,

Thanks for taking a lot at the syzbot report! It's been on my list for a
while, but didn't get to it.

> The commit 9df66d5b9f45 ("cfg80211: fix default HE tx bitrate mask in 2G
> band") correct bitmask of HE MCS, and settings of empty legacy rate plus
> HE MCS rate are correctly recognized instead of returning -EINVAL,
> so empty legacy rate propagates to __rate_control_send_low() and warn
> no supported rate.
> 
> Since the rate_mask is intentionally set to empty via nl80211, 

That's all true, however,

> change logic
> to avoid warning no supported rate if rate_mask is empty.

I don't necessarily think this follows.

> diff --git a/net/mac80211/rate.c b/net/mac80211/rate.c
> index 4dc1def69548..5787cb20de42 100644
> --- a/net/mac80211/rate.c
> +++ b/net/mac80211/rate.c
> @@ -377,7 +377,7 @@ static void __rate_control_send_low(struct ieee80211_hw *hw,
>  		info->control.rates[0].idx = i;
>  		break;
>  	}
> -	WARN_ONCE(i == sband->n_bitrates,
> +	WARN_ONCE(i == sband->n_bitrates && rate_mask,
>  		  "no supported rates for sta %pM (0x%x, band %d) in rate_mask 0x%x with flags 0x%x\n",
>  		  sta ? sta->addr : NULL,
>  		  sta ? sta->deflink.supp_rates[sband->band] : -1,

The warning is still valid - we're trying to pick a low rate with a NULL
station (i.e. we don't even really know where to send the frame), but we
don't have any rates to do so with.

Obviously this will remove the warning in this case, but I think the
underlying issue is that we're actually using the rate mask, intended
for the connection on the interface, for offchannel TX (looking at the
stack dump).

We had this precise discussion previously for scanning, and just like
there, fixed in ab9177d83c04 ("wifi: mac80211: don't use rate mask for
scanning"), I feel the right way to approach this issue here would be to
similarly not use the rate mask for offchannel TX, which is I think
pretty much the same situation, you could have a rate mask set for only
2.4 GHz where the connection is (and empty for other bands), which is
accepted by cfg80211 and mac80211, but then do offchannel TX on 5 GHz
anyway.

So I think the right way to approach this would be to do something like 

diff --git a/net/mac80211/offchannel.c b/net/mac80211/offchannel.c
index 28d03196ef75..33361b4d9acf 100644
--- a/net/mac80211/offchannel.c
+++ b/net/mac80211/offchannel.c
@@ -830,6 +830,8 @@ int ieee80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
 		flags = IEEE80211_TX_INTFL_NL80211_FRAME_TX |
 			IEEE80211_TX_CTL_REQ_TX_STATUS;
 
+	flags |= IEEE80211_TX_CTRL_SCAN_TX;
+
 	if (params->no_cck)
 		flags |= IEEE80211_TX_CTL_NO_CCK_RATE;
 

though at that point we need to rename that flag too, I guess.


johannes
Ping-Ke Shih July 29, 2024, 7:51 a.m. UTC | #2
Johannes Berg <johannes@sipsolutions.net> wrote:
> 
> We had this precise discussion previously for scanning, and just like
> there, fixed in ab9177d83c04 ("wifi: mac80211: don't use rate mask for
> scanning"), I feel the right way to approach this issue here would be to
> similarly not use the rate mask for offchannel TX, which is I think
> pretty much the same situation, you could have a rate mask set for only
> 2.4 GHz where the connection is (and empty for other bands), which is
> accepted by cfg80211 and mac80211, but then do offchannel TX on 5 GHz
> anyway.
> 
> So I think the right way to approach this would be to do something like
> 
> diff --git a/net/mac80211/offchannel.c b/net/mac80211/offchannel.c
> index 28d03196ef75..33361b4d9acf 100644
> --- a/net/mac80211/offchannel.c
> +++ b/net/mac80211/offchannel.c
> @@ -830,6 +830,8 @@ int ieee80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
>                 flags = IEEE80211_TX_INTFL_NL80211_FRAME_TX |
>                         IEEE80211_TX_CTL_REQ_TX_STATUS;
> 
> +       flags |= IEEE80211_TX_CTRL_SCAN_TX;
> +
>         if (params->no_cck)
>                 flags |= IEEE80211_TX_CTL_NO_CCK_RATE;
> 
> 
> though at that point we need to rename that flag too, I guess.

Thanks for the suggestions. I made and sent a patch [1] that works well in
my side using syzbot's reproducer code. 

[1] https://lore.kernel.org/linux-wireless/20240729074816.20323-1-pkshih@realtek.com/T/#u
diff mbox series

Patch

diff --git a/net/mac80211/rate.c b/net/mac80211/rate.c
index 4dc1def69548..5787cb20de42 100644
--- a/net/mac80211/rate.c
+++ b/net/mac80211/rate.c
@@ -377,7 +377,7 @@  static void __rate_control_send_low(struct ieee80211_hw *hw,
 		info->control.rates[0].idx = i;
 		break;
 	}
-	WARN_ONCE(i == sband->n_bitrates,
+	WARN_ONCE(i == sband->n_bitrates && rate_mask,
 		  "no supported rates for sta %pM (0x%x, band %d) in rate_mask 0x%x with flags 0x%x\n",
 		  sta ? sta->addr : NULL,
 		  sta ? sta->deflink.supp_rates[sband->band] : -1,