From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout-p-103.mailbox.org (mout-p-103.mailbox.org [80.241.56.161]) (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 580FC1F181F; Tue, 17 Feb 2026 14:04:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.241.56.161 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771337053; cv=none; b=VANutzFAhRJ5/pSSfnUDdkI/zqPZvt497cPJWIT3vs1fdvpzbljRUdxyT8ZAQijSTatZw2kzBilINodj5XDf36+ZsV9XUbyGu/IbZTFy/rjKWO/oNy7V/5gWNkdjtnxYnj3s0V8B27EJt7AkAVddSVU7K1HjEV+qVfqLtq2rK+A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771337053; c=relaxed/simple; bh=ppRD/uPxe+TTRNocgCzCwGOgX3BbHQSLRy7z1y3OVtU=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=k2CLNn2APoP492fNMnJC+/5PgbAaS1Hn82BkwowbY0rJlrZVN9+AePDUlhIBq9MHdx5ic8fK6dPQI/Rb8BYuLOOwA0kjW3PKP5rWLIACRC9z18ft0gp6jH9WOmqYswFk9apv/2mRYqCMjzNl+vQcbtx+QPW9a8O57ZSe6y6u7HQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mailbox.org; spf=pass smtp.mailfrom=mailbox.org; dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org header.b=ImZ3NB8u; arc=none smtp.client-ip=80.241.56.161 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mailbox.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mailbox.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org header.b="ImZ3NB8u" Received: from smtp102.mailbox.org (smtp102.mailbox.org [IPv6:2001:67c:2050:b231:465::102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-103.mailbox.org (Postfix) with ESMTPS id 4fFhFy3H7Gz9ss3; Tue, 17 Feb 2026 15:04:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1771337046; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ppRD/uPxe+TTRNocgCzCwGOgX3BbHQSLRy7z1y3OVtU=; b=ImZ3NB8uC842fnWRwfcSQz9+235VRMXHpI50PJUhqU9C48XkVHWqqnYAAPMgcVdNy1e5a3 Vi8i/MJK6llhGBRp1i/dtz0Vc0qJdiCjJf7dbWKx1xp9Gmr0BFoSHLikg7pKqkNms/H0yS VLSKHTUR+yoe1eiuhW8ML9qX0EBBwsCkbsDspAd/6s0AoagAH9YygcQmWqwDehrYH3eW53 UkCckDZF8BsVaTiLNmB1WmBM7xupGO5k1LXp1TX18bf4/yd9VeHpXCBklNigmFzHFJVH9l S3bA5eqsF0C1NG5bdc3X5Rfl8V02VvpAozXuLaZUyFXVv+Ezt78XBTob2N5Esw== Message-ID: <3d90656315ab0b52f4725ca7c2cd10859d1e4f69.camel@mailbox.org> Subject: Re: [RFC PATCH 2/4] rust: sync: Add dma_fence abstractions From: Philipp Stanner Reply-To: phasta@kernel.org To: Christian =?ISO-8859-1?Q?K=F6nig?= , Alice Ryhl Cc: Boris Brezillon , phasta@kernel.org, Danilo Krummrich , David Airlie , Simona Vetter , Gary Guo , Benno Lossin , Daniel Almeida , Joel Fernandes , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, rust-for-linux@vger.kernel.org Date: Tue, 17 Feb 2026 15:03:57 +0100 In-Reply-To: References: <20260209155843.725dcfe1@fedora> <20260210101525.7fb85f25@fedora> <20260210133617.0a4be958@fedora> <20260210142631.6f8a3411@fedora> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MBO-RS-ID: a39b3d18f28fd9b1e90 X-MBO-RS-META: 3szqqireognodmxtjpexkd4wuwt4jhd1 On Tue, 2026-02-10 at 16:45 +0100, Christian K=C3=B6nig wrote: > On 2/10/26 16:07, Alice Ryhl wrote: > > On Tue, Feb 10, 2026 at 02:56:52PM +0100, Christian K=C3=B6nig wrote: > > > On 2/10/26 14:49, Alice Ryhl wrote: > > > > On Tue, Feb 10, 2026 at 02:26:31PM +0100, Boris Brezillon wrote: > > > > > On Tue, 10 Feb 2026 13:15:31 +0000 > > > > > Alice Ryhl wrote: > > > > >=20 > > > > > > On Tue, Feb 10, 2026 at 01:36:17PM +0100, Boris Brezillon wrote= : > > > > > > > On Tue, 10 Feb 2026 10:15:04 +0000 > > > > > > > Alice Ryhl wrote: > > > > > > > =C2=A0=20 > > > > > > > > impl MustBeSignalled<'_> { > > > > > > > > =C2=A0=C2=A0=C2=A0 /// Drivers generally should not use thi= s one. > > > > > > > > =C2=A0=C2=A0=C2=A0 fn i_promise_it_will_be_signalled(self) = -> WillBeSignalled { ... } > > > > > > > >=20 > > > > > > > > =C2=A0=C2=A0=C2=A0 /// One way to ensure the fence has been= signalled is to signal it. > > > > > > > > =C2=A0=C2=A0=C2=A0 fn signal_fence(self) -> WillBeSignalled= { > > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 self.fence.signa= l(); > > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 self.i_promise_i= t_will_be_signalled() > > > > > > > > =C2=A0=C2=A0=C2=A0 } > > > > > > > >=20 > > > > > > > > =C2=A0=C2=A0=C2=A0 /// Another way to ensure the fence will= be signalled is to spawn a > > > > > > > > =C2=A0=C2=A0=C2=A0 /// workqueue item that promises to sign= al it. > > > > > > > > =C2=A0=C2=A0=C2=A0 fn transfer_to_wq( > > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 self, > > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 wq: &Workqueue, > > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 item: impl DmaFe= nceWorkItem, > > > > > > > > =C2=A0=C2=A0=C2=A0 ) -> WillBeSignalled { > > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // briefly obtai= n the lock class of the wq to indicate to > > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // lockdep that = the signalling path "blocks" on arbitrary jobs > > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // from this wq = completing > > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bindings::lock_a= cquire(&wq->key); > > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bindings::lock_r= elease(&wq->key); > > > > > > > >=20 > > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // enqueue the j= ob > > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 wq.enqueue(item,= wq); > > > > > > > >=20 > > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // The signature= of DmaFenceWorkItem::run() promises to arrange > > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // for it to be = signalled. > > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 self.i_promise_i= t_will_be_signalled() > > > > > > > > =C2=A0=C2=A0=C2=A0 }=C2=A0=20 > > > > > > >=20 > > > > > > > I guess what's still missing is some sort of `transfer_to_hw(= )` > > > > > > > function and way to flag the IRQ handler taking over the fenc= e > > > > > > > signaling token.=C2=A0=20 > > > > > >=20 > > > > > > Yes, transfer to hardware needs to be another piece of logic si= milar to > > > > > > transfer to wq. And I imagine there are many ways such a transf= er to > > > > > > hardware could work. > > > > > >=20 > > > > > > Unless you have a timeout on it, in which case the WillBeSignal= led is > > > > > > satisfied by the fact you have a timeout alone, and the signall= ing that > > > > > > happens from the irq is just an opportunistic signal from outsi= de the > > > > > > dma fence signalling critical path. > > > > >=20 > > > > > Yes and no. If it deadlocks in the completion WorkItem because of > > > > > allocations (or any of the forbidden use cases), I think we want = to > > > > > catch that, because that's a sign fences are likely to end up wit= h > > > > > timeouts when they should have otherwise been signaled properly. > > > > >=20 > > > > > > Well ... unless triggering timeouts can block on GFP_KERNEL > > > > > > allocations... > > > > >=20 > > > > > I mean, the timeout handler should also be considered a DMA-signa= lling > > > > > path, and the same rules should apply to it. > > > >=20 > > > > I guess that's fair. Even with a timeout you want both to be signal= ling > > > > path. > > > >=20 > > > > I guess more generally, if a fence is signalled by mechanism A or B= , > > > > whichever happens first, you have the choice between: > > >=20 > > > That doesn't happen in practice. > > >=20 > > > For each fence you only have one signaling path you need to guarantee > > > forward progress for. > > >=20 > > > All other signaling paths are just opportunistically optimizations > > > which *can* signal the fence, but there is no guarantee that they > > > will. > > >=20 > > > We used to have some exceptions to that, especially around aborting > > > submissions, but those turned out to be a really bad idea as well.=C2= =A0=20 > > >=20 > > > Thinking more about it you should probably enforce that there is only > > > one signaling path for each fence signaling. > >=20 > > I'm not really convinced by this. > >=20 > > First, the timeout path must be a fence signalling path because the > > reason you have a timeout in the first place is because the hw might > > never signal the fence. So if the timeout path deadlocks on a > > kmalloc(GFP_KERNEL) and the hw never comes around to wake you up, boom. >=20 > Mhm, good point. On the other hand the timeout handling should probably b= e considered part of the normal signaling path. Why would anyone want to allocate in a timeout path in the first place =E2= =80=93 especially for jobqueue? Timeout -> close the associated ring. Done. JobQueue will signal the done_fences with -ECANCELED.=20 What would the driver want to allocate in its timeout path, i.e.: timeout c= allback. P.