| Message ID | 20201026105818.2585306-1-daniel.vetter@ffwll.ch |
|---|---|
| Headers | show |
| Series | follow_pfn and other iomap races | expand |
Hi Daniel, On Mon, Oct 26, 2020 at 11:58:12AM +0100, Daniel Vetter wrote: > The media model assumes that buffers are all preallocated, so that > when a media pipeline is running we never miss a deadline because the > buffers aren't allocated or available. > > This means we cannot fix the v4l follow_pfn usage through > mmu_notifier, without breaking how this all works. The only real fix > is to deprecate userptr support for VM_IO | VM_PFNMAP mappings and > tell everyone to cut over to dma-buf memory sharing for zerocopy. > > userptr for normal memory will keep working as-is, this only affects > the zerocopy userptr usage enabled in 50ac952d2263 ("[media] > videobuf2-dma-sg: Support io userptr operations on io memory"). Note that this is true only for the videobuf2 change. The videobuf1 code was like this all the time and does not support normal memory in the dma_contig variant (because normal memory is rarely physically contiguous). If my understanding is correct that the CONFIG_STRICT_FOLLOW_PFN is not enabled by default, we stay backwards compatible, with only whoever decides to turn it on risking a breakage. I agree that this is a good first step towards deprecating this legacy code, so: Acked-by: Tomasz Figa <tfiga@chromium.org> Of course the last word goes to Mauro. :) Best regards, Tomasz > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > Cc: Jason Gunthorpe <jgg@ziepe.ca> > Cc: Kees Cook <keescook@chromium.org> > Cc: Dan Williams <dan.j.williams@intel.com> > Cc: Andrew Morton <akpm@linux-foundation.org> > Cc: John Hubbard <jhubbard@nvidia.com> > Cc: Jérôme Glisse <jglisse@redhat.com> > Cc: Jan Kara <jack@suse.cz> > Cc: Dan Williams <dan.j.williams@intel.com> > Cc: linux-mm@kvack.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-samsung-soc@vger.kernel.org > Cc: linux-media@vger.kernel.org > Cc: Pawel Osciak <pawel@osciak.com> > Cc: Marek Szyprowski <m.szyprowski@samsung.com> > Cc: Kyungmin Park <kyungmin.park@samsung.com> > Cc: Tomasz Figa <tfiga@chromium.org> > Cc: Laurent Dufour <ldufour@linux.ibm.com> > Cc: Vlastimil Babka <vbabka@suse.cz> > Cc: Daniel Jordan <daniel.m.jordan@oracle.com> > Cc: Michel Lespinasse <walken@google.com> > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> > -- > v3: > - Reference the commit that enabled the zerocopy userptr use case to > make it abundandtly clear that this patch only affects that, and not > normal memory userptr. The old commit message already explained that > normal memory userptr is unaffected, but I guess that was not clear > enough. > --- > drivers/media/common/videobuf2/frame_vector.c | 2 +- > drivers/media/v4l2-core/videobuf-dma-contig.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/common/videobuf2/frame_vector.c b/drivers/media/common/videobuf2/frame_vector.c > index 6590987c14bd..e630494da65c 100644 > --- a/drivers/media/common/videobuf2/frame_vector.c > +++ b/drivers/media/common/videobuf2/frame_vector.c > @@ -69,7 +69,7 @@ int get_vaddr_frames(unsigned long start, unsigned int nr_frames, > break; > > while (ret < nr_frames && start + PAGE_SIZE <= vma->vm_end) { > - err = follow_pfn(vma, start, &nums[ret]); > + err = unsafe_follow_pfn(vma, start, &nums[ret]); > if (err) { > if (ret == 0) > ret = err; > diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c b/drivers/media/v4l2-core/videobuf-dma-contig.c > index 52312ce2ba05..821c4a76ab96 100644 > --- a/drivers/media/v4l2-core/videobuf-dma-contig.c > +++ b/drivers/media/v4l2-core/videobuf-dma-contig.c > @@ -183,7 +183,7 @@ static int videobuf_dma_contig_user_get(struct videobuf_dma_contig_memory *mem, > user_address = untagged_baddr; > > while (pages_done < (mem->size >> PAGE_SHIFT)) { > - ret = follow_pfn(vma, user_address, &this_pfn); > + ret = unsafe_follow_pfn(vma, user_address, &this_pfn); > if (ret) > break; > > -- > 2.28.0 >
Hi Daniel, On Mon, Oct 26, 2020 at 11:58:08AM +0100, Daniel Vetter wrote: > This is used by media/videbuf2 for persistent dma mappings, not just > for a single dma operation and then freed again, so needs > FOLL_LONGTERM. > > Unfortunately current pup_locked doesn't support FOLL_LONGTERM due to > locking issues. Rework the code to pull the pup path out from the > mmap_sem critical section as suggested by Jason. > > By relying entirely on the vma checks in pin_user_pages and follow_pfn > (for vm_flags and vma_is_fsdax) we can also streamline the code a lot. > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > Cc: Jason Gunthorpe <jgg@ziepe.ca> > Cc: Pawel Osciak <pawel@osciak.com> > Cc: Marek Szyprowski <m.szyprowski@samsung.com> > Cc: Kyungmin Park <kyungmin.park@samsung.com> > Cc: Tomasz Figa <tfiga@chromium.org> > Cc: Mauro Carvalho Chehab <mchehab@kernel.org> > Cc: Andrew Morton <akpm@linux-foundation.org> > Cc: John Hubbard <jhubbard@nvidia.com> > Cc: Jérôme Glisse <jglisse@redhat.com> > Cc: Jan Kara <jack@suse.cz> > Cc: Dan Williams <dan.j.williams@intel.com> > Cc: linux-mm@kvack.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-samsung-soc@vger.kernel.org > Cc: linux-media@vger.kernel.org > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> > -- > v2: Streamline the code and further simplify the loop checks (Jason) > --- > mm/frame_vector.c | 50 ++++++++++++++--------------------------------- > 1 file changed, 15 insertions(+), 35 deletions(-) > Thank you for the patch. Please see my comments inline. > diff --git a/mm/frame_vector.c b/mm/frame_vector.c > index 10f82d5643b6..d44779e56313 100644 > --- a/mm/frame_vector.c > +++ b/mm/frame_vector.c > @@ -38,7 +38,6 @@ int get_vaddr_frames(unsigned long start, unsigned int nr_frames, > struct vm_area_struct *vma; > int ret = 0; > int err; > - int locked; > > if (nr_frames == 0) > return 0; > @@ -48,40 +47,25 @@ int get_vaddr_frames(unsigned long start, unsigned int nr_frames, > > start = untagged_addr(start); > > - mmap_read_lock(mm); > - locked = 1; > - vma = find_vma_intersection(mm, start, start + 1); > - if (!vma) { > - ret = -EFAULT; > - goto out; > - } > - > - /* > - * While get_vaddr_frames() could be used for transient (kernel > - * controlled lifetime) pinning of memory pages all current > - * users establish long term (userspace controlled lifetime) > - * page pinning. Treat get_vaddr_frames() like > - * get_user_pages_longterm() and disallow it for filesystem-dax > - * mappings. > - */ > - if (vma_is_fsdax(vma)) { > - ret = -EOPNOTSUPP; > - goto out; > - } > - > - if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) { > + ret = pin_user_pages_fast(start, nr_frames, > + FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM, > + (struct page **)(vec->ptrs)); > + if (ret > 0) { > vec->got_ref = true; > vec->is_pfns = false; > - ret = pin_user_pages_locked(start, nr_frames, > - gup_flags, (struct page **)(vec->ptrs), &locked); Should we drop the gup_flags argument, since it's ignored now? > - goto out; > + goto out_unlocked; > } > Should we initialize ret with 0 here, since pin_user_pages_fast() can return a negative error code, but below we use it as a counter for the looked up frames? Best regards, Tomasz > + mmap_read_lock(mm); > vec->got_ref = false; > vec->is_pfns = true; > do { > unsigned long *nums = frame_vector_pfns(vec); > > + vma = find_vma_intersection(mm, start, start + 1); > + if (!vma) > + break; > + > while (ret < nr_frames && start + PAGE_SIZE <= vma->vm_end) { > err = follow_pfn(vma, start, &nums[ret]); > if (err) { > @@ -92,17 +76,13 @@ int get_vaddr_frames(unsigned long start, unsigned int nr_frames, > start += PAGE_SIZE; > ret++; > } > - /* > - * We stop if we have enough pages or if VMA doesn't completely > - * cover the tail page. > - */ > - if (ret >= nr_frames || start < vma->vm_end) > + /* Bail out if VMA doesn't completely cover the tail page. */ > + if (start < vma->vm_end) > break; > - vma = find_vma_intersection(mm, start, start + 1); > - } while (vma && vma->vm_flags & (VM_IO | VM_PFNMAP)); > + } while (ret < nr_frames); > out: > - if (locked) > - mmap_read_unlock(mm); > + mmap_read_unlock(mm); > +out_unlocked: > if (!ret) > ret = -EFAULT; > if (ret > 0) > -- > 2.28.0 >
On Mon, Oct 26, 2020 at 11:15 PM Tomasz Figa <tfiga@chromium.org> wrote: > > Hi Daniel, > > On Mon, Oct 26, 2020 at 11:58:08AM +0100, Daniel Vetter wrote: > > This is used by media/videbuf2 for persistent dma mappings, not just > > for a single dma operation and then freed again, so needs > > FOLL_LONGTERM. > > > > Unfortunately current pup_locked doesn't support FOLL_LONGTERM due to > > locking issues. Rework the code to pull the pup path out from the > > mmap_sem critical section as suggested by Jason. > > > > By relying entirely on the vma checks in pin_user_pages and follow_pfn > > (for vm_flags and vma_is_fsdax) we can also streamline the code a lot. > > > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > > Cc: Jason Gunthorpe <jgg@ziepe.ca> > > Cc: Pawel Osciak <pawel@osciak.com> > > Cc: Marek Szyprowski <m.szyprowski@samsung.com> > > Cc: Kyungmin Park <kyungmin.park@samsung.com> > > Cc: Tomasz Figa <tfiga@chromium.org> > > Cc: Mauro Carvalho Chehab <mchehab@kernel.org> > > Cc: Andrew Morton <akpm@linux-foundation.org> > > Cc: John Hubbard <jhubbard@nvidia.com> > > Cc: Jérôme Glisse <jglisse@redhat.com> > > Cc: Jan Kara <jack@suse.cz> > > Cc: Dan Williams <dan.j.williams@intel.com> > > Cc: linux-mm@kvack.org > > Cc: linux-arm-kernel@lists.infradead.org > > Cc: linux-samsung-soc@vger.kernel.org > > Cc: linux-media@vger.kernel.org > > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> > > -- > > v2: Streamline the code and further simplify the loop checks (Jason) > > --- > > mm/frame_vector.c | 50 ++++++++++++++--------------------------------- > > 1 file changed, 15 insertions(+), 35 deletions(-) > > > > Thank you for the patch. Please see my comments inline. > > > diff --git a/mm/frame_vector.c b/mm/frame_vector.c > > index 10f82d5643b6..d44779e56313 100644 > > --- a/mm/frame_vector.c > > +++ b/mm/frame_vector.c > > @@ -38,7 +38,6 @@ int get_vaddr_frames(unsigned long start, unsigned int nr_frames, > > struct vm_area_struct *vma; > > int ret = 0; > > int err; > > - int locked; > > > > if (nr_frames == 0) > > return 0; > > @@ -48,40 +47,25 @@ int get_vaddr_frames(unsigned long start, unsigned int nr_frames, > > > > start = untagged_addr(start); > > > > - mmap_read_lock(mm); > > - locked = 1; > > - vma = find_vma_intersection(mm, start, start + 1); > > - if (!vma) { > > - ret = -EFAULT; > > - goto out; > > - } > > - > > - /* > > - * While get_vaddr_frames() could be used for transient (kernel > > - * controlled lifetime) pinning of memory pages all current > > - * users establish long term (userspace controlled lifetime) > > - * page pinning. Treat get_vaddr_frames() like > > - * get_user_pages_longterm() and disallow it for filesystem-dax > > - * mappings. > > - */ > > - if (vma_is_fsdax(vma)) { > > - ret = -EOPNOTSUPP; > > - goto out; > > - } > > - > > - if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) { > > + ret = pin_user_pages_fast(start, nr_frames, > > + FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM, > > + (struct page **)(vec->ptrs)); > > + if (ret > 0) { > > vec->got_ref = true; > > vec->is_pfns = false; > > - ret = pin_user_pages_locked(start, nr_frames, > > - gup_flags, (struct page **)(vec->ptrs), &locked); > > Should we drop the gup_flags argument, since it's ignored now? Hm right I think an earlier version even had that, but then I moved to inlining the functionality in all the places it's used. I'll drop the gup flag. > > - goto out; > > + goto out_unlocked; > > } > > > > Should we initialize ret with 0 here, since pin_user_pages_fast() can > return a negative error code, but below we use it as a counter for the > looked up frames? Indeed, that's a bug. Will fix for v5. -Daniel > Best regards, > Tomasz > > > + mmap_read_lock(mm); > > vec->got_ref = false; > > vec->is_pfns = true; > > do { > > unsigned long *nums = frame_vector_pfns(vec); > > > > + vma = find_vma_intersection(mm, start, start + 1); > > + if (!vma) > > + break; > > + > > while (ret < nr_frames && start + PAGE_SIZE <= vma->vm_end) { > > err = follow_pfn(vma, start, &nums[ret]); > > if (err) { > > @@ -92,17 +76,13 @@ int get_vaddr_frames(unsigned long start, unsigned int nr_frames, > > start += PAGE_SIZE; > > ret++; > > } > > - /* > > - * We stop if we have enough pages or if VMA doesn't completely > > - * cover the tail page. > > - */ > > - if (ret >= nr_frames || start < vma->vm_end) > > + /* Bail out if VMA doesn't completely cover the tail page. */ > > + if (start < vma->vm_end) > > break; > > - vma = find_vma_intersection(mm, start, start + 1); > > - } while (vma && vma->vm_flags & (VM_IO | VM_PFNMAP)); > > + } while (ret < nr_frames); > > out: > > - if (locked) > > - mmap_read_unlock(mm); > > + mmap_read_unlock(mm); > > +out_unlocked: > > if (!ret) > > ret = -EFAULT; > > if (ret > 0) > > -- > > 2.28.0 > >
Maybe I'm missing something, but shouldn't follow_pfn be unexported at the end of the series?
On Thu, Oct 29, 2020 at 9:57 AM Christoph Hellwig <hch@infradead.org> wrote: > > Maybe I'm missing something, but shouldn't follow_pfn be unexported > at the end of the series? kvm is a legit user and modular afaict. But since you can't use this without an mmu_notifier anyway (or digging around in pagetable locking), maybe it should be EXPORT_SYMBOL_GPL now at least? -Daniel
On Thu, Oct 29, 2020 at 10:25:16AM +0100, Daniel Vetter wrote: > On Thu, Oct 29, 2020 at 9:57 AM Christoph Hellwig <hch@infradead.org> wrote: > > > > Maybe I'm missing something, but shouldn't follow_pfn be unexported > > at the end of the series? > > kvm is a legit user and modular afaict. But since you can't use this > without an mmu_notifier anyway (or digging around in pagetable > locking), maybe it should be EXPORT_SYMBOL_GPL now at least? I think it should then take the notifier as an argument even if it isn't diretly used as a safety check, and get a new name describing it. EXPORT_SYMBOL_GPL is probably ok for now, but I'm drafting a new EXPORT_SYMBOL_FOR_MODULE() which will export symbols that can only be used by one specific module, with kvm being a prime user due to all the odd exports it requires that aren't really the kernel interface by any normal means.
On Thu, Oct 29, 2020 at 10:28 AM Christoph Hellwig <hch@infradead.org> wrote: > > On Thu, Oct 29, 2020 at 10:25:16AM +0100, Daniel Vetter wrote: > > On Thu, Oct 29, 2020 at 9:57 AM Christoph Hellwig <hch@infradead.org> wrote: > > > > > > Maybe I'm missing something, but shouldn't follow_pfn be unexported > > > at the end of the series? > > > > kvm is a legit user and modular afaict. But since you can't use this > > without an mmu_notifier anyway (or digging around in pagetable > > locking), maybe it should be EXPORT_SYMBOL_GPL now at least? > > I think it should then take the notifier as an argument even if it isn't > diretly used as a safety check, and get a new name describing it. Hm so Jason and me discussed this, but e.g. the s390 is safe with with just the pagetable locks. So we'd need two versions. The more practical problem is that I haven't found a reasonable way to check that a passed in mmu_notifier is registered against the mm we're working on, and without that check it feels a bit silly. But if you see how to do that I think we can do an EXPORT_SYMBOL_GPL follow_pfn which takes the notifier, and an __follow_pfn for s390 and similar internal code which isn't exported. > EXPORT_SYMBOL_GPL is probably ok for now, but I'm drafting a new > EXPORT_SYMBOL_FOR_MODULE() which will export symbols that can only be > used by one specific module, with kvm being a prime user due to all > the odd exports it requires that aren't really the kernel interface by > any normal means. Hm yeah that's another one. There's also some virt stuff that's currently on unsafe_follow_pfn and needs to be switched over, and I think that would also need an mmu notifier of some sorts to close the gaps. -Daniel
On Thu, Oct 29, 2020 at 10:38:16AM +0100, Daniel Vetter wrote: > Hm so Jason and me discussed this, but e.g. the s390 is safe with with > just the pagetable locks. So we'd need two versions. > > The more practical problem is that I haven't found a reasonable way to > check that a passed in mmu_notifier is registered against the mm we're > working on, and without that check it feels a bit silly. But if you > see how to do that I think we can do an EXPORT_SYMBOL_GPL follow_pfn > which takes the notifier, and an __follow_pfn for s390 and similar > internal code which isn't exported. True, this is a bit of a mess. So maybe just rename it to __follow_pfn, proper documentation of the requirements and a switch to EXPORT_SYMBOL_GPL.
Hi all Round 3 of my patch series to clamp down a bunch of races and gaps around follow_pfn and other access to iomem mmaps. Previous version: v1: https://lore.kernel.org/dri-devel/20201007164426.1812530-1-daniel.vetter@ffwll.ch/ v2: https://lore.kernel.org/dri-devel/20201009075934.3509076-1-daniel.vetter@ffwll.ch v3: https://lore.kernel.org/dri-devel/20201021085655.1192025-1-daniel.vetter@ffwll.ch/ And the discussion that sparked this journey: https://lore.kernel.org/dri-devel/20201007164426.1812530-1-daniel.vetter@ffwll.ch/ Changes in v4: - Drop the s390 patch, that was very stand-alone and now queued up to land through s390 trees. - Comment polish per Dan's review. Changes in v3: - Bunch of polish all over, no functional changes aside from one barrier in the resource code, for consistency. - A few more r-b tags. Changes in v2: - tons of small polish&fixes all over, thanks to all the reviewers who spotted issues - I managed to test at least the generic_access_phys and pci mmap revoke stuff with a few gdb sessions using our i915 debug tools (hence now also the drm/i915 patch to properly request all the pci bar regions) - reworked approach for the pci mmap revoke: Infrastructure moved into kernel/resource.c, address_space mapping is now set up at open time for everyone (which required some sysfs changes). Does indeed look a lot cleaner and a lot less invasive than I feared at first. I feel like this is ready for some wider soaking. Since the remaining bits are all kinda connnected probably simplest if it all goes through -mm. Cheers, Daniel Daniel Vetter (15): drm/exynos: Stop using frame_vector helpers drm/exynos: Use FOLL_LONGTERM for g2d cmdlists misc/habana: Stop using frame_vector helpers misc/habana: Use FOLL_LONGTERM for userptr mm/frame-vector: Use FOLL_LONGTERM media: videobuf2: Move frame_vector into media subsystem mm: Close race in generic_access_phys mm: Add unsafe_follow_pfn media/videbuf1|2: Mark follow_pfn usage as unsafe vfio/type1: Mark follow_pfn as unsafe PCI: Obey iomem restrictions for procfs mmap /dev/mem: Only set filp->f_mapping resource: Move devmem revoke code to resource framework sysfs: Support zapping of binary attr mmaps PCI: Revoke mappings like devmem drivers/char/mem.c | 86 +-------------- drivers/gpu/drm/exynos/Kconfig | 1 - drivers/gpu/drm/exynos/exynos_drm_g2d.c | 48 ++++----- drivers/media/common/videobuf2/Kconfig | 1 - drivers/media/common/videobuf2/Makefile | 1 + .../media/common/videobuf2}/frame_vector.c | 54 ++++------ drivers/media/platform/omap/Kconfig | 1 - drivers/media/v4l2-core/videobuf-dma-contig.c | 2 +- drivers/misc/habanalabs/Kconfig | 1 - drivers/misc/habanalabs/common/habanalabs.h | 6 +- drivers/misc/habanalabs/common/memory.c | 50 ++++----- drivers/pci/pci-sysfs.c | 4 + drivers/pci/proc.c | 6 ++ drivers/vfio/vfio_iommu_type1.c | 4 +- fs/sysfs/file.c | 11 ++ include/linux/ioport.h | 6 +- include/linux/mm.h | 47 +------- include/linux/sysfs.h | 2 + include/media/frame_vector.h | 47 ++++++++ include/media/videobuf2-core.h | 1 + kernel/resource.c | 101 +++++++++++++++++- mm/Kconfig | 3 - mm/Makefile | 1 - mm/memory.c | 78 +++++++++++++- mm/nommu.c | 17 +++ security/Kconfig | 13 +++ 26 files changed, 347 insertions(+), 245 deletions(-) rename {mm => drivers/media/common/videobuf2}/frame_vector.c (85%) create mode 100644 include/media/frame_vector.h