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@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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel