Re: [Xenomai-core] Re: I-pipe 1.7 breaks mlockall safety check
On Mon, 2007-02-19 at 01:20 +0100, 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.
Ack, it must be so anyway.
The only solution I see at the moment is to remove the call to
munlockall in the library initialization.
The main thread of a POSIX program cannot have real-time constraints
(i.e. it may be acceptable for it to take page faults, unless otherwise
_explicitely_ specified) so there is no point to trigger SIGXCPU in that
case; the user has to (re)assert mlockall explicitely before creating
real-time threads from the main one, period. I agree that compared to
the usual behaviour of skins, it's a bit disturbing, but this all comes
from the implicit initial shadowing that other skins don't do.
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Re: I-pipe 1.7 breaks mlockall safety check
On Mon, 2007-02-19 at 13:31 +0100, Jan Kiszka wrote:
Jan Kiszka wrote:
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.
May this hunk explain the behaviour?
Yes it is; the original version does overwrite the default flags
properly, not the modified one.
http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/arch/i386/patches/adeos-ipipe-2.6.20-i386-1.7-02.patch?a=i386;v=SVN-2.3.x#7755
munlockall is realised via mlockall, so OR'ing here would never take
away any flag.
Jan
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: I-pipe 1.7 breaks mlockall safety check
On Mon, 2007-02-19 at 23:48 +0100, Gilles Chanteperdrix wrote: Here comes yet another amendment of the nocow patch, which avoid a race between pgd_alloc creating a new pgd, and __ipipe_pin_range_globally not seeing the new pgd because its task is not yet in the task list. Unfortunately, __ipipe_pin_range_globally becomes an architecture dependent function, but at least we should have no race. The patch also fixes the issue with munlockall not clearing the VM_LOCKED flag. Ok, I'm queuing this one for 1.7-04, in order to play safe with 1.7-03 for the upcoming 2.3.1 release. Since the race has always been there anyway, we have some time ahead to shake this fix over 2.4-devel. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Re: I-pipe 1.7 breaks mlockall safety check
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
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Re: I-pipe 1.7 breaks mlockall safety check
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
Re: [Xenomai-core] Re: I-pipe 1.7 breaks mlockall safety check
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
Re: [Xenomai-core] Re: I-pipe 1.7 breaks mlockall safety check
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
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: I-pipe 1.7 breaks mlockall safety check
On Thu, 2007-02-15 at 14:06 +0100, Jan Kiszka wrote: Hi all, I think I found another unwanted side-effect of the no-cow changes: With the I-pipe 1.7 patch series the test for missing mlockall no longer works. I just - once again - wrote a test program that was lacking this call, but only with I-pipe 1.6-06 (same Xenomai version: latest trunk) I get the usual error message on startup. I can't reproduce this with 1.7-01 here. Which Xenomai codebase are you currently using (trunk/, 2.3.x maintenance or stock 2.3)? Jan -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: I-pipe 1.7 breaks mlockall safety check
On Thu, 2007-02-15 at 14:58 +0100, Jan Kiszka wrote: Philippe Gerum wrote: On Thu, 2007-02-15 at 14:06 +0100, Jan Kiszka wrote: Hi all, I think I found another unwanted side-effect of the no-cow changes: With the I-pipe 1.7 patch series the test for missing mlockall no longer works. I just - once again - wrote a test program that was lacking this call, but only with I-pipe 1.6-06 (same Xenomai version: latest trunk) I get the usual error message on startup. I can't reproduce this with 1.7-01 here. Which Xenomai codebase are you currently using (trunk/, 2.3.x maintenance or stock 2.3)? Specifically trunk, but the first observation was over 2.3.x maintenance. The test code is using the posix skin. I still don't find any explanation for that behaviour, only trivially testing with and without mlockall() in a bare main routine though. In relation to this, I've rolled out 1.7-02/x86, so that we could close the last pending issue(s) holding v2.3.1 wrt the interrupt pipeline support. Specifically, the -nocow related changes have been amended, and we are now back to the implementation that prevailed in the 1.6 series wrt vmalloc and ioremap memory, while still retaining the ability to break COW eagerly for the RT threads. Feedback welcome on this. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
