From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Rob Clark <robdclark@chromium.org>
Cc: Rob Clark <robdclark@gmail.com>,
dri-devel <dri-devel@lists.freedesktop.org>,
David Airlie <airlied@linux.ie>,
open list <linux-kernel@vger.kernel.org>,
Sean Paul <seanpaul@chromium.org>, Sean Paul <sean@poorly.run>
Subject: Re: [PATCH 2/2] drm/atomic: clear new_state pointers at hw_done
Date: Fri, 1 Nov 2019 23:44:31 +0200 [thread overview]
Message-ID: <20191101214431.GJ1208@intel.com> (raw)
In-Reply-To: <CAJs_Fx7u6VNDarYqUuUSMSsWK0jpS5ybse0h1X4AmtXO9Mia_w@mail.gmail.com>
On Fri, Nov 01, 2019 at 12:49:02PM -0700, Rob Clark wrote:
> On Fri, Nov 1, 2019 at 12:25 PM Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> >
> > On Fri, Nov 01, 2019 at 11:07:13AM -0700, Rob Clark wrote:
> > > From: Rob Clark <robdclark@chromium.org>
> > >
> > > The new state should not be accessed after this point. Clear the
> > > pointers to make that explicit.
> > >
> > > This makes the error corrected in the previous patch more obvious.
> > >
> > > Signed-off-by: Rob Clark <robdclark@chromium.org>
> > > ---
> > > drivers/gpu/drm/drm_atomic_helper.c | 29 +++++++++++++++++++++++++++++
> > > 1 file changed, 29 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > > index 732bd0ce9241..176831df8163 100644
> > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > @@ -2234,13 +2234,42 @@ EXPORT_SYMBOL(drm_atomic_helper_fake_vblank);
> > > */
> > > void drm_atomic_helper_commit_hw_done(struct drm_atomic_state *old_state)
> > > {
> > > + struct drm_connector *connector;
> > > + struct drm_connector_state *old_conn_state, *new_conn_state;
> > > struct drm_crtc *crtc;
> > > struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> > > + struct drm_plane *plane;
> > > + struct drm_plane_state *old_plane_state, *new_plane_state;
> > > struct drm_crtc_commit *commit;
> > > + struct drm_private_obj *obj;
> > > + struct drm_private_state *old_obj_state, *new_obj_state;
> > > int i;
> > >
> > > + /*
> > > + * After this point, drivers should not access the permanent modeset
> > > + * state, so we also clear the new_state pointers to make this
> > > + * restriction explicit.
> > > + *
> > > + * For the CRTC state, we do this in the same loop where we signal
> > > + * hw_done, since we still need to new_crtc_state to fish out the
> > > + * commit.
> > > + */
> > > +
> > > + for_each_oldnew_connector_in_state(old_state, connector, old_conn_state, new_conn_state, i) {
> > > + old_state->connectors[i].new_state = NULL;
> > > + }
> > > +
> > > + for_each_oldnew_plane_in_state(old_state, plane, old_plane_state, new_plane_state, i) {
> > > + old_state->planes[i].new_state = NULL;
> > > + }
> > > +
> > > + for_each_oldnew_private_obj_in_state(old_state, obj, old_obj_state, new_obj_state, i) {
> > > + old_state->private_objs[i].new_state = NULL;
> > > + }
> > > +
> > > for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) {
> > > old_state->crtcs[i].new_self_refresh_active = new_crtc_state->self_refresh_active;
> > > + old_state->crtcs[i].new_state = NULL;
> >
> > That's going to be a real PITA when doing programming after the fact from
> > a vblank worker. It's already a pain that the new_crtc_state->state is
> > getting NULLed somewhere.
> >
>
> I think you already have that problem, this just makes it explicit.
I don't yet. Except on a branch where I have my vblank workers.
And I think the only problem is having the helpers/core clobber
the pointers when it should not. I don't see why it can't just
leave them be and let me use them.
--
Ville Syrjälä
Intel
WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Rob Clark <robdclark@chromium.org>
Cc: David Airlie <airlied@linux.ie>,
open list <linux-kernel@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
Sean Paul <seanpaul@chromium.org>, Sean Paul <sean@poorly.run>
Subject: Re: [PATCH 2/2] drm/atomic: clear new_state pointers at hw_done
Date: Fri, 1 Nov 2019 23:44:31 +0200 [thread overview]
Message-ID: <20191101214431.GJ1208@intel.com> (raw)
Message-ID: <20191101214431.Uhju9EqfiLghtGj7Mumi1PGLmtgFm0O84_gz-TwWcWI@z> (raw)
In-Reply-To: <CAJs_Fx7u6VNDarYqUuUSMSsWK0jpS5ybse0h1X4AmtXO9Mia_w@mail.gmail.com>
On Fri, Nov 01, 2019 at 12:49:02PM -0700, Rob Clark wrote:
> On Fri, Nov 1, 2019 at 12:25 PM Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> >
> > On Fri, Nov 01, 2019 at 11:07:13AM -0700, Rob Clark wrote:
> > > From: Rob Clark <robdclark@chromium.org>
> > >
> > > The new state should not be accessed after this point. Clear the
> > > pointers to make that explicit.
> > >
> > > This makes the error corrected in the previous patch more obvious.
> > >
> > > Signed-off-by: Rob Clark <robdclark@chromium.org>
> > > ---
> > > drivers/gpu/drm/drm_atomic_helper.c | 29 +++++++++++++++++++++++++++++
> > > 1 file changed, 29 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > > index 732bd0ce9241..176831df8163 100644
> > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > @@ -2234,13 +2234,42 @@ EXPORT_SYMBOL(drm_atomic_helper_fake_vblank);
> > > */
> > > void drm_atomic_helper_commit_hw_done(struct drm_atomic_state *old_state)
> > > {
> > > + struct drm_connector *connector;
> > > + struct drm_connector_state *old_conn_state, *new_conn_state;
> > > struct drm_crtc *crtc;
> > > struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> > > + struct drm_plane *plane;
> > > + struct drm_plane_state *old_plane_state, *new_plane_state;
> > > struct drm_crtc_commit *commit;
> > > + struct drm_private_obj *obj;
> > > + struct drm_private_state *old_obj_state, *new_obj_state;
> > > int i;
> > >
> > > + /*
> > > + * After this point, drivers should not access the permanent modeset
> > > + * state, so we also clear the new_state pointers to make this
> > > + * restriction explicit.
> > > + *
> > > + * For the CRTC state, we do this in the same loop where we signal
> > > + * hw_done, since we still need to new_crtc_state to fish out the
> > > + * commit.
> > > + */
> > > +
> > > + for_each_oldnew_connector_in_state(old_state, connector, old_conn_state, new_conn_state, i) {
> > > + old_state->connectors[i].new_state = NULL;
> > > + }
> > > +
> > > + for_each_oldnew_plane_in_state(old_state, plane, old_plane_state, new_plane_state, i) {
> > > + old_state->planes[i].new_state = NULL;
> > > + }
> > > +
> > > + for_each_oldnew_private_obj_in_state(old_state, obj, old_obj_state, new_obj_state, i) {
> > > + old_state->private_objs[i].new_state = NULL;
> > > + }
> > > +
> > > for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, i) {
> > > old_state->crtcs[i].new_self_refresh_active = new_crtc_state->self_refresh_active;
> > > + old_state->crtcs[i].new_state = NULL;
> >
> > That's going to be a real PITA when doing programming after the fact from
> > a vblank worker. It's already a pain that the new_crtc_state->state is
> > getting NULLed somewhere.
> >
>
> I think you already have that problem, this just makes it explicit.
I don't yet. Except on a branch where I have my vblank workers.
And I think the only problem is having the helpers/core clobber
the pointers when it should not. I don't see why it can't just
leave them be and let me use them.
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-11-01 21:44 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-01 18:07 [PATCH 1/2] drm/atomic: fix self-refresh helpers crtc state dereference Rob Clark
2019-11-01 18:07 ` Rob Clark
2019-11-01 18:07 ` Rob Clark
2019-11-01 18:07 ` [PATCH 2/2] drm/atomic: clear new_state pointers at hw_done Rob Clark
2019-11-01 18:07 ` Rob Clark
2019-11-01 18:07 ` Rob Clark
2019-11-01 18:33 ` Maarten Lankhorst
2019-11-01 18:33 ` Maarten Lankhorst
2019-11-01 19:44 ` Rob Clark
2019-11-01 19:44 ` Rob Clark
2019-11-01 19:24 ` Ville Syrjälä
2019-11-01 19:24 ` Ville Syrjälä
2019-11-01 19:49 ` Rob Clark
2019-11-01 19:49 ` Rob Clark
2019-11-01 21:44 ` Ville Syrjälä [this message]
2019-11-01 21:44 ` Ville Syrjälä
2019-11-01 22:14 ` Rob Clark
2019-11-01 22:14 ` Rob Clark
2019-11-04 18:41 ` Ville Syrjälä
2019-11-04 18:41 ` Ville Syrjälä
2019-11-04 19:13 ` Rob Clark
2019-11-04 19:13 ` Rob Clark
2019-11-04 20:50 ` Ville Syrjälä
2019-11-04 20:50 ` Ville Syrjälä
2019-11-04 21:11 ` Rob Clark
2019-11-04 21:11 ` Rob Clark
2019-11-06 2:58 ` [drm/atomic] 554231a5c5: BUG:kernel_NULL_pointer_dereference, address kernel test robot
2019-11-06 2:58 ` [drm/atomic] 554231a5c5: BUG:kernel_NULL_pointer_dereference,address kernel test robot
2019-11-06 2:58 ` kernel test robot
2019-11-01 20:06 ` [PATCH 1/2] drm/atomic: fix self-refresh helpers crtc state dereference Sean Paul
2019-11-01 20:06 ` Sean Paul
2019-11-04 9:29 ` Maarten Lankhorst
2019-11-04 9:29 ` 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=20191101214431.GJ1208@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robdclark@chromium.org \
--cc=robdclark@gmail.com \
--cc=sean@poorly.run \
--cc=seanpaul@chromium.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.