From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: linux-s390 <linux-s390@vger.kernel.org>,
linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
"Jan Kara" <jack@suse.cz>, "Kees Cook" <keescook@chromium.org>,
"KVM list" <kvm@vger.kernel.org>,
"Daniel Vetter" <daniel.vetter@ffwll.com>,
"John Hubbard" <jhubbard@nvidia.com>,
LKML <linux-kernel@vger.kernel.org>,
"DRI Development" <dri-devel@lists.freedesktop.org>,
"Linux MM" <linux-mm@kvack.org>,
"Jérôme Glisse" <jglisse@redhat.com>,
"Linux PCI" <linux-pci@vger.kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Daniel Vetter" <daniel.vetter@intel.com>,
"Dan Williams" <dan.j.williams@intel.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
"open list:DMA BUFFER SHARING FRAMEWORK"
<linux-media@vger.kernel.org>
Subject: Re: [PATCH v3 12/16] PCI: Obey iomem restrictions for procfs mmap
Date: Thu, 22 Oct 2020 09:00:44 +0200 [thread overview]
Message-ID: <CAKMK7uEkAK42+19KRo06XzJFuMCVriEEg0jxqXq8oAdt2ExLsQ@mail.gmail.com> (raw)
In-Reply-To: <20201021232022.GN36674@ziepe.ca>
On Thu, Oct 22, 2020 at 1:20 AM Jason Gunthorpe <jgg@ziepe.ca> wrote:
>
> On Wed, Oct 21, 2020 at 09:24:08PM +0200, Daniel Vetter wrote:
> > On Wed, Oct 21, 2020 at 6:37 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> > >
> > > On Wed, Oct 21, 2020 at 05:54:54PM +0200, Daniel Vetter wrote:
> > >
> > > > 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.
> > >
> > > /dev/mem makes pgoff == pfn so it doesn't get changed by remap.
> > >
> > > pgoff doesn't get touched for MAP_SHARED either, so there are other
> > > users that could work like this - eg anyone mmaping IO memory is
> > > probably OK.
> >
> > I was more generally thinking for io_remap_pfn_users because of the
> > mkwrite use-case we might have in fbdev emulation in drm.
>
> You have a use case for MAP_PRIVATE and io_remap_pfn_range()??
Uh no :-) But for ioremaps and keep track of which pages userspace has
touched. Problem is that there's many displays where you need to
explicitly upload the data, and in drm we have ioctl calls for that.
fbdev mmap assumes this just magically happens. So you need to keep
track of write faults, launch a delayed worker which first re-protects
all ptes and then uploads the dirty pages. And ideally we wouldn't
have to implement this everywhere just for fbdev, but could wrap it
around an existing mmap implementation by just intercepting mkwrite.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-10-22 7:00 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
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 [this message]
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=CAKMK7uEkAK42+19KRo06XzJFuMCVriEEg0jxqXq8oAdt2ExLsQ@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 \
/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 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).