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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 8C41AEA8114 for ; Tue, 10 Feb 2026 13:34:32 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id EFEBE10E0D0; Tue, 10 Feb 2026 13:34:31 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.b="NXZEZ2Ef"; dkim-atps=neutral Received: from mail-ej1-f74.google.com (mail-ej1-f74.google.com [209.85.218.74]) by gabe.freedesktop.org (Postfix) with ESMTPS id 40CCC10E0D0 for ; Tue, 10 Feb 2026 13:34:31 +0000 (UTC) Received: by mail-ej1-f74.google.com with SMTP id a640c23a62f3a-b8718916c9aso89564066b.0 for ; Tue, 10 Feb 2026 05:34:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1770730470; x=1771335270; darn=lists.freedesktop.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=8/H7jmw8ZJJGOF6KNSe5xcMTZ4QJmclAwWnwXYIlcAk=; b=NXZEZ2EffLug06LUbvDniU9D6pw1IpztzjSJPuGGD44SUYgj2aFyVpBwD76yN//p3e xv5ZuGudwzMtxho/8lL4L0BksCd7uw6yeRsM3tVfINKR7GzkBq8H5FQDmLbboOctAzZF pqAdZI/qKkwdWgJNQZxmyOhO210EJ4lW0ZT8TpGrqu1zkA4fE23xBZWCp/Tv3xgh8nBh KceLJXL1Pjx8ERv1skOzBm8UcB5KoNBUnGD81q9HXap7kCXa48vNeXa1XtrzP55Sq66a 71zUz5wUZQuh8V1vdEwwmxcEq+XX0jEVoe+YE2bt8YbJnW8aVDMxD/rFlyj8y1gpeqK5 WRdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770730470; x=1771335270; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8/H7jmw8ZJJGOF6KNSe5xcMTZ4QJmclAwWnwXYIlcAk=; b=s+Qdlu5w8xW0yPx1x3F166bkncQPRrYB3zOURQlVzI+paVb7Sy3cFeK6U+Wns3JmHr mNdsyfukY0IHCMHLgdS0WztkrDH2h5c4xoIfUxEd+Q82ucP9QKLSZS50zjxREUZityFT oAwYIjv+RsubZzAjSmA81DoVhzHV63nLRfY7Ec20+iCYnIRSg5OGD/tlqKQ2jxmgQtvl LVAvoxBKlrg53DQSWNCMKusnyYJcKgbgFn/rzTc6sTUOOZrNb6H1o8kZQZUoAcgiYiIP 35paRZYY6bZUwwCJybQwPUUGQGpgKVSv9WBuRLNZB8RQPUQjrgoCRu4Qdb+8Kn6Ll3Qt 9tPQ== X-Forwarded-Encrypted: i=1; AJvYcCUQVxGDnYJTqCa3HhXiP78WIP0HCn93vFhQUdOvTpMFIdW+kN3I+Lhg2N6IH2X6fxqQ9wK28sNi6m4=@lists.freedesktop.org X-Gm-Message-State: AOJu0YyFhe/VtqyeYOg3yE1Ht3X9P+gTQn4acTgt9agIpl0so+cQOgfP M/2mWQ+3hExF7nMlPtFcpBNgsqpQjW69N2Px/MFzZ1ewiSDv6lEmZGXF4WhNeyJTVDBWPvHdlS5 /UU3ujKtlPmLyIbSFKw== X-Received: from ejbr12.prod.google.com ([2002:a17:906:364c:b0:b88:38ff:1869]) (user=aliceryhl job=prod-delivery.src-stubby-dispatcher) by 2002:a17:906:9f85:b0:b8e:4790:d7c7 with SMTP id a640c23a62f3a-b8edf175f83mr881079766b.6.1770730469653; Tue, 10 Feb 2026 05:34:29 -0800 (PST) Date: Tue, 10 Feb 2026 13:34:28 +0000 In-Reply-To: <20260210132147.4d5a491b@fedora> Mime-Version: 1.0 References: <20260209155843.725dcfe1@fedora> <20260210101525.7fb85f25@fedora> <20260210123432.588a20f5@fedora> <20260210132147.4d5a491b@fedora> Message-ID: Subject: Re: [RFC PATCH 2/4] rust: sync: Add dma_fence abstractions From: Alice Ryhl To: Boris Brezillon Cc: "Christian =?utf-8?B?S8O2bmln?=" , Philipp Stanner , 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 Content-Type: text/plain; charset="utf-8" X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Tue, Feb 10, 2026 at 01:21:47PM +0100, Boris Brezillon wrote: > On Tue, 10 Feb 2026 11:45:36 +0000 > Alice Ryhl wrote: > > > On Tue, Feb 10, 2026 at 12:34:32PM +0100, Boris Brezillon wrote: > > > On Tue, 10 Feb 2026 10:15:04 +0000 > > > Alice Ryhl wrote: > > > > > > > impl MustBeSignalled<'_> { > > > > /// Drivers generally should not use this one. > > > > fn i_promise_it_will_be_signalled(self) -> WillBeSignalled { ... } > > > > > > > > /// One way to ensure the fence has been signalled is to signal it. > > > > fn signal_fence(self) -> WillBeSignalled { > > > > self.fence.signal(); > > > > self.i_promise_it_will_be_signalled() > > > > } > > > > > > > > /// Another way to ensure the fence will be signalled is to spawn a > > > > /// workqueue item that promises to signal it. > > > > fn transfer_to_wq( > > > > self, > > > > wq: &Workqueue, > > > > item: impl DmaFenceWorkItem, > > > > ) -> WillBeSignalled { > > > > // briefly obtain the lock class of the wq to indicate to > > > > // lockdep that the signalling path "blocks" on arbitrary jobs > > > > // from this wq completing > > > > bindings::lock_acquire(&wq->key); > > > > bindings::lock_release(&wq->key); > > > > > > Sorry, I'm still trying to connect the dots here. I get that the intent > > > is to ensure the pseudo-lock ordering is always: > > > > > > -> dma_fence_lockdep_map > > > -> wq->lockdep_map > > > > > > but how can this order be the same in the WorkItem execution path? My > > > interpretation of process_one_work() makes me think we'll end up with > > > > > > -> wq->lockdep_map > > > -> work->run() > > > -> WorkItem::run() > > > -> dma_fence_lockdep_map > > > -> DmaFenceSignalingWorkItem::run() > > > ... > > > > > > Am I missing something? Is there a way you can insert the > > > dma_fence_lockdep_map acquisition before the wq->lockdep_map one in the > > > execution path? > > > > Conceptually, the dma_fence_lockdep_map is already taken by the time you > > get to WorkItem::run() because it was taken all the way back in the > > ioctl, so WorkItem::run() does not need to reacquire it. > > > > Now, of course that does not translate cleanly to how lockdep does > > things, so in lockdep we do have to re-acquire it in WorkItem::run(). > > You can do that by setting the trylock bit when calling lock_acquire() > > on dma_fence_lockdep_map. This has the correct semantics because trylock > > does not create an edge from wq->lockdep_map to dma_fence_lockdep_map. > > Ah, I never noticed dma_fence_begin_signalling() was recording a > try_lock not a regular lock. I guess it would do then. Calling dma_fence_begin_signalling() never blocks so 'trylock' is the right option. Actually, that raises one question for me. Right now it's implemented like this: /* explicitly nesting ... */ if (lock_is_held_type(&dma_fence_lockdep_map, 1)) return true; /* ... and non-recursive successful read_trylock */ lock_acquire(&dma_fence_lockdep_map, 0, 1, 1, 1, NULL, _RET_IP_); but why not drop the explicit nest check and pass `2` for read instead? lock_acquire(&dma_fence_lockdep_map, 0, 1, 2, 1, NULL, _RET_IP_); Note that passing 2 means that you're taking a readlock with same-instance recursion allowed. This way you could get rid of the cookie entirely because you're just taking the lock multiple times, and lockdep will count how many times it's taken for you. Alice