* Re: [PULL] fixes around VM_PFNMAP and follow_pfn for 5.12 merge window [not found] <YDOGERvNuU3+2WWe@phenom.ffwll.local> @ 2021-02-22 10:24 ` Daniel Vetter 2021-02-23 1:42 ` Linus Torvalds 2021-02-23 1:56 ` Linus Torvalds 0 siblings, 2 replies; 4+ messages in thread From: Daniel Vetter @ 2021-02-22 10:24 UTC (permalink / raw) To: Linus Torvalds Cc: Linux Kernel Mailing List, dri-devel, Linux MM, open list:DMA BUFFER SHARING FRAMEWORK, Linux PCI 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@ffwll.ch/ > > 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PULL] fixes around VM_PFNMAP and follow_pfn for 5.12 merge window 2021-02-22 10:24 ` [PULL] fixes around VM_PFNMAP and follow_pfn for 5.12 merge window Daniel Vetter @ 2021-02-23 1:42 ` Linus Torvalds 2021-02-23 7:22 ` Daniel Vetter 2021-02-23 1:56 ` Linus Torvalds 1 sibling, 1 reply; 4+ messages in thread From: Linus Torvalds @ 2021-02-23 1:42 UTC (permalink / raw) To: Daniel Vetter Cc: Linux Kernel Mailing List, dri-devel, Linux MM, open list:DMA BUFFER SHARING FRAMEWORK, Linux PCI 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PULL] fixes around VM_PFNMAP and follow_pfn for 5.12 merge window 2021-02-23 1:42 ` Linus Torvalds @ 2021-02-23 7:22 ` Daniel Vetter 0 siblings, 0 replies; 4+ messages in thread From: Daniel Vetter @ 2021-02-23 7:22 UTC (permalink / raw) To: Linus Torvalds Cc: Linux Kernel Mailing List, dri-devel, Linux MM, open list:DMA BUFFER SHARING FRAMEWORK, Linux PCI 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 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PULL] fixes around VM_PFNMAP and follow_pfn for 5.12 merge window 2021-02-22 10:24 ` [PULL] fixes around VM_PFNMAP and follow_pfn for 5.12 merge window Daniel Vetter 2021-02-23 1:42 ` Linus Torvalds @ 2021-02-23 1:56 ` Linus Torvalds 1 sibling, 0 replies; 4+ messages in thread From: Linus Torvalds @ 2021-02-23 1:56 UTC (permalink / raw) To: Daniel Vetter Cc: Linux Kernel Mailing List, dri-devel, Linux MM, open list:DMA BUFFER SHARING FRAMEWORK, Linux PCI 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-02-23 7:24 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <YDOGERvNuU3+2WWe@phenom.ffwll.local>
2021-02-22 10:24 ` [PULL] fixes around VM_PFNMAP and follow_pfn for 5.12 merge window Daniel Vetter
2021-02-23 1:42 ` Linus Torvalds
2021-02-23 7:22 ` Daniel Vetter
2021-02-23 1:56 ` Linus Torvalds
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).