linux-kernel - Re: [PATCH v2 2/8] dma-buf/dma-fence: Add dma_fence_check_and

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d7956d8e8401f7dd9951d93752a74d2f8f660830.camel@mailbox.org>
Date: Tue, 02 Dec 2025 10:19:09 +0100
From: Philipp Stanner <phasta@...lbox.org>
To: Christian König <christian.koenig@....com>, 
 phasta@...nel.org, Sumit Semwal <sumit.semwal@...aro.org>, Gustavo Padovan
 <gustavo@...ovan.org>, Felix Kuehling <Felix.Kuehling@....com>, Alex
 Deucher <alexander.deucher@....com>, David Airlie <airlied@...il.com>,
 Simona Vetter <simona@...ll.ch>, Jani Nikula <jani.nikula@...ux.intel.com>,
 Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>, Rodrigo Vivi
 <rodrigo.vivi@...el.com>,  Tvrtko Ursulin <tursulin@...ulin.net>, Huang Rui
 <ray.huang@....com>, Matthew Auld <matthew.auld@...el.com>,  Matthew Brost
 <matthew.brost@...el.com>, Maarten Lankhorst
 <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>,
 Thomas Zimmermann <tzimmermann@...e.de>, Lucas De Marchi
 <lucas.demarchi@...el.com>, Thomas Hellström
 <thomas.hellstrom@...ux.intel.com>
Cc: linux-media@...r.kernel.org, dri-devel@...ts.freedesktop.org, 
	linux-kernel@...r.kernel.org, amd-gfx@...ts.freedesktop.org, 
	intel-gfx@...ts.freedesktop.org, intel-xe@...ts.freedesktop.org
Subject: Re: [PATCH v2 2/8] dma-buf/dma-fence: Add
 dma_fence_check_and_signal()

On Mon, 2025-12-01 at 17:08 +0100, Christian König wrote:
> On 12/1/25 16:53, Philipp Stanner wrote:
> > On Mon, 2025-12-01 at 16:20 +0100, Christian König wrote:
> > > On 12/1/25 14:55, Philipp Stanner wrote:
> > > > On Mon, 2025-12-01 at 14:23 +0100, Christian König wrote:
> > > > > On 12/1/25 11:50, Philipp Stanner wrote:
> > > > > > The overwhelming majority of users of dma_fence signaling functions
> > > > > > don't care about whether the fence had already been signaled by someone
> > > > > > 
> > > > 
> > 
> > […]
> > 
> > > > > 
> > > > > > +{
> > > > > > +	unsigned long flags;
> > > > > > +	bool ret;
> > > > > > +
> > > > > > +	spin_lock_irqsave(fence->lock, flags);
> > > > > > +	ret = dma_fence_check_and_signal_locked(fence);
> > > > > > +	spin_unlock_irqrestore(fence->lock, flags);
> > > > > 
> > > > > Could this use guard(fence->lock, flags) ?
> > > > 
> > > > guard? You mean a lockdep guard? Do you have a pointer to someplace in
> > > > dma_fence who does what you mean / want?
> > > 
> > > E.g. like guard(spinlock_irqsave)(&fence->lock);
> > 
> > 
> > Hmm, but why?
> > It's obvious to all readers that I do spin_unlock_irqrestore() here.
> > It's very simple code, lock, 1 line, unlock. What would the guard
> > improve?
> 
> Well you can save using the local variables.
> 
> So this:
> 
> 	unsigned long flags;
> 	bool ret;
> 
> 	spin_lock_irqsave(fence->lock, flags);
> 	ret = dma_fence_check_and_signal_locked(fence);
> 	spin_unlock_irqrestore(fence->lock, flags);
> 
> 	return ret;
> 
> Becomes just:
> 
> 	guard(spinlock_irqsave)(&fence->lock);
> 	return dma_fence_check_and_signal_locked(fence);

Mhm, I guess I agree that __cleanup is a cool new feature that can be
useful at many places. But in this case I think it's actually less
readable and doesn't really give lots of advantages. And don't I have
to use a DEFINE_GUARD or DEFINE_FREE in the first place?

If it's your maintainer preference, I can look into that though..

P.