lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180221150727.GO5453@intel.com>
Date:   Wed, 21 Feb 2018 17:07:27 +0200
From:   Ville Syrjälä <ville.syrjala@...ux.intel.com>
To:     Rob Clark <robdclark@...il.com>
Cc:     dri-devel <dri-devel@...ts.freedesktop.org>,
        David Airlie <airlied@...ux.ie>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/4] drm/atomic: integrate modeset lock with private
 objects

On Wed, Feb 21, 2018 at 09:54:49AM -0500, Rob Clark wrote:
> On Wed, Feb 21, 2018 at 9:49 AM, Ville Syrjälä
> <ville.syrjala@...ux.intel.com> wrote:
> > On Wed, Feb 21, 2018 at 09:37:21AM -0500, Rob Clark wrote:
> >> Follow the same pattern of locking as with other state objects.  This
> >> avoids boilerplate in the driver.
> >
> > I'm not sure we really want to do this. What if the driver wants a
> > custom locking scheme for this state?
> 
> That seems like something we want to discourage, ie. all the more
> reason for this patch.
> 
> There is no reason drivers could not split their global state into
> multiple private objs's, each with their own lock, for more fine
> grained locking.  That is basically the only valid reason I can think
> of for "custom locking".

In i915 we have at least one case that would want something close to an
rwlock. Any crtc lock is enough for read, need all of them for write.
Though if we wanted to use private objs for that we might need to
actually make the states refcounted as well, otherwise I can imagine
we might land in some use-after-free issues once again.

Maybe we could duplicate the state into per-crtc and global copies, but
then we have to keep all of those in sync somehow which doesn't sound
particularly pleasant.

> 
> (And ofc drivers could add there own locks in addition to what is done
> by core, but I'd rather look at that on a case by case basis, rather
> than it being part of the boilerplate in each driver.)
> 
> BR,
> -R
> 
> >>
> >> Signed-off-by: Rob Clark <robdclark@...il.com>
> >> ---
> >>  drivers/gpu/drm/drm_atomic.c | 9 ++++++++-
> >>  include/drm/drm_atomic.h     | 5 +++++
> >>  2 files changed, 13 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> >> index fc8c4da409ff..004e621ab307 100644
> >> --- a/drivers/gpu/drm/drm_atomic.c
> >> +++ b/drivers/gpu/drm/drm_atomic.c
> >> @@ -1078,6 +1078,8 @@ drm_atomic_private_obj_init(struct drm_private_obj *obj,
> >>  {
> >>       memset(obj, 0, sizeof(*obj));
> >>
> >> +     drm_modeset_lock_init(&obj->lock);
> >> +
> >>       obj->state = state;
> >>       obj->funcs = funcs;
> >>  }
> >> @@ -1093,6 +1095,7 @@ void
> >>  drm_atomic_private_obj_fini(struct drm_private_obj *obj)
> >>  {
> >>       obj->funcs->atomic_destroy_state(obj, obj->state);
> >> +     drm_modeset_lock_fini(&obj->lock);
> >>  }
> >>  EXPORT_SYMBOL(drm_atomic_private_obj_fini);
> >>
> >> @@ -1113,7 +1116,7 @@ struct drm_private_state *
> >>  drm_atomic_get_private_obj_state(struct drm_atomic_state *state,
> >>                                struct drm_private_obj *obj)
> >>  {
> >> -     int index, num_objs, i;
> >> +     int index, num_objs, i, ret;
> >>       size_t size;
> >>       struct __drm_private_objs_state *arr;
> >>       struct drm_private_state *obj_state;
> >> @@ -1122,6 +1125,10 @@ drm_atomic_get_private_obj_state(struct drm_atomic_state *state,
> >>               if (obj == state->private_objs[i].ptr)
> >>                       return state->private_objs[i].state;
> >>
> >> +     ret = drm_modeset_lock(&obj->lock, state->acquire_ctx);
> >> +     if (ret)
> >> +             return ERR_PTR(ret);
> >> +
> >>       num_objs = state->num_private_objs + 1;
> >>       size = sizeof(*state->private_objs) * num_objs;
> >>       arr = krealloc(state->private_objs, size, GFP_KERNEL);
> >> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> >> index 09076a625637..9ae53b73c9d2 100644
> >> --- a/include/drm/drm_atomic.h
> >> +++ b/include/drm/drm_atomic.h
> >> @@ -218,6 +218,11 @@ struct drm_private_state_funcs {
> >>   * &drm_modeset_lock is required to duplicate and update this object's state.
> >>   */
> >>  struct drm_private_obj {
> >> +     /**
> >> +      * @lock: Modeset lock to protect the state object.
> >> +      */
> >> +     struct drm_modeset_lock lock;
> >> +
> >>       /**
> >>        * @state: Current atomic state for this driver private object.
> >>        */
> >> --
> >> 2.14.3
> >>
> >> _______________________________________________
> >> dri-devel mailing list
> >> dri-devel@...ts.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> > --
> > Ville Syrjälä
> > Intel OTC

-- 
Ville Syrjälä
Intel OTC

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