Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>  > 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.
> 
> The flag is checked if another thread is created, since xnshadow_map is
> called. The only solution I see at the moment is to remove the call to
> munlockall in the library initialization.
> 

So this piece of code should trigger again?

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

void *thread(void *arg)
{
        struct sched_param param = { .sched_priority = 10 };

        pthread_setschedparam(pthread_self(), SCHED_FIFO, &param);
        printf("shouldn't be printed...\n");
        return NULL;
}

int main(int argc, char *argv[])
{
        pthread_t th;

        pthread_create(&th, NULL, thread, NULL);
        pthread_join(th, NULL);
}


Well, it doesn't in fact, and I think I found my regression again. This
demo behaves as expected over 1.6-06, but remains silent over I-pipe 1.7-02.

Jan