On Mon, Jun 13, 2016 at 7:37 PM, Christian König <deathsimple@xxxxxxxxxxx> wrote: > Am 13.06.2016 um 18:33 schrieb Daniel Vetter: >> >> On Mon, Jun 13, 2016 at 04:12:43PM +0200, Christian König wrote: >>> >>> From: Christian König <christian.koenig@xxxxxxx> >>> >>> A regular spin_lock/unlock should do here as well. >>> >>> Signed-off-by: Christian König <christian.koenig@xxxxxxx> >> >> Just drive-by comment, but you can't mix up irq spinlocks with normal >> ones. And there's places where this is still irqsave, but some of these >> functions can be called directly from the scheduler kthread. You can only >> drop the _irqsave if you know you're always called from hardirq context >> (softirq isn't enough), or when you know someone already disabled >> interrupts. And you can simplify the _irqsave to just _irq when you are in >> always in process context and irqs are always still enabled. >> >> On a super-quick look seems fishy. > > > The point is there isn't even any IRQ involved in all of this. > > The spin is either locked from a work item or the kthread, never from irq > context. In that case git grep job_list_lock finds more of those in sched_fence.c. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
