From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org [80.241.56.151]) (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 E94343CC31A; Mon, 8 Jun 2026 15:31:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.241.56.151 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780932668; cv=none; b=NToAum91m75p9xI6oHHTbKC4oBgAeUyacL4ohTrdklMJpmgLf1OPpt5m79BbwQxTAjjCOUXBepPE38R2NmZrc0s7hQG8pzWGWZcDXJ+FMoepCG/sBPhsZrrI7/slg8vTaMfO61u9gDxRc8qRz55HobfCrHbIyPVo7cmEJVsR3yY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780932668; c=relaxed/simple; bh=3Ao1Wm5PqdN/lgeuaIxzpYEmwYvieq0bEQkDXHd6KJE=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=M4PrFBFsWt6FSRBVbDWXgUw3RfB6UTCmplprWKrA9qZ6V/rX70ld+HXflrk/cKsxcWTGPW6wRbiV7SHg2JAw1SSDVQXjgfXpLy8c7pifa2lfY3PtNbSqsdJ4IcPtXFUiHrek4ZU04RCc0jJT6g05XcYc5gRfZukAuQVMWnSoAh0= 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=eOqVfl0Y; arc=none smtp.client-ip=80.241.56.151 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="eOqVfl0Y" Received: from smtp1.mailbox.org (smtp1.mailbox.org [10.196.197.1]) (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-101.mailbox.org (Postfix) with ESMTPS id 4gYwx151nsz9tSP; Mon, 8 Jun 2026 17:31:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1780932661; 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=wn7yLxLm8kmCdN7adnHk3oLnLkZt7t/zPoim3PIkgr0=; b=eOqVfl0YD2dNt7u6nIK03/7OdlTIHMnSU1dWs33nGjnD/qHnPtne5qwyK4k0w4v4fs6Uhp pjoP1fyR3l6yMmI70LyoZkRMjFn4hiW1tkknL0QicSvCKcGsQYZr7YRYW4Lm/dasu/jJTI 42L58/aGXdROgytemZAS3jt7YS3PcmW0ClR3l6tYTU1dtrUm6rXPbCO1EUqNGVoasFqZ6w 4ZFqlyiXqvwGMutSAgl7iB/Kxwhl1mDWG49zVAxoAdOkEQNdG7rIwvvXYGqhm+7lixkFH6 MeUe8Y4khaNJzVrQ9Bg2d2nGtPM3G3gzHrNJGNaCBjCdnt8DgWA9tPBCx6xKFA== Message-ID: <256dc5ae3529e2548c4151af34a540476ac928c1.camel@mailbox.org> Subject: Re: [RFC PATCH] dma-fence: Fix races of fence callbacks versus destructors by locking From: Philipp Stanner Reply-To: phasta@kernel.org To: Danilo Krummrich Cc: phasta@kernel.org, Boris Brezillon , Sumit Semwal , Christian =?ISO-8859-1?Q?K=F6nig?= , Alice Ryhl , Daniel Almeida , Gary Guo , Tvrtko Ursulin , linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Date: Mon, 08 Jun 2026 17:30:58 +0200 In-Reply-To: References: <20260608142436.265820-2-phasta@kernel.org> <20260608170112.24fd92df@fedora-2.home> <6bdbdb6541392c6ea58e0035f0b20ac3c8f3e54e.camel@mailbox.org> 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: 728debd615e70e6d046 X-MBO-RS-META: q9xpqdt4tjm3ihj87tj9qjpfrc5uhntn On Mon, 2026-06-08 at 17:23 +0200, Danilo Krummrich wrote: > On Mon Jun 8, 2026 at 5:17 PM CEST, Philipp Stanner wrote: > > On Mon, 2026-06-08 at 17:01 +0200, Boris Brezillon wrote: > > > On Mon,=C2=A0 8 Jun 2026 16:24:37 +0200 > > > Philipp Stanner wrote: > > >=20 > > > > @@ -1020,11 +1024,20 @@ EXPORT_SYMBOL(dma_fence_wait_any_timeout); > > > > =C2=A0void dma_fence_set_deadline(struct dma_fence *fence, ktime_t = deadline) > > > > =C2=A0{ > > > > =C2=A0 const struct dma_fence_ops *ops; > > > > + unsigned long flags; > > > > =C2=A0 > > > > =C2=A0 rcu_read_lock(); > > > > =C2=A0 ops =3D rcu_dereference(fence->ops); > > > > - if (ops && ops->set_deadline && !dma_fence_is_signaled(fence)) > > > > + if (!ops || !ops->set_deadline) { > > > > + rcu_read_unlock(); > > > > + return; > > > > + } > > > > + > > > > + dma_fence_lock_irqsave(fence, flags); > > > > + if (!dma_fence_is_signaled_locked(fence)) > > > > =C2=A0 ops->set_deadline(fence, deadline); > > >=20 > > > You can't take the fence lock around ->set_deadline(), otherwise you'= ll > > > deadlock here [1] or here [2]. > > >=20 > > > > + > > > > + dma_fence_unlock_irqrestore(fence, flags); > > > > =C2=A0 rcu_read_unlock(); > > > > =C2=A0} > > >=20 > > >=20 > > > [1]https://elixir.bootlin.com/linux/v7.0.11/source/drivers/dma-buf/sw= _sync.c#L182 > > > [2]https://elixir.bootlin.com/linux/v7.0.11/source/drivers/gpu/drm/ms= m/msm_fence.c#L139 Oh, MSM actually doesn't btw, that's a false positive. That's a distinct spinlock on their fence context object. But yes, before we could upstream this, we would go through all the implementors like Danilo did, to find all the others. P. > >=20 > >=20 > > If we'd port these (and maybe some we have overlooked) simultaneously, > > they could completely drop their separate locking. > >=20 > > The fact that other parties were forced to take the fence lock in their > > callbacks (and even 100% of the functions' code) actually proves that > > this RFC is probably a good idea and callback-calls should be guarded > > by the fence lock :] >=20 > I think I looked into this recently and IIRC it indeed seems like all > implementors of set_deadline() take the lock within their callback.