[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

LPT versus nptl

More problems with running LTP against nptl (PCC64). When we try to run LPT most kernel tests fail with the message:

WARN : signal() failed for signal 32. error: 22 Invalid argument.
WARN : signal() failed for signal 33. error: 22 Invalid argument.

The root cause is that ltp/lib/tst_sig.c(tst_sig) sets up a signal handler for each signal, except for specific signals where that is not allowed. The problem is that which signals are "reserved" and how this is enforced at runtime differs for linuxthreads and nptl.

For linuxthreads LTP tries to use the following:

         * pthread-private signals SIGPTINTR and SIGPTRESCHED.
         * Setting a handler for these signals is disallowed when
         * the binary is linked against libpthread.
                case SIGPTINTR:
#endif /* SIGPTINTR */
                case SIGPTRESCHED:
#endif /* SIGPTRESCHED */


The first problem being that niether SIGPTINTR or SIGPTRESCHED is defined, anywhere. However LPT does not fail for linuxthreads since it does not enforce any restriction on int __pthread_sig_restart, __pthread_sig_cancel, and __pthread_sig_debug unless the application is actually threaded? (pthread__sigaction is envoked dynamically via libc_maybe_call2, I think?)

NPTL defines SIGCANCEL and SIGTIMER in the private header pthreadP.h which is not available applications at compile time. But NPTL builds a ./signal/sigaction.o which aggressively enforces the restriction on application use of SIGCANCEL and SIGTIMER! (even when the application is not threaded yet???)

The solution not obvious to me. Since NPTL is agressive in its enforcement, LPT will have to be aware of the which library it is linked to. A compile time test would be useful (PTHREAD_LINUXTHREADS vs PTHREAD_NPTL). If that is not acceptable then LTP will have to use the runtime test proposed in in: https://listman.redhat.com/pipermail/phil-list/2003-April/000866.html

However either solution still begs the guestion of how LTP will know the range of signals to avoid ...

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]