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.
