On Mon, Jun 13, 2016 at 7:37 PM, Christian König deathsimple@vodafone.de 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@amd.com
A regular spin_lock/unlock should do here as well.
Signed-off-by: Christian König christian.koenig@amd.com
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