[Xenomai-help] rt_queue_bind() returns -EACCES

[Xenomai-help] rt_queue_bind() returns -EACCES

[Petr Cervenka]

Hello everyone.

I'm trying linux kernel 2.6.38.8 together with xenomai 2.5.6.
My application tries to reuse already created rt_queue shared between couple of similiar applications.
When I try to recreate already existing rt_queue by rt_queue_create i get -EEXIST error (as I expected).
But if I try to bind it immediately with rt_queue_bind(&queue, QUEUE_NAME, TM_NONBLOCK) I get -EACCES error.
This error code is not in documentation and with the previously used version (kernel 2.6.32.6, xenomai 2.4.10) it was working fine.
Do you have any advice or suggestion?
Thanks in advance.

Petr Cervenka

Re: [Xenomai-help] rt_queue_bind() returns -EACCES

[Philippe Gerum]

On Tue, 2011-08-09 at 17:40 +0200, Petr Cervenka wrote:
> Hello everyone.
> 
> I'm trying linux kernel 2.6.38.8 together with xenomai 2.5.6.
> My application tries to reuse already created rt_queue shared between couple of similiar applications.
> When I try to recreate already existing rt_queue by rt_queue_create i get -EEXIST error (as I expected).
> But if I try to bind it immediately with rt_queue_bind(&queue, QUEUE_NAME, TM_NONBLOCK) I get -EACCES error.
> This error code is not in documentation and with the previously used version (kernel 2.6.32.6, xenomai 2.4.10) it was working fine.
> Do you have any advice or suggestion?

-EACCESS is returned in case an attempt is made to use a binding service
which does not match the target object. E.g. using rt_queue_bind() for
binding an existing task.

> Thanks in advance.
> 
> Petr Cervenka
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help

-- 
Philippe.

Re: [Xenomai-help] rt_queue_bind() returns -EACCES

[Petr Cervenka]

[-- Attachment #1: Type: text/plain, Size: 1968 bytes --]

Hello.

I created a simple examples which describe my problem.
It is some kind of server and client.
At first run a qserver and then qclient.
After that close the qserver and try to run it again.
It disallows (in my configuratio) to create the queue because it already exists and also the binding to it fails with error -EACCES.
This behavior continues till the qclient is closed. It's perhaps caused by the rt_queue_delete() at the end of qserver.

Also I have one question: How to break the rt_queue_bind call with TM_INFINITE parameter, because rt_task_unblock() doesn't work in this case?

______________________________________________________________
> Od: "Philippe Gerum" <rpm@xenomai.org>
> Komu: Petr Cervenka <grugh@domain.hid>
> Datum: 09.08.2011 18:04
> Předmět: Re: [Xenomai-help] rt_queue_bind() returns -EACCES
>
> CC: "xenomai-help" <xenomai@xenomai.org>
>On Tue, 2011-08-09 at 17:40 +0200, Petr Cervenka wrote:
>> Hello everyone.
>> 
>> I'm trying linux kernel 2.6.38.8 together with xenomai 2.5.6.
>> My application tries to reuse already created rt_queue shared between couple of similiar applications.
>> When I try to recreate already existing rt_queue by rt_queue_create i get -EEXIST error (as I expected).
>> But if I try to bind it immediately with rt_queue_bind(&queue, QUEUE_NAME, TM_NONBLOCK) I get -EACCES error.
>> This error code is not in documentation and with the previously used version (kernel 2.6.32.6, xenomai 2.4.10) it was working fine.
>> Do you have any advice or suggestion?
>
>-EACCESS is returned in case an attempt is made to use a binding service
>which does not match the target object. E.g. using rt_queue_bind() for
>binding an existing task.
>
>> Thanks in advance.
>> 
>> Petr Cervenka
>> 
>> _______________________________________________
>> Xenomai-help mailing list
>> Xenomai-help@domain.hid
>> https://mail.gna.org/listinfo/xenomai-help
>
>-- 
>Philippe.
>
>
>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: qserver.cpp --]
[-- Type: text/x-c++src; name="qserver.cpp", Size: 2246 bytes --]

#include <cstdlib>
#include <iostream>
#include <sys/mman.h>

#include <native/task.h>
#include <native/queue.h>
#include <native/timer.h>

using namespace std;

static RT_TASK task;
static RT_QUEUE queue;
static volatile bool end = false;

static void sigHandler(int sig __attribute__((unused))) {
    cout << "signal handler\n";
    end = true;
}

int main(int argc, char** argv) {
    int res;

    // lock memory
    mlockall(MCL_CURRENT | MCL_FUTURE);

    // setup signal handler
    signal(SIGINT, sigHandler);
    signal(SIGTERM, sigHandler);
    signal(SIGHUP, sigHandler);
    signal(SIGALRM, sigHandler);

    // shadow task
    cout << "rt_shadow_task\n";
    res = rt_task_shadow(
            &task,              // task
            "QSERVER",          // name
            10,                 // priority
            T_FPU               // mode T_FPU, T_CPU(i), T_SUSP, ...
            );
    if (res < 0) {
        cerr << "rt_task_shadow() failed: " << res << endl;
        goto cleanup_end;
    }

    // create queue
    cout << "rt_queue_create\n";
    res = rt_queue_create(
            &queue,             // queue
            "QQUEUE",           // name
            1000000,            // pool size
            Q_UNLIMITED,        // qlimit
            Q_FIFO | Q_SHARED   // mode
            );
    if (res == -EEXIST) {
        cout << "queue already exists, trying to bind it\n";
        cout << "rt_queue_bind\n";
        res = rt_queue_bind(&queue, "QQUEUE", TM_NONBLOCK);
    }
    if (res < 0) {
        cerr << "rt_queue_create() or rt_queue_bind() failed: " << res << endl;
        goto cleanup_task;
    }

    // endless loop
    while (!end && (res == 0 || res == -ETIMEDOUT)) {
        cout << ".";
        cout.flush();
        void *msg;
        res = rt_queue_receive(&queue, &msg, rt_timer_ns2ticks(1000000000ll));
        if (res >= 0) {
            cout << "rt_queue_free\n";
            rt_queue_free(&queue, msg);
        } else if (res != -ETIMEDOUT) {
            cerr << "rt_queue_receive() failed: " << res << endl;
        }
    }

cleanup_queue:
    cout << "rt_queue_delete\n";
    rt_queue_delete(&queue);
cleanup_task:
cleanup_end:
    cout << "application exit\n";
    return (EXIT_SUCCESS);
}

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: qclient.cpp --]
[-- Type: text/x-c++src; name="qclient.cpp", Size: 1555 bytes --]

#include <cstdlib>
#include <iostream>
#include <sys/mman.h>

#include <native/task.h>
#include <native/queue.h>
#include <native/timer.h>

using namespace std;

static RT_TASK task;
static RT_QUEUE queue;
static volatile bool end = false;

static void sigHandler(int sig __attribute__((unused))) {
    cout << "signal handler\n";
    end = true;
    rt_task_unblock(&task);
}

int main(int argc, char** argv) {
    int res;

    // lock memory
    mlockall(MCL_CURRENT | MCL_FUTURE);

    // setup signal handler
    signal(SIGINT, sigHandler);
    signal(SIGTERM, sigHandler);
    signal(SIGHUP, sigHandler);
    signal(SIGALRM, sigHandler);

    // shadow task
    cout << "rt_shadow_task\n";
    res = rt_task_shadow(
            &task,          // task
            "QCLIENT",      // name
            10,             // priority
            T_FPU           // mode T_FPU, T_CPU(i), T_SUSP, ...
            );
    if (res < 0) {
        cerr << "rt_task_shadow() failed: " << res << endl;
        goto cleanup_end;
    }

    // bind queue
    cout << "rt_queue_bind\n";
    res = rt_queue_bind(&queue, "QQUEUE", TM_INFINITE);
    if (res < 0) {
        cerr << "rt_queue_bind() failed: " << res << endl;
        goto cleanup_task;
    }

    // endless loop
    while (!end) {
        cout << ".";
        cout.flush();
        rt_task_sleep(rt_timer_ns2ticks(1000000000ll));
    }

cleanup_queue:
    cout << "rt_queue_unbind\n";
    rt_queue_unbind(&queue);
cleanup_task:
cleanup_end:
    cout << "application exit\n";
    return (EXIT_SUCCESS);
}

