Cc all the mailing lists ... my usual script crashed and I had to
hand-roll the email and screwed it up ofc :-/
-Daniel
On Mon, Feb 22, 2021 at 11:23 AM Daniel Vetter <[email protected]> wrote:
>
> Hi Linus,
>
> Another small pull from you to ponder.
>
> This is the first part of a patch series I've been working on for a while:
>
> https://lore.kernel.org/dri-devel/[email protected]/
>
> I've stumbled over this for my own learning and then realized there's a
> bunch of races around VM_PFNMAP mappings vs follow pfn.
>
> If you're happy with this then I'll follow up with the media patches to
> mark their leftover use of follow_pfn as unsafe (it's uapi, so unfixable
> issue, all we can do is a config option to harden the kernel). Plus
> hopefully kvm and vfio are then fixed too (you've been on the recent kvm
> thread where this popped up again) so that we can sunset follow_pfn usage
> completely.
>
> The last two patches have only been in linux-next in their current form
> for a week, there was some issue for platforms with HAVE_PCI_LEGACY (not
> that many) which took some sorting out. But looks all good now.
>
> Cheers, Daniel
>
> The following changes since commit 7c53f6b671f4aba70ff15e1b05148b10d58c2837:
>
> Linux 5.11-rc3 (2021-01-10 14:34:50 -0800)
>
> are available in the Git repository at:
>
> git://anongit.freedesktop.org/drm/drm tags/topic/iomem-mmap-vs-gup-2021-02-22
>
> for you to fetch changes up to 636b21b50152d4e203223ee337aca1cb3c1bfe53:
>
> PCI: Revoke mappings like devmem (2021-02-11 15:59:19 +0100)
>
> ----------------------------------------------------------------
> Fixes around VM_FPNMAP and follow_pfn
>
> - replace mm/frame_vector.c by get_user_pages in misc/habana and
> drm/exynos drivers, then move that into media as it's sole user
> - close race in generic_access_phys
> - s390 pci ioctl fix of this series landed in 5.11 already
> - properly revoke iomem mappings (/dev/mem, pci files)
>
> ----------------------------------------------------------------
> Daniel Vetter (13):
> 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
> 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: Also set up legacy files only after sysfs init
> 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 +
> {mm => drivers/media/common/videobuf2}/frame_vector.c | 55 +++++++++++++++---------------------------
> drivers/media/common/videobuf2/videobuf2-memops.c | 3 +--
> drivers/media/platform/omap/Kconfig | 1 -
> drivers/misc/habanalabs/Kconfig | 1 -
> drivers/misc/habanalabs/common/habanalabs.h | 6 +++--
> drivers/misc/habanalabs/common/memory.c | 52 +++++++++++++++-------------------------
> drivers/pci/pci-sysfs.c | 11 +++++++++
> drivers/pci/proc.c | 6 +++++
> fs/sysfs/file.c | 11 +++++++++
> include/linux/ioport.h | 6 +----
> include/linux/mm.h | 45 ++--------------------------------
> include/linux/sysfs.h | 2 ++
> include/media/frame_vector.h | 47 ++++++++++++++++++++++++++++++++++++
> include/media/videobuf2-core.h | 1 +
> kernel/resource.c | 98 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
> mm/Kconfig | 3 ---
> mm/Makefile | 1 -
> mm/memory.c | 46 ++++++++++++++++++++++++++++++++---
> 23 files changed, 287 insertions(+), 245 deletions(-)
> rename {mm => drivers/media/common/videobuf2}/frame_vector.c (85%)
> create mode 100644 include/media/frame_vector.h
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Feb 22, 2021 at 2:25 AM Daniel Vetter <[email protected]> wrote:
>
> Cc all the mailing lists ... my usual script crashed and I had to
> hand-roll the email and screwed it up ofc :-/
Oh, and you also didn't get a pr-tracker-bot response for this for the
same reason.
Even your fixed email was ignored by the bot (I think because of the
"Re:" in the subject line).
So consider this your manual pr-tracker-bot replacement.
Linus
On Mon, Feb 22, 2021 at 2:25 AM Daniel Vetter <[email protected]> wrote:
>
> Cc all the mailing lists ... my usual script crashed and I had to
> hand-roll the email and screwed it up ofc :-/
Oh, and my reply thus also became just a reply to you personally.
So repeating it here, in case somebody has comments about that
access_process_vm() issue.
On Mon, Feb 22, 2021 at 2:23 AM Daniel Vetter <[email protected]> wrote:
>
> I've stumbled over this for my own learning and then realized there's a
> bunch of races around VM_PFNMAP mappings vs follow pfn.
>
> If you're happy with this [..]
Happy? No. But it seems an improvement.
I did react to some of this: commit 0fb1b1ed7dd9 ("/dev/mem: Only set
filp->f_mapping") talks about _what_ it does, but not so much _why_ it
does it. It doesn't seem to actually matter, and seems almost
incidental (because you've looked at f_mapping and i_mapping just
didn't matter but was adjacent.
And generic_access_phys() remains horrific. Does anything actually use
this outside of the odd magical access_remote_vm() code?
I'm wondering if that code shouldn't just be removed entirely. It's
quite old, I'm not sure it's really relevant. See commit 28b2ee20c7cb
("access_process_vm device memory infrastructure").
I guess you do debug the X server, but still.. Do you actually ever
look at device memory through the debugger? I'd hope that you'd use an
access function and make gdb call it in the context of the debuggee?
Whatever. I've pulled it, and I'm not _unhappy_ with it, but I'd also
not call myself overly giddy and over the moon happy about this code.
Linus
On Tue, Feb 23, 2021 at 2:42 AM Linus Torvalds
<[email protected]> wrote:
>
> On Mon, Feb 22, 2021 at 2:25 AM Daniel Vetter <[email protected]> wrote:
> >
> > Cc all the mailing lists ... my usual script crashed and I had to
> > hand-roll the email and screwed it up ofc :-/
>
> Oh, and my reply thus also became just a reply to you personally.
>
> So repeating it here, in case somebody has comments about that
> access_process_vm() issue.
>
> On Mon, Feb 22, 2021 at 2:23 AM Daniel Vetter <[email protected]> wrote:
> >
> > I've stumbled over this for my own learning and then realized there's a
> > bunch of races around VM_PFNMAP mappings vs follow pfn.
> >
> > If you're happy with this [..]
>
> Happy? No. But it seems an improvement.
>
> I did react to some of this: commit 0fb1b1ed7dd9 ("/dev/mem: Only set
> filp->f_mapping") talks about _what_ it does, but not so much _why_ it
> does it. It doesn't seem to actually matter, and seems almost
> incidental (because you've looked at f_mapping and i_mapping just
> didn't matter but was adjacent.
Yeah it doesn't matter, it just confused me, so I wrote a patch to
remove it and get experts to tell me it actually really doesn't
matter. So that's really the entirety of that one. Like I said, I
mostly stumbled into this rat hole because I had some questions,
wanted to understand stuff better, and the code did not provide
consistent answers :-)
> And generic_access_phys() remains horrific. Does anything actually use
> this outside of the odd magical access_remote_vm() code?
>
> I'm wondering if that code shouldn't just be removed entirely. It's
> quite old, I'm not sure it's really relevant. See commit 28b2ee20c7cb
> ("access_process_vm device memory infrastructure").
>
> I guess you do debug the X server, but still.. Do you actually ever
> look at device memory through the debugger? I'd hope that you'd use an
> access function and make gdb call it in the context of the debuggee?
tbh I had no idea this exists, but yeah I've fired up gdb on some of
the register dumper tools we have that use the pci mmap files, and
after fixing some thinko in the first version it was still working
after the conversion.
From a quick git grep almost nothing wires this up, so yeah no idea
whether it's still used. Definitely not useful for X hackery anymore.
It is wired up for uio framework, and I guess for debugging userspace
drivers this comes handy. Although letting your debugger do
reads/writes to device registers sounds scary.
-Daniel
> Whatever. I've pulled it, and I'm not _unhappy_ with it, but I'd also
> not call myself overly giddy and over the moon happy about this code.
>
> Linus
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch