[Xenomai] Xenomai 3: kill() to non-Xenomai PIDs

[Xenomai] Xenomai 3: kill() to non-Xenomai PIDs

[Jan Kiszka]

Hi,

kill() is currently handled by libcobalt such that PIDs <= 0 are
forwarded to Linux and PIDs > 0 are considered to target only Xenomai
threads. But what if the user wants to address a regular Linux task from
within a Xenomai application? Shouldn't we retry kill via the Linux path
if Xenomai's syscall reports ESRCH?

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] Xenomai 3: kill() to non-Xenomai PIDs

[Jan Kiszka]

On 2015-10-16 16:49, Jan Kiszka wrote:
> Hi,
> 
> kill() is currently handled by libcobalt such that PIDs <= 0 are
> forwarded to Linux and PIDs > 0 are considered to target only Xenomai
> threads. But what if the user wants to address a regular Linux task from
> within a Xenomai application? Shouldn't we retry kill via the Linux path
> if Xenomai's syscall reports ESRCH?
> 

IOW:

diff --git a/lib/cobalt/signal.c b/lib/cobalt/signal.c
index aac4059..7e03301 100644
--- a/lib/cobalt/signal.c
+++ b/lib/cobalt/signal.c
@@ -99,6 +99,10 @@ COBALT_IMPL(int, kill, (pid_t pid, int sig))
 
 	ret = XENOMAI_SYSCALL2(sc_cobalt_kill, pid, sig);
 	if (ret) {
+		/* Retry with regular kill is no RT target was found. */
+		if (ret == -ESRCH)
+			return __STD(kill(pid, sig));
+
 		errno = -ret;
 		return -1;
 	}

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] Xenomai 3: kill() to non-Xenomai PIDs

[Philippe Gerum]

On 10/16/2015 04:56 PM, Jan Kiszka wrote:
> On 2015-10-16 16:49, Jan Kiszka wrote:
>> Hi,
>>
>> kill() is currently handled by libcobalt such that PIDs <= 0 are
>> forwarded to Linux and PIDs > 0 are considered to target only Xenomai
>> threads. But what if the user wants to address a regular Linux task from
>> within a Xenomai application? Shouldn't we retry kill via the Linux path
>> if Xenomai's syscall reports ESRCH?
>>
> 
> IOW:
> 
> diff --git a/lib/cobalt/signal.c b/lib/cobalt/signal.c
> index aac4059..7e03301 100644
> --- a/lib/cobalt/signal.c
> +++ b/lib/cobalt/signal.c
> @@ -99,6 +99,10 @@ COBALT_IMPL(int, kill, (pid_t pid, int sig))
>  
>  	ret = XENOMAI_SYSCALL2(sc_cobalt_kill, pid, sig);
>  	if (ret) {
> +		/* Retry with regular kill is no RT target was found. */
> +		if (ret == -ESRCH)
> +			return __STD(kill(pid, sig));
> +
>  		errno = -ret;
>  		return -1;
>  	}
> 
> Jan
> 

This may break code that sends signal 0 to detect whether a rt thread
exists (like copperplate does), which is the reason for the lack of
forwarding IIRC. (ret == -ESRCH && sig) would be required to forward
without breaking such assumption.

-- 
Philippe.

Re: [Xenomai] Xenomai 3: kill() to non-Xenomai PIDs

[Jan Kiszka]

On 2015-10-16 17:22, Philippe Gerum wrote:
> On 10/16/2015 04:56 PM, Jan Kiszka wrote:
>> On 2015-10-16 16:49, Jan Kiszka wrote:
>>> Hi,
>>>
>>> kill() is currently handled by libcobalt such that PIDs <= 0 are
>>> forwarded to Linux and PIDs > 0 are considered to target only Xenomai
>>> threads. But what if the user wants to address a regular Linux task from
>>> within a Xenomai application? Shouldn't we retry kill via the Linux path
>>> if Xenomai's syscall reports ESRCH?
>>>
>>
>> IOW:
>>
>> diff --git a/lib/cobalt/signal.c b/lib/cobalt/signal.c
>> index aac4059..7e03301 100644
>> --- a/lib/cobalt/signal.c
>> +++ b/lib/cobalt/signal.c
>> @@ -99,6 +99,10 @@ COBALT_IMPL(int, kill, (pid_t pid, int sig))
>>  
>>  	ret = XENOMAI_SYSCALL2(sc_cobalt_kill, pid, sig);
>>  	if (ret) {
>> +		/* Retry with regular kill is no RT target was found. */
>> +		if (ret == -ESRCH)
>> +			return __STD(kill(pid, sig));
>> +
>>  		errno = -ret;
>>  		return -1;
>>  	}
>>
>> Jan
>>
> 
> This may break code that sends signal 0 to detect whether a rt thread
> exists (like copperplate does), which is the reason for the lack of
> forwarding IIRC. (ret == -ESRCH && sig) would be required to forward
> without breaking such assumption.

That still breaks POSIX (what if the user wants to test for a non-rt
thread, like this is possible under regular Linux?). Can't copperplate
be changed to bypass the wrapper?

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] Xenomai 3: kill() to non-Xenomai PIDs

[Philippe Gerum]

On 10/16/2015 05:28 PM, Jan Kiszka wrote:
> On 2015-10-16 17:22, Philippe Gerum wrote:
>> On 10/16/2015 04:56 PM, Jan Kiszka wrote:
>>> On 2015-10-16 16:49, Jan Kiszka wrote:
>>>> Hi,
>>>>
>>>> kill() is currently handled by libcobalt such that PIDs <= 0 are
>>>> forwarded to Linux and PIDs > 0 are considered to target only Xenomai
>>>> threads. But what if the user wants to address a regular Linux task from
>>>> within a Xenomai application? Shouldn't we retry kill via the Linux path
>>>> if Xenomai's syscall reports ESRCH?
>>>>
>>>
>>> IOW:
>>>
>>> diff --git a/lib/cobalt/signal.c b/lib/cobalt/signal.c
>>> index aac4059..7e03301 100644
>>> --- a/lib/cobalt/signal.c
>>> +++ b/lib/cobalt/signal.c
>>> @@ -99,6 +99,10 @@ COBALT_IMPL(int, kill, (pid_t pid, int sig))
>>>  
>>>  	ret = XENOMAI_SYSCALL2(sc_cobalt_kill, pid, sig);
>>>  	if (ret) {
>>> +		/* Retry with regular kill is no RT target was found. */
>>> +		if (ret == -ESRCH)
>>> +			return __STD(kill(pid, sig));
>>> +
>>>  		errno = -ret;
>>>  		return -1;
>>>  	}
>>>
>>> Jan
>>>
>>
>> This may break code that sends signal 0 to detect whether a rt thread
>> exists (like copperplate does), which is the reason for the lack of
>> forwarding IIRC. (ret == -ESRCH && sig) would be required to forward
>> without breaking such assumption.
> 
> That still breaks POSIX (what if the user wants to test for a non-rt
> thread, like this is possible under regular Linux?). Can't copperplate
> be changed to bypass the wrapper?
> 

Probably, yes.


-- 
Philippe.

Re: [Xenomai] Xenomai 3: kill() to non-Xenomai PIDs

[Gilles Chanteperdrix]

On Fri, Oct 16, 2015 at 05:28:07PM +0200, Jan Kiszka wrote:
> On 2015-10-16 17:22, Philippe Gerum wrote:
> > On 10/16/2015 04:56 PM, Jan Kiszka wrote:
> >> On 2015-10-16 16:49, Jan Kiszka wrote:
> >>> Hi,
> >>>
> >>> kill() is currently handled by libcobalt such that PIDs <= 0 are
> >>> forwarded to Linux and PIDs > 0 are considered to target only Xenomai
> >>> threads. But what if the user wants to address a regular Linux task from
> >>> within a Xenomai application? Shouldn't we retry kill via the Linux path
> >>> if Xenomai's syscall reports ESRCH?
> >>>
> >>
> >> IOW:
> >>
> >> diff --git a/lib/cobalt/signal.c b/lib/cobalt/signal.c
> >> index aac4059..7e03301 100644
> >> --- a/lib/cobalt/signal.c
> >> +++ b/lib/cobalt/signal.c
> >> @@ -99,6 +99,10 @@ COBALT_IMPL(int, kill, (pid_t pid, int sig))
> >>  
> >>  	ret = XENOMAI_SYSCALL2(sc_cobalt_kill, pid, sig);
> >>  	if (ret) {
> >> +		/* Retry with regular kill is no RT target was found. */
> >> +		if (ret == -ESRCH)
> >> +			return __STD(kill(pid, sig));
> >> +
> >>  		errno = -ret;
> >>  		return -1;
> >>  	}
> >>
> >> Jan
> >>
> > 
> > This may break code that sends signal 0 to detect whether a rt thread
> > exists (like copperplate does), which is the reason for the lack of
> > forwarding IIRC. (ret == -ESRCH && sig) would be required to forward
> > without breaking such assumption.
> 
> That still breaks POSIX (what if the user wants to test for a non-rt
> thread, like this is possible under regular Linux?). Can't copperplate
> be changed to bypass the wrapper?

If I have understood the "xenomai 3" philosophy, is not an
application which wants to use the standard call supposed to use the
__STD prefix, or not use the wrapping at all ?

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] Xenomai 3: kill() to non-Xenomai PIDs

[Jan Kiszka]

On 2015-10-16 17:34, Gilles Chanteperdrix wrote:
> On Fri, Oct 16, 2015 at 05:28:07PM +0200, Jan Kiszka wrote:
>> On 2015-10-16 17:22, Philippe Gerum wrote:
>>> On 10/16/2015 04:56 PM, Jan Kiszka wrote:
>>>> On 2015-10-16 16:49, Jan Kiszka wrote:
>>>>> Hi,
>>>>>
>>>>> kill() is currently handled by libcobalt such that PIDs <= 0 are
>>>>> forwarded to Linux and PIDs > 0 are considered to target only Xenomai
>>>>> threads. But what if the user wants to address a regular Linux task from
>>>>> within a Xenomai application? Shouldn't we retry kill via the Linux path
>>>>> if Xenomai's syscall reports ESRCH?
>>>>>
>>>>
>>>> IOW:
>>>>
>>>> diff --git a/lib/cobalt/signal.c b/lib/cobalt/signal.c
>>>> index aac4059..7e03301 100644
>>>> --- a/lib/cobalt/signal.c
>>>> +++ b/lib/cobalt/signal.c
>>>> @@ -99,6 +99,10 @@ COBALT_IMPL(int, kill, (pid_t pid, int sig))
>>>>  
>>>>  	ret = XENOMAI_SYSCALL2(sc_cobalt_kill, pid, sig);
>>>>  	if (ret) {
>>>> +		/* Retry with regular kill is no RT target was found. */
>>>> +		if (ret == -ESRCH)
>>>> +			return __STD(kill(pid, sig));
>>>> +
>>>>  		errno = -ret;
>>>>  		return -1;
>>>>  	}
>>>>
>>>> Jan
>>>>
>>>
>>> This may break code that sends signal 0 to detect whether a rt thread
>>> exists (like copperplate does), which is the reason for the lack of
>>> forwarding IIRC. (ret == -ESRCH && sig) would be required to forward
>>> without breaking such assumption.
>>
>> That still breaks POSIX (what if the user wants to test for a non-rt
>> thread, like this is possible under regular Linux?). Can't copperplate
>> be changed to bypass the wrapper?
> 
> If I have understood the "xenomai 3" philosophy, is not an
> application which wants to use the standard call supposed to use the
> __STD prefix, or not use the wrapping at all ?

That's also a theoretical option, but should only be used if we can't
fix the limitation otherwise. The more exceptions we define, the less
portable we become for POSIX/Linux applications.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] Xenomai 3: kill() to non-Xenomai PIDs

[Jan Kiszka]

On 2015-10-16 17:31, Philippe Gerum wrote:
> On 10/16/2015 05:28 PM, Jan Kiszka wrote:
>> On 2015-10-16 17:22, Philippe Gerum wrote:
>>> On 10/16/2015 04:56 PM, Jan Kiszka wrote:
>>>> On 2015-10-16 16:49, Jan Kiszka wrote:
>>>>> Hi,
>>>>>
>>>>> kill() is currently handled by libcobalt such that PIDs <= 0 are
>>>>> forwarded to Linux and PIDs > 0 are considered to target only Xenomai
>>>>> threads. But what if the user wants to address a regular Linux task from
>>>>> within a Xenomai application? Shouldn't we retry kill via the Linux path
>>>>> if Xenomai's syscall reports ESRCH?
>>>>>
>>>>
>>>> IOW:
>>>>
>>>> diff --git a/lib/cobalt/signal.c b/lib/cobalt/signal.c
>>>> index aac4059..7e03301 100644
>>>> --- a/lib/cobalt/signal.c
>>>> +++ b/lib/cobalt/signal.c
>>>> @@ -99,6 +99,10 @@ COBALT_IMPL(int, kill, (pid_t pid, int sig))
>>>>  
>>>>  	ret = XENOMAI_SYSCALL2(sc_cobalt_kill, pid, sig);
>>>>  	if (ret) {
>>>> +		/* Retry with regular kill is no RT target was found. */
>>>> +		if (ret == -ESRCH)
>>>> +			return __STD(kill(pid, sig));
>>>> +
>>>>  		errno = -ret;
>>>>  		return -1;
>>>>  	}
>>>>
>>>> Jan
>>>>
>>>
>>> This may break code that sends signal 0 to detect whether a rt thread
>>> exists (like copperplate does), which is the reason for the lack of
>>> forwarding IIRC. (ret == -ESRCH && sig) would be required to forward
>>> without breaking such assumption.
>>
>> That still breaks POSIX (what if the user wants to test for a non-rt
>> thread, like this is possible under regular Linux?). Can't copperplate
>> be changed to bypass the wrapper?
>>
> 
> Probably, yes.
> 

Looking at cluster_probe, I wonder if there is actually a problem.
Doesn't that code also run over mercury? Then kill(pid, 0) also targets
the whole system, not just a set of Xenomai applications. Or do we need
to ensure that the caller is not migrated to Linux needlessly under
cobalt? IOW: can that probing happen under RT constraints?

The same applies for me to the other users of the kill-based probing
pattern (copperplate/heapobj-pshared.c and copperplate/regd/fs-common.c).

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] Xenomai 3: kill() to non-Xenomai PIDs

[Philippe Gerum]

On 10/16/2015 05:57 PM, Jan Kiszka wrote:
> On 2015-10-16 17:31, Philippe Gerum wrote:
>> On 10/16/2015 05:28 PM, Jan Kiszka wrote:
>>> On 2015-10-16 17:22, Philippe Gerum wrote:
>>>> On 10/16/2015 04:56 PM, Jan Kiszka wrote:
>>>>> On 2015-10-16 16:49, Jan Kiszka wrote:
>>>>>> Hi,
>>>>>>
>>>>>> kill() is currently handled by libcobalt such that PIDs <= 0 are
>>>>>> forwarded to Linux and PIDs > 0 are considered to target only Xenomai
>>>>>> threads. But what if the user wants to address a regular Linux task from
>>>>>> within a Xenomai application? Shouldn't we retry kill via the Linux path
>>>>>> if Xenomai's syscall reports ESRCH?
>>>>>>
>>>>>
>>>>> IOW:
>>>>>
>>>>> diff --git a/lib/cobalt/signal.c b/lib/cobalt/signal.c
>>>>> index aac4059..7e03301 100644
>>>>> --- a/lib/cobalt/signal.c
>>>>> +++ b/lib/cobalt/signal.c
>>>>> @@ -99,6 +99,10 @@ COBALT_IMPL(int, kill, (pid_t pid, int sig))
>>>>>  
>>>>>  	ret = XENOMAI_SYSCALL2(sc_cobalt_kill, pid, sig);
>>>>>  	if (ret) {
>>>>> +		/* Retry with regular kill is no RT target was found. */
>>>>> +		if (ret == -ESRCH)
>>>>> +			return __STD(kill(pid, sig));
>>>>> +
>>>>>  		errno = -ret;
>>>>>  		return -1;
>>>>>  	}
>>>>>
>>>>> Jan
>>>>>
>>>>
>>>> This may break code that sends signal 0 to detect whether a rt thread
>>>> exists (like copperplate does), which is the reason for the lack of
>>>> forwarding IIRC. (ret == -ESRCH && sig) would be required to forward
>>>> without breaking such assumption.
>>>
>>> That still breaks POSIX (what if the user wants to test for a non-rt
>>> thread, like this is possible under regular Linux?). Can't copperplate
>>> be changed to bypass the wrapper?
>>>
>>
>> Probably, yes.
>>
> 
> Looking at cluster_probe, I wonder if there is actually a problem.
> Doesn't that code also run over mercury? Then kill(pid, 0) also targets
> the whole system, not just a set of Xenomai applications.

