On Wed, Oct 21, 2020 at 10:56:39AM +0200, Daniel Vetter wrote: > Hi all, > > Round 3 of my patch series to clamp down a bunch of races and gaps > around follow_pfn and other access to iomem mmaps. Previous version: > > v1: https://lore.kernel.org/dri-devel/20201007164426.1812530-1-daniel.vetter@xxxxxxxx/ > v2: https://lore.kernel.org/dri-devel/20201009075934.3509076-1-daniel.vetter@xxxxxxxx > > And the discussion that sparked this journey: > > https://lore.kernel.org/dri-devel/20201007164426.1812530-1-daniel.vetter@xxxxxxxx/ > > I was waiting for the testing result for habanalabs from Oded, but I guess > Oded was waiting for my v3. > > Changes in v3: > - Bunch of polish all over, no functional changes aside from one barrier > in the resource code, for consistency. > - A few more r-b tags. > > Changes in v2: > - tons of small polish&fixes all over, thanks to all the reviewers who > spotted issues > - I managed to test at least the generic_access_phys and pci mmap revoke > stuff with a few gdb sessions using our i915 debug tools (hence now also > the drm/i915 patch to properly request all the pci bar regions) > - reworked approach for the pci mmap revoke: Infrastructure moved into > kernel/resource.c, address_space mapping is now set up at open time for > everyone (which required some sysfs changes). Does indeed look a lot > cleaner and a lot less invasive than I feared at first. > > The big thing I can't test are all the frame_vector changes in habanalbas, > exynos and media. Gerald has given the s390 patch a spin already. > > Review, testing, feedback all very much welcome. > > Daniel Vetter (16): > 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 > s390/pci: Remove races against pte updates > mm: Add unsafe_follow_pfn > media/videbuf1|2: Mark follow_pfn usage as unsafe > vfio/type1: Mark follow_pfn as unsafe > 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: Revoke mappings like devmem The whole thing looks like a great improvement! Thanks, Jason _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
