From: Daniel Vetter <daniel.vetter@ffwll.ch> To: Niklas Schnelle <schnelle@linux.ibm.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>, "open list:DMA BUFFER SHARING FRAMEWORK" <linux-media@vger.kernel.org>, linux-s390 <linux-s390@vger.kernel.org>, "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>, "Heiko Carstens" <hca@linux.ibm.com>, "Vasily Gorbik" <gor@linux.ibm.com> Subject: Re: [PATCH v3 08/16] s390/pci: Remove races against pte updates Date: Wed, 21 Oct 2020 15:56:23 +0200 [thread overview] Message-ID: <CAKMK7uEBv9y1mLAyo8ypV=bW=TMNky-QvhCTxcMe4O65WtmMZQ@mail.gmail.com> (raw) In-Reply-To: <07557af4-32b5-7610-292c-9fd3bbfe9229@linux.ibm.com> On Wed, Oct 21, 2020 at 11:38 AM Niklas Schnelle <schnelle@linux.ibm.com> wrote: > > > > On 10/21/20 10:56 AM, 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.com> > ^^^^ > This should be ".ch", but since this is clearly a typo and you also send from @ffwll.ch, > I took the liberty and fixed it for this commit and applied your patch to our internal > branch, Heiko or Vasily will then pick it up for the s390 tree. Uh yes, and I've copypasted this to all patches :-/ Thanks for picking this up, I'll drop it here from my series. Cheers, Daniel > > Thanks! > > > --- > > 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; > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
next prev parent reply other threads:[~2020-10-21 13:56 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 [this message] 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 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='CAKMK7uEBv9y1mLAyo8ypV=bW=TMNky-QvhCTxcMe4O65WtmMZQ@mail.gmail.com' \ --to=daniel.vetter@ffwll.ch \ --cc=akpm@linux-foundation.org \ --cc=dan.j.williams@intel.com \ --cc=daniel.vetter@intel.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=gerald.schaefer@linux.ibm.com \ --cc=gor@linux.ibm.com \ --cc=hca@linux.ibm.com \ --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-s390@vger.kernel.org \ --cc=linux-samsung-soc@vger.kernel.org \ --cc=schnelle@linux.ibm.com \ --subject='Re: [PATCH v3 08/16] s390/pci: Remove races against pte updates' \ /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).