| Message ID | 20211014075153.3655910-1-arnd@kernel.org (mailing list archive) |
|---|---|
| State | Awaiting Upstream |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | ath10k: fix invalid dma_addr_t token assignment | expand |
| Context | Check | Description |
|---|---|---|
| netdev/tree_selection | success | Not a local patch |
Arnd Bergmann <arnd@kernel.org> writes: > From: Arnd Bergmann <arnd@arndb.de> > > Using a kernel pointer in place of a dma_addr_t token can > lead to undefined behavior if that makes it into cache > management functions. The compiler caught one such attempt > in a cast: > > drivers/net/wireless/ath/ath10k/mac.c: In function 'ath10k_add_interface': > drivers/net/wireless/ath/ath10k/mac.c:5586:47: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] > 5586 | arvif->beacon_paddr = (dma_addr_t)arvif->beacon_buf; > | ^ > > Looking through how this gets used down the way, I'm fairly > sure that beacon_paddr is never accessed again for ATH10K_DEV_TYPE_HL > devices, and if it was accessed, that would be a bug. That's my understanding as well. beacon_paddr is only accessed in ath10k_wmi_event_host_swba() and only low latency (ATH10K_DEV_TYPE_LL) should use that function. > Change the assignment to use a known-invalid address token > instead, which avoids the warning and makes it easier to catch > bugs if it does end up getting used. > > Fixes: e263bdab9c0e ("ath10k: high latency fixes for beacon buffer") > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > --- > drivers/net/wireless/ath/ath10k/mac.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c > index 7ca68c81d9b6..c0e78eaa65f8 100644 > --- a/drivers/net/wireless/ath/ath10k/mac.c > +++ b/drivers/net/wireless/ath/ath10k/mac.c > @@ -5583,7 +5583,7 @@ static int ath10k_add_interface(struct ieee80211_hw *hw, > if (ar->bus_param.dev_type == ATH10K_DEV_TYPE_HL) { > arvif->beacon_buf = kmalloc(IEEE80211_MAX_FRAME_LEN, > GFP_KERNEL); > - arvif->beacon_paddr = (dma_addr_t)arvif->beacon_buf; > + arvif->beacon_paddr = DMA_MAPPING_ERROR; In the pending branch I added a comment here: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=02a383c9bf959147a95c4efeaa4edf35c4450fac
On 14/10/2021 04:51, Arnd Bergmann wrote: > From: Arnd Bergmann <arnd@arndb.de> > > Using a kernel pointer in place of a dma_addr_t token can > lead to undefined behavior if that makes it into cache > management functions. The compiler caught one such attempt > in a cast: > > drivers/net/wireless/ath/ath10k/mac.c: In function > 'ath10k_add_interface': > drivers/net/wireless/ath/ath10k/mac.c:5586:47: error: cast from > pointer to integer of different size [-Werror=pointer-to-int-cast] > 5586 | arvif->beacon_paddr = > (dma_addr_t)arvif->beacon_buf; > | ^ > > Looking through how this gets used down the way, I'm fairly > sure that beacon_paddr is never accessed again for ATH10K_DEV_TYPE_HL > devices, and if it was accessed, that would be a bug. > > Change the assignment to use a known-invalid address token > instead, which avoids the warning and makes it easier to catch > bugs if it does end up getting used. > > Fixes: e263bdab9c0e ("ath10k: high latency fixes for beacon buffer") > Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Fabio Estevam <festevam@denx.de>
Arnd Bergmann <arnd@kernel.org> wrote: > Using a kernel pointer in place of a dma_addr_t token can > lead to undefined behavior if that makes it into cache > management functions. The compiler caught one such attempt > in a cast: > > drivers/net/wireless/ath/ath10k/mac.c: In function 'ath10k_add_interface': > drivers/net/wireless/ath/ath10k/mac.c:5586:47: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] > 5586 | arvif->beacon_paddr = (dma_addr_t)arvif->beacon_buf; > | ^ > > Looking through how this gets used down the way, I'm fairly > sure that beacon_paddr is never accessed again for ATH10K_DEV_TYPE_HL > devices, and if it was accessed, that would be a bug. > > Change the assignment to use a known-invalid address token > instead, which avoids the warning and makes it easier to catch > bugs if it does end up getting used. > > Fixes: e263bdab9c0e ("ath10k: high latency fixes for beacon buffer") > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Patch applied to ath-next branch of ath.git, thanks. 937e79c67740 ath10k: fix invalid dma_addr_t token assignment
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index 7ca68c81d9b6..c0e78eaa65f8 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -5583,7 +5583,7 @@ static int ath10k_add_interface(struct ieee80211_hw *hw, if (ar->bus_param.dev_type == ATH10K_DEV_TYPE_HL) { arvif->beacon_buf = kmalloc(IEEE80211_MAX_FRAME_LEN, GFP_KERNEL); - arvif->beacon_paddr = (dma_addr_t)arvif->beacon_buf; + arvif->beacon_paddr = DMA_MAPPING_ERROR; } else { arvif->beacon_buf = dma_alloc_coherent(ar->dev,