From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E7FF328B3F7; Thu, 22 May 2025 13:50:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747921810; cv=none; b=mh9d0acTk0mJLsai4+++QnAzLvCEjYV0iK0uRstS/v25YrOmqApKJupp/J+mJbaMMk8KW9ttUEirAY593GcC7LKEc+E6Fz9F5Ky+j7xowx18/vFoeBf1hS9bSdk84p3wnyggjrgCl1SiWjDfpi1p2iV+skd4gpV2ByS8mVe6CCY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747921810; c=relaxed/simple; bh=ktheC8UrqvazeBtNepLrvQqF9eDTiWiVXke3rVgh9vk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=EAXmLRrCgZOh30tY97QDADgUq4LNWI2XKZNAa+mdov8Z9i7zGX8lOwHQvPJ42p0qefhNbZGu/N8Q0wTi8DHIRG6PQ1Pl8OYhckwMLKjsBWQ5ExwrfggFaOKEUOE2nISzC87ncU3Yluxylmq339dJaRadls8bKJrrjRYEl9tK4i8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=oCEI14UI; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="oCEI14UI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5B238C4CEE4; Thu, 22 May 2025 13:50:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747921809; bh=ktheC8UrqvazeBtNepLrvQqF9eDTiWiVXke3rVgh9vk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=oCEI14UIkH/IO/X9oU9p5cjgx2Au6n8zDfWPWZeMznx02//mHz1Kd5F5Gm7642Jrt OYhUlzxB2Wf+re6OM3zIj00XcwvAq2elObtX3IwmcIKa/r+bpBoOu651q2jHxzwQQ/ PJq+X6sONf5ygxiibdx8fPHY1/dHdTTjVwsTIfBPdhWxvP2YKZXogSFfDPTxGvA2RA Y3LtLbypAKGmaVDBEqTsFWSZE2NdHu3P7pYplEXSUpWhNeRxcmsnKpT9PG0QqNhn07 3B8lK+Pt0UBbzd6UiEAUYuC8Kfhl726PBJLkn7l0RzTpdqOXMLs9vJfE54RcRLY0/9 9z6otqMAX86oQ== Date: Thu, 22 May 2025 15:50:04 +0200 From: Danilo Krummrich To: Christian =?iso-8859-1?Q?K=F6nig?= Cc: phasta@kernel.org, Lyude Paul , David Airlie , Simona Vetter , Sumit Semwal , dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org Subject: Re: [PATCH 2/2] drm/nouveau: Don't signal when killing the fence context Message-ID: References: <20250522112540.161411-2-phasta@kernel.org> <20250522112540.161411-3-phasta@kernel.org> <06210b9dc5e5ea8365295b77942c3ca030f02729.camel@mailbox.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Thu, May 22, 2025 at 03:05:02PM +0200, Christian König wrote: > E.g. when you don't know the implementation side use the defined API and don't mess with the internals. If you do know the implementation side then it's valid that you check the internals. I assume you meant this as "bothering with the internals of you *own* fence is fine, but not with foreign ones". And if the driver messes with the internals of its own fence code that's fine, but in this case we talk about the generic dma_fence implementation, i.e. an internal flag of the dma_fence implementation. In general, a driver should *never* bother with implementation details of a generic component, regardless whether the author knows the internal details. Things are *always* prone to change and then this may result into subtle bugs.