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.

-- 


                                            Gilles Chanteperdrix.

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

Reply via email to