All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Dan Williams <dan.j.williams@intel.com>
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>,
	"Linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	"Daniel Vetter" <daniel.vetter@intel.com>,
	"Jason Gunthorpe" <jgg@ziepe.ca>,
	"Kees Cook" <keescook@chromium.org>,
	"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>
Subject: Re: [PATCH 10/13] PCI: revoke mappings like devmem
Date: Thu, 8 Oct 2020 10:09:54 +0200	[thread overview]
Message-ID: <CAKMK7uEETcQrPBC=4URQZtD73nA9MvQpBx-TOv95bdwzNOOA2g@mail.gmail.com> (raw)
In-Reply-To: <CAPcyv4iN1q0LUVTO6igMKPe-8hnR5ULF+mBnWy6bdXfY2M6YmA@mail.gmail.com>

On Thu, Oct 8, 2020 at 12:29 AM Dan Williams <dan.j.williams@intel.com> wrote:
>
> On Wed, Oct 7, 2020 at 3:23 PM Dan Williams <dan.j.williams@intel.com> wrote:
> >
> > On Wed, Oct 7, 2020 at 12:49 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > >
> > > On Wed, Oct 7, 2020 at 9:33 PM Dan Williams <dan.j.williams@intel.com> wrote:
> > > >
> > > > On Wed, Oct 7, 2020 at 11:11 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > > >
> > > > > Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
> > > > > the region") /dev/kmem zaps ptes when the kernel requests exclusive
> > > > > acccess to an iomem region. And with CONFIG_IO_STRICT_DEVMEM, this is
> > > > > the default for all driver uses.
> > > > >
> > > > > Except there's two more ways to access pci bars: sysfs and proc mmap
> > > > > support. Let's plug that hole.
> > > >
> > > > Ooh, yes, lets.
> > > >
> > > > > For revoke_devmem() to work we need to link our vma into the same
> > > > > address_space, with consistent vma->vm_pgoff. ->pgoff is already
> > > > > adjusted, because that's how (io_)remap_pfn_range works, but for the
> > > > > mapping we need to adjust vma->vm_file->f_mapping. Usually that's done
> > > > > at ->open time, but that's a bit tricky here with all the entry points
> > > > > and arch code. So instead create a fake file and adjust vma->vm_file.
> > > >
> > > > I don't think you want to share the devmem inode for this, this should
> > > > be based off the sysfs inode which I believe there is already only one
> > > > instance per resource. In contrast /dev/mem can have multiple inodes
> > > > because anyone can just mknod a new character device file, the same
> > > > problem does not exist for sysfs.
> > >
> > > But then I need to find the right one, plus I also need to find the
> > > right one for the procfs side. That gets messy, and I already have no
> > > idea how to really test this. Shared address_space is the same trick
> > > we're using in drm (where we have multiple things all pointing to the
> > > same underlying resources, through different files), and it gets the
> > > job done. So that's why I figured the shared address_space is the
> > > cleaner solution since then unmap_mapping_range takes care of
> > > iterating over all vma for us. I guess I could reimplement that logic
> > > with our own locking and everything in revoke_devmem, but feels a bit
> > > silly. But it would also solve the problem of having mutliple
> > > different mknod of /dev/kmem with different address_space behind them.
> > > Also because of how remap_pfn_range works, all these vma do use the
> > > same pgoff already anyway.
> >
> > True, remap_pfn_range() makes sure that ->pgoff is an absolute
> > physical address offset for all use cases. So you might be able to
> > just point proc_bus_pci_open() at the shared devmem address space. For
> > sysfs it's messier. I think you would need to somehow get the inode
> > from kernfs_fop_open() to adjust its address space, but only if the
> > bin_file will ultimately be used for PCI memory.

Just read the code  a bit more, and for proc it's impossible. There's
only a single file, and before you mmap it you have to call a few
ioctl to select the right pci resource on that device you want to
mmap. Which includes legacy ioport stuff, and at least for now those
don't get revoked (maybe they should, but I'm looking at iomem here
now). Setting the mapping too early in ->open means that on
architectures which can do ioport as mmaps (not many, but powerpc is
among them) we'd shoot down these mmaps too.

