From: "Toke Høiland-Jørgensen" <toke@toke.dk> To: Robin Murphy <robin.murphy@arm.com>, Christoph Hellwig <hch@lst.de>, Maxime Bizon <mbizon@freebox.fr> Cc: Oleksandr Natalenko <oleksandr@natalenko.name>, Linus Torvalds <torvalds@linux-foundation.org>, Halil Pasic <pasic@linux.ibm.com>, Marek Szyprowski <m.szyprowski@samsung.com>, Kalle Valo <kvalo@kernel.org>, "David S. Miller" <davem@davemloft.net>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Olha Cherevyk <olha.cherevyk@gmail.com>, iommu <iommu@lists.linux-foundation.org>, linux-wireless <linux-wireless@vger.kernel.org>, Netdev <netdev@vger.kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, stable <stable@vger.kernel.org> Subject: Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP Date: Thu, 24 Mar 2022 18:07:29 +0100 [thread overview] Message-ID: <871qyr9t4e.fsf@toke.dk> (raw) In-Reply-To: <d8a1cbf4-a521-78ec-1560-28d855e0913e@arm.com> Robin Murphy <robin.murphy@arm.com> writes: > On 2022-03-24 16:31, Christoph Hellwig wrote: >> On Thu, Mar 24, 2022 at 05:29:12PM +0100, Maxime Bizon wrote: >>>> I'm looking into this; but in the interest of a speedy resolution of >>>> the regression I would be in favour of merging that partial revert >>>> and reinstating it if/when we identify (and fix) any bugs in ath9k :) >>> >>> This looks fishy: >>> >>> ath9k/recv.c >>> >>> /* We will now give hardware our shiny new allocated skb */ >>> new_buf_addr = dma_map_single(sc->dev, requeue_skb->data, >>> common->rx_bufsize, dma_type); >>> if (unlikely(dma_mapping_error(sc->dev, new_buf_addr))) { >>> dev_kfree_skb_any(requeue_skb); >>> goto requeue_drop_frag; >>> } >>> >>> /* Unmap the frame */ >>> dma_unmap_single(sc->dev, bf->bf_buf_addr, >>> common->rx_bufsize, dma_type); >>> >>> bf->bf_mpdu = requeue_skb; >>> bf->bf_buf_addr = new_buf_addr; >> >> Creating a new mapping for the same buffer before unmapping the >> previous one does looks rather bogus. But it does not fit the >> pattern where revering the sync_single changes make the driver >> work again. > > OK, you made me look :) > > Now that it's obvious what to look for, I can only conclude that during > the stanza in ath_edma_get_buffers(), the device is still writing to the > buffer while ownership has been transferred to the CPU, and whatever got > written while ath9k_hw_process_rxdesc_edma() was running then gets wiped > out by the subsequent sync_for_device, which currently resets the > SWIOTLB slot to the state that sync_for_cpu copied out. By the letter of > the DMA API that's not allowed, but on the other hand I'm not sure if we > even have a good idiom for "I can't tell if the device has finished with > this buffer or not unless I look at it" :/ Right, but is that sync_for_device call really needed? AFAICT, that ath9k_hw_process_rxdesc_edma() invocation doesn't actually modify any of the data when it returns EINPROGRESS, so could we just skip it? Like the patch below? Or am I misunderstanding the semantics here? -Toke diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c index 0c0624a3b40d..19244d4c0ada 100644 --- a/drivers/net/wireless/ath/ath9k/recv.c +++ b/drivers/net/wireless/ath/ath9k/recv.c @@ -647,12 +647,8 @@ static bool ath_edma_get_buffers(struct ath_softc *sc, common->rx_bufsize, DMA_FROM_DEVICE); ret = ath9k_hw_process_rxdesc_edma(ah, rs, skb->data); - if (ret == -EINPROGRESS) { - /*let device gain the buffer again*/ - dma_sync_single_for_device(sc->dev, bf->bf_buf_addr, - common->rx_bufsize, DMA_FROM_DEVICE); + if (ret == -EINPROGRESS) return false; - } __skb_unlink(skb, &rx_edma->rx_fifo); if (ret == -EINVAL) {
WARNING: multiple messages have this Message-ID (diff)
From: "Toke Høiland-Jørgensen via iommu" <iommu@lists.linux-foundation.org> To: Robin Murphy <robin.murphy@arm.com>, Christoph Hellwig <hch@lst.de>, Maxime Bizon <mbizon@freebox.fr> Cc: Netdev <netdev@vger.kernel.org>, Kalle Valo <kvalo@kernel.org>, linux-wireless <linux-wireless@vger.kernel.org>, Oleksandr Natalenko <oleksandr@natalenko.name>, stable <stable@vger.kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Halil Pasic <pasic@linux.ibm.com>, iommu <iommu@lists.linux-foundation.org>, Olha Cherevyk <olha.cherevyk@gmail.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Linus Torvalds <torvalds@linux-foundation.org>, "David S. Miller" <davem@davemloft.net> Subject: Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP Date: Thu, 24 Mar 2022 18:07:29 +0100 [thread overview] Message-ID: <871qyr9t4e.fsf@toke.dk> (raw) In-Reply-To: <d8a1cbf4-a521-78ec-1560-28d855e0913e@arm.com> Robin Murphy <robin.murphy@arm.com> writes: > On 2022-03-24 16:31, Christoph Hellwig wrote: >> On Thu, Mar 24, 2022 at 05:29:12PM +0100, Maxime Bizon wrote: >>>> I'm looking into this; but in the interest of a speedy resolution of >>>> the regression I would be in favour of merging that partial revert >>>> and reinstating it if/when we identify (and fix) any bugs in ath9k :) >>> >>> This looks fishy: >>> >>> ath9k/recv.c >>> >>> /* We will now give hardware our shiny new allocated skb */ >>> new_buf_addr = dma_map_single(sc->dev, requeue_skb->data, >>> common->rx_bufsize, dma_type); >>> if (unlikely(dma_mapping_error(sc->dev, new_buf_addr))) { >>> dev_kfree_skb_any(requeue_skb); >>> goto requeue_drop_frag; >>> } >>> >>> /* Unmap the frame */ >>> dma_unmap_single(sc->dev, bf->bf_buf_addr, >>> common->rx_bufsize, dma_type); >>> >>> bf->bf_mpdu = requeue_skb; >>> bf->bf_buf_addr = new_buf_addr; >> >> Creating a new mapping for the same buffer before unmapping the >> previous one does looks rather bogus. But it does not fit the >> pattern where revering the sync_single changes make the driver >> work again. > > OK, you made me look :) > > Now that it's obvious what to look for, I can only conclude that during > the stanza in ath_edma_get_buffers(), the device is still writing to the > buffer while ownership has been transferred to the CPU, and whatever got > written while ath9k_hw_process_rxdesc_edma() was running then gets wiped > out by the subsequent sync_for_device, which currently resets the > SWIOTLB slot to the state that sync_for_cpu copied out. By the letter of > the DMA API that's not allowed, but on the other hand I'm not sure if we > even have a good idiom for "I can't tell if the device has finished with > this buffer or not unless I look at it" :/ Right, but is that sync_for_device call really needed? AFAICT, that ath9k_hw_process_rxdesc_edma() invocation doesn't actually modify any of the data when it returns EINPROGRESS, so could we just skip it? Like the patch below? Or am I misunderstanding the semantics here? -Toke diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c index 0c0624a3b40d..19244d4c0ada 100644 --- a/drivers/net/wireless/ath/ath9k/recv.c +++ b/drivers/net/wireless/ath/ath9k/recv.c @@ -647,12 +647,8 @@ static bool ath_edma_get_buffers(struct ath_softc *sc, common->rx_bufsize, DMA_FROM_DEVICE); ret = ath9k_hw_process_rxdesc_edma(ah, rs, skb->data); - if (ret == -EINPROGRESS) { - /*let device gain the buffer again*/ - dma_sync_single_for_device(sc->dev, bf->bf_buf_addr, - common->rx_bufsize, DMA_FROM_DEVICE); + if (ret == -EINPROGRESS) return false; - } __skb_unlink(skb, &rx_edma->rx_fifo); if (ret == -EINVAL) { _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2022-03-24 17:07 UTC|newest] Thread overview: 139+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-03-23 7:19 [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP Oleksandr Natalenko 2022-03-23 7:19 ` Oleksandr Natalenko via iommu 2022-03-23 7:28 ` Kalle Valo 2022-03-23 7:28 ` Kalle Valo 2022-03-23 17:27 ` Linus Torvalds 2022-03-23 17:27 ` Linus Torvalds 2022-03-23 19:06 ` Robin Murphy 2022-03-23 19:06 ` Robin Murphy 2022-03-23 19:16 ` Linus Torvalds 2022-03-23 19:16 ` Linus Torvalds 2022-03-23 20:54 ` Robin Murphy 2022-03-23 20:54 ` Robin Murphy 2022-03-24 5:57 ` Christoph Hellwig 2022-03-24 5:57 ` Christoph Hellwig 2022-03-24 10:25 ` Oleksandr Natalenko 2022-03-24 10:25 ` Oleksandr Natalenko via iommu 2022-03-24 11:05 ` Robin Murphy 2022-03-24 11:05 ` Robin Murphy 2022-03-24 14:27 ` Toke Høiland-Jørgensen 2022-03-24 14:27 ` Toke Høiland-Jørgensen via iommu 2022-03-24 16:29 ` Maxime Bizon 2022-03-24 16:29 ` Maxime Bizon 2022-03-24 16:31 ` Christoph Hellwig 2022-03-24 16:31 ` Christoph Hellwig 2022-03-24 16:52 ` Robin Murphy 2022-03-24 16:52 ` Robin Murphy 2022-03-24 17:07 ` Toke Høiland-Jørgensen [this message] 2022-03-24 17:07 ` Toke Høiland-Jørgensen via iommu 2022-03-24 19:26 ` Linus Torvalds 2022-03-24 19:26 ` Linus Torvalds 2022-03-24 21:14 ` Toke Høiland-Jørgensen 2022-03-24 21:14 ` Toke Høiland-Jørgensen via iommu 2022-03-25 10:25 ` Maxime Bizon 2022-03-25 10:25 ` Maxime Bizon 2022-03-25 11:27 ` Robin Murphy 2022-03-25 11:27 ` Robin Murphy 2022-03-25 23:38 ` Halil Pasic 2022-03-25 23:38 ` Halil Pasic 2022-03-26 16:05 ` Toke Høiland-Jørgensen 2022-03-26 16:05 ` Toke Høiland-Jørgensen via iommu 2022-03-26 18:38 ` Linus Torvalds 2022-03-26 18:38 ` Linus Torvalds 2022-03-26 22:38 ` David Laight 2022-03-26 22:38 ` David Laight 2022-03-26 22:41 ` Linus Torvalds 2022-03-26 22:41 ` Linus Torvalds 2022-03-25 16:25 ` Toke Høiland-Jørgensen 2022-03-25 16:25 ` Toke Høiland-Jørgensen via iommu 2022-03-25 16:45 ` Robin Murphy 2022-03-25 16:45 ` Robin Murphy 2022-03-25 18:13 ` Toke Høiland-Jørgensen via iommu 2022-03-25 18:13 ` Toke Høiland-Jørgensen 2022-03-25 18:30 ` Linus Torvalds 2022-03-25 18:30 ` Linus Torvalds 2022-03-25 19:14 ` Robin Murphy 2022-03-25 19:14 ` Robin Murphy 2022-03-25 19:21 ` Linus Torvalds 2022-03-25 19:21 ` Linus Torvalds 2022-03-25 19:26 ` Oleksandr Natalenko via iommu 2022-03-25 19:26 ` Oleksandr Natalenko 2022-03-25 19:27 ` Linus Torvalds 2022-03-25 19:27 ` Linus Torvalds 2022-03-25 19:35 ` Oleksandr Natalenko via iommu 2022-03-25 19:35 ` Oleksandr Natalenko 2022-03-25 20:37 ` Johannes Berg 2022-03-25 20:37 ` Johannes Berg 2022-03-25 20:47 ` Linus Torvalds 2022-03-25 20:47 ` Linus Torvalds 2022-03-25 21:13 ` Johannes Berg 2022-03-25 21:13 ` Johannes Berg 2022-03-25 21:40 ` David Laight 2022-03-25 21:40 ` David Laight 2022-03-25 21:56 ` Linus Torvalds 2022-03-25 21:56 ` Linus Torvalds 2022-03-25 22:41 ` David Laight 2022-03-25 22:41 ` David Laight 2022-03-27 3:15 ` Halil Pasic 2022-03-27 3:15 ` Halil Pasic 2022-03-28 9:48 ` Johannes Berg 2022-03-28 9:48 ` Johannes Berg 2022-03-28 9:50 ` Johannes Berg 2022-03-28 9:50 ` Johannes Berg 2022-03-28 9:57 ` Johannes Berg 2022-03-28 9:57 ` Johannes Berg 2022-03-27 3:48 ` Halil Pasic 2022-03-27 3:48 ` Halil Pasic 2022-03-27 5:06 ` Linus Torvalds 2022-03-27 5:06 ` Linus Torvalds 2022-03-27 5:21 ` Linus Torvalds 2022-03-27 5:21 ` Linus Torvalds 2022-03-27 15:24 ` David Laight 2022-03-27 15:24 ` David Laight 2022-03-27 19:23 ` Linus Torvalds 2022-03-27 19:23 ` Linus Torvalds 2022-03-27 20:04 ` Linus Torvalds 2022-03-27 20:04 ` Linus Torvalds 2022-03-27 23:52 ` Halil Pasic 2022-03-27 23:52 ` Halil Pasic 2022-03-28 0:30 ` Linus Torvalds 2022-03-28 0:30 ` Linus Torvalds 2022-03-28 12:02 ` Halil Pasic 2022-03-28 12:02 ` Halil Pasic 2022-03-27 23:37 ` Halil Pasic 2022-03-27 23:37 ` Halil Pasic 2022-03-28 0:37 ` Linus Torvalds 2022-03-28 0:37 ` Linus Torvalds 2022-03-25 7:12 ` Oleksandr Natalenko 2022-03-25 7:12 ` Oleksandr Natalenko via iommu 2022-03-25 9:21 ` Thorsten Leemhuis 2022-03-25 9:21 ` Thorsten Leemhuis 2022-03-24 18:31 ` Halil Pasic 2022-03-24 18:31 ` Halil Pasic 2022-03-25 16:31 ` Christoph Hellwig 2022-03-25 16:31 ` Christoph Hellwig 2022-03-24 18:02 ` Halil Pasic 2022-03-24 18:02 ` Halil Pasic 2022-03-25 15:25 ` Halil Pasic 2022-03-25 15:25 ` Halil Pasic 2022-03-25 16:23 ` Robin Murphy 2022-03-25 16:23 ` Robin Murphy 2022-03-25 16:32 ` Christoph Hellwig 2022-03-25 16:32 ` Christoph Hellwig 2022-03-25 18:15 ` Toke Høiland-Jørgensen via iommu 2022-03-25 18:15 ` Toke Høiland-Jørgensen 2022-03-25 18:42 ` Robin Murphy 2022-03-25 18:42 ` Robin Murphy 2022-03-25 18:46 ` Linus Torvalds 2022-03-25 18:46 ` Linus Torvalds 2022-03-28 6:37 ` Christoph Hellwig 2022-03-28 6:37 ` Christoph Hellwig 2022-03-28 8:15 ` David Laight 2022-03-28 8:15 ` David Laight 2022-03-30 12:11 ` Halil Pasic 2022-03-30 12:11 ` Halil Pasic 2022-03-24 8:55 ` Oleksandr Natalenko 2022-03-24 8:55 ` Oleksandr Natalenko via iommu 2022-03-24 12:32 ` [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP #forregzbot Thorsten Leemhuis 2022-03-25 9:24 ` Thorsten Leemhuis 2022-03-27 9:00 ` Thorsten Leemhuis
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=871qyr9t4e.fsf@toke.dk \ --to=toke@toke.dk \ --cc=davem@davemloft.net \ --cc=gregkh@linuxfoundation.org \ --cc=hch@lst.de \ --cc=iommu@lists.linux-foundation.org \ --cc=kuba@kernel.org \ --cc=kvalo@kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-wireless@vger.kernel.org \ --cc=m.szyprowski@samsung.com \ --cc=mbizon@freebox.fr \ --cc=netdev@vger.kernel.org \ --cc=oleksandr@natalenko.name \ --cc=olha.cherevyk@gmail.com \ --cc=pabeni@redhat.com \ --cc=pasic@linux.ibm.com \ --cc=robin.murphy@arm.com \ --cc=stable@vger.kernel.org \ --cc=torvalds@linux-foundation.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: linkBe 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.