Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp1020375ybx; Fri, 1 Nov 2019 15:17:30 -0700 (PDT) X-Google-Smtp-Source: APXvYqz+EZ/flEI1laHEBdz0/Hjahw04HMFnxCD+3cp7ajPkahgwSmUNj21sKZbCRqmmq5F0h+8o X-Received: by 2002:a17:906:a38d:: with SMTP id k13mr60163ejz.213.1572646650320; Fri, 01 Nov 2019 15:17:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572646650; cv=none; d=google.com; s=arc-20160816; b=h+3LZxbfIwC+ikxF3hZSezC4FtBfFJu9UGcuwb3fIsrwwxBIjYY/+szAEg15fDMCHG YFEQSmhOcI6XFM11EHzkOqWqXDqhEqBOnLyLYtg5e2lQzfLUNpRfyKHebBRl0GvaWDCf y0XXAvub+u+XP5tDXg8HnMFAT33ur9q6/yQP8HDGvowJxVqJ1Fv4Cy+qFL969zLZOQPk AOVOjZMIyBmylOrT+Unyww1P+4DjSgJPltRkw7+piLDd2zJZdlGwPbkh7uSQMBcQNbme 3PGgWFMwgf4HCPhq+XPuQ6eD7LgRhh8h8/CAUshn6WFa5QTmPA8bWo1C/AJ6wuoGJC7m jUbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=QvyUOnCPDzDncgYUYYWR7jovyh1VoufcneVERJJM/xk=; b=KCahOBtIekvKQ73BLY1T2S75eGTFf9MloN+bq4eqNvrnCPlgGpRumD6n5//+Ltu21U tyeDC4+4YFVI1nEj4wSNnAdhpt186omaS3ImDbJeSWS1GR0VyP2WoLqrFFkVx/DE4jIT O6lmaoAP2HvOpIU9RWCkQBSBo7a+fTVM4OASRS39DHldtMyxWCf0k2C0eREnXcfQR5dz /l4meV4lfrEA44uGp2Bc3X3S7xsbOlPK/xK+a5FLxE09WABLSH1ljDc/QJ+aKY+c2TvE Ys6BCNXy2bw056gUvhLMW3sWWp7BQIM5fYOVsRp1fkf5Kdy3PcvvPmSdEfyiLioequuW JCnQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Np9oSpVB; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l8si6939006ejr.125.2019.11.01.15.17.07; Fri, 01 Nov 2019 15:17:30 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Np9oSpVB; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726986AbfKAWOY (ORCPT + 99 others); Fri, 1 Nov 2019 18:14:24 -0400 Received: from mail-ed1-f67.google.com ([209.85.208.67]:33254 "EHLO mail-ed1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725989AbfKAWOY (ORCPT ); Fri, 1 Nov 2019 18:14:24 -0400 Received: by mail-ed1-f67.google.com with SMTP id c4so8650681edl.0 for ; Fri, 01 Nov 2019 15:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=QvyUOnCPDzDncgYUYYWR7jovyh1VoufcneVERJJM/xk=; b=Np9oSpVBax/Jy6y6l7TV2WU11Y6jOVq1AVCCZwGRV9Jn7chNfW54O9xi7EIr5LhD8V Z4EtYwCqcbrWE+owXXFWuvfSrmF3Lrv1rK0K/S8q3sUusmfPn4+giBuYsuQ6qcyNnsYH gliZpctGD2F85ionOIZ5H9m1BIB6xZT8V5xklP6MhXhRwOnhO+7UPUOQL+9tbPz+vJK2 B7jJjBZ5qkM7VggrsKhifmRbaMi84i9hJcSi2FFnxZoXl+oy++ISJIa2fhgXpGjagOpX kWbEA7vRUjSybnZNbNHgNuiZSZqg+s1VXRRkHQfoCVbMeu1/1YMSz99u6aW14zhzD413 rQyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=QvyUOnCPDzDncgYUYYWR7jovyh1VoufcneVERJJM/xk=; b=E7w67Z5/CkY6sJjVVt8HvelB42YVUsvAz9DYHzUPfa9L3aCc+Wtt0Gl3knvtNgMP+Y bws9FL1h5bxrVpe9NzQ2eTybzb9U82mTsEOr4lhz8lJdkowHKrDMJWU4AAnFMg4iKVQ3 en1PXAcIlSC+urt8jg6vu2RywOEJz+Q9YBvFbNg/yxf6XlpAhhpkWviVPRs2ga8fG8Ay 0Cc8DP+MR4n97egGD937hLE1J4mFKt0TJzo5CYHHYA0mIkr1EJp7SdOBdPq/6dRoS/gY lK2LsEgx2NR7Bc9yTah/yTpOy/IgRHFgpEWktKZllJ/QT6SLWC9T80Gz3/TXMNXEAniO 0F1Q== X-Gm-Message-State: APjAAAUrGdHdLC6ZahVfPgMRrt0MD5wPxQ1HHK4Mu86n4RM+L5O0KcZG mc1SqJKwXtY80EkNz+KrcJiD4oW0ISihlnTEXm8= X-Received: by 2002:a17:906:e212:: with SMTP id gf18mr12222737ejb.90.1572646460987; Fri, 01 Nov 2019 15:14:20 -0700 (PDT) MIME-Version: 1.0 References: <20191101180713.5470-1-robdclark@gmail.com> <20191101180713.5470-2-robdclark@gmail.com> <20191101192458.GI1208@intel.com> <20191101214431.GJ1208@intel.com> In-Reply-To: <20191101214431.GJ1208@intel.com> From: Rob Clark Date: Fri, 1 Nov 2019 15:14:09 -0700 Message-ID: Subject: Re: [PATCH 2/2] drm/atomic: clear new_state pointers at hw_done To: =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= Cc: Rob Clark , dri-devel , David Airlie , open list , Sean Paul , Sean Paul Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 1, 2019 at 2:44 PM Ville Syrj=C3=A4l=C3=A4 wrote: > > On Fri, Nov 01, 2019 at 12:49:02PM -0700, Rob Clark wrote: > > On Fri, Nov 1, 2019 at 12:25 PM Ville Syrj=C3=A4l=C3=A4 > > wrote: > > > > > > On Fri, Nov 01, 2019 at 11:07:13AM -0700, Rob Clark wrote: > > > > From: Rob Clark > > > > > > > > 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 > > > > --- > > > > 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 thi= s > > > > + * restriction explicit. > > > > + * > > > > + * For the CRTC state, we do this in the same loop where we s= ignal > > > > + * 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 =3D NULL; > > > > + } > > > > + > > > > + for_each_oldnew_plane_in_state(old_state, plane, old_plane_st= ate, new_plane_state, i) { > > > > + old_state->planes[i].new_state =3D 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 =3D 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 =3D new_c= rtc_state->self_refresh_active; > > > > + old_state->crtcs[i].new_state =3D 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 i= s > > > 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. > I guess it comes down to what assumptions you can make in driver backend. But if you can, for example, move planes between crtcs, I think you can't make assumptions about the order in which things complete even if you don't have commits overtaking each other on a single crtc.. BR, -R