Philippe Gerum wrote:
> Jan Kiszka wrote:
>> My customer managed to find another hidden door to Xenomai's hell:
>> Trying to create a Xenomai POSIX thread from within a native thread. A
>> think the other way around would "work" as well. The precise scenario
>> was native thread -> dlopen(libs that's linked against libpthread_rt) ->
>> __init_posix_interface -> __wrap_pthread_setschedparam -> oops. That
>> scenario revealed two more issues in fact.
>> Here is a patch to remove this hell gate by catching xnshadow_map
>> invocations from withing already mapped shadow thread.
> Any reason why the XNMAPPED predicate did not work in your case?
Sorry, which one? Keep in mind that the thread thrown at the second
xnshadow_map is a virgin one, just allocated from scratch.
>> ChangeLog | 5 +++++
>> ksrc/nucleus/shadow.c | 5 +++++
>> 2 files changed, 10 insertions(+)
>> Index: xenomai/ksrc/nucleus/shadow.c
>> --- xenomai.orig/ksrc/nucleus/shadow.c
>> +++ xenomai/ksrc/nucleus/shadow.c
>> @@ -1334,6 +1334,8 @@ void xnshadow_exit(void)
>> * - -EINVAL is returned if the thread control block does not bear the
>> * XNSHADOW bit, or if the thread has already been mapped.
>> + * - -EBUSY is returned if the current Linux task is already mapped.
>> + *
>> * Environments:
>> * This service can be called from:
>> @@ -1351,6 +1353,9 @@ int xnshadow_map(xnthread_t *thread, xnc
>> unsigned muxid, magic;
>> int err;
>> + if (xnshadow_thread(current))
>> + return -EBUSY;
>> if (!xnthread_test_state(thread, XNSHADOW))
>> return -EINVAL;
>> Index: xenomai/ChangeLog
>> --- xenomai.orig/ChangeLog
>> +++ xenomai/ChangeLog
>> @@ -1,3 +1,8 @@
>> +2008-11-21 Jan Kiszka <[EMAIL PROTECTED]>
>> + * ksrc/nucleus/shadow.c (xnshadow_map): Reject already mapped
>> + tasks with -EBUSY.
>> 2008-11-16 Philippe Gerum <[EMAIL PROTECTED]>
>> * ksrc/arch/blackfin/patches: Upgrade to to
Siemens AG, Corporate Technology, CT SE 2 ES-OS
Corporate Competence Center Embedded Linux
Xenomai-core mailing list