All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Kalle Valo <kvalo@kernel.org>, Bagas Sanjaya <bagasdotme@gmail.com>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH v5.18] ath9k: Properly clear TX status area before reporting to mac80211
Date: Thu, 31 Mar 2022 10:35:17 +0200	[thread overview]
Message-ID: <87pmm2h64a.fsf@toke.dk> (raw)
In-Reply-To: <87fsmyvg22.fsf@tynnyri.adurom.net>

Kalle Valo <kvalo@kernel.org> writes:

> Bagas Sanjaya <bagasdotme@gmail.com> writes:
>
>> On 30/03/22 23.44, Toke Høiland-Jørgensen wrote:
>>> The ath9k driver was not properly clearing the status area in the
>>> ieee80211_tx_info struct before reporting TX status to mac80211. Instead,
>>> it was manually filling in fields, which meant that fields introduced later
>>> were left as-is.
>>>
>>> Conveniently, mac80211 actually provides a helper to zero out the status
>>> area, so use that to make sure we zero everything.
>>>
>>> The last commit touching the driver function writing the status information
>>> seems to have actually been fixing an issue that was also caused by the
>>> area being uninitialised; but it only added clearing of a single field
>>> instead of the whole struct. That is now redundant, though, so revert that
>>> commit and use it as a convenient Fixes tag.
>>>
>>> Fixes: cc591d77aba1 ("ath9k: Make sure to zero status.tx_time before reporting TX status")
>>> Reported-by: Bagas Sanjaya <bagasdotme@gmail.com>
>>> Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
>>
>> No regressions and UBSAN warning [1] reported on dmesg.
>>
>> Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
>>
>> However, there is something missing. I don't see Cc: stable@vger.kernel.org
>> trailer in this patch. I think it should, because I reported that this issue
>> first occurred on v5.17, then still appeared on v5.17.1.
>
> I can add that during commit.

Thanks! And sorry about that, I have gotten so used to the netdev policy
of not including an explicit stable Cc that I totally forgot that this
doesn't apply to the wireless tree.

In any case I think the stable tree autoselection bit should pick it up
from the Fixes tag, though...

-Toke

  reply	other threads:[~2022-03-31  8:35 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-30 16:44 [PATCH v5.18] ath9k: Properly clear TX status area before reporting to mac80211 Toke Høiland-Jørgensen
2022-03-31  5:06 ` Bagas Sanjaya
2022-03-31  5:18   ` Bagas Sanjaya
2022-03-31  5:36   ` Kalle Valo
2022-03-31  8:35     ` Toke Høiland-Jørgensen [this message]
2022-03-31  9:31       ` Kalle Valo
2022-04-01  6:37 ` [v5.18] " Kalle Valo
2022-04-01 17:26 ` [PATCH v5.18] " Peter Seiderer
2022-04-02 12:00   ` Toke Høiland-Jørgensen
2022-04-02 14:33   ` Peter Seiderer
2022-04-02 15:11     ` Toke Høiland-Jørgensen
2022-04-02 16:19       ` Peter Seiderer
2022-04-04 11:04         ` Peter Seiderer
2022-04-04 16:03           ` Toke Høiland-Jørgensen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87pmm2h64a.fsf@toke.dk \
    --to=toke@toke.dk \
    --cc=bagasdotme@gmail.com \
    --cc=kvalo@kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.