Re: [Xenomai-help] rt_queue_bind() returns -EACCES

[Philippe Gerum]

On Thu, 2011-08-11 at 10:33 +0200, Petr Cervenka wrote:
> Hello.
> 
> I created a simple examples which describe my problem.
> It is some kind of server and client.
> At first run a qserver and then qclient.
> After that close the qserver and try to run it again.
> It disallows (in my configuratio) to create the queue because it already exists and also the binding to it fails with error -EACCES.
> This behavior continues till the qclient is closed. It's perhaps caused by the rt_queue_delete() at the end of qserver.

That is the intended behavior. When deleted, the queue is maintained
internally until the last client bound to it exits, which also disallows
creating another queue with the same name until the latter event
happens.

However, deleting the queue also makes it unreachable for further
bindings, until it is completely dismantled after the last client exits.
At which point you may re-create a queue with the same name and bind to
it. Logically speaking, that deleted queue does not exist anymore,
except for the currently bound client(s), for consistency reasons.

> 
> Also I have one question: How to break the rt_queue_bind call with TM_INFINITE parameter, because rt_task_unblock() doesn't work in this case?
> 

If the caller is a Xenomai thread, then it should be unblocked with
rt_task_unblock(), otherwise this would be a bug. If this is a plain
linux task, then it would not be allowed to block and immediately return
with -EWOULDBLOCK if the object does not exist.

> ______________________________________________________________
> > Od: "Philippe Gerum" <rpm@xenomai.org>
> > Komu: Petr Cervenka <grugh@domain.hid>
> > Datum: 09.08.2011 18:04
> > Předmět: Re: [Xenomai-help] rt_queue_bind() returns -EACCES
> >
> > CC: "xenomai-help" <xenomai@xenomai.org>
> >On Tue, 2011-08-09 at 17:40 +0200, Petr Cervenka wrote:
> >> Hello everyone.
> >> 
> >> I'm trying linux kernel 2.6.38.8 together with xenomai 2.5.6.
> >> My application tries to reuse already created rt_queue shared between couple of similiar applications.
> >> When I try to recreate already existing rt_queue by rt_queue_create i get -EEXIST error (as I expected).
> >> But if I try to bind it immediately with rt_queue_bind(&queue, QUEUE_NAME, TM_NONBLOCK) I get -EACCES error.
> >> This error code is not in documentation and with the previously used version (kernel 2.6.32.6, xenomai 2.4.10) it was working fine.
> >> Do you have any advice or suggestion?
> >
> >-EACCESS is returned in case an attempt is made to use a binding service
> >which does not match the target object. E.g. using rt_queue_bind() for
> >binding an existing task.
> >
> >> Thanks in advance.
> >> 
> >> Petr Cervenka
> >> 
> >> _______________________________________________
> >> Xenomai-help mailing list
> >> Xenomai-help@domain.hid
> >> https://mail.gna.org/listinfo/xenomai-help
> >
> >-- 
> >Philippe.
> >
> >
> >

-- 
Philippe.

Re: [Xenomai-help] rt_queue_bind() returns -EACCES

[Gilles Chanteperdrix]

On 08/11/2011 11:10 AM, Philippe Gerum wrote:
> On Thu, 2011-08-11 at 10:33 +0200, Petr Cervenka wrote:
>> Hello.
>>
>> I created a simple examples which describe my problem.
>> It is some kind of server and client.
>> At first run a qserver and then qclient.
>> After that close the qserver and try to run it again.
>> It disallows (in my configuratio) to create the queue because it already exists and also the binding to it fails with error -EACCES.
>> This behavior continues till the qclient is closed. It's perhaps caused by the rt_queue_delete() at the end of qserver.
> 
> That is the intended behavior. When deleted, the queue is maintained
> internally until the last client bound to it exits, which also disallows
> creating another queue with the same name until the latter event
> happens.
> 
> However, deleting the queue also makes it unreachable for further
> bindings, until it is completely dismantled after the last client exits.
> At which point you may re-create a queue with the same name and bind to
> it. Logically speaking, that deleted queue does not exist anymore,
> except for the currently bound client(s), for consistency reasons.