Looking at the code there's the generic implementation, which consults
pci_iobar_pfn. And the only other implementation for sparc looks
similar, they separate iomem vs ioport through different pfn. So I
think this should indeed work.

> To me this seems like a new sysfs_create_bin_file() flavor that
> registers the file with the common devmem address_space.

Hm I think we could just add a i_mapping member to bin_attributes and
let the normal open code set that up for us. That should work.
mmapable binary sysfs file is already a similar special case.
-Daniel




--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Dan Williams <dan.j.williams@intel.com>
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>,
	"Jason Gunthorpe" <jgg@ziepe.ca>,
	"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>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	"Linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: [PATCH 10/13] PCI: revoke mappings like devmem
Date: Thu, 8 Oct 2020 10:09:54 +0200	[thread overview]
Message-ID: <CAKMK7uEETcQrPBC=4URQZtD73nA9MvQpBx-TOv95bdwzNOOA2g@mail.gmail.com> (raw)
In-Reply-To: <CAPcyv4iN1q0LUVTO6igMKPe-8hnR5ULF+mBnWy6bdXfY2M6YmA@mail.gmail.com>

On Thu, Oct 8, 2020 at 12:29 AM Dan Williams <dan.j.williams@intel.com> wrote:
>
> On Wed, Oct 7, 2020 at 3:23 PM Dan Williams <dan.j.williams@intel.com> wrote:
> >
> > On Wed, Oct 7, 2020 at 12:49 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > >
> > > On Wed, Oct 7, 2020 at 9:33 PM Dan Williams <dan.j.williams@intel.com> wrote:
> > > >
> > > > On Wed, Oct 7, 2020 at 11:11 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > > >
> > > > > Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
> > > > > the region") /dev/kmem zaps ptes when the kernel requests exclusive
> > > > > acccess to an iomem region. And with CONFIG_IO_STRICT_DEVMEM, this is
> > > > > the default for all driver uses.
> > > > >
> > > > > Except there's two more ways to access pci bars: sysfs and proc mmap
> > > > > support. Let's plug that hole.
> > > >
> > > > Ooh, yes, lets.
> > > >
> > > > > For revoke_devmem() to work we need to link our vma into the same
> > > > > address_space, with consistent vma->vm_pgoff. ->pgoff is already
> > > > > adjusted, because that's how (io_)remap_pfn_range works, but for the
> > > > > mapping we need to adjust vma->vm_file->f_mapping. Usually that's done
> > > > > at ->open time, but that's a bit tricky here with all the entry points
> > > > > and arch code. So instead create a fake file and adjust vma->vm_file.
> > > >
> > > > I don't think you want to share the devmem inode for this, this should
> > > > be based off the sysfs inode which I believe there is already only one
> > > > instance per resource. In contrast /dev/mem can have multiple inodes
> > > > because anyone can just mknod a new character device file, the same
> > > > problem does not exist for sysfs.
> > >
> > > But then I need to find the right one, plus I also need to find the
> > > right one for the procfs side. That gets messy, and I already have no
> > > idea how to really test this. Shared address_space is the same trick
> > > we're using in drm (where we have multiple things all pointing to the
> > > same underlying resources, through different files), and it gets the
> > > job done. So that's why I figured the shared address_space is the
> > > cleaner solution since then unmap_mapping_range takes care of
> > > iterating over all vma for us. I guess I could reimplement that logic
> > > with our own locking and everything in revoke_devmem, but feels a bit
> > > silly. But it would also solve the problem of having mutliple
> > > different mknod of /dev/kmem with different address_space behind them.
> > > Also because of how remap_pfn_range works, all these vma do use the
> > > same pgoff already anyway.
> >
> > True, remap_pfn_range() makes sure that ->pgoff is an absolute
> > physical address offset for all use cases. So you might be able to
> > just point proc_bus_pci_open() at the shared devmem address space. For
> > sysfs it's messier. I think you would need to somehow get the inode
> > from kernfs_fop_open() to adjust its address space, but only if the
> > bin_file will ultimately be used for PCI memory.

