Hi
I got report about race condition in LinuxThread's sigaction wrapper located in libpthread/linuxthreads/signals.c
In sigaction wrapper
A.1) override handler for new action to point at pthread_sighandler A.2) __libc_sigaction A.3) update global array (sighandler) used by pthread_sighandler with real action (from new)
pthread_sighandler
B.1) find real action (indexed by signal number) B.2) unconditionally execute action
IIUC, if we receive signal in a window between A.2 and A.3 we are missing executing real action (likely we try to execute NULL).
Does that make sense?
Cheers Vladimir
Hello,
Honestly, I would not recommend anyone to use LinuxThreads today.
It is the "old" way of doing threads in Linux.
Everyone (to my knowledge) is using NPTL now.
Is there a really good reason for you to use LinuxThreads?
Yann
On 25/05/2021 14:49, Vladimir Murzin wrote:
Hi
I got report about race condition in LinuxThread's sigaction wrapper located in libpthread/linuxthreads/signals.c
In sigaction wrapper
A.1) override handler for new action to point at pthread_sighandler A.2) __libc_sigaction A.3) update global array (sighandler) used by pthread_sighandler with real action (from new)
pthread_sighandler
B.1) find real action (indexed by signal number) B.2) unconditionally execute action
IIUC, if we receive signal in a window between A.2 and A.3 we are missing executing real action (likely we try to execute NULL).
Does that make sense?
Cheers Vladimir _______________________________________________ devel mailing list devel@uclibc-ng.org https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
I realize my e-mail could seem a little bit rude.
I apologize if it's the case.
I'm just very surprised someone is still using LinuxThreads.
On 25/05/2021 14:59, Yann Sionneau wrote:
Hello,
Honestly, I would not recommend anyone to use LinuxThreads today.
It is the "old" way of doing threads in Linux.
Everyone (to my knowledge) is using NPTL now.
Is there a really good reason for you to use LinuxThreads?
Yann
On 25/05/2021 14:49, Vladimir Murzin wrote:
Hi
I got report about race condition in LinuxThread's sigaction wrapper located in libpthread/linuxthreads/signals.c
In sigaction wrapper A.1) override handler for new action to point at pthread_sighandler A.2) __libc_sigaction A.3) update global array (sighandler) used by pthread_sighandler with real action (from new) pthread_sighandler
B.1) find real action (indexed by signal number) B.2) unconditionally execute action
IIUC, if we receive signal in a window between A.2 and A.3 we are missing executing real action (likely we try to execute NULL).
Does that make sense?
Cheers Vladimir _______________________________________________ devel mailing list devel@uclibc-ng.org https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
devel mailing list devel@uclibc-ng.org https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
Hi,
On 5/25/21 1:59 PM, Yann Sionneau wrote:
Hello,
Honestly, I would not recommend anyone to use LinuxThreads today.
It is the "old" way of doing threads in Linux.
Everyone (to my knowledge) is using NPTL now.
Is there a really good reason for you to use LinuxThreads?
AFAIK, it is only option for NOMMU targets (well with FDPIC NPTL should be possible, but that another story)
Cheers Vladimir
Yann
On 25/05/2021 14:49, Vladimir Murzin wrote:
Hi
I got report about race condition in LinuxThread's sigaction wrapper located in libpthread/linuxthreads/signals.c
In sigaction wrapper A.1) override handler for new action to point at pthread_sighandler A.2) __libc_sigaction A.3) update global array (sighandler) used by pthread_sighandler with real action (from new) pthread_sighandler
B.1) find real action (indexed by signal number) B.2) unconditionally execute action
IIUC, if we receive signal in a window between A.2 and A.3 we are missing executing real action (likely we try to execute NULL).
Does that make sense?
Cheers Vladimir _______________________________________________ devel mailing list devel@uclibc-ng.org https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel