Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> As the xnsched structures get initialized later, during xnpod_init,
>>> xnsched_cpu always returned 0 in the gatekeeper_thread prologue. That
>>> caused binding of all gatekeepers to CPU 0.
>>>
>>> Signed-off-by: Jan Kiszka <[email protected]>
>>> ---
>>>
>>> ksrc/nucleus/shadow.c | 5 ++++-
>>> 1 files changed, 4 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c
>>> index 1dedd85..2243c0e 100644
>>> --- a/ksrc/nucleus/shadow.c
>>> +++ b/ksrc/nucleus/shadow.c
>>> @@ -823,11 +823,14 @@ static int gatekeeper_thread(void *data)
>>> struct task_struct *this_task = current;
>>> DECLARE_WAITQUEUE(wait, this_task);
>>> struct xnsched *sched = data;
>>> - int cpu = xnsched_cpu(sched);
>>> struct xnthread *target;
>>> cpumask_t cpumask;
>>> + int cpu;
>>> spl_t s;
>>>
>>> + /* sched not fully initialized, xnsched_cpu does not work yet */
>>> + cpu = sched - nkpod_struct.sched;
>>> +
>>> this_task->flags |= PF_NOFREEZE;
>>> sigfillset(&this_task->blocked);
>>> cpumask = cpumask_of_cpu(cpu);
>> This does not look good, it means that the gatekeeper accesses the sched
>> structure before it is initialized. So, IMO, the proper fix would be to
>> start the gatekeepers only after the sched structure has been initialized.
>>
>
> I briefly thought about moving xnshadow_mount into xnpod_init. But given
> the fact that it worked like this before and that I was not able to
> quickly exclude new regressions when reordering things, I decided to
> restore the old pattern.
Ok. What about passing cpu as the gatekeeper argument, and using
xnpod_sched_slot(cpu) to find the sched pointer ?
--
Gilles.
_______________________________________________
Xenomai-core mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-core