Over mercury, the whole system is the rt domain.

 Or do we need
> to ensure that the caller is not migrated to Linux needlessly under
> cobalt? IOW: can that probing happen under RT constraints?
> 

It does with clusters. In general, no restriction on the calling domain
should exist for this low level interface.

> The same applies for me to the other users of the kill-based probing
> pattern (copperplate/heapobj-pshared.c and copperplate/regd/fs-common.c).
> 
> Jan
> 


-- 
Philippe.

Re: [Xenomai] Xenomai 3: kill() to non-Xenomai PIDs

[Jan Kiszka]

On 2015-10-16 18:00, Philippe Gerum wrote:
> On 10/16/2015 05:57 PM, Jan Kiszka wrote:
>> On 2015-10-16 17:31, Philippe Gerum wrote:
>>> On 10/16/2015 05:28 PM, Jan Kiszka wrote:
>>>> On 2015-10-16 17:22, Philippe Gerum wrote:
>>>>> On 10/16/2015 04:56 PM, Jan Kiszka wrote:
>>>>>> On 2015-10-16 16:49, Jan Kiszka wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> kill() is currently handled by libcobalt such that PIDs <= 0 are
>>>>>>> forwarded to Linux and PIDs > 0 are considered to target only Xenomai
>>>>>>> threads. But what if the user wants to address a regular Linux task from
>>>>>>> within a Xenomai application? Shouldn't we retry kill via the Linux path
>>>>>>> if Xenomai's syscall reports ESRCH?
>>>>>>>
>>>>>>
>>>>>> IOW:
>>>>>>
>>>>>> diff --git a/lib/cobalt/signal.c b/lib/cobalt/signal.c
>>>>>> index aac4059..7e03301 100644
>>>>>> --- a/lib/cobalt/signal.c
>>>>>> +++ b/lib/cobalt/signal.c
>>>>>> @@ -99,6 +99,10 @@ COBALT_IMPL(int, kill, (pid_t pid, int sig))
>>>>>>  
>>>>>>  	ret = XENOMAI_SYSCALL2(sc_cobalt_kill, pid, sig);
>>>>>>  	if (ret) {
>>>>>> +		/* Retry with regular kill is no RT target was found. */
>>>>>> +		if (ret == -ESRCH)
>>>>>> +			return __STD(kill(pid, sig));
>>>>>> +
>>>>>>  		errno = -ret;
>>>>>>  		return -1;
>>>>>>  	}
>>>>>>
>>>>>> Jan
>>>>>>
>>>>>
>>>>> This may break code that sends signal 0 to detect whether a rt thread
>>>>> exists (like copperplate does), which is the reason for the lack of
>>>>> forwarding IIRC. (ret == -ESRCH && sig) would be required to forward
>>>>> without breaking such assumption.
>>>>
>>>> That still breaks POSIX (what if the user wants to test for a non-rt
>>>> thread, like this is possible under regular Linux?). Can't copperplate
>>>> be changed to bypass the wrapper?
>>>>
>>>
>>> Probably, yes.
>>>
>>
>> Looking at cluster_probe, I wonder if there is actually a problem.
>> Doesn't that code also run over mercury? Then kill(pid, 0) also targets
>> the whole system, not just a set of Xenomai applications.
> 
> Over mercury, the whole system is the rt domain.
> 
>  Or do we need
>> to ensure that the caller is not migrated to Linux needlessly under
>> cobalt? IOW: can that probing happen under RT constraints?
>>
> 
> It does with clusters. In general, no restriction on the calling domain
> should exist for this low level interface.

Ok, will handle that path cobalt-specific then.

> 
>> The same applies for me to the other users of the kill-based probing
>> pattern (copperplate/heapobj-pshared.c and copperplate/regd/fs-common.c).

But these are fine, no?

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] Xenomai 3: kill() to non-Xenomai PIDs

[Philippe Gerum]

On 10/16/2015 06:03 PM, Jan Kiszka wrote:
> On 2015-10-16 18:00, Philippe Gerum wrote:
>> On 10/16/2015 05:57 PM, Jan Kiszka wrote:
>>> On 2015-10-16 17:31, Philippe Gerum wrote:
>>>> On 10/16/2015 05:28 PM, Jan Kiszka wrote:
>>>>> On 2015-10-16 17:22, Philippe Gerum wrote:
>>>>>> On 10/16/2015 04:56 PM, Jan Kiszka wrote:
>>>>>>> On 2015-10-16 16:49, Jan Kiszka wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> kill() is currently handled by libcobalt such that PIDs <= 0 are
>>>>>>>> forwarded to Linux and PIDs > 0 are considered to target only Xenomai
>>>>>>>> threads. But what if the user wants to address a regular Linux task from
>>>>>>>> within a Xenomai application? Shouldn't we retry kill via the Linux path
>>>>>>>> if Xenomai's syscall reports ESRCH?
>>>>>>>>
>>>>>>>
>>>>>>> IOW:
>>>>>>>
>>>>>>> diff --git a/lib/cobalt/signal.c b/lib/cobalt/signal.c
>>>>>>> index aac4059..7e03301 100644
>>>>>>> --- a/lib/cobalt/signal.c
>>>>>>> +++ b/lib/cobalt/signal.c
>>>>>>> @@ -99,6 +99,10 @@ COBALT_IMPL(int, kill, (pid_t pid, int sig))
>>>>>>>  
>>>>>>>  	ret = XENOMAI_SYSCALL2(sc_cobalt_kill, pid, sig);
>>>>>>>  	if (ret) {
>>>>>>> +		/* Retry with regular kill is no RT target was found. */
>>>>>>> +		if (ret == -ESRCH)
>>>>>>> +			return __STD(kill(pid, sig));
>>>>>>> +
>>>>>>>  		errno = -ret;
>>>>>>>  		return -1;
>>>>>>>  	}
>>>>>>>
>>>>>>> Jan
>>>>>>>
>>>>>>
>>>>>> This may break code that sends signal 0 to detect whether a rt thread
>>>>>> exists (like copperplate does), which is the reason for the lack of
>>>>>> forwarding IIRC. (ret == -ESRCH && sig) would be required to forward
>>>>>> without breaking such assumption.
>>>>>
>>>>> That still breaks POSIX (what if the user wants to test for a non-rt
>>>>> thread, like this is possible under regular Linux?). Can't copperplate
>>>>> be changed to bypass the wrapper?
>>>>>
>>>>
>>>> Probably, yes.
>>>>
>>>
>>> Looking at cluster_probe, I wonder if there is actually a problem.
>>> Doesn't that code also run over mercury? Then kill(pid, 0) also targets
>>> the whole system, not just a set of Xenomai applications.
>>
>> Over mercury, the whole system is the rt domain.
>>
>>  Or do we need
>>> to ensure that the caller is not migrated to Linux needlessly under
>>> cobalt? IOW: can that probing happen under RT constraints?
>>>
>>
>> It does with clusters. In general, no restriction on the calling domain
>> should exist for this low level interface.
> 
> Ok, will handle that path cobalt-specific then.
> 
>>
>>> The same applies for me to the other users of the kill-based probing
>>> pattern (copperplate/heapobj-pshared.c and copperplate/regd/fs-common.c).
> 
> But these are fine, no?
> 

