From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 BDB3E30E82C; Mon, 8 Jun 2026 17:59:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780941587; cv=none; b=ZI1YSRuPBVZI8VpmM/8MrbX2Ex7coZhY5xHtUDQyVN8JCM2sSBbOkXbIkmI26YV0I1AsaO4cg1nQ6Esb/jJZ+gYw/YlWpj+HWmf4tkPOemQ+dSChqrQL/np+elBDPicpgWHjhZhkhOAzSNs9EEp6pr0Q9wtlU9QzBFroPy0Zaqk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780941587; c=relaxed/simple; bh=q2JqATLztu+mIBVuhWa8EiLN1hz2Egk+EZOysl2E1h4=; h=Mime-Version:Content-Type:Date:Message-Id:To:From:Subject:Cc: References:In-Reply-To; b=BsGpLDKu03Ruk0JRdAcLjuwFPJF71gmauyCcAlFrtkzvSoJXw2nZrZvkm2eiClZftHE2AwNXLkB9KAf730lHMoDjYl46LabWdWdattM9yz6AMyjhvVWhtm/SOwp/hQOwBvi244Rb8f91eZOQ7A4GnkR8w36F7wLCftzA9hO3Q4M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kUHCV6/e; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kUHCV6/e" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 637D81F00893; Mon, 8 Jun 2026 17:59:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780941586; bh=q2JqATLztu+mIBVuhWa8EiLN1hz2Egk+EZOysl2E1h4=; h=Date:To:From:Subject:Cc:References:In-Reply-To; b=kUHCV6/ezHm16sVuomaCS9gJrTOweRjwt3q9+UtmWmTxStpGTivrtB1eWFoPeGTRi Rt1rYLWtTlbygc6r7E1o3j234o8PH7MkGBgbgDrmb3oMAWu57Xq+WFIXYJFoGCXoHz VG120l533CGIe9Tkjbe4fVAGbgJvzkL1Qt+LyOR+ZMdECbY9d39OTW+ylMga4MxFSD uaUXJq43RAMak/XdyjRKHviGfGTs5m1vA4QyIffN3ZFbGQJj+e98O+u4y2LZoSS2Vq DCjTk+LOp3hVUTmJdiV0VL7NqiQmGRZORKd1d4EHF75sMs3UTPKN6PMViSfZpfdKjj KCZTTCkCOaOPg== Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 08 Jun 2026 19:59:42 +0200 Message-Id: To: =?utf-8?q?Christian_K=C3=B6nig?= From: "Danilo Krummrich" Subject: Re: [RFC PATCH] dma-fence: Fix races of fence callbacks versus destructors by locking Cc: , "Sumit Semwal" , "Boris Brezillon" , "Alice Ryhl" , "Daniel Almeida" , "Gary Guo" , "Tvrtko Ursulin" , , , References: <20260608142436.265820-2-phasta@kernel.org> <95f4ae6b-9dec-4122-84e0-fbb0cdee9cb5@amd.com> <9d49c901-fcdf-487a-a733-0320d0bdf94c@amd.com> In-Reply-To: <9d49c901-fcdf-487a-a733-0320d0bdf94c@amd.com> On Mon Jun 8, 2026 at 7:34 PM CEST, Christian K=C3=B6nig wrote: > That's why we need the RCU grace period to make sure that nobody is > referencing the driver stuff any more. Right, and that's what Philipp tries to address, the requirement to wait fo= r an RCU grace period is perfectly fine if it is only about freeing memory, but = it can become painful if the fence private data contains data also needs to be destructed in some way. IOW, if a driver signals a fence, it is lifecycle-wise reasonable to destru= ct the private data that is no longer needed (remaining users only deal with s= truct dma_fence) and having to wait for a full grace period adds sublety and complication that can be avoided with the proposed approach. That said, I'd like to ask the opposite question: What are the concerns wit= h the proposed approach over (pure) RCU?