Hi Philippe,

I just verfied that the mlockall issue persists. But it doesn't appear
to be a regression anymore. This little posix demo exposes it now on
both 2.6.20-1.7-02 and 2.6.19-1.6-06 against latest trunk:

#include <stdio.h>
#include <sys/mman.h>
#include <pthread.h>

int main(int argc, char *argv[])
{
        struct sched_param param = { .sched_priority = 10 };

//      mlockall(MCL_CURRENT|MCL_FUTURE);

        pthread_setschedparam(pthread_self(), SCHED_FIFO, &param);

        printf("shouldn't be printed...\n");
        pause();
}


In contrast, the same done via the native skin (rt_task_shadow) triggers
warning and program termination as expected.

It looks to me like the temporary mlockall during libpthread_rt init is
not really reverted (but munlockall is actually called) or not
propagated to the mm state that is later checked on xnshadow_map.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to