Since retransmission clears info->control, rate control needs to be called
again, otherwise the driver might crash due to invalid rates.
Cc: [email protected] # 5.14+
Reported-by: Aaro Koskinen <[email protected]>
Reported-by: Robert W <[email protected]>
Fixes: 03c3911d2d67 ("mac80211: call ieee80211_tx_h_rate_ctrl() when dequeue")
Signed-off-by: Felix Fietkau <[email protected]>
---
net/mac80211/tx.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 278945e3e08a..e19f6e246642 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1822,15 +1822,15 @@ static int invoke_tx_handlers_late(struct ieee80211_tx_data *tx)
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(tx->skb);
ieee80211_tx_result res = TX_CONTINUE;
+ if (!ieee80211_hw_check(&tx->local->hw, HAS_RATE_CONTROL))
+ CALL_TXH(ieee80211_tx_h_rate_ctrl);
+
if (unlikely(info->flags & IEEE80211_TX_INTFL_RETRANSMISSION)) {
__skb_queue_tail(&tx->skbs, tx->skb);
tx->skb = NULL;
goto txh_done;
}
- if (!ieee80211_hw_check(&tx->local->hw, HAS_RATE_CONTROL))
- CALL_TXH(ieee80211_tx_h_rate_ctrl);
-
CALL_TXH(ieee80211_tx_h_michael_mic_add);
CALL_TXH(ieee80211_tx_h_sequence);
CALL_TXH(ieee80211_tx_h_fragment);
--
2.30.1
Hi,
On Mon, Nov 22, 2021 at 09:43:23PM +0100, Felix Fietkau wrote:
> Since retransmission clears info->control, rate control needs to be called
> again, otherwise the driver might crash due to invalid rates.
>
> Cc: [email protected] # 5.14+
> Reported-by: Aaro Koskinen <[email protected]>
> Reported-by: Robert W <[email protected]>
> Fixes: 03c3911d2d67 ("mac80211: call ieee80211_tx_h_rate_ctrl() when dequeue")
> Signed-off-by: Felix Fietkau <[email protected]>
Tested-by: Aaro Koskinen <[email protected]>
A.
> ---
> net/mac80211/tx.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
> index 278945e3e08a..e19f6e246642 100644
> --- a/net/mac80211/tx.c
> +++ b/net/mac80211/tx.c
> @@ -1822,15 +1822,15 @@ static int invoke_tx_handlers_late(struct ieee80211_tx_data *tx)
> struct ieee80211_tx_info *info = IEEE80211_SKB_CB(tx->skb);
> ieee80211_tx_result res = TX_CONTINUE;
>
> + if (!ieee80211_hw_check(&tx->local->hw, HAS_RATE_CONTROL))
> + CALL_TXH(ieee80211_tx_h_rate_ctrl);
> +
> if (unlikely(info->flags & IEEE80211_TX_INTFL_RETRANSMISSION)) {
> __skb_queue_tail(&tx->skbs, tx->skb);
> tx->skb = NULL;
> goto txh_done;
> }
>
> - if (!ieee80211_hw_check(&tx->local->hw, HAS_RATE_CONTROL))
> - CALL_TXH(ieee80211_tx_h_rate_ctrl);
> -
> CALL_TXH(ieee80211_tx_h_michael_mic_add);
> CALL_TXH(ieee80211_tx_h_sequence);
> CALL_TXH(ieee80211_tx_h_fragment);
> --
> 2.30.1
>
Hi, this is your Linux kernel regression tracker speaking.
On 22.11.21 21:43, Felix Fietkau wrote:
> Since retransmission clears info->control, rate control needs to be called
> again, otherwise the driver might crash due to invalid rates.
>
> Cc: [email protected] # 5.14+
> Reported-by: Aaro Koskinen <[email protected]>
> Reported-by: Robert W <[email protected]>
> Fixes: 03c3911d2d67 ("mac80211: call ieee80211_tx_h_rate_ctrl() when dequeue")
> Signed-off-by: Felix Fietkau <[email protected]>
FWIW: In case you need to send an improved patch, could you please add
this before the 'Reported-by:' (see at (¹) below for the reasoning):
Link:
https://lore.kernel.org/r/[email protected]/
Link:
https://lore.kernel.org/r/[email protected]/
And if the patch is already good to go: could the subsystem maintainer
please add it when applying? See (¹) for the reasoning.
Ciao, Thorsten
(¹) Long story: The commit message would benefit from a link to the
regression report, for reasons explained in
Documentation/process/submitting-patches.rst. To quote:
```
If related discussions or any other background information behind the
change can be found on the web, add 'Link:' tags pointing to it. In case
your patch fixes a bug, for example, add a tag with a URL referencing
the report in the mailing list archives or a bug tracker;
```
This concept is old, but the text was reworked recently to make this use
case for the Link: tag clearer. For details see:
https://git.kernel.org/linus/1f57bd42b77c
Yes, that "Link:" is not really crucial; but it's good to have if
someone needs to look into the backstory of this change sometime in the
future. But I care for a different reason. I'm tracking this regression
(and others) with regzbot, my Linux kernel regression tracking bot. This
bot will notice if a patch with a Link: tag to a tracked regression gets
posted and record that, which allowed anyone looking into the regression
to quickly gasp the current status from regzbot's webui
(https://linux-regtracking.leemhuis.info/regzbot ) or its reports. The
bot will also notice if a commit with a Link: tag to a regression report
is applied by Linus and then automatically mark the regression as
resolved then.
IOW: this tag makes my life a regression tracker a lot easier, as I
otherwise have to tell regzbot manually when the fix lands. :-/
P.S.: As a Linux kernel regression tracker I'm getting a lot of reports
on my table. I can only look briefly into most of them. Unfortunately
therefore I sometimes will get things wrong or miss something important.
I hope that's not the case here; if you think it is, don't hesitate to
tell me about it in a public reply. That's in everyone's interest, as
what I wrote above might be misleading to everyone reading this; any
suggestion I gave they thus might sent someone reading this down the
wrong rabbit hole, which none of us wants.
BTW, I have no personal interest in this issue, which is tracked using
regzbot, my Linux kernel regression tracking bot
(https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting
this mail to get things rolling again and hence don't need to be CC on
all further activitie wrt to this regression. Ohh, and feel free to
ignore the following lines, they are meant for regzbot:
#regzbot ignore-activity
#regzbot ^backmonitor:
https://lore.kernel.org/r/[email protected]/
#regzbot ^backmonitor:
https://lore.kernel.org/r/[email protected]/
Hi, this is your Linux kernel regression tracker speaking.
Top-posting for once, to make this easy accessible to everyone.
What is talking below fix so long to get mainlined? The patch and the
confirmation that it fixes the regressions was 19 days ago. The patch is
also in linux-next for 12 days. From my point of view as regression
tracker that seem "too long", as this is a regression that also affects
a stable kernel.
Or am I missing something?
Ciao, Thorsten
P.S.: As a Linux kernel regression tracker I'm getting a lot of reports
on my table. I can only look briefly into most of them. Unfortunately
therefore I sometimes will get things wrong or miss something important.
I hope that's not the case here; if you think it is, don't hesitate to
tell me about it in a public reply. That's in everyone's interest, as
what I wrote above might be misleading to everyone reading this; any
suggestion I gave thus might sent someone reading this down the wrong
rabbit hole, which none of us wants.
BTW, I have no personal interest in this issue, which is tracked using
regzbot, my Linux kernel regression tracking bot
(https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting
this mail to get things rolling again and hence don't need to be CC on
all further activities wrt to this regression.
#regzbot poke
On 22.11.21 21:43, Felix Fietkau wrote:
> Since retransmission clears info->control, rate control needs to be called
> again, otherwise the driver might crash due to invalid rates.
>
> Cc: [email protected] # 5.14+
> Reported-by: Aaro Koskinen <[email protected]>
> Reported-by: Robert W <[email protected]>
> Fixes: 03c3911d2d67 ("mac80211: call ieee80211_tx_h_rate_ctrl() when dequeue")
> Signed-off-by: Felix Fietkau <[email protected]>
> ---
> net/mac80211/tx.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
> index 278945e3e08a..e19f6e246642 100644
> --- a/net/mac80211/tx.c
> +++ b/net/mac80211/tx.c
> @@ -1822,15 +1822,15 @@ static int invoke_tx_handlers_late(struct ieee80211_tx_data *tx)
> struct ieee80211_tx_info *info = IEEE80211_SKB_CB(tx->skb);
> ieee80211_tx_result res = TX_CONTINUE;
>
> + if (!ieee80211_hw_check(&tx->local->hw, HAS_RATE_CONTROL))
> + CALL_TXH(ieee80211_tx_h_rate_ctrl);
> +
> if (unlikely(info->flags & IEEE80211_TX_INTFL_RETRANSMISSION)) {
> __skb_queue_tail(&tx->skbs, tx->skb);
> tx->skb = NULL;
> goto txh_done;
> }
>
> - if (!ieee80211_hw_check(&tx->local->hw, HAS_RATE_CONTROL))
> - CALL_TXH(ieee80211_tx_h_rate_ctrl);
> -
> CALL_TXH(ieee80211_tx_h_michael_mic_add);
> CALL_TXH(ieee80211_tx_h_sequence);
> CALL_TXH(ieee80211_tx_h_fragment);
>
Thorsten Leemhuis <[email protected]> writes:
> Hi, this is your Linux kernel regression tracker speaking.
>
> Top-posting for once, to make this easy accessible to everyone.
>
> What is talking below fix so long to get mainlined? The patch and the
> confirmation that it fixes the regressions was 19 days ago. The patch is
> also in linux-next for 12 days. From my point of view as regression
> tracker that seem "too long", as this is a regression that also affects
> a stable kernel.
>
> Or am I missing something?
In general it just takes time for wireless patches to reach Linus' tree.
For example, we don't usually send pull requests to the net tree every
week so that alone causes delay.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches