From: Halil Pasic <pasic@linux.ibm.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Toke Høiland-Jørgensen" <toke@toke.dk>,
"Robin Murphy" <robin.murphy@arm.com>,
"Christoph Hellwig" <hch@lst.de>,
"Maxime Bizon" <mbizon@freebox.fr>,
"Oleksandr Natalenko" <oleksandr@natalenko.name>,
"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>,
"Halil Pasic" <pasic@linux.ibm.com>
Subject: Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP
Date: Mon, 28 Mar 2022 01:52:11 +0200 [thread overview]
Message-ID: <20220328015211.296739a4.pasic@linux.ibm.com> (raw)
In-Reply-To: <CAHk-=wgUx5CVF_1aEkhhEiRGXHgKzUdKiyctBKcHAxkxPpbiaw@mail.gmail.com>
On Sat, 26 Mar 2022 22:21:03 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Sat, Mar 26, 2022 at 10:06 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > On Sat, Mar 26, 2022 at 8:49 PM Halil Pasic <pasic@linux.ibm.com> wrote:
> > >
> > > I agree it CPU modified buffers *concurrently* with DMA can never work,
> > > and I believe the ownership model was conceived to prevent this
> > > situation.
> >
> > But that just means that the "ownership" model is garbage, and cannot
> > handle this REAL LIFE situation.
>
> Just to clarify: I obviously agree that the "both sides modify
> concurrently" obviously cannot work with bounce buffers.
>
> People still do want to do that, but they'll limit themselves to
> actual cache-coherent DMA when they do so (or do nasty uncached
> accesses but at least no bounce buffering).
Thanks for the explanation!
>
> But the "bounce ownership back and forth" model comes up empty when
> the CPU wants to read while the DMA is still going on. And that not
> only can work, but *has* worked.
>
> You could have a new "get me a non-ownership copy" operation of
> course,
Yes, https://www.spinics.net/lists/linux-wireless/msg222442.html was
mostly about exploring that idea.
> but that hits the problem of "which existing drivers need it?"
>
> We have no idea, outside of ath9k.
>
> This is why I believe we have to keep the existing semantics in a way
> that keep ath9k - and any number of unknown other drivers - happy.
I agree.
>
> And then for the cases where you want to introduce the zeroing because
> you don't know how much data the DMA returned - those are the ones
> you'll have to mark some way.
I have no intention of pursuing this. When fixing the information leak,
I happened to realize, that a somewhat similar situation can emerge when
mappings are reused. It seemed like an easy fix, so I asked the swiotlb
maintainers, and they agreed. It ain't my field of expertise, and the
drivers I'm interested in don't need this functionality.
Regards,
Halil
>
> Linus
WARNING: multiple messages have this Message-ID (diff)
From: Halil Pasic <pasic@linux.ibm.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Toke Høiland-Jørgensen" <toke@toke.dk>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
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>,
"David S. Miller" <davem@davemloft.net>,
"Halil Pasic" <pasic@linux.ibm.com>,
iommu <iommu@lists.linux-foundation.org>,
"Olha Cherevyk" <olha.cherevyk@gmail.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Maxime Bizon" <mbizon@freebox.fr>,
"Paolo Abeni" <pabeni@redhat.com>,
"Robin Murphy" <robin.murphy@arm.com>,
"Christoph Hellwig" <hch@lst.de>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP
Date: Mon, 28 Mar 2022 01:52:11 +0200 [thread overview]
Message-ID: <20220328015211.296739a4.pasic@linux.ibm.com> (raw)
In-Reply-To: <CAHk-=wgUx5CVF_1aEkhhEiRGXHgKzUdKiyctBKcHAxkxPpbiaw@mail.gmail.com>
On Sat, 26 Mar 2022 22:21:03 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Sat, Mar 26, 2022 at 10:06 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > On Sat, Mar 26, 2022 at 8:49 PM Halil Pasic <pasic@linux.ibm.com> wrote:
> > >
> > > I agree it CPU modified buffers *concurrently* with DMA can never work,
> > > and I believe the ownership model was conceived to prevent this
> > > situation.
> >
> > But that just means that the "ownership" model is garbage, and cannot
> > handle this REAL LIFE situation.
>
> Just to clarify: I obviously agree that the "both sides modify
> concurrently" obviously cannot work with bounce buffers.
>
> People still do want to do that, but they'll limit themselves to
> actual cache-coherent DMA when they do so (or do nasty uncached
> accesses but at least no bounce buffering).
Thanks for the explanation!
>
> But the "bounce ownership back and forth" model comes up empty when
> the CPU wants to read while the DMA is still going on. And that not
> only can work, but *has* worked.
>
> You could have a new "get me a non-ownership copy" operation of
> course,
Yes, https://www.spinics.net/lists/linux-wireless/msg222442.html was
mostly about exploring that idea.
> but that hits the problem of "which existing drivers need it?"
>
> We have no idea, outside of ath9k.
>
> This is why I believe we have to keep the existing semantics in a way
> that keep ath9k - and any number of unknown other drivers - happy.
I agree.
>
> And then for the cases where you want to introduce the zeroing because
> you don't know how much data the DMA returned - those are the ones
> you'll have to mark some way.
I have no intention of pursuing this. When fixing the information leak,
I happened to realize, that a somewhat similar situation can emerge when
mappings are reused. It seemed like an easy fix, so I asked the swiotlb
maintainers, and they agreed. It ain't my field of expertise, and the
drivers I'm interested in don't need this functionality.
Regards,
Halil
>
> Linus
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2022-03-27 23:52 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
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 [this message]
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=20220328015211.296739a4.pasic@linux.ibm.com \
--to=pasic@linux.ibm.com \
--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=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.