linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: "DRI Development" <dri-devel@lists.freedesktop.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"KVM list" <kvm@vger.kernel.org>, "Linux MM" <linux-mm@kvack.org>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
	"open list:DMA BUFFER SHARING FRAMEWORK"
	<linux-media@vger.kernel.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	"Daniel Vetter" <daniel.vetter@intel.com>,
	"Kees Cook" <keescook@chromium.org>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"John Hubbard" <jhubbard@nvidia.com>,
	"Jérôme Glisse" <jglisse@redhat.com>, "Jan Kara" <jack@suse.cz>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Linux PCI" <linux-pci@vger.kernel.org>,
	"Daniel Vetter" <daniel.vetter@ffwll.com>
Subject: Re: [PATCH v3 12/16] PCI: Obey iomem restrictions for procfs mmap
Date: Wed, 21 Oct 2020 17:54:54 +0200	[thread overview]
Message-ID: <CAKMK7uGq0=ks7Zj1Et44k7x9FwE9u_ua4zANSqrLRri0v01V+Q@mail.gmail.com> (raw)
In-Reply-To: <20201021151352.GL36674@ziepe.ca>

On Wed, Oct 21, 2020 at 5:13 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
>
> On Wed, Oct 21, 2020 at 04:42:11PM +0200, Daniel Vetter wrote:
>
> > Uh yes. In drivers/gpu this isn't a problem because we only install
> > ptes from the vm_ops->fault handler. So no races. And I don't think
> > you can fix this otherwise through holding locks: mmap_sem we can't
> > hold because before vma_link we don't even know which mm_struct is
> > involved, so can't solve the race. Plus this would be worse that
> > mm_take_all_locks used by mmu notifier. And the address_space
> > i_mmap_lock is also no good since it's not held during the ->mmap
> > callback, when we write the ptes. And the resource locks is even less
> > useful, since we're not going to hold that at vma_link() time for
> > sure.
> >
> > Hence delaying the pte writes after the vma_link, which means ->fault
> > time, looks like the only way to close this gap.
>
> > Trouble is I have no idea how to do this cleanly ...
>
> How about add a vm_ops callback 'install_pages'/'prefault_pages' ?
>
> Call it after vm_link() - basically just move the remap_pfn, under
> some other lock, into there.

Yeah, I think that would be useful. This might also be useful for
something entirely different: For legacy fbdev emulation on top of drm
kernel modesetting drivers we need to track dirty pages of VM_IO
mmaps. Right now that's a gross hack, and essentially we just pay the
price for entirely separate storage and an additional memcpy when this
is needed to emulate fbdev mmap on top of drm. But if we have
install_ptes callback or similar we could just wrap the native vm_ops
and add a mkwrite callback on top for that dirty tracking. For that
the hook would need to be after vm_set_page_prot so that we
write-protect the ptes by default, since that's where we compute
vma_wants_writenotify(). That's also after vma_link, so one hook for
two use-cases.

The trouble is that io_remap_pfn adjust vma->pgoff, so we'd need to
split that. So ideally ->mmap would never set up any ptes.

I guess one option would be if remap_pfn_range would steal the
vma->vm_ops pointer for itself, then it could set up the correct
->install_ptes hook. But there's tons of callers for that, so not sure
that's a bright idea.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


  reply	other threads:[~2020-10-21 15:55 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-21  8:56 [PATCH v3 00/16] follow_pfn and other iomap races Daniel Vetter
2020-10-21  8:56 ` [PATCH v3 01/16] drm/exynos: Stop using frame_vector helpers Daniel Vetter
2020-10-21  8:56 ` [PATCH v3 02/16] drm/exynos: Use FOLL_LONGTERM for g2d cmdlists Daniel Vetter
2020-10-21  8:56 ` [PATCH v3 03/16] misc/habana: Stop using frame_vector helpers Daniel Vetter
2020-10-21  8:56 ` [PATCH v3 04/16] misc/habana: Use FOLL_LONGTERM for userptr Daniel Vetter
2020-10-23  9:12   ` Daniel Vetter
2020-10-21  8:56 ` [PATCH v3 05/16] mm/frame-vector: Use FOLL_LONGTERM Daniel Vetter
2020-10-21  8:56 ` [PATCH v3 06/16] media: videobuf2: Move frame_vector into media subsystem Daniel Vetter
2020-10-21  8:56 ` [PATCH v3 07/16] mm: Close race in generic_access_phys Daniel Vetter
2020-10-21  8:56 ` [PATCH v3 08/16] s390/pci: Remove races against pte updates Daniel Vetter
2020-10-21  9:37   ` Niklas Schnelle
2020-10-21 13:56     ` Daniel Vetter
2020-10-21  8:56 ` [PATCH v3 09/16] mm: Add unsafe_follow_pfn Daniel Vetter
2020-10-21  8:56 ` [PATCH v3 10/16] media/videbuf1|2: Mark follow_pfn usage as unsafe Daniel Vetter
2020-10-21  8:56 ` [PATCH v3 11/16] vfio/type1: Mark follow_pfn " Daniel Vetter
2020-10-21  8:56 ` [PATCH v3 12/16] PCI: Obey iomem restrictions for procfs mmap Daniel Vetter
2020-10-21 12:50   ` Jason Gunthorpe
2020-10-21 14:42     ` Daniel Vetter
2020-10-21 15:13       ` Jason Gunthorpe
2020-10-21 15:54         ` Daniel Vetter [this message]
2020-10-21 16:37           ` Jason Gunthorpe
2020-10-21 19:24             ` Daniel Vetter
2020-10-21 23:20               ` Jason Gunthorpe
2020-10-22  7:00                 ` Daniel Vetter
2020-10-22 11:43                   ` Jason Gunthorpe
2020-10-22 13:04                     ` Daniel Vetter
2020-10-21  8:56 ` [PATCH v3 13/16] /dev/mem: Only set filp->f_mapping Daniel Vetter
2020-10-21 18:21   ` Dan Williams
2020-10-21  8:56 ` [PATCH v3 14/16] resource: Move devmem revoke code to resource framework Daniel Vetter
2020-10-21 18:59   ` Dan Williams
2020-10-21 19:25     ` Daniel Vetter
2020-10-21  8:56 ` [PATCH v3 15/16] sysfs: Support zapping of binary attr mmaps Daniel Vetter
2020-10-21  8:56 ` [PATCH v3 16/16] PCI: Revoke mappings like devmem Daniel Vetter
2020-10-21 12:51 ` [PATCH v3 00/16] follow_pfn and other iomap races Jason Gunthorpe

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='CAKMK7uGq0=ks7Zj1Et44k7x9FwE9u_ua4zANSqrLRri0v01V+Q@mail.gmail.com' \
    --to=daniel.vetter@ffwll.ch \
    --cc=akpm@linux-foundation.org \
    --cc=bhelgaas@google.com \
    --cc=dan.j.williams@intel.com \
    --cc=daniel.vetter@ffwll.com \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jack@suse.cz \
    --cc=jgg@ziepe.ca \
    --cc=jglisse@redhat.com \
    --cc=jhubbard@nvidia.com \
    --cc=keescook@chromium.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --subject='Re: [PATCH v3 12/16] PCI: Obey iomem restrictions for procfs mmap' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).