From: Jason Gunthorpe <jgg@ziepe.ca> To: "Christian König" <ckoenig.leichtzumerken@gmail.com> Cc: "Daniel Vetter" <daniel.vetter@ffwll.ch>, "Intel Graphics Development" <intel-gfx@lists.freedesktop.org>, "DRI Development" <dri-devel@lists.freedesktop.org>, "Sumit Semwal" <sumit.semwal@linaro.org>, linaro-mm-sig@lists.linaro.org, "John Stultz" <john.stultz@linaro.org>, "Matthew Wilcox" <willy@infradead.org>, "Thomas Zimmermann" <tzimmermann@suse.de>, "Daniel Vetter" <daniel.vetter@intel.com>, "Suren Baghdasaryan" <surenb@google.com>, "Christian König" <christian.koenig@amd.com>, linux-media@vger.kernel.org Subject: Re: [Linaro-mm-sig] Re: [PATCH] dma-buf: Require VM_PFNMAP vma for mmap Date: Wed, 23 Nov 2022 08:53:18 -0400 [thread overview] Message-ID: <Y34XvmtHfb4ZwopN@ziepe.ca> (raw) In-Reply-To: <f8f844a5-0910-d19a-5aea-df7a1d83b1d3@gmail.com> On Wed, Nov 23, 2022 at 01:49:41PM +0100, Christian König wrote: > Am 23.11.22 um 13:46 schrieb Jason Gunthorpe: > > On Wed, Nov 23, 2022 at 11:06:55AM +0100, Daniel Vetter wrote: > > > > > > Maybe a GFP flag to set the page reference count to zero or something > > > > like this? > > > Hm yeah that might work. I'm not sure what it will all break though? > > > And we'd need to make sure that underflowing the page refcount dies in > > > a backtrace. > > Mucking with the refcount like this to protect against crazy out of > > tree drives seems horrible.. > > Well not only out of tree drivers. The intree KVM got that horrible > wrong as well, those where the latest guys complaining about it. kvm was taking refs on special PTEs? That seems really unlikely? > > The WARN_ON(pag_count(p) != 1) seems like a reasonable thing to do > > though, though you must combine this with the special PTE flag.. > > That's not sufficient. The pages are released much later than things > actually go wrong. In most cases this WARN_ON here won't hit. How so? As long as the page is mapped into the PTE there is no issue with corruption. If dmabuf checks the refcount after it does the unmap mapping range it should catch any bogus pin that might be confused about address coherency. Jason
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@ziepe.ca> To: "Christian König" <ckoenig.leichtzumerken@gmail.com> Cc: "Daniel Vetter" <daniel.vetter@ffwll.ch>, "Christian König" <christian.koenig@amd.com>, "DRI Development" <dri-devel@lists.freedesktop.org>, "Intel Graphics Development" <intel-gfx@lists.freedesktop.org>, "Thomas Zimmermann" <tzimmermann@suse.de>, "Suren Baghdasaryan" <surenb@google.com>, "Matthew Wilcox" <willy@infradead.org>, "John Stultz" <john.stultz@linaro.org>, "Daniel Vetter" <daniel.vetter@intel.com>, "Sumit Semwal" <sumit.semwal@linaro.org>, linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org Subject: Re: [Linaro-mm-sig] Re: [PATCH] dma-buf: Require VM_PFNMAP vma for mmap Date: Wed, 23 Nov 2022 08:53:18 -0400 [thread overview] Message-ID: <Y34XvmtHfb4ZwopN@ziepe.ca> (raw) In-Reply-To: <f8f844a5-0910-d19a-5aea-df7a1d83b1d3@gmail.com> On Wed, Nov 23, 2022 at 01:49:41PM +0100, Christian König wrote: > Am 23.11.22 um 13:46 schrieb Jason Gunthorpe: > > On Wed, Nov 23, 2022 at 11:06:55AM +0100, Daniel Vetter wrote: > > > > > > Maybe a GFP flag to set the page reference count to zero or something > > > > like this? > > > Hm yeah that might work. I'm not sure what it will all break though? > > > And we'd need to make sure that underflowing the page refcount dies in > > > a backtrace. > > Mucking with the refcount like this to protect against crazy out of > > tree drives seems horrible.. > > Well not only out of tree drivers. The intree KVM got that horrible > wrong as well, those where the latest guys complaining about it. kvm was taking refs on special PTEs? That seems really unlikely? > > The WARN_ON(pag_count(p) != 1) seems like a reasonable thing to do > > though, though you must combine this with the special PTE flag.. > > That's not sufficient. The pages are released much later than things > actually go wrong. In most cases this WARN_ON here won't hit. How so? As long as the page is mapped into the PTE there is no issue with corruption. If dmabuf checks the refcount after it does the unmap mapping range it should catch any bogus pin that might be confused about address coherency. Jason
next prev parent reply other threads:[~2022-11-23 12:53 UTC|newest] Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-11-22 17:08 [PATCH] dma-buf: Require VM_PFNMAP vma for mmap Daniel Vetter 2022-11-22 17:08 ` [Intel-gfx] " Daniel Vetter 2022-11-22 17:08 ` Daniel Vetter 2022-11-22 18:03 ` Jason Gunthorpe 2022-11-22 18:03 ` Jason Gunthorpe 2022-11-22 18:08 ` Daniel Vetter 2022-11-22 18:08 ` [Intel-gfx] " Daniel Vetter 2022-11-22 18:08 ` Daniel Vetter 2022-11-22 18:50 ` Jason Gunthorpe 2022-11-22 18:50 ` Jason Gunthorpe 2022-11-22 19:29 ` Daniel Vetter 2022-11-22 19:29 ` [Intel-gfx] " Daniel Vetter 2022-11-22 19:29 ` Daniel Vetter 2022-11-22 19:34 ` Jason Gunthorpe 2022-11-22 19:34 ` Jason Gunthorpe 2022-11-22 19:50 ` Daniel Vetter 2022-11-22 19:50 ` [Intel-gfx] " Daniel Vetter 2022-11-22 19:50 ` Daniel Vetter 2022-11-23 9:06 ` Christian König 2022-11-23 9:06 ` Christian König 2022-11-23 9:06 ` [Intel-gfx] " Christian König 2022-11-23 9:30 ` Daniel Vetter 2022-11-23 9:30 ` Daniel Vetter 2022-11-23 9:30 ` [Intel-gfx] " Daniel Vetter 2022-11-23 9:39 ` [Linaro-mm-sig] " Christian König 2022-11-23 9:39 ` Christian König 2022-11-23 9:39 ` [Intel-gfx] " Christian König 2022-11-23 10:06 ` Daniel Vetter 2022-11-23 10:06 ` Daniel Vetter 2022-11-23 10:06 ` [Intel-gfx] " Daniel Vetter 2022-11-23 12:46 ` Jason Gunthorpe 2022-11-23 12:46 ` Jason Gunthorpe 2022-11-23 12:49 ` Christian König 2022-11-23 12:49 ` Christian König 2022-11-23 12:49 ` [Intel-gfx] " Christian König 2022-11-23 12:53 ` Jason Gunthorpe [this message] 2022-11-23 12:53 ` Jason Gunthorpe 2022-11-23 13:12 ` Christian König 2022-11-23 13:12 ` Christian König 2022-11-23 13:12 ` [Intel-gfx] " Christian König 2022-11-23 13:28 ` Jason Gunthorpe 2022-11-23 13:28 ` Jason Gunthorpe 2022-11-23 14:28 ` Daniel Vetter 2022-11-23 14:28 ` Daniel Vetter 2022-11-23 14:28 ` [Intel-gfx] " Daniel Vetter 2022-11-23 15:04 ` Jason Gunthorpe 2022-11-23 15:04 ` Jason Gunthorpe 2022-11-23 16:22 ` Daniel Vetter 2022-11-23 16:22 ` [Intel-gfx] " Daniel Vetter 2022-11-23 16:22 ` Daniel Vetter 2022-11-23 14:34 ` Daniel Vetter 2022-11-23 14:34 ` [Intel-gfx] " Daniel Vetter 2022-11-23 14:34 ` Daniel Vetter 2022-11-23 15:08 ` Jason Gunthorpe 2022-11-23 15:08 ` Jason Gunthorpe 2022-11-23 15:15 ` Christian König 2022-11-23 15:15 ` [Intel-gfx] " Christian König 2022-11-23 15:15 ` Christian König 2022-11-23 16:26 ` Daniel Vetter 2022-11-23 16:26 ` [Intel-gfx] " Daniel Vetter 2022-11-23 16:26 ` Daniel Vetter 2022-11-23 16:26 ` Jason Gunthorpe 2022-11-23 16:26 ` Jason Gunthorpe 2022-11-22 19:43 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork 2022-11-22 20:08 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork 2022-11-23 8:07 ` [PATCH] " Thomas Zimmermann 2022-11-23 8:07 ` [Intel-gfx] " Thomas Zimmermann 2022-11-23 8:07 ` Thomas Zimmermann 2022-11-23 9:33 ` Daniel Vetter 2022-11-23 9:33 ` Daniel Vetter 2022-11-23 9:33 ` [Intel-gfx] " Daniel Vetter 2022-11-23 9:58 ` [Intel-gfx] ✗ Fi.CI.IGT: failure for " Patchwork
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=Y34XvmtHfb4ZwopN@ziepe.ca \ --to=jgg@ziepe.ca \ --cc=christian.koenig@amd.com \ --cc=ckoenig.leichtzumerken@gmail.com \ --cc=daniel.vetter@ffwll.ch \ --cc=daniel.vetter@intel.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=john.stultz@linaro.org \ --cc=linaro-mm-sig@lists.linaro.org \ --cc=linux-media@vger.kernel.org \ --cc=sumit.semwal@linaro.org \ --cc=surenb@google.com \ --cc=tzimmermann@suse.de \ --cc=willy@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: 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.