[Intel-gfx] [PATCH] drm/i915: Convert breadcrumbs spinlock to be irqsafe

Chris Wilson chris at chris-wilson.co.uk
Fri Oct 28 11:26:09 UTC 2016


On Fri, Oct 28, 2016 at 11:49:34AM +0100, Tvrtko Ursulin wrote:
> 
> 
> On 28/10/16 11:42, Chris Wilson wrote:
> >On Fri, Oct 28, 2016 at 11:27:43AM +0100, Tvrtko Ursulin wrote:
> >>
> >>
> >>On 28/10/16 11:10, Chris Wilson wrote:
> >>>On Fri, Oct 28, 2016 at 10:42:22AM +0100, Tvrtko Ursulin wrote:
> >>>>
> >>>>
> >>>>On 27/10/16 17:10, Chris Wilson wrote:
> >>>>>The breadcrumbs are about to be used from within IRQ context sections,
> >>>>>therefore we need to employ the irqsafe spinlock variants.
> >>>>>
> >>>>>(This is split out of the defer global seqno allocation patch due to
> >>>>>realisation that we need a more complete conversion if we want to defer
> >>>>>request submission even further.)
> >>>
> >>>[snip]
> >>>
> >>>>Assuming I got the above right and you agree to change it:
> >>>
> >>>You made me go and reduce them to _bh as appropriate anyway!!!
> >>
> >>Hm, but can't enable signalling be called with irqs disabled when
> >>fences are exported?
> >
> >Yes, but that supercedes the spin_lock_bh, so we can just call
> >spin_lock() in enabling_signaling as we can assert that we will always
> >be called with irqs disabled here (due to spin_lock_irqsafe(fence->lock)
> >in the callpath).
> 
> But as long as the b->lock is taken in the irqs disabled section
> somewhere, other callers like signaller thread, debugfs, etc, cannot
> just take it with _bh.

Lockdep doesn't complain, if we take spin_lock(b->lock) under irq inside our
tasklet (enable_signaling)  so long as we use spin_lock_bh() elsewhere.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the Intel-gfx mailing list