Best way to detect if a filedescriptor is a cobalt filedescriptor (/socket)

Best way to detect if a filedescriptor is a cobalt filedescriptor (/socket)

[Lange Norbert]

Hi,

I am opening a packetsocket, which is supposed to be realtime. Unfortunatly if the rtpacket (rtnet?) module is not loaded,
then this will just silently fall back to a linux packet socket. Then later demote thread during accesses.

How would I be able to detect this early during startup? I could __STD(close) the descriptor and check the returncode for EBADF I suppose...


Mit besten Grüßen / Kind regards

NORBERT LANGE
AT-DES

ANDRITZ HYDRO GmbH
Eibesbrunnergasse 20
1120 Vienna / AUSTRIA
p: +43 50805 56684
norbert.lange@andritz.com
andritz.com
________________________________

This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system.

ANDRITZ HYDRO GmbH


Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You
________________________________

Re: Best way to detect if a filedescriptor is a cobalt filedescriptor (/socket)

[Jan Kiszka]

On 09.07.19 16:49, Lange Norbert via Xenomai wrote:
> Hi,
> 
> I am opening a packetsocket, which is supposed to be realtime. Unfortunatly if the rtpacket (rtnet?) module is not loaded,
> then this will just silently fall back to a linux packet socket. Then later demote thread during accesses.
> 
> How would I be able to detect this early during startup? I could __STD(close) the descriptor and check the returncode for EBADF I suppose...
> 

Yeah, looks this is some feature we lost while embedding the RTDM file
descriptor range into the regular Linux space.

We could either add a compile-time or runtime feature to libcobalt that permits
to disable this silent fallback again or introduce alternative open and socket
implementations that do not expose this behavior. Spontaneously, I would be in
favor or a runtime switch for the existing implementations.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

RE: Best way to detect if a filedescriptor is a cobalt filedescriptor (/socket)

[Lange Norbert]

> -----Original Message-----
> From: Jan Kiszka <jan.kiszka@siemens.com>
> Sent: Mittwoch, 10. Juli 2019 08:13
> To: Lange Norbert <norbert.lange@andritz.com>; Xenomai
> (xenomai@xenomai.org) <xenomai@xenomai.org>; Philippe Gerum
> <rpm@xenomai.org>
> Subject: Re: Best way to detect if a filedescriptor is a cobalt filedescriptor
> (/socket)
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> On 09.07.19 16:49, Lange Norbert via Xenomai wrote:
> > Hi,
> >
> > I am opening a packetsocket, which is supposed to be realtime.
> > Unfortunatly if the rtpacket (rtnet?) module is not loaded, then this will
> just silently fall back to a linux packet socket. Then later demote thread
> during accesses.
> >
> > How would I be able to detect this early during startup? I could
> __STD(close) the descriptor and check the returncode for EBADF I suppose...
> >
>
> Yeah, looks this is some feature we lost while embedding the RTDM file
> descriptor range into the regular Linux space.

My scheme does not work either, __STD(close) seems to return 0 for the cobalt fd,
But doesn’t seem to do anything beyond that.

Note: I am using Philippe's "cobalt: switch hand over status to -ENODEV for non-RTDM fd" patch,
so potential it’s a regression of this patch.

> We could either add a compile-time or runtime feature to libcobalt that
> permits to disable this silent fallback again or introduce alternative open and
> socket implementations that do not expose this behavior. Spontaneously, I
> would be in favor or a runtime switch for the existing implementations.

I assumed that __RT(open) would call the __cobalt_open function (without fallback),
__STD(open) would call libc' open, and  __wrap_open would be the only function trying both.
Turns out that __wrap and __cobalt are identical, but I don’t understand the reasoning behind it.

Norbert
________________________________

This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system.

ANDRITZ HYDRO GmbH


Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You
________________________________

Re: Best way to detect if a filedescriptor is a cobalt filedescriptor (/socket)

[Philippe Gerum]

On 7/10/19 11:20 AM, Lange Norbert wrote:
> 
> 
>> -----Original Message-----
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>> Sent: Mittwoch, 10. Juli 2019 08:13
>> To: Lange Norbert <norbert.lange@andritz.com>; Xenomai
>> (xenomai@xenomai.org) <xenomai@xenomai.org>; Philippe Gerum
>> <rpm@xenomai.org>
>> Subject: Re: Best way to detect if a filedescriptor is a cobalt filedescriptor
>> (/socket)
>>
>> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
>> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
>> ATTACHMENTS.
>>
>>
>> On 09.07.19 16:49, Lange Norbert via Xenomai wrote:
>>> Hi,
>>>
>>> I am opening a packetsocket, which is supposed to be realtime.
>>> Unfortunatly if the rtpacket (rtnet?) module is not loaded, then this will
>> just silently fall back to a linux packet socket. Then later demote thread
>> during accesses.
>>>
>>> How would I be able to detect this early during startup? I could
>> __STD(close) the descriptor and check the returncode for EBADF I suppose...
>>>
>>
>> Yeah, looks this is some feature we lost while embedding the RTDM file
>> descriptor range into the regular Linux space.
> 
> My scheme does not work either, __STD(close) seems to return 0 for the cobalt fd,
> But doesn’t seem to do anything beyond that.
> 

The logic is the other way around: ask the Cobalt co-kernel to perform
some action on a (supposedly) Xenomai-registered fd, otherwise have
libcobalt fallback to glibc if the fd is not managed by the co-kernel.
That would be calling __RT(close), not __STD(close) first.

v2 of the patch switching from -EBADF to -ENODEV is needed to have this
working:
https://lab.xenomai.org/xenomai-rpm.git/commit/?h=for-upstream/next&id=0d7384acca2a71323be0d7412fd99aca6f0450d8

Which includes these bits:

diff --git a/kernel/cobalt/rtdm/fd.c b/kernel/cobalt/rtdm/fd.c
index 81943c2f3..06f462d1d 100644
--- a/kernel/cobalt/rtdm/fd.c
+++ b/kernel/cobalt/rtdm/fd.c
@@ -835,7 +835,7 @@ int rtdm_fd_close(int ufd, unsigned int magic)
 	if (magic != 0 && fd->magic != magic) {
 ebadf:
 		xnlock_put_irqrestore(&fdtree_lock, s);
-		return -EBADF;
+		return -ENODEV;
 	}

 	set_compat_bit(fd);


Another other option is to use __RT(fcntl(fd, F_GETFD)): EINVAL would be
returned for this query on a Cobalt-managed fd, otherwise a success code
would denote a regular fd.

> Note: I am using Philippe's "cobalt: switch hand over status to -ENODEV for non-RTDM fd" patch,
> so potential it’s a regression of this patch.
> 
>> We could either add a compile-time or runtime feature to libcobalt that
>> permits to disable this silent fallback again or introduce alternative open and
>> socket implementations that do not expose this behavior. Spontaneously, I
>> would be in favor or a runtime switch for the existing implementations.
> 
> I assumed that __RT(open) would call the __cobalt_open function (without fallback),
> __STD(open) would call libc' open, and  __wrap_open would be the only function trying both.
> Turns out that __wrap and __cobalt are identical, but I don’t understand the reasoning behind it.

To have an opportunity for late binding on the __wrap symbols too, so
that one can override the libcobalt wrappers for interposing its own
version of the cobalt calls. OTOH, __cobalt bindings are guaranteed to
tap into the original libcobalt implementation. Some users need this to
provide their own flavor of Xenomai POSIX system calls on top of libcobalt.

-- 
Philippe.