From: Oleksandr Natalenko <oleksandr@natalenko.name>
To: Robin Murphy <robin.murphy@arm.com>, Christoph Hellwig <hch@lst.de>
Cc: "Linus Torvalds" <torvalds@linux-foundation.org>,
"Halil Pasic" <pasic@linux.ibm.com>,
"Christoph Hellwig" <hch@lst.de>,
"Marek Szyprowski" <m.szyprowski@samsung.com>,
"Toke Høiland-Jørgensen" <toke@toke.dk>,
"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 11:25:06 +0100 [thread overview]
Message-ID: <4386660.LvFx2qVVIh@natalenko.name> (raw)
In-Reply-To: <20220324055732.GB12078@lst.de>
Hello.
On čtvrtek 24. března 2022 6:57:32 CET Christoph Hellwig wrote:
> On Wed, Mar 23, 2022 at 08:54:08PM +0000, Robin Murphy wrote:
> > I'll admit I still never quite grasped the reason for also adding the
> > override to swiotlb_sync_single_for_device() in aa6f8dcbab47, but I think
> > by that point we were increasingly tired and confused and starting to
> > second-guess ourselves (well, I was, at least). I don't think it's wrong
> > per se, but as I said I do think it can bite anyone who's been doing
> > dma_sync_*() wrong but getting away with it until now. If ddbd89deb7d3
> > alone turns out to work OK then I'd be inclined to try a partial revert of
> > just that one hunk.
>
> Agreed. Let's try that first.
>
> Oleksandr, can you try the patch below:
>
>
> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> index 6db1c475ec827..6c350555e5a1c 100644
> --- a/kernel/dma/swiotlb.c
> +++ b/kernel/dma/swiotlb.c
> @@ -701,13 +701,10 @@ void swiotlb_tbl_unmap_single(struct device *dev, phys_addr_t tlb_addr,
> void swiotlb_sync_single_for_device(struct device *dev, phys_addr_t tlb_addr,
> size_t size, enum dma_data_direction dir)
> {
> - /*
> - * Unconditional bounce is necessary to avoid corruption on
> - * sync_*_for_cpu or dma_ummap_* when the device didn't overwrite
> - * the whole lengt of the bounce buffer.
> - */
> - swiotlb_bounce(dev, tlb_addr, size, DMA_TO_DEVICE);
> - BUG_ON(!valid_dma_direction(dir));
> + if (dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL)
> + swiotlb_bounce(dev, tlb_addr, size, DMA_TO_DEVICE);
> + else
> + BUG_ON(dir != DMA_FROM_DEVICE);
> }
>
> void swiotlb_sync_single_for_cpu(struct device *dev, phys_addr_t tlb_addr,
>
With this patch the AP works for me.
Thanks.
--
Oleksandr Natalenko (post-factum)
WARNING: multiple messages have this Message-ID (diff)
From: Oleksandr Natalenko via iommu <iommu@lists.linux-foundation.org>
To: Robin Murphy <robin.murphy@arm.com>, Christoph Hellwig <hch@lst.de>
Cc: "Toke Høiland-Jørgensen" <toke@toke.dk>,
Netdev <netdev@vger.kernel.org>, "Kalle Valo" <kvalo@kernel.org>,
linux-wireless <linux-wireless@vger.kernel.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
stable <stable@vger.kernel.org>,
"David S. Miller" <davem@davemloft.net>,
"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>,
"Christoph Hellwig" <hch@lst.de>
Subject: Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP
Date: Thu, 24 Mar 2022 11:25:06 +0100 [thread overview]
Message-ID: <4386660.LvFx2qVVIh@natalenko.name> (raw)
In-Reply-To: <20220324055732.GB12078@lst.de>
Hello.
On čtvrtek 24. března 2022 6:57:32 CET Christoph Hellwig wrote:
> On Wed, Mar 23, 2022 at 08:54:08PM +0000, Robin Murphy wrote:
> > I'll admit I still never quite grasped the reason for also adding the
> > override to swiotlb_sync_single_for_device() in aa6f8dcbab47, but I think
> > by that point we were increasingly tired and confused and starting to
> > second-guess ourselves (well, I was, at least). I don't think it's wrong
> > per se, but as I said I do think it can bite anyone who's been doing
> > dma_sync_*() wrong but getting away with it until now. If ddbd89deb7d3
> > alone turns out to work OK then I'd be inclined to try a partial revert of
> > just that one hunk.
>
> Agreed. Let's try that first.
>
> Oleksandr, can you try the patch below:
>
>
> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> index 6db1c475ec827..6c350555e5a1c 100644
> --- a/kernel/dma/swiotlb.c
> +++ b/kernel/dma/swiotlb.c
> @@ -701,13 +701,10 @@ void swiotlb_tbl_unmap_single(struct device *dev, phys_addr_t tlb_addr,
> void swiotlb_sync_single_for_device(struct device *dev, phys_addr_t tlb_addr,
> size_t size, enum dma_data_direction dir)
> {
> - /*
> - * Unconditional bounce is necessary to avoid corruption on
> - * sync_*_for_cpu or dma_ummap_* when the device didn't overwrite
> - * the whole lengt of the bounce buffer.
> - */
> - swiotlb_bounce(dev, tlb_addr, size, DMA_TO_DEVICE);
> - BUG_ON(!valid_dma_direction(dir));
> + if (dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL)
> + swiotlb_bounce(dev, tlb_addr, size, DMA_TO_DEVICE);
> + else
> + BUG_ON(dir != DMA_FROM_DEVICE);
> }
>
> void swiotlb_sync_single_for_cpu(struct device *dev, phys_addr_t tlb_addr,
>
With this patch the AP works for me.
Thanks.
--
Oleksandr Natalenko (post-factum)
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2022-03-24 10:25 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 [this message]
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
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=4386660.LvFx2qVVIh@natalenko.name \
--to=oleksandr@natalenko.name \
--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=netdev@vger.kernel.org \
--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=toke@toke.dk \
--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: 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.