Maybe we could return -EIDRM instead of -EEXIST when in this case?

-- 
					    Gilles.

Re: [Xenomai-help] rt_queue_bind() returns -EACCES

[Philippe Gerum]

On Thu, 2011-08-11 at 11:37 +0200, Gilles Chanteperdrix wrote:
> On 08/11/2011 11:10 AM, Philippe Gerum wrote:
> > On Thu, 2011-08-11 at 10:33 +0200, Petr Cervenka wrote:
> >> Hello.
> >>
> >> I created a simple examples which describe my problem.
> >> It is some kind of server and client.
> >> At first run a qserver and then qclient.
> >> After that close the qserver and try to run it again.
> >> It disallows (in my configuratio) to create the queue because it already exists and also the binding to it fails with error -EACCES.
> >> This behavior continues till the qclient is closed. It's perhaps caused by the rt_queue_delete() at the end of qserver.
> > 
> > That is the intended behavior. When deleted, the queue is maintained
> > internally until the last client bound to it exits, which also disallows
> > creating another queue with the same name until the latter event
> > happens.
> > 
> > However, deleting the queue also makes it unreachable for further
> > bindings, until it is completely dismantled after the last client exits.
> > At which point you may re-create a queue with the same name and bind to
> > it. Logically speaking, that deleted queue does not exist anymore,
> > except for the currently bound client(s), for consistency reasons.
> 
> Maybe we could return -EIDRM instead of -EEXIST when in this case?
> 

Not sure. EIDRM is conventionally about telling the caller that some
previously valid identifier has been revoked while the operation was
ongoing, which does not match the case of trying to establish a fresh
binding to a zombie object. In the first case, we did have a valid
object on entry, in the second one, that object has never been valid
from the caller's standpoint.

I'm unsure that returning EIDRM would be trivial to implement anyway. We
would have to make the registry layer aware of the "magic" tags used by
the upstream interfaces, so that it could check atomically EIDRM vs
EEXIST when failing to hash the object key. Granted, we could move this
magic into the xnobject struct directly though and get rid of it
elsewhere. Some work ahead in such a case.

-- 
Philippe.

Re: [Xenomai-help] rt_queue_bind() returns -EACCES

[Philippe Gerum]

On Thu, 2011-08-11 at 12:03 +0200, Philippe Gerum wrote:
> On Thu, 2011-08-11 at 11:37 +0200, Gilles Chanteperdrix wrote:
> > On 08/11/2011 11:10 AM, Philippe Gerum wrote:
> > > On Thu, 2011-08-11 at 10:33 +0200, Petr Cervenka wrote:
> > >> Hello.
> > >>
> > >> I created a simple examples which describe my problem.
> > >> It is some kind of server and client.
> > >> At first run a qserver and then qclient.
> > >> After that close the qserver and try to run it again.
> > >> It disallows (in my configuratio) to create the queue because it already exists and also the binding to it fails with error -EACCES.
> > >> This behavior continues till the qclient is closed. It's perhaps caused by the rt_queue_delete() at the end of qserver.
> > > 
> > > That is the intended behavior. When deleted, the queue is maintained
> > > internally until the last client bound to it exits, which also disallows
> > > creating another queue with the same name until the latter event
> > > happens.
> > > 
> > > However, deleting the queue also makes it unreachable for further
> > > bindings, until it is completely dismantled after the last client exits.
> > > At which point you may re-create a queue with the same name and bind to
> > > it. Logically speaking, that deleted queue does not exist anymore,
> > > except for the currently bound client(s), for consistency reasons.
> > 
> > Maybe we could return -EIDRM instead of -EEXIST when in this case?
> > 
> 
> Not sure. EIDRM is conventionally about telling the caller that some
> previously valid identifier has been revoked while the operation was
> ongoing, which does not match the case of trying to establish a fresh
> binding to a zombie object.

Or trying to create a new object, the same way.

>  In the first case, we did have a valid
> object on entry, in the second one, that object has never been valid
> from the caller's standpoint.
> 
> I'm unsure that returning EIDRM would be trivial to implement anyway. We
> would have to make the registry layer aware of the "magic" tags used by
> the upstream interfaces, so that it could check atomically EIDRM vs
> EEXIST when failing to hash the object key. Granted, we could move this
> magic into the xnobject struct directly though and get rid of it
> elsewhere. Some work ahead in such a case.
> 

-- 
Philippe.

Re: [Xenomai-help] rt_queue_bind() returns -EACCES

[Petr Cervenka]

Hello.

I have couple of notices (or maybe errors) and questions
1) rt_mutex_acquire(...) causes now segmentation fault, when the mutex is not initialized with rt_mutex_create(...)

2) rt_queue_bind(&queue, TM_INFINITE) is not possible to interrupt by rt_task_unblock(...). 
See the qclient example from my previous message, where the signal handler is not able to unblock the main task.

3) Do you have any advice or idea how to create following scheme (or something similar):
I have one server application which creates RT_QUEUE (and listens on it).
Then I have couple of clients which binds to that queue (and possibly could send some request message to it from time to time).
How to ensure the possibility to close the server and open it again?
Because even if I don't call the rt_queue_delete(...) explicitly at the end of server, the result is perhaps the same (when server process finishs).
Thanks in advance for any help.

Best regards
Petr Cervenka

______________________________________________________________
> Od: "Philippe Gerum" <rpm@xenomai.org>
> Komu: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> Datum: 11.08.2011 12:06
> Předmět: Re: [Xenomai-help] rt_queue_bind() returns -EACCES
>
> CC: "xenomai-help" <xenomai@xenomai.org>
>On Thu, 2011-08-11 at 12:03 +0200, Philippe Gerum wrote:
>> On Thu, 2011-08-11 at 11:37 +0200, Gilles Chanteperdrix wrote:
>> > On 08/11/2011 11:10 AM, Philippe Gerum wrote:
>> > > On Thu, 2011-08-11 at 10:33 +0200, Petr Cervenka wrote:
>> > >> Hello.
>> > >>
>> > >> I created a simple examples which describe my problem.
>> > >> It is some kind of server and client.
>> > >> At first run a qserver and then qclient.
>> > >> After that close the qserver and try to run it again.
>> > >> It disallows (in my configuratio) to create the queue because it already exists and also the binding to it fails with error -EACCES.
>> > >> This behavior continues till the qclient is closed. It's perhaps caused by the rt_queue_delete() at the end of qserver.
>> > > 
>> > > That is the intended behavior. When deleted, the queue is maintained
>> > > internally until the last client bound to it exits, which also disallows
>> > > creating another queue with the same name until the latter event
>> > > happens.
>> > > 
>> > > However, deleting the queue also makes it unreachable for further
>> > > bindings, until it is completely dismantled after the last client exits.
>> > > At which point you may re-create a queue with the same name and bind to
>> > > it. Logically speaking, that deleted queue does not exist anymore,
>> > > except for the currently bound client(s), for consistency reasons.
>> > 
>> > Maybe we could return -EIDRM instead of -EEXIST when in this case?
>> > 
>> 
>> Not sure. EIDRM is conventionally about telling the caller that some
>> previously valid identifier has been revoked while the operation was
>> ongoing, which does not match the case of trying to establish a fresh
>> binding to a zombie object.
>
>Or trying to create a new object, the same way.
>
>>  In the first case, we did have a valid
>> object on entry, in the second one, that object has never been valid
>> from the caller's standpoint.
>> 
>> I'm unsure that returning EIDRM would be trivial to implement anyway. We
>> would have to make the registry layer aware of the "magic" tags used by
>> the upstream interfaces, so that it could check atomically EIDRM vs
>> EEXIST when failing to hash the object key. Granted, we could move this
>> magic into the xnobject struct directly though and get rid of it
>> elsewhere. Some work ahead in such a case.
>> 
>
>-- 
>Philippe.
>
>
>