rt_task_shadow() secondary mode

rt_task_shadow() secondary mode

[Richard Weinberger]

Hi!

An application I'm working on assumes that rt_task_shadow() with prio
being 0 returns in secondary mode. This seems to be the case on
Xenomai 2.6 but no longer on 3.1.

Is this a known/desired change?

-- 
Thanks,
//richard

Re: rt_task_shadow() secondary mode

[Jan Kiszka]

On 08.07.21 11:03, Richard Weinberger via Xenomai wrote:
> Hi!
> 
> An application I'm working on assumes that rt_task_shadow() with prio
> being 0 returns in secondary mode. This seems to be the case on
> Xenomai 2.6 but no longer on 3.1.
> 
> Is this a known/desired change?
> 

The general philosophy of Xenomai is that applications should not rely
on the exact switching behavior. So the question would be why your
application needs one or the other behavior?

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: rt_task_shadow() secondary mode

[Richard Weinberger]

On Thu, Jul 8, 2021 at 11:25 AM Jan Kiszka <jan.kiszka@siemens.com> wrote:
> The general philosophy of Xenomai is that applications should not rely
> on the exact switching behavior. So the question would be why your
> application needs one or the other behavior?

In this particular case the application uses the ioctl() system call
to call into a
xenomai kernel module. The module implements the rt and nrt variant of
ioctl() and
the application assumes which version of the ioctl() implementation
will get reached.

-- 
Thanks,
//richard

Re: rt_task_shadow() secondary mode

[Jan Kiszka]

On 08.07.21 11:51, Richard Weinberger wrote:
> On Thu, Jul 8, 2021 at 11:25 AM Jan Kiszka <jan.kiszka@siemens.com> wrote:
>> The general philosophy of Xenomai is that applications should not rely
>> on the exact switching behavior. So the question would be why your
>> application needs one or the other behavior?
> 
> In this particular case the application uses the ioctl() system call
> to call into a
> xenomai kernel module. The module implements the rt and nrt variant of
> ioctl() and
> the application assumes which version of the ioctl() implementation
> will get reached.

...that might be the actual design bug. If a driver implements the a
service for both calling modes, the service should effectively do the
same, ie. should be mode-agnostic. Seems, this was violated here.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: rt_task_shadow() secondary mode

[Richard Weinberger]

On Thu, Jul 8, 2021 at 11:54 AM Jan Kiszka <jan.kiszka@siemens.com> wrote:
>
> On 08.07.21 11:51, Richard Weinberger wrote:
> > On Thu, Jul 8, 2021 at 11:25 AM Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >> The general philosophy of Xenomai is that applications should not rely
> >> on the exact switching behavior. So the question would be why your
> >> application needs one or the other behavior?
> >
> > In this particular case the application uses the ioctl() system call
> > to call into a
> > xenomai kernel module. The module implements the rt and nrt variant of
> > ioctl() and
> > the application assumes which version of the ioctl() implementation
> > will get reached.
>
> ...that might be the actual design bug. If a driver implements the a
> service for both calling modes, the service should effectively do the
> same, ie. should be mode-agnostic. Seems, this was violated here.

Can be, the driver was designed a long time ago. :-)
In the nrt ioctl() the driver uses e.g. ioremap(), this cannot work in primary
mode. Is the desired approach switching to secondary mode when in primary
mode such a code path is to be executed?

-- 
Thanks,
//richard

Re: rt_task_shadow() secondary mode

[Philippe Gerum]

Jan Kiszka via Xenomai <xenomai@xenomai.org> writes:

> On 08.07.21 11:51, Richard Weinberger wrote:
>> On Thu, Jul 8, 2021 at 11:25 AM Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>> The general philosophy of Xenomai is that applications should not rely
>>> on the exact switching behavior. So the question would be why your
>>> application needs one or the other behavior?
>> 
>> In this particular case the application uses the ioctl() system call
>> to call into a
>> xenomai kernel module. The module implements the rt and nrt variant of
>> ioctl() and
>> the application assumes which version of the ioctl() implementation
>> will get reached.
>
> ...that might be the actual design bug. If a driver implements the a
> service for both calling modes, the service should effectively do the
> same, ie. should be mode-agnostic. Seems, this was violated here.
>
> Jan

True, but this said, rt_task_shadow() should definitely leave the caller
into secondary mode if called for SCHED_OTHER, since this would be the
natural execution stage in that case. So rt_task_shadow() behaves like
the documentation states, but should not in this particular case
(prio=0).

-- 
Philippe.

Re: rt_task_shadow() secondary mode

[Jan Kiszka]

On 08.07.21 12:04, Richard Weinberger wrote:
> On Thu, Jul 8, 2021 at 11:54 AM Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>
>> On 08.07.21 11:51, Richard Weinberger wrote:
>>> On Thu, Jul 8, 2021 at 11:25 AM Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>> The general philosophy of Xenomai is that applications should not rely
>>>> on the exact switching behavior. So the question would be why your
>>>> application needs one or the other behavior?
>>>
>>> In this particular case the application uses the ioctl() system call
>>> to call into a
>>> xenomai kernel module. The module implements the rt and nrt variant of
>>> ioctl() and
>>> the application assumes which version of the ioctl() implementation
>>> will get reached.
>>
>> ...that might be the actual design bug. If a driver implements the a
>> service for both calling modes, the service should effectively do the
>> same, ie. should be mode-agnostic. Seems, this was violated here.
> 
> Can be, the driver was designed a long time ago. :-)
> In the nrt ioctl() the driver uses e.g. ioremap(), this cannot work in primary
> mode. Is the desired approach switching to secondary mode when in primary
> mode such a code path is to be executed?
> 