Yes, don't care for mode switches there.


-- 
Philippe.

Re: [Xenomai] Xenomai 3: kill() to non-Xenomai PIDs

[Philippe Gerum]

On 10/16/2015 06:06 PM, Philippe Gerum wrote:
> On 10/16/2015 06:03 PM, Jan Kiszka wrote:
>> On 2015-10-16 18:00, Philippe Gerum wrote:
>>> On 10/16/2015 05:57 PM, Jan Kiszka wrote:
>>>> On 2015-10-16 17:31, Philippe Gerum wrote:
>>>>> On 10/16/2015 05:28 PM, Jan Kiszka wrote:
>>>>>> On 2015-10-16 17:22, Philippe Gerum wrote:
>>>>>>> On 10/16/2015 04:56 PM, Jan Kiszka wrote:
>>>>>>>> On 2015-10-16 16:49, Jan Kiszka wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> kill() is currently handled by libcobalt such that PIDs <= 0 are
>>>>>>>>> forwarded to Linux and PIDs > 0 are considered to target only Xenomai
>>>>>>>>> threads. But what if the user wants to address a regular Linux task from
>>>>>>>>> within a Xenomai application? Shouldn't we retry kill via the Linux path
>>>>>>>>> if Xenomai's syscall reports ESRCH?
>>>>>>>>>
>>>>>>>>
>>>>>>>> IOW:
>>>>>>>>
>>>>>>>> diff --git a/lib/cobalt/signal.c b/lib/cobalt/signal.c
>>>>>>>> index aac4059..7e03301 100644
>>>>>>>> --- a/lib/cobalt/signal.c
>>>>>>>> +++ b/lib/cobalt/signal.c
>>>>>>>> @@ -99,6 +99,10 @@ COBALT_IMPL(int, kill, (pid_t pid, int sig))
>>>>>>>>  
>>>>>>>>  	ret = XENOMAI_SYSCALL2(sc_cobalt_kill, pid, sig);
>>>>>>>>  	if (ret) {
>>>>>>>> +		/* Retry with regular kill is no RT target was found. */
>>>>>>>> +		if (ret == -ESRCH)
>>>>>>>> +			return __STD(kill(pid, sig));
>>>>>>>> +
>>>>>>>>  		errno = -ret;
>>>>>>>>  		return -1;
>>>>>>>>  	}
>>>>>>>>
>>>>>>>> Jan
>>>>>>>>
>>>>>>>
>>>>>>> This may break code that sends signal 0 to detect whether a rt thread
>>>>>>> exists (like copperplate does), which is the reason for the lack of
>>>>>>> forwarding IIRC. (ret == -ESRCH && sig) would be required to forward
>>>>>>> without breaking such assumption.
>>>>>>
>>>>>> That still breaks POSIX (what if the user wants to test for a non-rt
>>>>>> thread, like this is possible under regular Linux?). Can't copperplate
>>>>>> be changed to bypass the wrapper?
>>>>>>
>>>>>
>>>>> Probably, yes.
>>>>>
>>>>
>>>> Looking at cluster_probe, I wonder if there is actually a problem.
>>>> Doesn't that code also run over mercury? Then kill(pid, 0) also targets
>>>> the whole system, not just a set of Xenomai applications.
>>>
>>> Over mercury, the whole system is the rt domain.
>>>
>>>  Or do we need
>>>> to ensure that the caller is not migrated to Linux needlessly under
>>>> cobalt? IOW: can that probing happen under RT constraints?
>>>>
>>>
>>> It does with clusters. In general, no restriction on the calling domain
>>> should exist for this low level interface.
>>
>> Ok, will handle that path cobalt-specific then.
>>
>>>
>>>> The same applies for me to the other users of the kill-based probing
>>>> pattern (copperplate/heapobj-pshared.c and copperplate/regd/fs-common.c).
>>
>> But these are fine, no?
>>
> 
> Yes, don't care for mode switches there.
> 
> 

In fact, those will never target a non-Xenomai thread over cobalt.

-- 
Philippe.