[Intel-gfx] [PATCH 1/4] drm: Complain if drivers still use the ->load callback

Daniel Vetter daniel at ffwll.ch
Tue Jan 28 15:02:02 UTC 2020


On Tue, Jan 28, 2020 at 10:47:59AM +0000, Chris Wilson wrote:
> Quoting Daniel Vetter (2020-01-28 10:45:58)
> > Kinda time to get this sorted. The locking around this really is not
> > nice.
> > 
> > Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
> > ---
> >  drivers/gpu/drm/drm_drv.c | 6 ++++++
> >  include/drm/drm_drv.h     | 3 +++
> >  2 files changed, 9 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index 7c18a980cd4b..8deff75b484c 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -948,6 +948,12 @@ int drm_dev_register(struct drm_device *dev, unsigned long flags)
> >  
> >         mutex_lock(&drm_global_mutex);
> >  
> > +       if (dev->driver->load) {
> > +               if (!drm_core_check_feature(dev, DRIVER_LEGACY))
> > +                       DRM_INFO("drm driver %s is using deprecated ->load callback\n",
> > +                                dev->driver->name);
> 
> DRM_WARN() if the plan is to remove it?

Consensus from the security check work that Kees Cook is doing seems to
be:
- Put new thing in place, convert lots
- Start to do opt-in/informational stuff
- Once you're sure it's all gone, put in the big splat that kills the
  box/driver. Apparently radeon/amdgpu are the hold-outs, once those are
  done I think I'll just outright disable ->load/unload for
  !DRIVER_LEGACY.

Cheers, Daniel

> That should encourage people to complain louder.
> -Chris
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the Intel-gfx mailing list