diff options
Diffstat (limited to '.topmsg')
| -rw-r--r-- | .topmsg | 82 |
1 files changed, 70 insertions, 12 deletions
@@ -1,12 +1,70 @@ -commit aea5c83461dac53b8619b7bf2ef1fb348ecb4ef1 -Author: Samuel Thibault <samuel.thibault@ens-lyon.org> -Date: Tue Sep 20 21:58:36 2016 +0200 - - Fix exc2signal.c template - - As a follow-up to 0e3426bbcf2ff61d06d580fc9362fde79953a281 - - * hurd/exc2signal.c: #include <hurd/signal.h> - (_hurd_exception2signal): Replace 'exception', 'code', 'subcode', - 'sigcode', 'error' parameters with 'detail' parameter. Fix code - accordingly. +Subject: [PATCH] Global signal dispositions. + +Although they should not change the +default behaviors of signals for cthread programs, these patches add +new functions which can be used by libpthread to enable +POSIX-conforming behavior of signals on a per-thread basis. + +YYYY-MM-DD Jeremie Koenig <jk@jk.fr.eu.org> + + e407ae3 Hurd signals: implement global signal dispositions + 38eb4b3 Hurd signals: provide a sigstate destructor + 344dfd6 Hurd signals: fix sigwait() for global signals + fb055f2 Hurd signals: fix global untraced signals. + +YYYY-MM-DD Thomas Schwinge <thomas@codesourcery.com> + + * sysdeps/mach/hurd/fork.c (__fork): In the child, reinitialize + the global sigstate's lock. + +This is work in progress. + +This cures an issue that would very rarely cause a deadlock in the child +in fork, tries to unlock ss' critical section lock at the end of fork. +This will typically (always?) be observed in /bin/sh, which is not +surprising as that is the foremost caller of fork. + +To reproduce an intermediate state, add an endless loop if +_hurd_global_sigstate is locked after __proc_dostop (cast through +volatile); that is, while still being in the fork's parent process. + +When that triggers (use the libtool testsuite), the signal thread has +already locked ss (which is _hurd_global_sigstate), and is stuck at +hurdsig.c:685 in post_signal, trying to lock _hurd_siglock (which the +main thread already has locked and keeps locked until after +__task_create). This is the case that ss->thread == MACH_PORT_NULL, that +is, a global signal. In the main thread, between __proc_dostop and +__task_create is the __thread_abort call on the signal thread which would +abort any current kernel operation (but leave ss locked). Later in fork, +in the parent, when _hurd_siglock is unlocked in fork, the parent's +signal thread can proceed and will unlock eventually the global sigstate. +In the client, _hurd_siglock will likewise be unlocked, but the global +sigstate never will be, as the client's signal thread has been configured +to restart execution from _hurd_msgport_receive. Thus, when the child +tries to unlock ss' critical section lock at the end of fork, it will +first lock the global sigstate, will spin trying to lock it, which can +never be successful, and we get our deadlock. + +Options seem to be: + + * Move the locking of _hurd_siglock earlier in post_signal -- but that + may generally impact performance, if this locking isn't generally + needed anyway? + + On the other hand, would it actually make sense to wait here until we + are not any longer in a critical section (which is meant to disable + signal delivery anway (but not for preempted signals?))? + + * Clear the global sigstate in the fork's child with the rationale that + we're anyway restarting the signal thread from a clean state. This + has now been implemented. + +Why has this problem not been observed before Jérémie's patches? (Or has +it? Perhaps even more rarely?) In _S_msg_sig_post, the signal is now +posted to a *global receiver thread*, whereas previously it was posted to +the *designated signal-receiving thread*. The latter one was in a +critical section in fork, so didn't try to handle the signal until after +leaving the critical section? (Not completely analyzed and verified.) + +Another question is what the signal is that is being received +during/around the time __proc_dostop executes. |