From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792661220; b=WDk49icU9DriWz7bg6pWlNJ/N78uaBpxUJDHOKc/sbjhXQ+2t1OFVYbinICECDKGAwFJ odji+MuyWg/n67sHwfX6UC5DCAqpaeJ72bcfwomdQ8I0if+NKSZIpK9s6a5ShFABb/xmH Z59lIHZye3NRCnLjw68dql4QPF84Tdpelb1c3S34KS8sBxVZVxaMQrUZcNo9JjmSllrXz +v/VaBRndYM3cRzqO2S7rNC18zlvXQMUWvaW/E7Ubdn0Dw4joFVsKfW6t9Bktg2nHDjZr p8fPIrrMHjmq++TRX7btZgJIdaKc5XDTEczi9k7YfhsZISMEXmjK3kM8MwVH3CWNC/w== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792661220; h=Received:DKIM-Signature:Mime-Version:Content-Transfer-Encoding: Content-Type:Date:Message-Id:From:Subject:Cc:To:References: In-Reply-To; bh=ZmPB/v9tM4KF5zLghO8YC3xqrkWiPWbC0/Vuu64P2zc=; b=UU7EjTGi/OPxRtHU1ywTu1I1cvcYyRGmNcwgcJQJ60R6GBGYtV05pl5KhT1TJzRw3Z7f p6oNLWBgcDdP0jx4US0yMGzN5e7utM/DTMK7uobcguNNWtae65INyjmXjPHqvd/6S39lg WC63DQH82UmH2vnmlfqLtcfi+hRiooWuO2ev1skiXb0KIX+xd7s1SFs8zsCP69Fma/xXs sziQ2D1cNt08K4jzPpczHYA429dw6XOJSAkj04nWX1Uv20ZdV7OWcO2W0/np5CLqHSij4 qku3xYFENw2434uCj3lkg9nQnpnIZDgMfsaGqDsl8qZRvrQEy4Gmgfyw/uS6MPKRk4w== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=gAULB+Wz; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CD7AC606A31A for ; Thu, 22 Oct 2026 09:26:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=gAULB+Wz Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2F4741F000C1; Thu, 22 Oct 2026 09:26:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792661219; bh=ZmPB/v9tM4KF5zLghO8YC3xqrkWiPWbC0/Vuu64P2zc=; h=Date:From:Subject:Cc:To:References:In-Reply-To; b=gAULB+WzMFf2g6TfXl9xO1Ups/0MyP52OxVeJrz/JE9VEPyNqF63NcriZwfEx8bQg 4oFm2itv3EwCPwOZDHDKipyMAAHEA27oTbiadgFk7lnbttx5KN2GbIZ3jDBe1hluKb mHWY5x0JFN2U/uF6doUay4fdXnqKqu4YkYyh/jxezi0VMjScVbWQ6WKVph6Uw8TanI StCxRzcPMoPonsvWyK+uLSCMu7hu3zfmbV736BWsA+qfX0LDqegn1rsbbOpeh8+3Hf 1YRI9gK6cX+uLNtRSSwS5uFqEBd4G6r/dAJOeiSVF0Wnl3oMOAnTaGrV79s/F0AFzF pfJfoR+SJ3u1A== X-Mailing-List: linux-arm-msm@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 22 Oct 2026 11:26:51 +0200 Message-Id: From: "Danilo Krummrich" Subject: Re: [PATCH v3 7/8] drm/nouveau: use DRM_GPUVM_RESV_PROTECTED Cc: , , , , "Abhinav Kumar" , "Alice Ryhl" , "Anna Maniscalco" , "Antonino Maniscalco" , "Boris Brezillon" , "David Airlie" , "Dmitry Baryshkov" , "Jessica Zhang" , "Jonathan Corbet" , "Liviu Dudau" , "Lyude Paul" , "Maarten Lankhorst" , "Marijn Suijten" , "Maxime Ripard" , "Randy Dunlap" , "Rob Clark" , "Rodrigo Vivi" , "Sean Paul" , "Shuah Khan" , "Simona Vetter" , "Steven Price" , =?utf-8?q?Thomas_Hellstr=C3=B6m?= , "Thomas Zimmermann" To: "Matthew Brost" References: <20261001220632.3190896-1-matthew.brost@intel.com> <20261001220632.3190896-8-matthew.brost@intel.com> In-Reply-To: On Sun Oct 18, 2026 at 3:32 AM CEST, Matthew Brost wrote: > On Sat, Oct 17, 2026 at 06:02:26PM -0700, Matthew Brost wrote: >> On Sat, Oct 17, 2026 at 11:31:06PM +0200, Danilo Krummrich wrote: >> > On Fri Oct 2, 2026 at 12:06 AM CEST, Matthew Brost wrote: >> > > @@ -1187,6 +1187,27 @@ bind_validate_region(struct nouveau_job *job) >> > > return 0; >> > > } >> > > =20 >> > > +/* >> > > + * Lock the VM's common dma-resv together with the one of @obj, as = needed to >> > > + * drop what may be the last reference of a &drm_gpuvm_bo. >> > > + */ >> > > +static void >> > > +nouveau_uvmm_lock_vm_and_obj(struct nouveau_uvmm *uvmm, struct drm_= exec *exec, >> > > + struct drm_gem_object *obj) >> > > +{ >> > > + int ret; >> > > + >> > > + drm_exec_init(exec, DRM_EXEC_IGNORE_DUPLICATES, 2); >> > > + drm_exec_until_all_locked(exec) { >> > > + ret =3D drm_exec_lock_obj(exec, drm_gpuvm_resv_obj(&uvmm->base)); >> > > + if (!ret) >> > > + ret =3D drm_exec_lock_obj(exec, obj); >> >=20 >> > What happens if we reach this with ENOMEM? In such a case we may retur= n without >>=20 >> Right, valid issue. Sashiko flagged this too. >>=20 >> Originally, I thought we would need to open-code the WW transaction, but >> instead I ended up fixing drm_exec [1]. >>=20 >> So I think we should merge [1] and run the MSM and Nouveau work in a >> no-failure mode. >>=20 >> One thing I'd add is an assert(!ret) if Nouveau has support for that >> (see xe_assert.h for what we do in Xe so our CI can catch things we >> believe are impossible). I suppose the open-coded version would be a >> WARN_ON() or WARN_ON_ONCE(). >>=20 >> Also likey a BUILD_BUG_ON(2 <=3D DRM_EXEC_INLINE_OBJECTS). >>=20 > > Ugh, logic inversion. > > Rather: > > BUILD_BUG_ON(2 > DRM_EXEC_INLINE_OBJECTS) > > Matt > >> Let me know if you want me to respin with these changes. That'd be great, thanks! Please prefer BUILD_BUG_ON(), I'd like to avoid the need for any WARN_ON() = in this code path. >>=20 >> Matt=20 >>=20 >> [1] https://patchwork.freedesktop.org/series/175390/ >>=20 >> > any locks being held and nouveau would just continue calling into func= tion that >> > expect locks to be held and hence produced UB, right? >> >=20 >> > (I think there is a similar case in MSM, but it was pre-existing, so I= picked all >> > other patches.) >> >=20 >> > > + drm_exec_retry_on_contention(exec); >> > > + if (drm_WARN_ON(uvmm->base.drm, ret)) >> > > + break; >> > > + } >> > > +}