| Message ID | 20220630200405.1883897-3-dmitry.osipenko@collabora.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | DRM GEM fixes | expand |
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@vger.kernel.org > Suggested-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> > Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> This might break drivers whose obj->funcs->mmap() callback already handles this case, and has userspace that does the right thing. I think the disabling must be checked on a per-driver basis to avoid that; in particular drivers that already call dma_buf_mmap() should be able to continue doing this. Also the Fixes: review comment remains, thanks, Thomas > --- > drivers/gpu/drm/drm_gem.c | 4 ++++ > drivers/gpu/drm/drm_gem_shmem_helper.c | 9 --------- > 2 files changed, 4 insertions(+), 9 deletions(-) > > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c > index 86d670c71286..fc9ec42fa0ab 100644 > --- a/drivers/gpu/drm/drm_gem.c > +++ b/drivers/gpu/drm/drm_gem.c > @@ -1034,6 +1034,10 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned long obj_size, > { > int ret; > > + /* Don't allow imported objects to be mapped */ > + if (obj->import_attach) > + return -EINVAL; > + > /* Check for valid size. */ > if (obj_size < vma->vm_end - vma->vm_start) > return -EINVAL; > diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c > index 8ad0e02991ca..6190f5018986 100644 > --- a/drivers/gpu/drm/drm_gem_shmem_helper.c > +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c > @@ -609,17 +609,8 @@ EXPORT_SYMBOL_GPL(drm_gem_shmem_vm_ops); > */ > int drm_gem_shmem_mmap(struct drm_gem_shmem_object *shmem, struct vm_area_struct *vma) > { > - struct drm_gem_object *obj = &shmem->base; > int ret; > > - if (obj->import_attach) { > - /* Drop the reference drm_gem_mmap_obj() acquired.*/ > - drm_gem_object_put(obj); > - vma->vm_private_data = NULL; > - > - return dma_buf_mmap(obj->dma_buf, vma, 0); > - } > - > ret = drm_gem_shmem_get_pages(shmem); > if (ret) { > drm_gem_vm_close(vma);
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@vger.kernel.org >> Suggested-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> >> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> > > 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. > I think the disabling must be checked on a per-driver basis to avoid > that; in particular drivers that already call dma_buf_mmap() should be > able to continue doing this. > > Also the Fixes: review comment remains, This should've been broken forever, don't think that we have a fixes tag here. I looked thought all my previous patches and added the Fixes wherever was possible. If I really missed something, then please let me know.
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@vger.kernel.org >>> Suggested-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> >>> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> >> 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. Thanks, Thomas > >> I think the disabling must be checked on a per-driver basis to avoid >> that; in particular drivers that already call dma_buf_mmap() should be >> able to continue doing this. >> >> Also the Fixes: review comment remains, > This should've been broken forever, don't think that we have a fixes tag > here. I looked thought all my previous patches and added the Fixes > wherever was possible. If I really missed something, then please let me > know. >
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@vger.kernel.org >>>> Suggested-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> >>>> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> >>> 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.
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 86d670c71286..fc9ec42fa0ab 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -1034,6 +1034,10 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned long obj_size, { int ret; + /* Don't allow imported objects to be mapped */ + if (obj->import_attach) + return -EINVAL; + /* Check for valid size. */ if (obj_size < vma->vm_end - vma->vm_start) return -EINVAL; diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c index 8ad0e02991ca..6190f5018986 100644 --- a/drivers/gpu/drm/drm_gem_shmem_helper.c +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c @@ -609,17 +609,8 @@ EXPORT_SYMBOL_GPL(drm_gem_shmem_vm_ops); */ int drm_gem_shmem_mmap(struct drm_gem_shmem_object *shmem, struct vm_area_struct *vma) { - struct drm_gem_object *obj = &shmem->base; int ret; - if (obj->import_attach) { - /* Drop the reference drm_gem_mmap_obj() acquired.*/ - drm_gem_object_put(obj); - vma->vm_private_data = NULL; - - return dma_buf_mmap(obj->dma_buf, vma, 0); - } - ret = drm_gem_shmem_get_pages(shmem); if (ret) { drm_gem_vm_close(vma);
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@vger.kernel.org Suggested-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> --- drivers/gpu/drm/drm_gem.c | 4 ++++ drivers/gpu/drm/drm_gem_shmem_helper.c | 9 --------- 2 files changed, 4 insertions(+), 9 deletions(-)