From: Daniel Vetter <daniel@ffwll.ch> To: DRI Development <dri-devel@lists.freedesktop.org> Cc: "Intel Graphics Development" <intel-gfx@lists.freedesktop.org>, "Daniel Vetter" <daniel.vetter@ffwll.ch>, "Gerald Schaefer" <gerald.schaefer@linux.ibm.com>, "Daniel Vetter" <daniel.vetter@intel.com>, "Jason Gunthorpe" <jgg@ziepe.ca>, "Dan Williams" <dan.j.williams@intel.com>, "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>, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-media@vger.kernel.org, "Niklas Schnelle" <schnelle@linux.ibm.com>, linux-s390@vger.kernel.org Subject: Re: [PATCH 29/65] s390/pci: Remove races against pte updates Date: Fri, 23 Oct 2020 14:26:02 +0200 Message-ID: <20201023122602.GB401619@phenom.ffwll.local> (raw) In-Reply-To: <20201023122216.2373294-29-daniel.vetter@ffwll.ch> On Fri, Oct 23, 2020 at 02:21:40PM +0200, Daniel Vetter wrote: > Way back it was a reasonable assumptions that iomem mappings never > change the pfn range they point at. But this has changed: > > - gpu drivers dynamically manage their memory nowadays, invalidating > ptes with unmap_mapping_range when buffers get moved > > - contiguous dma allocations have moved from dedicated carvetouts to > cma regions. This means if we miss the unmap the pfn might contain > pagecache or anon memory (well anything allocated with GFP_MOVEABLE) > > - even /dev/mem now invalidates mappings when the kernel requests that > iomem region when CONFIG_IO_STRICT_DEVMEM is set, see commit > 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims the > region") > > Accessing pfns obtained from ptes without holding all the locks is > therefore no longer a good idea. Fix this. > > Since zpci_memcpy_from|toio seems to not do anything nefarious with > locks we just need to open code get_pfn and follow_pfn and make sure > we drop the locks only after we're done. The write function also needs > the copy_from_user move, since we can't take userspace faults while > holding the mmap sem. > > v2: Move VM_IO | VM_PFNMAP checks around so they keep returning EINVAL > like before (Gerard) > > v3: Polish commit message (Niklas) > > Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > Cc: Jason Gunthorpe <jgg@ziepe.ca> > Cc: Dan Williams <dan.j.williams@intel.com> > Cc: Kees Cook <keescook@chromium.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: 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: Niklas Schnelle <schnelle@linux.ibm.com> > Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com> > Cc: linux-s390@vger.kernel.org > Cc: Niklas Schnelle <schnelle@linux.ibm.com> > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Apologies for this random patch bomb, typoed git send-email command :-/ v4 of this will come properly on Monday or so. -Daniel > --- > arch/s390/pci/pci_mmio.c | 98 +++++++++++++++++++++++----------------- > 1 file changed, 57 insertions(+), 41 deletions(-) > > diff --git a/arch/s390/pci/pci_mmio.c b/arch/s390/pci/pci_mmio.c > index 401cf670a243..1a6adbc68ee8 100644 > --- a/arch/s390/pci/pci_mmio.c > +++ b/arch/s390/pci/pci_mmio.c > @@ -119,33 +119,15 @@ static inline int __memcpy_toio_inuser(void __iomem *dst, > return rc; > } > > -static long get_pfn(unsigned long user_addr, unsigned long access, > - unsigned long *pfn) > -{ > - struct vm_area_struct *vma; > - long ret; > - > - mmap_read_lock(current->mm); > - ret = -EINVAL; > - vma = find_vma(current->mm, user_addr); > - if (!vma) > - goto out; > - ret = -EACCES; > - if (!(vma->vm_flags & access)) > - goto out; > - ret = follow_pfn(vma, user_addr, pfn); > -out: > - mmap_read_unlock(current->mm); > - return ret; > -} > - > SYSCALL_DEFINE3(s390_pci_mmio_write, unsigned long, mmio_addr, > const void __user *, user_buffer, size_t, length) > { > u8 local_buf[64]; > void __iomem *io_addr; > void *buf; > - unsigned long pfn; > + struct vm_area_struct *vma; > + pte_t *ptep; > + spinlock_t *ptl; > long ret; > > if (!zpci_is_enabled()) > @@ -158,7 +140,7 @@ SYSCALL_DEFINE3(s390_pci_mmio_write, unsigned long, mmio_addr, > * We only support write access to MIO capable devices if we are on > * a MIO enabled system. Otherwise we would have to check for every > * address if it is a special ZPCI_ADDR and would have to do > - * a get_pfn() which we don't need for MIO capable devices. Currently > + * a pfn lookup which we don't need for MIO capable devices. Currently > * ISM devices are the only devices without MIO support and there is no > * known need for accessing these from userspace. > */ > @@ -176,21 +158,37 @@ SYSCALL_DEFINE3(s390_pci_mmio_write, unsigned long, mmio_addr, > } else > buf = local_buf; > > - ret = get_pfn(mmio_addr, VM_WRITE, &pfn); > + ret = -EFAULT; > + if (copy_from_user(buf, user_buffer, length)) > + goto out_free; > + > + mmap_read_lock(current->mm); > + ret = -EINVAL; > + vma = find_vma(current->mm, mmio_addr); > + if (!vma) > + goto out_unlock_mmap; > + if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) > + goto out_unlock_mmap; > + ret = -EACCES; > + if (!(vma->vm_flags & VM_WRITE)) > + goto out_unlock_mmap; > + > + ret = follow_pte_pmd(vma->vm_mm, mmio_addr, NULL, &ptep, NULL, &ptl); > if (ret) > - goto out; > - io_addr = (void __iomem *)((pfn << PAGE_SHIFT) | > + goto out_unlock_mmap; > + > + io_addr = (void __iomem *)((pte_pfn(*ptep) << PAGE_SHIFT) | > (mmio_addr & ~PAGE_MASK)); > > - ret = -EFAULT; > if ((unsigned long) io_addr < ZPCI_IOMAP_ADDR_BASE) > - goto out; > - > - if (copy_from_user(buf, user_buffer, length)) > - goto out; > + goto out_unlock_pt; > > ret = zpci_memcpy_toio(io_addr, buf, length); > -out: > +out_unlock_pt: > + pte_unmap_unlock(ptep, ptl); > +out_unlock_mmap: > + mmap_read_unlock(current->mm); > +out_free: > if (buf != local_buf) > kfree(buf); > return ret; > @@ -274,7 +272,9 @@ SYSCALL_DEFINE3(s390_pci_mmio_read, unsigned long, mmio_addr, > u8 local_buf[64]; > void __iomem *io_addr; > void *buf; > - unsigned long pfn; > + struct vm_area_struct *vma; > + pte_t *ptep; > + spinlock_t *ptl; > long ret; > > if (!zpci_is_enabled()) > @@ -287,7 +287,7 @@ SYSCALL_DEFINE3(s390_pci_mmio_read, unsigned long, mmio_addr, > * We only support read access to MIO capable devices if we are on > * a MIO enabled system. Otherwise we would have to check for every > * address if it is a special ZPCI_ADDR and would have to do > - * a get_pfn() which we don't need for MIO capable devices. Currently > + * a pfn lookup which we don't need for MIO capable devices. Currently > * ISM devices are the only devices without MIO support and there is no > * known need for accessing these from userspace. > */ > @@ -306,22 +306,38 @@ SYSCALL_DEFINE3(s390_pci_mmio_read, unsigned long, mmio_addr, > buf = local_buf; > } > > - ret = get_pfn(mmio_addr, VM_READ, &pfn); > + mmap_read_lock(current->mm); > + ret = -EINVAL; > + vma = find_vma(current->mm, mmio_addr); > + if (!vma) > + goto out_unlock_mmap; > + if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) > + goto out_unlock_mmap; > + ret = -EACCES; > + if (!(vma->vm_flags & VM_WRITE)) > + goto out_unlock_mmap; > + > + ret = follow_pte_pmd(vma->vm_mm, mmio_addr, NULL, &ptep, NULL, &ptl); > if (ret) > - goto out; > - io_addr = (void __iomem *)((pfn << PAGE_SHIFT) | (mmio_addr & ~PAGE_MASK)); > + goto out_unlock_mmap; > + > + io_addr = (void __iomem *)((pte_pfn(*ptep) << PAGE_SHIFT) | > + (mmio_addr & ~PAGE_MASK)); > > if ((unsigned long) io_addr < ZPCI_IOMAP_ADDR_BASE) { > ret = -EFAULT; > - goto out; > + goto out_unlock_pt; > } > ret = zpci_memcpy_fromio(buf, io_addr, length); > - if (ret) > - goto out; > - if (copy_to_user(user_buffer, buf, length)) > + > +out_unlock_pt: > + pte_unmap_unlock(ptep, ptl); > +out_unlock_mmap: > + mmap_read_unlock(current->mm); > + > + if (!ret && copy_to_user(user_buffer, buf, length)) > ret = -EFAULT; > > -out: > if (buf != local_buf) > kfree(buf); > return ret; > -- > 2.28.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
next prev parent reply index Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <20201021163242.1458885-1-daniel.vetter@ffwll.ch> [not found] ` <20201023122216.2373294-1-daniel.vetter@ffwll.ch> 2020-10-23 12:21 ` [PATCH 05/65] drm/atomic-helper: Add dma-fence annotations Daniel Vetter 2020-10-23 12:21 ` [PATCH 06/65] drm/vkms: Annotate vblank timer Daniel Vetter 2020-10-23 12:21 ` [PATCH 07/65] drm/vblank: Annotate with dma-fence signalling section Daniel Vetter 2020-10-23 12:21 ` [PATCH 08/65] drm/amdgpu: add dma-fence annotations to atomic commit path Daniel Vetter 2020-10-23 12:21 ` [PATCH 17/65] drm/scheduler: use dma-fence annotations in main thread Daniel Vetter 2020-10-23 12:21 ` [PATCH 18/65] drm/amdgpu: use dma-fence annotations in cs_submit() Daniel Vetter 2020-10-23 12:21 ` [PATCH 19/65] drm/amdgpu: s/GFP_KERNEL/GFP_ATOMIC in scheduler code Daniel Vetter 2020-10-23 12:21 ` [PATCH 20/65] drm/scheduler: use dma-fence annotations in tdr work Daniel Vetter 2020-10-23 12:21 ` [PATCH 21/65] drm/amdgpu: use dma-fence annotations for gpu reset code Daniel Vetter 2020-10-23 12:21 ` [PATCH 22/65] Revert "drm/amdgpu: add fbdev suspend/resume on gpu reset" Daniel Vetter 2020-10-23 12:21 ` [PATCH 23/65] drm/i915: Annotate dma_fence_work Daniel Vetter 2020-10-23 12:21 ` [PATCH 29/65] s390/pci: Remove races against pte updates Daniel Vetter 2020-10-23 12:26 ` Daniel Vetter [this message] 2020-10-23 12:21 ` [PATCH 30/65] drm/exynos: Stop using frame_vector helpers Daniel Vetter 2020-10-23 12:21 ` [PATCH 31/65] drm/exynos: Use FOLL_LONGTERM for g2d cmdlists Daniel Vetter 2020-10-23 12:21 ` [PATCH 32/65] misc/habana: Stop using frame_vector helpers Daniel Vetter 2020-10-23 12:21 ` [PATCH 33/65] misc/habana: Use FOLL_LONGTERM for userptr Daniel Vetter 2020-10-23 12:21 ` [PATCH 34/65] mm/frame-vector: Use FOLL_LONGTERM Daniel Vetter 2020-10-23 12:21 ` [PATCH 35/65] media: videobuf2: Move frame_vector into media subsystem Daniel Vetter 2020-10-23 12:21 ` [PATCH 36/65] mm: Close race in generic_access_phys Daniel Vetter 2020-10-23 12:21 ` [PATCH 37/65] mm: Add unsafe_follow_pfn Daniel Vetter 2020-10-23 12:21 ` [PATCH 38/65] media/videbuf1|2: Mark follow_pfn usage as unsafe Daniel Vetter 2020-10-23 12:21 ` [PATCH 39/65] vfio/type1: Mark follow_pfn " Daniel Vetter 2020-10-23 12:21 ` [PATCH 40/65] PCI: Obey iomem restrictions for procfs mmap Daniel Vetter 2020-10-23 12:21 ` [PATCH 41/65] /dev/mem: Only set filp->f_mapping Daniel Vetter 2020-10-23 12:21 ` [PATCH 42/65] resource: Move devmem revoke code to resource framework Daniel Vetter 2020-10-23 12:21 ` [PATCH 43/65] sysfs: Support zapping of binary attr mmaps Daniel Vetter 2020-10-23 12:21 ` [PATCH 44/65] PCI: Revoke mappings like devmem Daniel Vetter
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=20201023122602.GB401619@phenom.ffwll.local \ --to=daniel@ffwll.ch \ --cc=akpm@linux-foundation.org \ --cc=dan.j.williams@intel.com \ --cc=daniel.vetter@ffwll.ch \ --cc=daniel.vetter@intel.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=gerald.schaefer@linux.ibm.com \ --cc=intel-gfx@lists.freedesktop.org \ --cc=jack@suse.cz \ --cc=jgg@ziepe.ca \ --cc=jglisse@redhat.com \ --cc=jhubbard@nvidia.com \ --cc=keescook@chromium.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-media@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-s390@vger.kernel.org \ --cc=linux-samsung-soc@vger.kernel.org \ --cc=schnelle@linux.ibm.com \ /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
Linux-Media Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-media/0 linux-media/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-media linux-media/ https://lore.kernel.org/linux-media \ linux-media@vger.kernel.org public-inbox-index linux-media Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-media AGPL code for this site: git clone https://public-inbox.org/public-inbox.git