From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 94C31C433DF for ; Thu, 28 May 2020 20:02:53 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 779F82073B for ; Thu, 28 May 2020 20:02:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 779F82073B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id D045C6E210; Thu, 28 May 2020 20:02:49 +0000 (UTC) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by gabe.freedesktop.org (Postfix) with ESMTPS id 51A526E20A for ; Thu, 28 May 2020 20:02:48 +0000 (UTC) IronPort-SDR: ot53eXkKFQnHzG3KlpvcSMKjP/EZaOsgfmujC7xeDCFBXR6Y8KLiGKjtr/BMFP4dwDGAqYDpQA Pga4Lml+ZLAA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 May 2020 13:02:47 -0700 IronPort-SDR: Y3hmyNe40AIBbc3EHg/8laYbSpwEQL47qWdbyAimXzaVMhLWST0NJ8MwrYOi8LdLutToYB78C9 B6ddFPopbNow== X-IronPort-AV: E=Sophos;i="5.73,446,1583222400"; d="scan'208";a="443102118" Received: from unknown (HELO intel.com) ([10.237.72.89]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 May 2020 13:02:46 -0700 Date: Thu, 28 May 2020 22:58:52 +0300 From: "Lisovskiy, Stanislav" To: Ville Syrjala Message-ID: <20200528195852.GA25073@intel.com> References: <20200527200245.13184-1-ville.syrjala@linux.intel.com> <20200528193852.GA24971@intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200528193852.GA24971@intel.com> User-Agent: Mutt/1.9.4 (2018-02-28) Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fix global state use-after-frees with a refcount X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: intel-gfx@lists.freedesktop.org Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Thu, May 28, 2020 at 10:38:52PM +0300, Lisovskiy, Stanislav wrote: > On Wed, May 27, 2020 at 11:02:45PM +0300, Ville Syrjala wrote: > > From: Ville Syrj=E4l=E4 > > = > > While the current locking/serialization of the global state > > suffices for protecting the obj->state access and the actual > > hardware reprogramming, we do have a problem with accessing > > the old/new states during nonblocking commits. > > = > > The state computation and swap will be protected by the crtc > > locks, but the commit_tails can finish out of order, thus also > > causing the atomic states to be cleaned up out of order. This > > would mean the commit that started first but finished last has > > had its new state freed as the no-longer-needed old state by the > > other commit. > > = > > To fix this let's just refcount the states. obj->state amounts > > to one reference, and the intel_atomic_state holds extra references > > to both its new and old global obj states. > > = > > Fixes: 0ef1905ecf2e ("drm/i915: Introduce better global state handling") > > Signed-off-by: Ville Syrj=E4l=E4 > > --- > > .../gpu/drm/i915/display/intel_global_state.c | 45 ++++++++++++++++--- > > .../gpu/drm/i915/display/intel_global_state.h | 3 ++ > > 2 files changed, 42 insertions(+), 6 deletions(-) > > = > > diff --git a/drivers/gpu/drm/i915/display/intel_global_state.c b/driver= s/gpu/drm/i915/display/intel_global_state.c > > index 212d4ee68205..7a19215ad844 100644 > > --- a/drivers/gpu/drm/i915/display/intel_global_state.c > > +++ b/drivers/gpu/drm/i915/display/intel_global_state.c > > @@ -10,6 +10,28 @@ > > #include "intel_display_types.h" > > #include "intel_global_state.h" > > = > > +static void __intel_atomic_global_state_free(struct kref *kref) > > +{ > > + struct intel_global_state *obj_state =3D > > + container_of(kref, struct intel_global_state, ref); > > + struct intel_global_obj *obj =3D obj_state->obj; > > + > > + obj->funcs->atomic_destroy_state(obj, obj_state); > > +} > > + > > +static void intel_atomic_global_state_put(struct intel_global_state *o= bj_state) > > +{ > > + kref_put(&obj_state->ref, __intel_atomic_global_state_free); > > +} > > + > > +static struct intel_global_state * > > +intel_atomic_global_state_get(struct intel_global_state *obj_state) > > +{ > > + kref_get(&obj_state->ref); > > + > > + return obj_state; > > +} > > + > > void intel_atomic_global_obj_init(struct drm_i915_private *dev_priv, > > struct intel_global_obj *obj, > > struct intel_global_state *state, > > @@ -17,6 +39,10 @@ void intel_atomic_global_obj_init(struct drm_i915_pr= ivate *dev_priv, > > { > > memset(obj, 0, sizeof(*obj)); > > = > > + state->obj =3D obj; > > + > > + kref_init(&state->ref); > > + > > obj->state =3D state; > > obj->funcs =3D funcs; > > list_add_tail(&obj->head, &dev_priv->global_obj_list); > > @@ -28,7 +54,9 @@ void intel_atomic_global_obj_cleanup(struct drm_i915_= private *dev_priv) > > = > > list_for_each_entry_safe(obj, next, &dev_priv->global_obj_list, head)= { > > list_del(&obj->head); > > - obj->funcs->atomic_destroy_state(obj, obj->state); > > + > > + drm_WARN_ON(&dev_priv->drm, kref_read(&obj->state->ref) !=3D 1); > > + intel_atomic_global_state_put(obj->state); > > } > > } > > = > > @@ -97,10 +125,14 @@ intel_atomic_get_global_obj_state(struct intel_ato= mic_state *state, > > if (!obj_state) > > return ERR_PTR(-ENOMEM); > > = > > + obj_state->obj =3D obj; > > obj_state->changed =3D false; > > = > > + kref_init(&obj_state->ref); > > + > > state->global_objs[index].state =3D obj_state; > > - state->global_objs[index].old_state =3D obj->state; > > + state->global_objs[index].old_state =3D > > + intel_atomic_global_state_get(obj->state); > > state->global_objs[index].new_state =3D obj_state; > > state->global_objs[index].ptr =3D obj; > > obj_state->state =3D state; > > @@ -163,7 +195,9 @@ void intel_atomic_swap_global_state(struct intel_at= omic_state *state) > > new_obj_state->state =3D NULL; > > = > > state->global_objs[i].state =3D old_obj_state; > > - obj->state =3D new_obj_state; > > + > > + intel_atomic_global_state_put(obj->state); > > + obj->state =3D intel_atomic_global_state_get(new_obj_state); > > } > > } > > = > > @@ -172,10 +206,9 @@ void intel_atomic_clear_global_state(struct intel_= atomic_state *state) > > int i; > > = > > for (i =3D 0; i < state->num_global_objs; i++) { > > - struct intel_global_obj *obj =3D state->global_objs[i].ptr; > > + intel_atomic_global_state_put(state->global_objs[i].old_state); > > + intel_atomic_global_state_put(state->global_objs[i].new_state); > = > Shouldn't we clean old_state only? = > = > As I understand in absence of any transaction you now have a pool of > global_obj each has a state with single kref taken. > = > So when we are going to get a new state, we do +1 kref to old_state(which= is current global obj->state) > in order to prevent it being cleared by competing commit. > However the new state doesn't have any kref taken by that moment. > Then you swap do -1 kref for the old state and do +1 kref for new state, = > which means that when you -1 kref again for old state in atomic_clear als= o, = > it will be destroyed, however regarding the new state, as I understand > it still has only single kref grabbed when it was swapped, = > so isn't it going to be now removed? unless we are lucky and somebody > haven't grabbed it already as an old_state in the next commit? > = > Stan Ah actually I got it - forgot that kref is init as 1. = But then you probably don't even need to increment kref for new state = when swapping. Before assigning new obj->state you release one kref in swap(which makes se= nse) Then you just do only intel_atomic_global_state_put(old_state) in atomic_cl= ear and then no need in doing intel_atomic_global_state_get(new_state) during swap. = I.e we always call intel_atomic_global_state_get/put only regarding "old" = obj->state and each new_state will be disposed when it becomes old_state. Stan > > = > > - obj->funcs->atomic_destroy_state(obj, > > - state->global_objs[i].state); > > state->global_objs[i].ptr =3D NULL; > > state->global_objs[i].state =3D NULL; > > state->global_objs[i].old_state =3D NULL; > > diff --git a/drivers/gpu/drm/i915/display/intel_global_state.h b/driver= s/gpu/drm/i915/display/intel_global_state.h > > index e6163a469029..1f16fa3073c9 100644 > > --- a/drivers/gpu/drm/i915/display/intel_global_state.h > > +++ b/drivers/gpu/drm/i915/display/intel_global_state.h > > @@ -6,6 +6,7 @@ > > #ifndef __INTEL_GLOBAL_STATE_H__ > > #define __INTEL_GLOBAL_STATE_H__ > > = > > +#include > > #include > > = > > struct drm_i915_private; > > @@ -54,7 +55,9 @@ struct intel_global_obj { > > for_each_if(obj) > > = > > struct intel_global_state { > > + struct intel_global_obj *obj; > > struct intel_atomic_state *state; > > + struct kref ref; > > bool changed; > > }; > > = > > -- = > > 2.26.2 > > = > > _______________________________________________ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx