posix: Skip auto-shadowing if current thread is already shadowed

While the user can also avoid double shadowing by providing the XENO_NOSHADOW environment variable, there is still no reason to attempt auto-shadowing in their absence if the current thread is already a Xenomai thread. This helps, e.g., in complex dlopen scenarios where the POSIX lib is pulled in belatedly, potentially after some other lib already shadowed the dlopen caller.

Quoted 6 lines · Jan Kiszka

While the user can also avoid double shadowing by providing the XENO_NOSHADOW environment variable, there is still no reason to attempt auto-shadowing in their absence if the current thread is already a Xenomai thread. This helps, e.g., in complex dlopen scenarios where the POSIX lib is pulled in belatedly, potentially after some other lib already shadowed the dlopen caller.

Well, last time I checked, calling __wrap_pthread_setschedparam for an already shadowed threads was a nop.

It usefaults the thread stack
though, maybe we can move the faulting of the tread stack to the "promoted" case.

Quoted 10 lines · Gilles Chanteperdrix

Quoted 6 lines · Jan Kiszka

While the user can also avoid double shadowing by providing the XENO_NOSHADOW environment variable, there is still no reason to attempt auto-shadowing in their absence if the current thread is already a Xenomai thread. This helps, e.g., in complex dlopen scenarios where the POSIX lib is pulled in belatedly, potentially after some other lib already shadowed the dlopen caller.

Quoted 2 lines

Well, last time I checked, calling __wrap_pthread_setschedparam for an already shadowed threads was a nop.

I'm getting an EBUSY from xnshadow_map as called by __pthread_shadow. And that, of course, lets the lib init code bail out.

While the user can also avoid double shadowing by providing the XENO_NOSHADOW environment variable, there is still no reason to attempt auto-shadowing in their absence if the current thread is already a Xenomai thread. This helps, e.g., in complex dlopen scenarios where the POSIX lib is pulled in belatedly, potentially after some other lib already shadowed the dlopen caller.

Signed-off-by Jan Kiszka <[email protected]>

---
 src/skins/posix/init.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

src/skins/posix/init.c +1 -0

index 80725c5..ca1d9e1 100644
@@ -31,6 +31,7 @@
 #include <rtdk.h>
 
 #include <asm-generic/xenomai/bind.h>
+#include <asm-generic/xenomai/current.h>
 
 int __pse51_muxid = -1;
 int __pse51_rtdm_muxid = -1;

Quoted 27 lines · Jan Kiszka

While the user can also avoid double shadowing by providing the XENO_NOSHADOW environment variable, there is still no reason to attempt auto-shadowing in their absence if the current thread is already a Xenomai thread. This helps, e.g., in complex dlopen scenarios where the POSIX lib is pulled in belatedly, potentially after some other lib already shadowed the dlopen caller.

Signed-off-by Jan Kiszka<[email protected]>

---
  src/skins/posix/init.c |    3 ++-
  1 files changed, 2 insertions(+), 1 deletions(-)

src/skins/posix/init.c +1 -0

index 80725c5..ca1d9e1 100644
@@ -31,6 +31,7 @@
  #include<rtdk.h>
 
  #include<asm-generic/xenomai/bind.h>
+#include<asm-generic/xenomai/current.h>
 
  int __pse51_muxid = -1;
  int __pse51_rtdm_muxid = -1;

@@ -67,7 +68,7 @@ static __constructor__ void __init_posix_interface(void)
  	}
 

src/skins/posix/init.c static __constructor__ void __init_posix_interface(void) · line 74

Quoted 7 lines

src/skins/posix/init.c +1 -1

  	noshadow = getenv("XENO_NOSHADOW");
-	if (!noshadow || !*noshadow) {
+	if ((!noshadow || !*noshadow)&&  xeno_get_current() == XN_NO_HANDLE) {
  		err = __real_pthread_getschedparam(pthread_self(),&policy,
  						&parm);
  		if (err) {

Ping for this patch. Any concerns remaining?