On Fri, Oct 28, 2016 at 12:26:09PM +0100, Chris Wilson wrote: > 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. The key part is that we never take the spin_lock in irq context, just I am introducing it into softirq context. Hence why, I think, lockdep is happy. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
