Re: [Xenomai-core] [RFC] Fixes for domain migration races

[Jan Kiszka <jan.kiszka@domain.hid>]

On 2011-07-27 20:44, Gilles Chanteperdrix wrote:
> On 07/19/2011 08:44 AM, Jan Kiszka wrote:
>> Hi,
>>
>> I've just uploaded my upstream queue that mostly deals with the various
>> races I found in the domain migration code.
>>
>> One of my concerns raised earlier turned out to be for no reason: We do
>> not allow Linux to wake up a task that has TASK_ATOMICSWITCH set. So the
>> deletion race can indeed be fixed by the patch I sent earlier.
> 
> So, I still have the same question: is not the solution of synchronizing
> with the gatekeeper as soon as we get out from schedule in secondary
> mode better than waiting the task_exit callback? It looks more correct,
> and it avoids gksched.

Yes, I was on the wrong track /wrt wakeup races during the early
migration phase.

It is a possible and valid scenario that the task returns from
schedule() without being migrated. That can only happen if a signal was
queued in the meantime. The task will not be woken up again, that is
prevented by ATOMICSWITCH, but it will check for pending signals itself
before falling asleep. In that case it will enter TASK_RUNNING again and
return either before the gatekeeper could run or, on SMP, may continue
in parallel on a different CPU.

What saves us now from the fatal scenario that both the task runs and
the gatekeeper resumes its Xenomai part is that TASK_INTERRUPTIBLE state
was left. And if we wait for the gatekeeper to realize this like you
suggested, we ensure that neither the object is deleted too early nor
TASK_INTERRUPTIBLE is reentered again by doing Linux work.

I've cleaned up my queue correspondingly and just pushed it.

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux