dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 2/4] drm/atomic: Add accessor macros for the current state.
Date: Thu, 17 Nov 2016 14:26:19 +0200	[thread overview]
Message-ID: <20161117122619.GT31595@intel.com> (raw)
In-Reply-To: <a12aeb18-6d73-ddc4-6a06-3c9f0f2c5148@linux.intel.com>

On Thu, Nov 17, 2016 at 12:58:00PM +0100, Maarten Lankhorst wrote:
> Op 16-11-16 om 17:32 schreef Ville Syrjälä:
> > On Wed, Nov 16, 2016 at 05:11:56PM +0100, Maarten Lankhorst wrote:
> >> Op 16-11-16 om 16:04 schreef Daniel Vetter:
> >>> On Wed, Nov 16, 2016 at 04:35:45PM +0200, Ville Syrjälä wrote:
> >>>> On Wed, Nov 16, 2016 at 02:58:06PM +0100, Maarten Lankhorst wrote:
> >>>>> With checks! This will allow safe access to the current state,
> >>>>> while ensuring that the correct locks are held.
> >>>>>
> >>>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >>>>> ---
> >>>>>  include/drm/drm_atomic.h       | 66 ++++++++++++++++++++++++++++++++++++++++++
> >>>>>  include/drm/drm_modeset_lock.h | 21 ++++++++++++++
> >>>>>  2 files changed, 87 insertions(+)
> >>>>>
> >>>>> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> >>>>> index e527684dd394..462408a2d1b8 100644
> >>>>> --- a/include/drm/drm_atomic.h
> >>>>> +++ b/include/drm/drm_atomic.h
> >>>>> @@ -334,6 +334,72 @@ __drm_atomic_get_current_plane_state(struct drm_atomic_state *state,
> >>>>>  	return plane->state;
> >>>>>  }
> >>>>>  
> >>>>> +
> >>>>> +/**
> >>>>> + * drm_atomic_get_current_plane_state - get current plane state
> >>>>> + * @plane: plane to grab
> >>>>> + *
> >>>>> + * This function returns the current plane state for the given plane,
> >>>>> + * with extra locking checks to make sure that the plane state can be
> >>>>> + * retrieved safely.
> >>>>> + *
> >>>>> + * Returns:
> >>>>> + *
> >>>>> + * Pointer to the current plane state.
> >>>>> + */
> >>>>> +static inline struct drm_plane_state *
> >>>>> +drm_atomic_get_current_plane_state(struct drm_plane *plane)
> >>>>> +{
> >>>>> +	struct drm_plane_state *plane_state = plane->state;
> >>>>> +	struct drm_crtc *crtc = plane_state ? plane_state->crtc : NULL;
> >>>>> +
> >>>>> +	if (crtc)
> >>>>> +		drm_modeset_lock_assert_one_held(&plane->mutex, &crtc->mutex);
> >>>>> +	else
> >>>>> +		drm_modeset_lock_assert_held(&plane->mutex);
> >>>> Hmm. Daniel recently smashed me on the head with a big clue bat to point
> >>>> out that accessing object->state isn't safe unless you hold the object lock.
> >>>> So this thing seems suspicious. What's the use case for this?
> >>>>
> >>>> I guess in this case it might be safe since a parallel update would lock
> >>>> the crtc as well. But it does feel like promoting potentially dangerous
> >>>> behaviour. Also there are no barriers so I'm not sure this would be
> >>>> guaranteed to give us the correct answer anyway.
> >>>>
> >>>> As far as all of these functions go, should they return const*? Presumably
> >>>> you wouldn't want to allow changes to the current state.
> >>> Yep, need at least a lockdep check for the plane->mutex. And imo also a
> >>> check that we're indeed in atomic_check per the idea I dropped on the
> >>> cover letter.
> >>>
> >>> And +1 on const * for these, that seems like a very important check.
> >> Well I allowed for crtc lock held because the __ function uses crtc->mutex as safety lock.
> > What is this so called __ function exactly?
> __drm_atomic_get_current_plane_state, which is only used by drm_atomic_crtc_state_for_each_plane_state.
> 
> It iterates over crtc_state->plane_mask and then gets new_plane_state if available, or plane->state if the plane is not part of the state.
> This is mostly used for watermark calculations.

Sounds like we should kill that sucker and make things clearer by
enforcing the "want to access foo->state? then grab foo->lock first"
rule.

> >> I thought of const, but some code like i915_page_flip manipulates the current state with the right locks held.
> >> Perhaps we should disallow that. :)
> >>
> >> ~Maarten
> 

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2016-11-17 12:26 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-16 13:58 [PATCH v2 0/4] drm/atomic: Add accessor macros for all atomic state Maarten Lankhorst
2016-11-16 13:58 ` [PATCH v2 1/4] drm/atomic: Add new iterators over all state, v2 Maarten Lankhorst
2016-11-16 13:58 ` [PATCH v2 2/4] drm/atomic: Add accessor macros for the current state Maarten Lankhorst
2016-11-16 14:35   ` Ville Syrjälä
2016-11-16 15:04     ` Daniel Vetter
2016-11-16 16:11       ` Maarten Lankhorst
2016-11-16 16:26         ` Daniel Vetter
2016-11-16 16:32         ` Ville Syrjälä
2016-11-17 11:58           ` Maarten Lankhorst
2016-11-17 12:26             ` Ville Syrjälä [this message]
2016-11-17 12:42               ` Maarten Lankhorst
2016-11-17 12:50                 ` Ville Syrjälä
2016-11-17 13:20                   ` [PATCH v2.1 2/4] drm/atomic: Add accessor macros for the current state, v2 Maarten Lankhorst
2016-12-09 22:27                     ` Daniel Vetter
2016-12-14 13:15                     ` Daniel Vetter
2016-12-15 10:24                       ` [PATCH v2.2 2/4] drm/atomic: Add accessor macros for the current state, v3 Maarten Lankhorst
2016-11-16 13:58 ` [PATCH v2 3/4] drm/atomic: Add macros to access existing old/new state Maarten Lankhorst
2016-12-28 14:25   ` Daniel Vetter
2016-11-16 13:58 ` [PATCH v2 4/4] drm/atomic: Add checks to ensure get_state is not called after swapping Maarten Lankhorst
2016-11-16 14:18 ` [PATCH v2 0/4] drm/atomic: Add accessor macros for all atomic state Daniel Vetter
2016-11-16 16:11   ` Maarten Lankhorst
2016-11-16 16:27     ` Daniel Vetter
2016-12-14 13:17 ` Daniel Vetter
2016-12-15  9:19   ` Maarten Lankhorst

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161117122619.GT31595@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=maarten.lankhorst@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).