Just read the code  a bit more, and for proc it's impossible. There's
only a single file, and before you mmap it you have to call a few
ioctl to select the right pci resource on that device you want to
mmap. Which includes legacy ioport stuff, and at least for now those
don't get revoked (maybe they should, but I'm looking at iomem here
now). Setting the mapping too early in ->open means that on
architectures which can do ioport as mmaps (not many, but powerpc is
among them) we'd shoot down these mmaps too.

Looking at the code there's the generic implementation, which consults
pci_iobar_pfn. And the only other implementation for sparc looks
similar, they separate iomem vs ioport through different pfn. So I
think this should indeed work.

> To me this seems like a new sysfs_create_bin_file() flavor that
> registers the file with the common devmem address_space.

Hm I think we could just add a i_mapping member to bin_attributes and
let the normal open code set that up for us. That should work.
mmapable binary sysfs file is already a similar special case.
-Daniel




--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Dan Williams <dan.j.williams@intel.com>
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>,
	"Jason Gunthorpe" <jgg@ziepe.ca>,
	"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>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	"Linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: [PATCH 10/13] PCI: revoke mappings like devmem
Date: Thu, 8 Oct 2020 10:09:54 +0200	[thread overview]
Message-ID: <CAKMK7uEETcQrPBC=4URQZtD73nA9MvQpBx-TOv95bdwzNOOA2g@mail.gmail.com> (raw)
In-Reply-To: <CAPcyv4iN1q0LUVTO6igMKPe-8hnR5ULF+mBnWy6bdXfY2M6YmA@mail.gmail.com>

On Thu, Oct 8, 2020 at 12:29 AM Dan Williams <dan.j.williams@intel.com> wrote:
>
> On Wed, Oct 7, 2020 at 3:23 PM Dan Williams <dan.j.williams@intel.com> wrote:
> >
> > On Wed, Oct 7, 2020 at 12:49 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > >
> > > On Wed, Oct 7, 2020 at 9:33 PM Dan Williams <dan.j.williams@intel.com> wrote:
> > > >
> > > > On Wed, Oct 7, 2020 at 11:11 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > > >
> > > > > Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
> > > > > the region") /dev/kmem zaps ptes when the kernel requests exclusive
> > > > > acccess to an iomem region. And with CONFIG_IO_STRICT_DEVMEM, this is
> > > > > the default for all driver uses.
> > > > >
> > > > > Except there's two more ways to access pci bars: sysfs and proc mmap
> > > > > support. Let's plug that hole.
> > > >
> > > > Ooh, yes, lets.
> > > >
> > > > > For revoke_devmem() to work we need to link our vma into the same
> > > > > address_space, with consistent vma->vm_pgoff. ->pgoff is already
> > > > > adjusted, because that's how (io_)remap_pfn_range works, but for the
> > > > > mapping we need to adjust vma->vm_file->f_mapping. Usually that's done
> > > > > at ->open time, but that's a bit tricky here with all the entry points
> > > > > and arch code. So instead create a fake file and adjust vma->vm_file.
> > > >
> > > > I don't think you want to share the devmem inode for this, this should
> > > > be based off the sysfs inode which I believe there is already only one
> > > > instance per resource. In contrast /dev/mem can have multiple inodes
> > > > because anyone can just mknod a new character device file, the same
> > > > problem does not exist for sysfs.
> > >
> > > But then I need to find the right one, plus I also need to find the
> > > right one for the procfs side. That gets messy, and I already have no
> > > idea how to really test this. Shared address_space is the same trick
> > > we're using in drm (where we have multiple things all pointing to the
> > > same underlying resources, through different files), and it gets the
> > > job done. So that's why I figured the shared address_space is the
> > > cleaner solution since then unmap_mapping_range takes care of
> > > iterating over all vma for us. I guess I could reimplement that logic
> > > with our own locking and everything in revoke_devmem, but feels a bit
> > > silly. But it would also solve the problem of having mutliple
> > > different mknod of /dev/kmem with different address_space behind them.
> > > Also because of how remap_pfn_range works, all these vma do use the
> > > same pgoff already anyway.
> >
> > True, remap_pfn_range() makes sure that ->pgoff is an absolute
> > physical address offset for all use cases. So you might be able to
> > just point proc_bus_pci_open() at the shared devmem address space. For
> > sysfs it's messier. I think you would need to somehow get the inode
> > from kernfs_fop_open() to adjust its address space, but only if the
> > bin_file will ultimately be used for PCI memory.

