| Message ID | 20190917120936.7501-1-daniel.vetter@ffwll.ch (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/2] drm/kms: Duct-tape for mode object lifetime checks | expand |
On 2019-09-17 2:09 p.m., Daniel Vetter wrote: > commit 4f5368b5541a902f6596558b05f5c21a9770dd32 > Author: Daniel Vetter <daniel.vetter@ffwll.ch> > Date: Fri Jun 14 08:17:23 2019 +0200 > > drm/kms: Catch mode_object lifetime errors > > uncovered a bit a mess in dp drivers. Most drivers (from a quick look, > all except i915) register all the dp stuff in their init code, which > is too early. With CONFIG_DRM_DP_AUX_CHARDEV this will blow up, > because drm_dp_aux_register tries to add a child to a device in sysfs > (the connector) which doesn't even exist yet. > > No one seems to have cared thus far. But with the above change I also > moved the setting of dev->registered after the ->load callback, in an > attempt to keep old drivers from hitting any WARN_ON backtraces. But > that moved radeon.ko from the "working, by accident" to "now also > broken" category. > > Since this is a huge mess I figured a revert would be simplest. But > this check has already caught issues in i915: > > commit 1b9bd09630d4db4827cc04d358a41a16a6bc2cb0 > Author: Ville Syrjälä <ville.syrjala@linux.intel.com> > Date: Tue Aug 20 19:16:57 2019 +0300 > > drm/i915: Do not create a new max_bpc prop for MST connectors > > Hence I'd like to retain it. Fix the radeon regression by moving the > setting of dev->registered back to were it was, and stop the > backtraces with an explicit check for dev->driver->load. > > Everyone else will stay as broken with CONFIG_DRM_DP_AUX_CHARDEV. The > next patch will improve the kerneldoc and add a todo entry for this. > > Fixes: 4f5368b5541a ("drm/kms: Catch mode_object lifetime errors") > Cc: Sean Paul <sean@poorly.run> > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > Reported-by: Michel Dänzer <michel@daenzer.net> > Cc: Michel Dänzer <michel@daenzer.net> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> Tested-by: Michel Dänzer <mdaenzer@redhat.com> Thanks!
On Tue, Sep 17, 2019 at 04:48:51PM +0200, Michel Dänzer wrote: > On 2019-09-17 2:09 p.m., Daniel Vetter wrote: > > commit 4f5368b5541a902f6596558b05f5c21a9770dd32 > > Author: Daniel Vetter <daniel.vetter@ffwll.ch> > > Date: Fri Jun 14 08:17:23 2019 +0200 > > > > drm/kms: Catch mode_object lifetime errors > > > > uncovered a bit a mess in dp drivers. Most drivers (from a quick look, > > all except i915) register all the dp stuff in their init code, which > > is too early. With CONFIG_DRM_DP_AUX_CHARDEV this will blow up, > > because drm_dp_aux_register tries to add a child to a device in sysfs > > (the connector) which doesn't even exist yet. > > > > No one seems to have cared thus far. But with the above change I also > > moved the setting of dev->registered after the ->load callback, in an > > attempt to keep old drivers from hitting any WARN_ON backtraces. But > > that moved radeon.ko from the "working, by accident" to "now also > > broken" category. > > > > Since this is a huge mess I figured a revert would be simplest. But > > this check has already caught issues in i915: > > > > commit 1b9bd09630d4db4827cc04d358a41a16a6bc2cb0 > > Author: Ville Syrjälä <ville.syrjala@linux.intel.com> > > Date: Tue Aug 20 19:16:57 2019 +0300 > > > > drm/i915: Do not create a new max_bpc prop for MST connectors > > > > Hence I'd like to retain it. Fix the radeon regression by moving the > > setting of dev->registered back to were it was, and stop the > > backtraces with an explicit check for dev->driver->load. > > > > Everyone else will stay as broken with CONFIG_DRM_DP_AUX_CHARDEV. The > > next patch will improve the kerneldoc and add a todo entry for this. > > > > Fixes: 4f5368b5541a ("drm/kms: Catch mode_object lifetime errors") > > Cc: Sean Paul <sean@poorly.run> > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > > Reported-by: Michel Dänzer <michel@daenzer.net> > > Cc: Michel Dänzer <michel@daenzer.net> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > > Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> > Tested-by: Michel Dänzer <mdaenzer@redhat.com> Thanks, merged into drm-misc-next-fixes. -Daniel
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index b634882056c8..0c9978af9f72 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -983,14 +983,14 @@ int drm_dev_register(struct drm_device *dev, unsigned long flags) if (ret) goto err_minors; + dev->registered = true; + if (dev->driver->load) { ret = dev->driver->load(dev, flags); if (ret) goto err_minors; } - dev->registered = true; - if (drm_core_check_feature(dev, DRIVER_MODESET)) drm_modeset_register_all(dev); diff --git a/drivers/gpu/drm/drm_mode_object.c b/drivers/gpu/drm/drm_mode_object.c index c355ba8e6d5d..6a23e36ed4fe 100644 --- a/drivers/gpu/drm/drm_mode_object.c +++ b/drivers/gpu/drm/drm_mode_object.c @@ -42,7 +42,7 @@ int __drm_mode_object_add(struct drm_device *dev, struct drm_mode_object *obj, { int ret; - WARN_ON(dev->registered && !obj_free_cb); + WARN_ON(!dev->driver->load && dev->registered && !obj_free_cb); mutex_lock(&dev->mode_config.idr_mutex); ret = idr_alloc(&dev->mode_config.object_idr, register_obj ? obj : NULL, @@ -104,7 +104,7 @@ void drm_mode_object_register(struct drm_device *dev, void drm_mode_object_unregister(struct drm_device *dev, struct drm_mode_object *object) { - WARN_ON(dev->registered && !object->free_cb); + WARN_ON(!dev->driver->load && dev->registered && !object->free_cb); mutex_lock(&dev->mode_config.idr_mutex); if (object->id) {
commit 4f5368b5541a902f6596558b05f5c21a9770dd32 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Jun 14 08:17:23 2019 +0200 drm/kms: Catch mode_object lifetime errors uncovered a bit a mess in dp drivers. Most drivers (from a quick look, all except i915) register all the dp stuff in their init code, which is too early. With CONFIG_DRM_DP_AUX_CHARDEV this will blow up, because drm_dp_aux_register tries to add a child to a device in sysfs (the connector) which doesn't even exist yet. No one seems to have cared thus far. But with the above change I also moved the setting of dev->registered after the ->load callback, in an attempt to keep old drivers from hitting any WARN_ON backtraces. But that moved radeon.ko from the "working, by accident" to "now also broken" category. Since this is a huge mess I figured a revert would be simplest. But this check has already caught issues in i915: commit 1b9bd09630d4db4827cc04d358a41a16a6bc2cb0 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Tue Aug 20 19:16:57 2019 +0300 drm/i915: Do not create a new max_bpc prop for MST connectors Hence I'd like to retain it. Fix the radeon regression by moving the setting of dev->registered back to were it was, and stop the backtraces with an explicit check for dev->driver->load. Everyone else will stay as broken with CONFIG_DRM_DP_AUX_CHARDEV. The next patch will improve the kerneldoc and add a todo entry for this. Fixes: 4f5368b5541a ("drm/kms: Catch mode_object lifetime errors") Cc: Sean Paul <sean@poorly.run> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reported-by: Michel Dänzer <michel@daenzer.net> Cc: Michel Dänzer <michel@daenzer.net> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> --- drivers/gpu/drm/drm_drv.c | 4 ++-- drivers/gpu/drm/drm_mode_object.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)