From: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
To: Praneesh P <praneesh.p@oss.qualcomm.com>,
Joshua Klinesmith <joshuaklinesmith@gmail.com>,
linux-wireless@vger.kernel.org
Cc: ath11k@lists.infradead.org
Subject: Re: [PATCH wireless] wifi: ath11k: fix monitor mode frame length by using correct descriptor size
Date: Tue, 5 May 2026 15:32:28 -0700 [thread overview]
Message-ID: <32843bc8-15c3-4b18-8044-b0466b9223a9@oss.qualcomm.com> (raw)
In-Reply-To: <299f83be-748c-458c-be07-df6a0fe02f38@oss.qualcomm.com>
On 4/29/2026 2:52 AM, Praneesh P wrote:
> On 4/7/2026 8:18 AM, Joshua Klinesmith wrote:
>> The monitor mode RX path in ath11k_dp_rx_mon_mpdu_pop() and
>> ath11k_dp_rx_full_mon_mpdu_pop() uses sizeof(struct hal_rx_desc) to
>> compute the packet buffer offset. This is the size of the union of all
>> chip-specific descriptors (the maximum), not the actual descriptor size
>> for the running chip. The later ath11k_dp_rx_msdus_set_payload() then
>> strips only hw_params.hal_desc_sz bytes (the chip-specific size) from
>> the front of the skb.
>>
>> On IPQ8074 and QCN9074, sizeof(struct hal_rx_desc) is 392 but
>> hal_desc_sz is 384, leaving 8 extra bytes of descriptor data at the
>> end of every monitor mode frame delivered to userspace. On WCN6855 the
>> sizes happen to match so the bug is not visible.
>>
>> The same mismatch in ath11k_dp_mon_set_frag_len() causes incorrect
>> fragment length calculation for multi-buffer MSDUs, under-counting
>> intermediate fragments by 8 bytes and over-counting the last fragment.
>>
>> Fix by using ar->ab->hw_params.hal_desc_sz consistently in both
>> monitor mpdu_pop functions and passing it through to set_frag_len.
>>
>> Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
>> Link: https://github.com/openwrt/openwrt/issues/16183
>> Signed-off-by: Joshua Klinesmith <joshuaklinesmith@gmail.com>
>> ---
>> drivers/net/wireless/ath/ath11k/dp_rx.c | 27 ++++++++++++++-----------
>> 1 file changed, 15 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath11k/dp_rx.c b/drivers/net/wireless/ath/ath11k/dp_rx.c
>> index 85defe11750d..c86ffc203f15 100644
>> --- a/drivers/net/wireless/ath/ath11k/dp_rx.c
>> +++ b/drivers/net/wireless/ath/ath11k/dp_rx.c
>> @@ -4511,10 +4511,11 @@ int ath11k_dp_rx_pdev_alloc(struct ath11k_base *ab, int mac_id)
>> return 0;
>> }
>>
>> -static void ath11k_dp_mon_set_frag_len(u32 *total_len, u32 *frag_len)
>> +static void ath11k_dp_mon_set_frag_len(u32 *total_len, u32 *frag_len,
>> + u32 hal_desc_sz)
>> {
>> - if (*total_len >= (DP_RX_BUFFER_SIZE - sizeof(struct hal_rx_desc))) {
>> - *frag_len = DP_RX_BUFFER_SIZE - sizeof(struct hal_rx_desc);
>> + if (*total_len >= (DP_RX_BUFFER_SIZE - hal_desc_sz)) {
>> + *frag_len = DP_RX_BUFFER_SIZE - hal_desc_sz;
>> *total_len -= *frag_len;
>> } else {
>> *frag_len = *total_len;
>> @@ -4658,19 +4659,19 @@ static u32 ath11k_dp_rx_mon_comp_ppduid(u32 msdu_ppdu_id, u32 *ppdu_id,
>>
>> static void ath11k_dp_mon_get_buf_len(struct hal_rx_msdu_desc_info *info,
>> bool *is_frag, u32 *total_len,
>> - u32 *frag_len, u32 *msdu_cnt)
>> + u32 *frag_len, u32 *msdu_cnt,
>> + u32 hal_desc_sz)
>> {
>> if (info->msdu_flags & RX_MSDU_DESC_INFO0_MSDU_CONTINUATION) {
>> if (!*is_frag) {
>> *total_len = info->msdu_len;
>> *is_frag = true;
>> }
>> - ath11k_dp_mon_set_frag_len(total_len,
>> - frag_len);
>> + ath11k_dp_mon_set_frag_len(total_len, frag_len, hal_desc_sz);
>> } else {
>> if (*is_frag) {
>> - ath11k_dp_mon_set_frag_len(total_len,
>> - frag_len);
>> + ath11k_dp_mon_set_frag_len(total_len, frag_len,
>> + hal_desc_sz);
>> } else {
>> *frag_len = info->msdu_len;
>> }
>> @@ -4792,7 +4793,7 @@ u32 ath11k_dp_rx_mon_mpdu_pop(struct ath11k *ar, int mac_id,
>>
>> rx_desc = (struct hal_rx_desc *)msdu->data;
>>
>> - rx_pkt_offset = sizeof(struct hal_rx_desc);
>> + rx_pkt_offset = ar->ab->hw_params.hal_desc_sz;
>> l2_hdr_offset = ath11k_dp_rx_h_msdu_end_l3pad(ar->ab, rx_desc);
>>
>> if (is_first_msdu) {
>> @@ -4823,7 +4824,8 @@ u32 ath11k_dp_rx_mon_mpdu_pop(struct ath11k *ar, int mac_id,
>> }
>> ath11k_dp_mon_get_buf_len(&msdu_list.msdu_info[i],
>> &is_frag, &total_len,
>> - &frag_len, &msdu_cnt);
>> + &frag_len, &msdu_cnt,
>> + rx_pkt_offset);
>> rx_buf_size = rx_pkt_offset + l2_hdr_offset + frag_len;
>>
>> ath11k_dp_pkt_set_pktlen(msdu, rx_buf_size);
>> @@ -5424,7 +5426,7 @@ ath11k_dp_rx_full_mon_mpdu_pop(struct ath11k *ar,
>>
>> rx_desc = (struct hal_rx_desc *)msdu->data;
>>
>> - rx_pkt_offset = sizeof(struct hal_rx_desc);
>> + rx_pkt_offset = ar->ab->hw_params.hal_desc_sz;
>> l2_hdr_offset = ath11k_dp_rx_h_msdu_end_l3pad(ar->ab, rx_desc);
>>
>> if (is_first_msdu) {
>> @@ -5439,7 +5441,8 @@ ath11k_dp_rx_full_mon_mpdu_pop(struct ath11k *ar,
>>
>> ath11k_dp_mon_get_buf_len(&msdu_list.msdu_info[i],
>> &is_frag, &total_len,
>> - &frag_len, &msdu_cnt);
>> + &frag_len, &msdu_cnt,
>> + rx_pkt_offset);
>>
>> rx_buf_size = rx_pkt_offset + l2_hdr_offset + frag_len;
>
> Thanks for fixing the offset handling in the monitor Rx path, but still
> there is another instance that still relies on sizeof(struct hal_rx_desc).
>
> ath11k_dp_rx_h_ppdu(), which is also invoked from the monitor path, uses:
>
> ath11k_dbg_dump(ab, ATH11K_DBG_DATA, NULL, "", rx_desc, sizeof(struct
> hal_rx_desc));
>
> This should likewise be converted to use hw_params.hal_desc_sz to avoid
> dumping beyond the chip-specific descriptor size on platforms where they
> differ.
Joshua, can you submit a v2 that addresses this observation?
/jeff
prev parent reply other threads:[~2026-05-05 22:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-07 2:48 [PATCH wireless] wifi: ath11k: fix monitor mode frame length by using correct descriptor size Joshua Klinesmith
2026-04-29 7:38 ` Rameshkumar Sundaram
2026-04-29 9:52 ` Praneesh P
2026-05-05 22:32 ` Jeff Johnson [this message]
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=32843bc8-15c3-4b18-8044-b0466b9223a9@oss.qualcomm.com \
--to=jeff.johnson@oss.qualcomm.com \
--cc=ath11k@lists.infradead.org \
--cc=joshuaklinesmith@gmail.com \
--cc=linux-wireless@vger.kernel.org \
--cc=praneesh.p@oss.qualcomm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox