On Tue, Dec 1, 2020 at 4:43 PM Pavel Machek <pa...@ucw.cz> wrote:
>
> Hi!
>
> > From: Lyude Paul <ly...@redhat.com>
> >
> > commit de9f8eea5a44b0b756d3d6345af7f8e630a3c8c0 upstream.
>
> So this says protected by mutex:
>
> >       /**
> > -      * @registered: Is this connector exposed (registered) with userspace?
> > +      * @registration_state: Is this connector initializing, exposed
> > +      * (registered) with userspace, or unregistered?
> > +      *
> >        * Protected by @mutex.
> >        */
> > -     bool registered;
> > +     enum drm_connector_registration_state registration_state;
> >
> >       /**
> >        * @modes:
> > @@ -1165,6 +1214,24 @@ static inline void drm_connector_unrefer
> >       drm_connector_put(connector);
> >  }
> >
> > +/**
> > + * drm_connector_is_unregistered - has the connector been unregistered from
> > + * userspace?
> > + * @connector: DRM connector
> > + *
> > + * Checks whether or not @connector has been unregistered from userspace.
> > + *
> > + * Returns:
> > + * True if the connector was unregistered, false if the connector is
> > + * registered or has not yet been registered with userspace.
> > + */
> > +static inline bool
> > +drm_connector_is_unregistered(struct drm_connector *connector)
> > +{
> > +     return READ_ONCE(connector->registration_state) ==
> > +             DRM_CONNECTOR_UNREGISTERED;
> > +}
>
>
> But this uses READ_ONCE() for protection, and corresponding
> WRITE_ONCE() is nowhere to be seen. Should this take the mutex, too?

The read once here doesn't protect against any races, but just against
creative compilers doing funny stuff that might really break code
logic. I guess for symmetry we could throw the WRITE_ONCE on the write
side, but it really shouldn't matter, the entire thing is racy by
design. We0d also only ever need the write once on the unregister
call.
-Daniel

>
> Best regards,
>                                                                 Pavel
> --
> http://www.livejournal.com/~pavelmachek



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

Reply via email to