On Mon, 2007-02-19 at 00:31 +0100, Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > 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.
> 
> The problem is that the root thread is already shadowed in this program
> when pthread_setschedparam is called. So, xnshadow_map is not called and
> the flag is not checked.
> 

Yep. This makes sense, since kernel-wise, sys_munlockall does clear the
VM_LOCKED bit from the caller's mm default flags.

Since this behaviour is specific to the POSIX skin because it silently
shadows the main thread as a Xenomai thread from the SCHED_NORMAL class,
maybe we should check the mm state in the POSIX thread creation routine
too, when SCHED_FIFO or SCHED_RR are passed as the scheduling class.

-- 
Philippe.



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

Reply via email to