[LITMUS^RT] WARNING: DEBUG_LOCKS_WARN_ON

[Sebastiano Catellani]

Hi everyone,

I'm developing a scheduler that supports a specific resource sharing
protocol. In particular it allows a task, which is waiting for a busy
resource, to dequeue the lock owner from its the ready queue and requeue it
to the waiting task's cpu.

So, under particular conditions, the schedule function performs the dequeue
and the migration:

static void dequeue_and_migrate(int from_cpu, int target_cpu, struct
task_struct* owner)
{
pfp_domain_t *from = remote_pfp(from_cpu);
pfp_domain_t *to = remote_pfp(target_cpu);

 if (get_partition(owner) == target_cpu)
return;

preempt_disable();
 local_irq_disable();

raw_spin_lock(&from->slock);

tsk_rt(owner)->task_params.cpu = target_cpu;
 fp_dequeue(from, owner);

raw_spin_unlock(&from->slock);

raw_spin_lock(&to->slock);

requeue(owner, to);
preempt(to);

raw_spin_unlock(&to->slock);

local_irq_enable();
preempt_enable();
}

When the lock owner releases the resource, it migrates back to the former
cpu. This is performed using the migration function used by DPCP.

At run-time I have this warning:

WARNING: at kernel/sched/core.c:2885 sub_preempt_count+0x9e/0xf0()
DEBUG_LOCKS_WARN_ON(val > preempt_count())
CPU: 2 PID: 1702 Comm: rtspin Not tainted 3.10.5-litmus2013.1 #354
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
 0000000000000009 ffff88001cd27de0 ffffffff8155ae8e ffff88001cd27e18
 ffffffff8102f356 0000000000000001 ffff88001eada160 ffff88001cea0830
 ffff88001eada160 ffff88001fd0fb20 ffff88001cd27e78 ffffffff8102f3f7
Call Trace:
 [<ffffffff8155ae8e>] dump_stack+0x19/0x1b
 [<ffffffff8102f356>] warn_slowpath_common+0x66/0x90
 [<ffffffff8102f3f7>] warn_slowpath_fmt+0x47/0x50
 [<ffffffff8105e5be>] sub_preempt_count+0x9e/0xf0
 [<ffffffff8129ba0d>] pfp_lock+0x49d/0x6b0
 [<ffffffff81293bca>] sys_litmus_lock+0x16a/0x1e0
 [<ffffffff815625d2>] system_call_fastpath+0x16/0x1b
---[ end trace 3c8b462b5826d6f4 ]---

>From the point of view of the tasks, only the first occurrence of the
condition is affected by some problems, otherwise the rest of the execution
is correct. In particular the lock owner, after the unlock event and the
migration back, executes till the deadline instead of till the expiration
of the execution time.

Anyone has any suggestion?

Thanks in advance,

Sebastiano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20140224/5b1ed73a/attachment.html>