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 daniel@ffwll.ch 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/20201127164131.2244124-1-daniel.vetter@ffw...
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
On Mon, Feb 22, 2021 at 2:25 AM Daniel Vetter daniel@ffwll.ch 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 daniel@ffwll.ch 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 torvalds@linux-foundation.org wrote:
On Mon, Feb 22, 2021 at 2:25 AM Daniel Vetter daniel@ffwll.ch 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 daniel@ffwll.ch 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
On Mon, Feb 22, 2021 at 2:25 AM Daniel Vetter daniel@ffwll.ch 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
dri-devel@lists.freedesktop.org
-
Daniel Vetter -
Linus Torvalds