Correct. That is easily achieved by returning -ENOSYS from the rt
handler when seeing that nrt request in its context.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: rt_task_shadow() secondary mode

[Jan Kiszka]

On 08.07.21 12:09, Philippe Gerum wrote:
> 
> Jan Kiszka via Xenomai <xenomai@xenomai.org> writes:
> 
>> On 08.07.21 11:51, Richard Weinberger wrote:
>>> On Thu, Jul 8, 2021 at 11:25 AM Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>> The general philosophy of Xenomai is that applications should not rely
>>>> on the exact switching behavior. So the question would be why your
>>>> application needs one or the other behavior?
>>>
>>> In this particular case the application uses the ioctl() system call
>>> to call into a
>>> xenomai kernel module. The module implements the rt and nrt variant of
>>> ioctl() and
>>> the application assumes which version of the ioctl() implementation
>>> will get reached.
>>
>> ...that might be the actual design bug. If a driver implements the a
>> service for both calling modes, the service should effectively do the
>> same, ie. should be mode-agnostic. Seems, this was violated here.
>>
>> Jan
> 
> True, but this said, rt_task_shadow() should definitely leave the caller
> into secondary mode if called for SCHED_OTHER, since this would be the
> natural execution stage in that case. So rt_task_shadow() behaves like
> the documentation states, but should not in this particular case
> (prio=0).
> 

Then it needs to be understood what technically triggers this and
resolved, likely via an explicit migration.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: rt_task_shadow() secondary mode

[Philippe Gerum]

Jan Kiszka <jan.kiszka@siemens.com> writes:

> On 08.07.21 12:09, Philippe Gerum wrote:
>> 
>> Jan Kiszka via Xenomai <xenomai@xenomai.org> writes:
>> 
>>> On 08.07.21 11:51, Richard Weinberger wrote:
>>>> On Thu, Jul 8, 2021 at 11:25 AM Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>> The general philosophy of Xenomai is that applications should not rely
>>>>> on the exact switching behavior. So the question would be why your
>>>>> application needs one or the other behavior?
>>>>
>>>> In this particular case the application uses the ioctl() system call
>>>> to call into a
>>>> xenomai kernel module. The module implements the rt and nrt variant of
>>>> ioctl() and
>>>> the application assumes which version of the ioctl() implementation
>>>> will get reached.
>>>
>>> ...that might be the actual design bug. If a driver implements the a
>>> service for both calling modes, the service should effectively do the
>>> same, ie. should be mode-agnostic. Seems, this was violated here.
>>>
>>> Jan
>> 
>> True, but this said, rt_task_shadow() should definitely leave the caller
>> into secondary mode if called for SCHED_OTHER, since this would be the
>> natural execution stage in that case. So rt_task_shadow() behaves like
>> the documentation states, but should not in this particular case
>> (prio=0).
>> 
>
> Then it needs to be understood what technically triggers this and
> resolved, likely via an explicit migration.
>

Sure, good exercise for the reader to get ones feet wet with libalchemy.
If somebody wants to tackle this: check callers of
threadobj_run_corespec() in libcopperplate.

The common case in this routine is to force a switch back to primary
mode for the caller, on exit from threadobj_shadow(). We may want to
make this conditional to the scheduling policy and priority. Following
threadobj_init() for the content of idata may help too.

-- 
Philippe.

Re: rt_task_shadow() secondary mode

[Richard Weinberger]

On Thu, Jul 8, 2021 at 2:51 PM Philippe Gerum <rpm@xenomai.org> wrote:
> > Then it needs to be understood what technically triggers this and
> > resolved, likely via an explicit migration.
> >
>
> Sure, good exercise for the reader to get ones feet wet with libalchemy.
> If somebody wants to tackle this: check callers of
> threadobj_run_corespec() in libcopperplate.
>
> The common case in this routine is to force a switch back to primary
> mode for the caller, on exit from threadobj_shadow(). We may want to
> make this conditional to the scheduling policy and priority. Following
> threadobj_init() for the content of idata may help too.

Hmm.
I see cobalt_thread_harden() being called long before threadobj_init().
cobalt_thread_trampoline() calls it too.
Same for pthread_setschedparam_ex() if the task in question is main().

-- 
Thanks,
//richard

Re: rt_task_shadow() secondary mode

[Richard Weinberger]

On Fri, Jul 9, 2021 at 12:05 AM Richard Weinberger
<richard.weinberger@gmail.com> wrote:
> Hmm.
> I see cobalt_thread_harden() being called long before threadobj_init().
> cobalt_thread_trampoline() calls it too.
> Same for pthread_setschedparam_ex() if the task in question is main().

Correction: It is always pthread_setschedparam_ex().
I forgot that I had pthread_create wrapping enabled in one test...

-- 
Thanks,
//richard