On Thu, Oct 24, 2019 at 12:43 PM Thierry Reding
<thierry.reding@xxxxxxxxx> wrote:
>
> On Thu, Oct 24, 2019 at 12:40:55PM +0200, Thierry Reding wrote:
> > On Wed, Oct 23, 2019 at 04:49:52PM +0200, Daniel Vetter wrote:
> > > Properties can't be attached after registering, userspace would get
> > > confused (no one bothers to reprobe really).
> > >
> > > - Add kerneldoc
> > > - Enforce this with some checks. This needs a somewhat ugly check
> > > since connectors can be added later on, but we still need to attach
> > > all properties before they go public.
> > >
> > > Note that we already enforce that properties themselves are created
> > > before the entire device is registered.
> > >
> > > Cc: Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx>
> > > Cc: Rajat Jain <rajatja@xxxxxxxxxx>
> > > Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx>
> > > ---
> > > drivers/gpu/drm/drm_mode_object.c | 14 ++++++++++++++
> > > 1 file changed, 14 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_mode_object.c b/drivers/gpu/drm/drm_mode_object.c
> > > index 6a23e36ed4fe..35c2719407a8 100644
> > > --- a/drivers/gpu/drm/drm_mode_object.c
> > > +++ b/drivers/gpu/drm/drm_mode_object.c
> > > @@ -224,12 +224,26 @@ EXPORT_SYMBOL(drm_mode_object_get);
> > > * This attaches the given property to the modeset object with the given initial
> > > * value. Currently this function cannot fail since the properties are stored in
> > > * a statically sized array.
> > > + *
> > > + * Note that all properties must be attached before the object itself is
> > > + * registered and accessible from userspace.
> > > */
> > > void drm_object_attach_property(struct drm_mode_object *obj,
> > > struct drm_property *property,
> > > uint64_t init_val)
> > > {
> > > int count = obj->properties->count;
> > > + struct drm_device *dev = property->dev;
> > > +
> > > +
> > > + if (obj->type == DRM_MODE_OBJECT_CONNECTOR) {
> > > + struct drm_connector *connector = obj_to_connector(obj);
> > > +
> > > + WARN_ON(!dev->driver->load &&
> > > + connector->registration_state == DRM_CONNECTOR_REGISTERED);
> > > + } else {
> > > + WARN_ON(!dev->driver->load && dev->registered);
> > > + }
> >
> > I'm not sure I understand why dev->driver->load needs to be a special
> > case. Don't the same rules apply for those drivers as well?
>
> Nevermind, I just noticed that drm_dev_register() sets dev->registered
> to true before calling the driver's ->load() implementation, so makes
> sense:
We tried to be clever with this already before, see:
commit e0f32f78e51b9989ee89f608fd0dd10e9c230652 (tag:
drm-misc-next-fixes-2019-09-18)
Author: Daniel Vetter <daniel.vetter@xxxxxxxx>
Date: Tue Sep 17 14:09:35 2019 +0200
drm/kms: Duct-tape for mode object lifetime checks
commit 4f5368b5541a902f6596558b05f5c21a9770dd32
Author: Daniel Vetter <daniel.vetter@xxxxxxxx>
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@xxxxxxxxxxxxxxx>
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@xxxxxxxxxx>
Cc: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx>
Reported-by: Michel Dänzer <michel@xxxxxxxxxxx>
Reviewed-by: Michel Dänzer <mdaenzer@xxxxxxxxxx>
Tested-by: Michel Dänzer <mdaenzer@xxxxxxxxxx>
Cc: Michel Dänzer <michel@xxxxxxxxxxx>
Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx>
Link: https://patchwork.freedesktop.org/patch/msgid/20190917120936.7501-1-daniel.vetter@xxxxxxxx>
I think I'll add a reference to the above to the commit message when applying.
> Reviewed-by: Thierry Reding <treding@xxxxxxxxxx>
Thanks for taking a look.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
