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 059A03FFFA7; Tue, 9 Jun 2026 11:39:16 +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=1781005160; cv=none; b=baUzmybH6s8mfHZ5LzF1/Ybdnf5VWwQYDm1/3XUPJCvntrxuuCNnbqSUYGY++k+eQ2mum9of+uNJRSJ6Mea23y4abszCLuKBjPE4M3y7jx5cnWjHvqTMy2Vgb7r+WgfMqF0zCBpxgt2aOMpRTPIeWOiKcqY8LdYTU+TwS7OCRjE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781005160; c=relaxed/simple; bh=G22FCbzMoMSFXLB/+ltVXi9K/ZR8hGAzPX5+k2w2/ds=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=N+lUHEeaoaWCoJt2UqIldE1qvrrbhewdkxEtot+rkKWev7M3RfsFsu989IJTxsUEnyvfJqZ7ppo+ea3ZcfXmDS1ULU/I4tCNCnYCvsEB3g9qgFZXRWM3tQVRWMZKyj/iBGRTqzzfPbPMPtQkPzNzR17rq/1/U70UXNfBhSZnqqY= 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=tk5HlD4L; 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="tk5HlD4L" Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.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-101.mailbox.org (Postfix) with ESMTPS id 4gZRl52q1Fz9tr7; Tue, 9 Jun 2026 13:39:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1781005153; 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=eluLLDgP42hnm6jSqwzWJSIrEMLWAxnFr1RN8X6YAUo=; b=tk5HlD4L9kqxIDcZlFhew/dR8jEsftGQ+wCMkGLdLOrCCkOVQ7Bho2T2WQIaP67moDgwxv 9dm3zNzGOrb8PPnNNBIcoad6erBNpY9vEe5TF9JVbYHvkWunfu6DwBOkPjc09Y54oF5BhM GazDZiH7A9GLSK1KTnQiUTZWNoDO4aXuVtmpY2We1Vw1U85LkZlA2mhqO8QKEGlzxKq1on FuTpHQ1DIwrOiJM7fP58UAcNf/yqXvtGHH94umZXFnxv4YOJ6U7KydRony9llLW6nCKW8j xgj8QwnlCU2QOtSVFMqPh7H6h6RpfhRYr90IhSvl7aI0mU57YJlHya6eTc4oOA== Message-ID: Subject: Re: [RFC PATCH] dma-fence: Fix races of fence callbacks versus destructors by locking From: Philipp Stanner Reply-To: phasta@kernel.org To: Christian =?ISO-8859-1?Q?K=F6nig?= , phasta@kernel.org, Danilo Krummrich Cc: Sumit Semwal , Boris Brezillon , Alice Ryhl , Daniel Almeida , Gary Guo , Tvrtko Ursulin , linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Date: Tue, 09 Jun 2026 13:39:09 +0200 In-Reply-To: <1bb5efeb-a5d3-4d0b-ae69-8dc8620604d4@amd.com> References: <20260608142436.265820-2-phasta@kernel.org> <95f4ae6b-9dec-4122-84e0-fbb0cdee9cb5@amd.com> <9d49c901-fcdf-487a-a733-0320d0bdf94c@amd.com> <74bd33a06b75c291c3e2eda19e0250fbd280c49b.camel@mailbox.org> <66349a9f-d9dd-498b-b118-1c79d3aa3cca@amd.com> <11d7c83185a18d13760b6e77275e97c110dcddcc.camel@mailbox.org> <1bb5efeb-a5d3-4d0b-ae69-8dc8620604d4@amd.com> 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: f42b8e1ecef5c7e0890 X-MBO-RS-META: ef3tzkx4ydxh7gmaugqom6nkt6ostb57 On Tue, 2026-06-09 at 12:53 +0200, Christian K=C3=B6nig wrote: > >=20 > > // driver > > dma_fence_signal(f); // revokes all accesses to our driver through back= end_ops > > // synchronize_rcu() now unnecessary \o/ > > cleanup(f); // We know that all accessors are gone > > dma_fence_put(f); >=20 > Yeah and exactly that doesn't work. >=20 > Just think about the Nouveau case when you have your fences on a double l= inked list. >=20 > When the fence lock is independent, e.g. have a separate lock for each fe= nce then this lock can't protect this double linked list. >=20 > So your cleanup path needs to take a lock which protects the list, but yo= u then run into lock inversion. static bool nouveau_fence_is_signaled(struct dma_fence *f) { struct nouveau_fence *fence =3D to_nouveau_fence(f); struct nouveau_fence_chan *fctx =3D nouveau_fctx(fence); struct nouveau_channel *chan; bool ret =3D false; rcu_read_lock(); chan =3D rcu_dereference(fence->channel); if (chan) ret =3D (int)(fctx->read(chan) - fence->base.seqno) >=3D 0; rcu_read_unlock(); return ret; } AFAICT fctx->read() does not take f->lock. So where is the lock inversion? Again, ideally we can get to the point where no one except for the fence subsystem itself has to take the lock manually anymore. >=20 > > >=20 > > > So you are left with few options: Either the fence lock is external, > > > which we don't want because that make the fence non-independent, or > > > cleanup() defers work to irq_work or work_structs, which creates > > > numerous lifetime issues. > >=20 > > Yup, this is uncool and we want to avoid that. > >=20 > > But these seem to be the options > >=20 > > 1. Ensure proper synchronization > > 2. Wait for a grace period in a hot path > > 3. Defer cleanup() with some delay mechanism > >=20 > > #1 is by far the cleanest approach. I still cannot see any downside, > > and quite a few upsides. > >=20 > > https://elixir.bootlin.com/linux/v7.1-rc6/source/drivers/dma-buf/dma-fe= nce.c#L1025 > >=20 > > ^ is already racing with the signaled check. >=20 > Yeah so what? That is just an opportunistic check.=20 What happens if someone signals the fence while the set_deadline() callback is running? P.