linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
To: kvalo@codeaurora.org, linux-wireless@vger.kernel.org,
	wcn36xx@lists.infradead.org,
	Johannes Berg <johannes@sipsolutions.net>
Cc: loic.poulain@linaro.org, benl@squareup.com, daniel.thompson@linaro.org
Subject: Re: [PATCH 4/4] wcn36xx: Put DXE block into reset before freeing memory
Date: Sun, 17 Oct 2021 02:28:00 +0100	[thread overview]
Message-ID: <86d286ad-2790-fa03-d879-a79101bd1ae9@linaro.org> (raw)
In-Reply-To: <20211015131741.2455824-5-bryan.odonoghue@linaro.org>

On 15/10/2021 14:17, Bryan O'Donoghue wrote:
> When deiniting the DXE hardware we should reset the block to ensure there
> is no spurious DMA write transaction from the downstream WCNSS to upstream
> MSM at a skbuff address we will have released.
> 
> This is actually a pretty serious bug. Immediately after the reset we
> release skbs, skbs which are from the perspective of the WCNSS DXE still
> valid addresses for DMA.
> 
> Without first placing the DXE block into reset, it is possible for an
> upstream DMA transaction to write to skbs we have freed.
> 
> We have seen some backtraces from usage in testing on 50k+ devices which
> indicates an invalid RX of an APs beacon to unmapped memory.
> 
> The logical conclusion is that an RX transaction happened to a region of
> memory that was previously valid but was subsequently released.
> 
> The only time such a window of opportunity exists is when we have
> deallocated the skbs attached to the DMA BDs in other words after doing
> wcn36xx_stop().
> 
> If we free the skbs on the DMA channel, we need to make sure we have
> quiesced potential DMA on that channel prior to freeing.
> 
> This patch should eliminate that error.
> 
> Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware")
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> ---
>   drivers/net/wireless/ath/wcn36xx/dxe.c | 6 ++++++
>   1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/net/wireless/ath/wcn36xx/dxe.c b/drivers/net/wireless/ath/wcn36xx/dxe.c
> index e89002502869a..56f605c23f36c 100644
> --- a/drivers/net/wireless/ath/wcn36xx/dxe.c
> +++ b/drivers/net/wireless/ath/wcn36xx/dxe.c
> @@ -1020,6 +1020,8 @@ int wcn36xx_dxe_init(struct wcn36xx *wcn)
>   
>   void wcn36xx_dxe_deinit(struct wcn36xx *wcn)
>   {
> +	int reg_data = 0;
> +
>   	/* Disable channel interrupts */
>   	wcn36xx_dxe_disable_ch_int(wcn, WCN36XX_INT_MASK_CHAN_RX_H);
>   	wcn36xx_dxe_disable_ch_int(wcn, WCN36XX_INT_MASK_CHAN_RX_L);
> @@ -1035,6 +1037,10 @@ void wcn36xx_dxe_deinit(struct wcn36xx *wcn)
>   		wcn->tx_ack_skb = NULL;
>   	}
>   
> +	/* Put the DXE block into reset before freeing memory */
> +	reg_data = WCN36XX_DXE_REG_RESET;
> +	wcn36xx_dxe_write_register(wcn, WCN36XX_DXE_REG_CSR_RESET, reg_data);
> +
>   	wcn36xx_dxe_ch_free_skbs(wcn, &wcn->dxe_rx_l_ch);
>   	wcn36xx_dxe_ch_free_skbs(wcn, &wcn->dxe_rx_h_ch);
>   
> 

Johannes asked me separately if we need to wait for the quiesence to 
complete.

I don't see that downstream but, that doesn't mean we shouldn't do it.

So I'll investigate that.

Also - now that I look at this code, this being the second usage of the 
CSR_RESET like this, also means the reset can be functionally decomposed 
into a routine.

So - I'll look into the first and definitely do the second as a V2

      reply	other threads:[~2021-10-17  1:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-15 13:17 [PATCH 0/4] wcn36xx: Fix DMA buffer allocation and free logic Bryan O'Donoghue
2021-10-15 13:17 ` [PATCH 1/4] wcn36xx: Fix DXE lock layering violation Bryan O'Donoghue
2021-10-15 13:17 ` [PATCH 2/4] wcn36xx: Fix DXE/DMA channel enable/disable cycle Bryan O'Donoghue
2021-10-15 13:17 ` [PATCH 3/4] wcn36xx: Release DMA channel descriptor allocations Bryan O'Donoghue
2021-10-15 13:17 ` [PATCH 4/4] wcn36xx: Put DXE block into reset before freeing memory Bryan O'Donoghue
2021-10-17  1:28   ` Bryan O'Donoghue [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=86d286ad-2790-fa03-d879-a79101bd1ae9@linaro.org \
    --to=bryan.odonoghue@linaro.org \
    --cc=benl@squareup.com \
    --cc=daniel.thompson@linaro.org \
    --cc=johannes@sipsolutions.net \
    --cc=kvalo@codeaurora.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=loic.poulain@linaro.org \
    --cc=wcn36xx@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).