On 6/30/22 23:26, Thomas Hellström (Intel) wrote: > > On 6/30/22 22:22, Dmitry Osipenko wrote: >> Hello Thomas, >> >> On 6/30/22 23:15, Thomas Hellström (Intel) wrote: >>> Hi, Dmitry, >>> >>> On 6/30/22 22:04, Dmitry Osipenko wrote: >>>> Drivers that use drm_gem_mmap() and drm_gem_mmap_obj() helpers don't >>>> handle imported dma-bufs properly, which results in mapping of >>>> something >>>> else than the imported dma-buf. On NVIDIA Tegra we get a hard lockup >>>> when >>>> userspace writes to the memory mapping of a dma-buf that was imported >>>> into >>>> Tegra's DRM GEM. >>>> >>>> Majority of DRM drivers prohibit mapping of the imported GEM objects. >>>> Mapping of imported GEMs require special care from userspace since it >>>> should sync dma-buf because mapping coherency of the exporter device >>>> may >>>> not match the DRM device. Let's prohibit the mapping for all DRM >>>> drivers >>>> for consistency. >>>> >>>> Cc: stable@xxxxxxxxxxxxxxx >>>> Suggested-by: Thomas Hellström <thomas.hellstrom@xxxxxxxxxxxxxxx> >>>> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@xxxxxxxxxxxxx> >>> This might break drivers whose obj->funcs->mmap() callback already >>> handles this case, and has userspace that does the right thing. >> The drm-shmem helper should be the only that maps imported GEMs >> properly, but drivers that use drm-shmem already prohibit to map >> imported GEMs. Okay, I'll try to re-check once again to be sure. > > OK. If you aren't 100.1% sure, then please drop the Cc: stable tag and > let the patch ride out at least an -rc series, because breaking a stable > kernel is something we woudln't want to do. Apparently the OMAP DRM driver should be broken similarly to the Tegra DRM. Unlikely that anyone else maps the imported GEMs in practice, other drivers are prohibiting the mapping AFAICS. I'll make the v8 without the stable tag since it's not a critical problem after all because it never worked for the broken drivers. -- Best regards, Dmitry