Just read the code  a bit more, and for proc it's impossible. There's
only a single file, and before you mmap it you have to call a few
ioctl to select the right pci resource on that device you want to
mmap. Which includes legacy ioport stuff, and at least for now those
don't get revoked (maybe they should, but I'm looking at iomem here
now). Setting the mapping too early in ->open means that on
architectures which can do ioport as mmaps (not many, but powerpc is
among them) we'd shoot down these mmaps too.

Looking at the code there's the generic implementation, which consults
pci_iobar_pfn. And the only other implementation for sparc looks
similar, they separate iomem vs ioport through different pfn. So I
think this should indeed work.

> To me this seems like a new sysfs_create_bin_file() flavor that
> registers the file with the common devmem address_space.

Hm I think we could just add a i_mapping member to bin_attributes and
let the normal open code set that up for us. That should work.
mmapable binary sysfs file is already a similar special case.
-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

  reply	other threads:[~2020-10-08  8:10 UTC|newest]

Thread overview: 166+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-07 16:44 [PATCH 00/13] follow_pfn and other iomap races Daniel Vetter
2020-10-07 16:44 ` Daniel Vetter
2020-10-07 16:44 ` Daniel Vetter
2020-10-07 16:44 ` [PATCH 01/13] drm/exynos: Stop using frame_vector helpers Daniel Vetter
2020-10-07 16:44   ` Daniel Vetter
2020-10-07 16:44   ` Daniel Vetter
2020-10-07 20:32   ` John Hubbard
2020-10-07 20:32     ` John Hubbard
2020-10-07 20:32     ` John Hubbard
2020-10-07 21:32     ` Daniel Vetter
2020-10-07 21:32       ` Daniel Vetter
2020-10-07 21:32       ` Daniel Vetter
2020-10-07 21:36       ` John Hubbard
2020-10-07 21:36         ` John Hubbard
2020-10-07 21:36         ` John Hubbard
2020-10-07 21:50         ` Daniel Vetter
2020-10-07 21:50           ` Daniel Vetter
2020-10-07 21:50           ` Daniel Vetter
2020-10-07 16:44 ` [PATCH 02/13] drm/exynos: Use FOLL_LONGTERM for g2d cmdlists Daniel Vetter
2020-10-07 16:44   ` Daniel Vetter
2020-10-07 16:44   ` Daniel Vetter
2020-10-07 20:43   ` John Hubbard
2020-10-07 20:43     ` John Hubbard
2020-10-07 20:43     ` John Hubbard
2020-10-07 16:44 ` [PATCH 03/13] misc/habana: Stop using frame_vector helpers Daniel Vetter
2020-10-07 16:44   ` Daniel Vetter
2020-10-07 16:44   ` Daniel Vetter
2020-10-07 20:38   ` John Hubbard
2020-10-07 20:38     ` John Hubbard
2020-10-07 20:38     ` John Hubbard
2020-10-07 16:44 ` [PATCH 04/13] misc/habana: Use FOLL_LONGTERM for userptr Daniel Vetter
2020-10-07 16:44   ` Daniel Vetter
2020-10-07 16:44   ` Daniel Vetter
2020-10-07 20:46   ` John Hubbard
2020-10-07 20:46     ` John Hubbard
2020-10-07 20:46     ` John Hubbard
2020-10-07 16:44 ` [PATCH 05/13] mm/frame-vector: Use FOLL_LONGTERM Daniel Vetter
2020-10-07 16:44   ` Daniel Vetter
2020-10-07 16:44   ` Daniel Vetter
2020-10-07 16:53   ` Jason Gunthorpe
2020-10-07 16:53     ` Jason Gunthorpe
2020-10-07 16:53     ` Jason Gunthorpe
2020-10-07 17:12     ` Daniel Vetter
2020-10-07 17:12       ` Daniel Vetter
2020-10-07 17:12       ` Daniel Vetter
2020-10-07 17:33       ` Jason Gunthorpe
2020-10-07 17:33         ` Jason Gunthorpe
2020-10-07 17:33         ` Jason Gunthorpe
2020-10-07 21:13   ` John Hubbard
2020-10-07 21:13     ` John Hubbard
2020-10-07 21:13     ` John Hubbard
2020-10-07 21:30     ` Daniel Vetter
2020-10-07 21:30       ` Daniel Vetter
2020-10-07 21:30       ` Daniel Vetter
2020-10-07 16:44 ` [PATCH 06/13] media: videobuf2: Move frame_vector into media subsystem Daniel Vetter
2020-10-07 16:44   ` Daniel Vetter
2020-10-07 16:44   ` Daniel Vetter
2020-10-07 22:18   ` John Hubbard
2020-10-07 22:18     ` John Hubbard
2020-10-07 22:18     ` John Hubbard
2020-10-07 16:44 ` [PATCH 07/13] mm: close race in generic_access_phys Daniel Vetter
2020-10-07 16:44   ` Daniel Vetter
2020-10-07 16:44   ` Daniel Vetter
2020-10-07 17:27   ` Jason Gunthorpe
2020-10-07 17:27     ` Jason Gunthorpe
2020-10-07 17:27     ` Jason Gunthorpe
2020-10-07 18:01     ` Daniel Vetter
2020-10-07 18:01       ` Daniel Vetter
2020-10-07 18:01       ` Daniel Vetter
2020-10-07 23:21       ` Jason Gunthorpe
2020-10-07 23:21         ` Jason Gunthorpe
2020-10-07 23:21         ` Jason Gunthorpe
2020-10-08  0:44   ` John Hubbard
2020-10-08  0:44     ` John Hubbard
2020-10-08  0:44     ` John Hubbard
2020-10-08  7:23     ` Daniel Vetter
2020-10-08  7:23       ` Daniel Vetter
2020-10-08  7:23       ` Daniel Vetter
2020-10-07 16:44 ` [PATCH 08/13] s390/pci: Remove races against pte updates Daniel Vetter
2020-10-07 16:44   ` Daniel Vetter
2020-10-07 16:44   ` Daniel Vetter
2020-10-08 16:44   ` Gerald Schaefer
2020-10-08 16:44     ` Gerald Schaefer
2020-10-08 16:44     ` Gerald Schaefer
2020-10-08 17:16     ` Daniel Vetter
2020-10-08 17:16       ` Daniel Vetter
2020-10-08 17:16       ` Daniel Vetter
2020-10-07 16:44 ` [PATCH 09/13] PCI: obey iomem restrictions for procfs mmap Daniel Vetter
2020-10-07 16:44   ` Daniel Vetter
2020-10-07 16:44   ` Daniel Vetter
2020-10-07 18:46   ` Bjorn Helgaas
2020-10-07 18:46     ` Bjorn Helgaas
2020-10-07 18:46     ` Bjorn Helgaas
2020-10-07 18:46     ` Bjorn Helgaas
2020-10-07 16:44 ` [PATCH 10/13] PCI: revoke mappings like devmem Daniel Vetter
2020-10-07 16:44   ` Daniel Vetter
2020-10-07 16:44   ` Daniel Vetter
2020-10-07 18:41   ` Bjorn Helgaas
2020-10-07 18:41     ` Bjorn Helgaas
2020-10-07 18:41     ` Bjorn Helgaas
2020-10-07 19:24     ` Daniel Vetter
2020-10-07 19:24       ` Daniel Vetter
2020-10-07 19:24       ` Daniel Vetter
2020-10-07 19:33   ` Dan Williams
2020-10-07 19:33     ` Dan Williams
2020-10-07 19:33     ` Dan Williams
2020-10-07 19:47     ` Daniel Vetter
2020-10-07 19:47       ` Daniel Vetter
2020-10-07 19:47       ` Daniel Vetter
2020-10-07 22:23       ` Dan Williams
2020-10-07 22:23         ` Dan Williams
2020-10-07 22:23         ` Dan Williams
2020-10-07 22:29         ` Dan Williams
2020-10-07 22:29           ` Dan Williams
2020-10-07 22:29           ` Dan Williams
2020-10-08  8:09           ` Daniel Vetter [this message]
2020-10-08  8:09             ` Daniel Vetter
2020-10-08  8:09             ` Daniel Vetter
2020-10-07 23:24     ` Jason Gunthorpe
2020-10-07 23:24       ` Jason Gunthorpe
2020-10-07 23:24       ` Jason Gunthorpe
2020-10-08  7:31       ` Daniel Vetter
2020-10-08  7:31         ` Daniel Vetter
2020-10-08  7:31         ` Daniel Vetter
2020-10-08  7:49       ` Dan Williams
2020-10-08  7:49         ` Dan Williams
2020-10-08  7:49         ` Dan Williams
2020-10-08  8:13         ` Daniel Vetter
2020-10-08  8:13           ` Daniel Vetter
2020-10-08  8:13           ` Daniel Vetter
2020-10-08  8:35           ` Dan Williams
2020-10-08  8:35             ` Dan Williams
2020-10-08  8:35             ` Dan Williams
2020-10-08 12:41         ` Jason Gunthorpe
2020-10-08 12:41           ` Jason Gunthorpe
2020-10-08 12:41           ` Jason Gunthorpe
2020-10-07 16:44 ` [PATCH 11/13] mm: add unsafe_follow_pfn Daniel Vetter
2020-10-07 16:44   ` Daniel Vetter
2020-10-07 16:44   ` Daniel Vetter
2020-10-07 17:36   ` Jason Gunthorpe
2020-10-07 17:36     ` Jason Gunthorpe
2020-10-07 17:36     ` Jason Gunthorpe
2020-10-07 18:10     ` Daniel Vetter
2020-10-07 18:10       ` Daniel Vetter
2020-10-07 18:10       ` Daniel Vetter
2020-10-07 19:00       ` Jason Gunthorpe
2020-10-07 19:00         ` Jason Gunthorpe
2020-10-07 19:00         ` Jason Gunthorpe
2020-10-07 19:38         ` Daniel Vetter
2020-10-07 19:38           ` Daniel Vetter
2020-10-07 19:38           ` Daniel Vetter
2020-10-07 16:44 ` [PATCH 12/13] media/videbuf1|2: Mark follow_pfn usage as unsafe Daniel Vetter
2020-10-07 16:44   ` Daniel Vetter
2020-10-07 16:44   ` Daniel Vetter
2020-10-07 16:44 ` [PATCH 13/13] vfio/type1: Mark follow_pfn " Daniel Vetter
2020-10-07 16:44   ` Daniel Vetter
2020-10-07 16:44   ` Daniel Vetter
2020-10-07 17:39   ` Jason Gunthorpe
2020-10-07 17:39     ` Jason Gunthorpe
2020-10-07 17:39     ` Jason Gunthorpe
2020-10-07 18:14     ` Daniel Vetter
2020-10-07 18:14       ` Daniel Vetter
2020-10-07 18:14       ` Daniel Vetter
2020-10-07 18:47       ` Jason Gunthorpe
2020-10-07 18:47         ` Jason Gunthorpe
2020-10-07 18:47         ` 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='CAKMK7uEETcQrPBC=4URQZtD73nA9MvQpBx-TOv95bdwzNOOA2g@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@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 10/13] PCI: revoke mappings like devmem' \
    /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 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.