On Sat, 2019-06-29 at 17:39 +0200, Daniel Vetter wrote:
On Fri, Jun 28, 2019 at 7:24 PM Sean Paul sean@poorly.run wrote:
On Fri, Jun 14, 2019 at 08:17:23AM +0200, Daniel Vetter wrote:
Only dynamic mode objects, i.e. those which are refcounted and have a free callback, can be added while the overall drm_device is visible to userspace. All others must be added before drm_dev_register and removed after drm_dev_unregister.
Small issue around drivers still using the load/unload callbacks, we need to make sure we set dev->registered so that load/unload code in these callbacks doesn't trigger false warnings. Only a small adjustement in drm_dev_register was needed.
Motivated by some irc discussions about object ids of dynamic objects like blobs become invalid, and me going on a bit an audit spree.
Seems like a very worthwhile change, any idea how many drivers are going to be sad after this change?
None I think/hope, really just defense WARN_ON just in case. The main ones that would be sad are all the ones that have a ->load callback, but I'm taking care of them. Everyone else does things correctly and calls drm_dev_register last in their probe function (or around where they set up fbdev, which is also register the driver at least to the fbdev world, so really the same).
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, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index cb6f0245de7c..48c84e3e1931 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -997,14 +997,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 1c6e51135962..c355ba8e6d5d 100644 --- a/drivers/gpu/drm/drm_mode_object.c +++ b/drivers/gpu/drm/drm_mode_object.c @@ -42,6 +42,8 @@ int __drm_mode_object_add(struct drm_device *dev, struct drm_mode_object *obj, { int ret;
WARN_ON(dev->registered && !obj_free_cb);
Getting warnings on i915 with MST, we add fake MST connectors when a sink with MST support is connected;
intel_dp_add_mst_connector()->drm_connector_attach_max_bpc_property()
Not sure how to fix that, add a global i915 device property like we do for "audio" and "Broadcast RGB" don't look the right approach here. Any tips?
We definitely need a platform with a MST sink on our CI.
These should probably have a comment above them giving some guidance to the driver developer.
With some comments, this is:
What comment do you expect here? drm_dev_register explains what you should do already, and I expect driver developers to find that one pretty quickly. From there: "This should be done last in the device initialization sequence to make sure userspace can't access an inconsistent state." -Daniel
Reviewed-by: Sean Paul sean@poorly.run
mutex_lock(&dev->mode_config.idr_mutex); ret = idr_alloc(&dev->mode_config.object_idr, register_obj? obj : NULL, 1, 0, GFP_KERNEL); @@ -102,6 +104,8 @@ 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);mutex_lock(&dev->mode_config.idr_mutex); if (object->id) { idr_remove(&dev->mode_config.object_idr, object-id);
-- 2.20.1
dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
-- Sean Paul, Software Engineer, Google / Chromium OS