1995-02-18 01:27:10 +00:00
|
|
|
/* _hurd_ctty_output -- Do an output RPC and generate SIGTTOU if necessary.
|
2022-01-01 18:54:23 +00:00
|
|
|
Copyright (C) 1995-2022 Free Software Foundation, Inc.
|
1997-02-15 04:31:36 +00:00
|
|
|
This file is part of the GNU C Library.
|
1995-02-18 01:27:10 +00:00
|
|
|
|
1997-02-15 04:31:36 +00:00
|
|
|
The GNU C Library is free software; you can redistribute it and/or
|
2001-07-06 04:58:11 +00:00
|
|
|
modify it under the terms of the GNU Lesser General Public
|
|
|
|
|
License as published by the Free Software Foundation; either
|
|
|
|
|
version 2.1 of the License, or (at your option) any later version.
|
1995-02-18 01:27:10 +00:00
|
|
|
|
1997-02-15 04:31:36 +00:00
|
|
|
The GNU C Library is distributed in the hope that it will be useful,
|
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
2001-07-06 04:58:11 +00:00
|
|
|
Lesser General Public License for more details.
|
1995-02-18 01:27:10 +00:00
|
|
|
|
2001-07-06 04:58:11 +00:00
|
|
|
You should have received a copy of the GNU Lesser General Public
|
2012-02-09 23:18:22 +00:00
|
|
|
License along with the GNU C Library; if not, see
|
Prefer https to http for gnu.org and fsf.org URLs
Also, change sources.redhat.com to sourceware.org.
This patch was automatically generated by running the following shell
script, which uses GNU sed, and which avoids modifying files imported
from upstream:
sed -ri '
s,(http|ftp)(://(.*\.)?(gnu|fsf|sourceware)\.org($|[^.]|\.[^a-z])),https\2,g
s,(http|ftp)(://(.*\.)?)sources\.redhat\.com($|[^.]|\.[^a-z]),https\2sourceware.org\4,g
' \
$(find $(git ls-files) -prune -type f \
! -name '*.po' \
! -name 'ChangeLog*' \
! -path COPYING ! -path COPYING.LIB \
! -path manual/fdl-1.3.texi ! -path manual/lgpl-2.1.texi \
! -path manual/texinfo.tex ! -path scripts/config.guess \
! -path scripts/config.sub ! -path scripts/install-sh \
! -path scripts/mkinstalldirs ! -path scripts/move-if-change \
! -path INSTALL ! -path locale/programs/charmap-kw.h \
! -path po/libc.pot ! -path sysdeps/gnu/errlist.c \
! '(' -name configure \
-execdir test -f configure.ac -o -f configure.in ';' ')' \
! '(' -name preconfigure \
-execdir test -f preconfigure.ac ';' ')' \
-print)
and then by running 'make dist-prepare' to regenerate files built
from the altered files, and then executing the following to cleanup:
chmod a+x sysdeps/unix/sysv/linux/riscv/configure
# Omit irrelevant whitespace and comment-only changes,
# perhaps from a slightly-different Autoconf version.
git checkout -f \
sysdeps/csky/configure \
sysdeps/hppa/configure \
sysdeps/riscv/configure \
sysdeps/unix/sysv/linux/csky/configure
# Omit changes that caused a pre-commit check to fail like this:
# remote: *** error: sysdeps/powerpc/powerpc64/ppc-mcount.S: trailing lines
git checkout -f \
sysdeps/powerpc/powerpc64/ppc-mcount.S \
sysdeps/unix/sysv/linux/s390/s390-64/syscall.S
# Omit change that caused a pre-commit check to fail like this:
# remote: *** error: sysdeps/sparc/sparc64/multiarch/memcpy-ultra3.S: last line does not end in newline
git checkout -f sysdeps/sparc/sparc64/multiarch/memcpy-ultra3.S
2019-09-07 05:40:42 +00:00
|
|
|
<https://www.gnu.org/licenses/>. */
|
1995-02-18 01:27:10 +00:00
|
|
|
|
|
|
|
|
#include <hurd.h>
|
|
|
|
|
#include <hurd/signal.h>
|
|
|
|
|
|
|
|
|
|
/* Call *RPC on PORT and/or CTTY. If a call on CTTY returns EBACKGROUND,
|
|
|
|
|
generate SIGTTOU if appropriate. */
|
|
|
|
|
|
|
|
|
|
error_t
|
|
|
|
|
_hurd_ctty_output (io_t port, io_t ctty, error_t (*rpc) (io_t))
|
|
|
|
|
{
|
|
|
|
|
if (ctty == MACH_PORT_NULL)
|
1999-03-08 21:02:22 +00:00
|
|
|
return (*rpc) (port);
|
1995-02-18 01:27:10 +00:00
|
|
|
else
|
|
|
|
|
{
|
1999-03-08 21:02:22 +00:00
|
|
|
struct hurd_sigstate *ss = _hurd_self_sigstate ();
|
|
|
|
|
error_t err;
|
1995-02-18 01:27:10 +00:00
|
|
|
|
1999-03-08 21:02:22 +00:00
|
|
|
do
|
1995-02-18 01:27:10 +00:00
|
|
|
{
|
hurd: Global signal disposition
This adds _hurd_sigstate_set_global_rcv used by libpthread to enable
POSIX-confirming behavior of signals on a per-thread basis.
This also provides a sigstate destructor _hurd_sigstate_delete, and a
global process signal state, which needs to be locked and check when
global disposition is enabled, thus the addition of _hurd_sigstate_lock
_hurd_sigstate_actions _hurd_sigstate_pending _hurd_sigstate_unlock helpers.
This also updates all the glibc code accordingly.
This also drops support for get_int(INIT_SIGMASK), which did not make sense
any more since we do not have a single signal thread any more.
During fork/spawn, this also reinitializes the child global sigstate's
lock. That 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 anyway (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.
2019-12-29 16:59:55 +00:00
|
|
|
struct sigaction *actions;
|
|
|
|
|
|
1999-03-08 21:02:22 +00:00
|
|
|
/* Don't use the ctty io port if we are blocking or ignoring
|
|
|
|
|
SIGTTOU. We redo this check at the top of the loop in case
|
|
|
|
|
the signal handler changed the state. */
|
hurd: Global signal disposition
This adds _hurd_sigstate_set_global_rcv used by libpthread to enable
POSIX-confirming behavior of signals on a per-thread basis.
This also provides a sigstate destructor _hurd_sigstate_delete, and a
global process signal state, which needs to be locked and check when
global disposition is enabled, thus the addition of _hurd_sigstate_lock
_hurd_sigstate_actions _hurd_sigstate_pending _hurd_sigstate_unlock helpers.
This also updates all the glibc code accordingly.
This also drops support for get_int(INIT_SIGMASK), which did not make sense
any more since we do not have a single signal thread any more.
During fork/spawn, this also reinitializes the child global sigstate's
lock. That 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 anyway (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.
2019-12-29 16:59:55 +00:00
|
|
|
_hurd_sigstate_lock (ss);
|
|
|
|
|
actions = _hurd_sigstate_actions (ss);
|
Break some lines before not after operators.
The GNU Coding Standards specify that line breaks in expressions
should go before an operator, not after one. This patch fixes various
code to do this. It only changes code that appears to be mostly
following GNU style anyway, not files and directories with
substantially different formatting. It is not exhaustive even for
files using GNU style (for example, changes to sysdeps files are
deferred for subsequent cleanups). Some files changed are shared with
gnulib, but most are specific to glibc. Changes were made manually,
with places to change found by grep (so some cases, e.g. where the
operator was followed by a comment at end of line, are particularly
liable to have been missed by grep, but I did include cases where the
operator was followed by backslash-newline).
This patch generally does not attempt to address other coding style
issues in the expressions changed (for example, missing spaces before
'(', or lack of parentheses to ensure indentation of continuation
lines properly reflects operator precedence).
Tested for x86_64, and with build-many-glibcs.py.
* benchtests/bench-memmem.c (simple_memmem): Break lines before
rather than after operators.
* benchtests/bench-skeleton.c (TIMESPEC_AFTER): Likewise.
* crypt/md5.c (md5_finish_ctx): Likewise.
* crypt/sha256.c (__sha256_finish_ctx): Likewise.
* crypt/sha512.c (__sha512_finish_ctx): Likewise.
* elf/cache.c (load_aux_cache): Likewise.
* elf/dl-load.c (open_verify): Likewise.
* elf/get-dynamic-info.h (elf_get_dynamic_info): Likewise.
* elf/readelflib.c (process_elf_file): Likewise.
* elf/rtld.c (dl_main): Likewise.
* elf/sprof.c (generate_call_graph): Likewise.
* hurd/ctty-input.c (_hurd_ctty_input): Likewise.
* hurd/ctty-output.c (_hurd_ctty_output): Likewise.
* hurd/dtable.c (reauth_dtable): Likewise.
* hurd/getdport.c (__getdport): Likewise.
* hurd/hurd/signal.h (_hurd_interrupted_rpc_timeout): Likewise.
* hurd/hurd/sigpreempt.h (HURD_PREEMPT_SIGNAL_P): Likewise.
* hurd/hurdfault.c (_hurdsig_fault_catch_exception_raise):
Likewise.
* hurd/hurdioctl.c (fioctl): Likewise.
* hurd/hurdselect.c (_hurd_select): Likewise.
* hurd/hurdsig.c (_hurdsig_abort_rpcs): Likewise.
(STOPSIGS): Likewise.
* hurd/hurdstartup.c (_hurd_startup): Likewise.
* hurd/intr-msg.c (_hurd_intr_rpc_mach_msg): Likewise.
* hurd/lookup-retry.c (__hurd_file_name_lookup_retry): Likewise.
* hurd/msgportdemux.c (msgport_server): Likewise.
* hurd/setauth.c (_hurd_setauth): Likewise.
* include/features.h (__GLIBC_USE_DEPRECATED_SCANF): Likewise.
* libio/libioP.h [IO_DEBUG] (CHECK_FILE): Likewise.
* locale/programs/ld-ctype.c (set_class_defaults): Likewise.
* localedata/tests-mbwc/tst_swscanf.c (tst_swscanf): Likewise.
* login/tst-utmp.c (do_check): Likewise.
(simulate_login): Likewise.
* mach/lowlevellock.h (lll_lock): Likewise.
(lll_trylock): Likewise.
* math/test-fenv.c (ALL_EXC): Likewise.
* math/test-fenvinline.c (ALL_EXC): Likewise.
* misc/sys/cdefs.h (__attribute_deprecated_msg__): Likewise.
* nis/nis_call.c (__do_niscall3): Likewise.
* nis/nis_callback.c (cb_prog_1): Likewise.
* nis/nis_defaults.c (searchaccess): Likewise.
* nis/nis_findserv.c (__nis_findfastest_with_timeout): Likewise.
* nis/nis_ismember.c (internal_ismember): Likewise.
* nis/nis_local_names.c (nis_local_principal): Likewise.
* nis/nss_nis/nis-rpc.c (_nss_nis_getrpcbyname_r): Likewise.
* nis/nss_nisplus/nisplus-netgrp.c (_nss_nisplus_getnetgrent_r):
Likewise.
* nis/ypclnt.c (yp_match): Likewise.
(yp_first): Likewise.
(yp_next): Likewise.
(yp_master): Likewise.
(yp_order): Likewise.
* nscd/hstcache.c (cache_addhst): Likewise.
* nscd/initgrcache.c (addinitgroupsX): Likewise.
* nss/nss_compat/compat-pwd.c (copy_pwd_changes): Likewise.
(internal_getpwuid_r): Likewise.
* nss/nss_compat/compat-spwd.c (copy_spwd_changes): Likewise.
* posix/glob.h (__GLOB_FLAGS): Likewise.
* posix/regcomp.c (peek_token): Likewise.
(peek_token_bracket): Likewise.
(parse_expression): Likewise.
* posix/regexec.c (sift_states_iter_mb): Likewise.
(check_node_accept_bytes): Likewise.
* posix/tst-spawn3.c (do_test): Likewise.
* posix/wordexp-test.c (testit): Likewise.
* posix/wordexp.c (parse_tilde): Likewise.
(exec_comm): Likewise.
* posix/wordexp.h (__WRDE_FLAGS): Likewise.
* resource/vtimes.c (TIMEVAL_TO_VTIMES): Likewise.
* setjmp/sigjmp.c (__sigjmp_save): Likewise.
* stdio-common/printf_fp.c (__printf_fp_l): Likewise.
* stdio-common/tst-fileno.c (do_test): Likewise.
* stdio-common/vfprintf-internal.c (vfprintf): Likewise.
* stdlib/strfmon_l.c (__vstrfmon_l_internal): Likewise.
* stdlib/strtod_l.c (round_and_return): Likewise.
(____STRTOF_INTERNAL): Likewise.
* stdlib/tst-strfrom.h (TEST_STRFROM): Likewise.
* string/strcspn.c (STRCSPN): Likewise.
* string/test-memmem.c (simple_memmem): Likewise.
* termios/tcsetattr.c (tcsetattr): Likewise.
* time/alt_digit.c (_nl_parse_alt_digit): Likewise.
* time/asctime.c (asctime_internal): Likewise.
* time/strptime_l.c (__strptime_internal): Likewise.
* time/sys/time.h (timercmp): Likewise.
* time/tzfile.c (__tzfile_compute): Likewise.
2019-02-22 01:32:36 +00:00
|
|
|
if (__sigismember (&ss->blocked, SIGTTOU)
|
hurd: Global signal disposition
This adds _hurd_sigstate_set_global_rcv used by libpthread to enable
POSIX-confirming behavior of signals on a per-thread basis.
This also provides a sigstate destructor _hurd_sigstate_delete, and a
global process signal state, which needs to be locked and check when
global disposition is enabled, thus the addition of _hurd_sigstate_lock
_hurd_sigstate_actions _hurd_sigstate_pending _hurd_sigstate_unlock helpers.
This also updates all the glibc code accordingly.
This also drops support for get_int(INIT_SIGMASK), which did not make sense
any more since we do not have a single signal thread any more.
During fork/spawn, this also reinitializes the child global sigstate's
lock. That 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 anyway (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.
2019-12-29 16:59:55 +00:00
|
|
|
|| actions[SIGTTOU].sa_handler == SIG_IGN)
|
1995-02-18 01:27:10 +00:00
|
|
|
err = EIO;
|
|
|
|
|
else
|
1999-03-08 21:02:22 +00:00
|
|
|
err = 0;
|
hurd: Global signal disposition
This adds _hurd_sigstate_set_global_rcv used by libpthread to enable
POSIX-confirming behavior of signals on a per-thread basis.
This also provides a sigstate destructor _hurd_sigstate_delete, and a
global process signal state, which needs to be locked and check when
global disposition is enabled, thus the addition of _hurd_sigstate_lock
_hurd_sigstate_actions _hurd_sigstate_pending _hurd_sigstate_unlock helpers.
This also updates all the glibc code accordingly.
This also drops support for get_int(INIT_SIGMASK), which did not make sense
any more since we do not have a single signal thread any more.
During fork/spawn, this also reinitializes the child global sigstate's
lock. That 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 anyway (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.
2019-12-29 16:59:55 +00:00
|
|
|
_hurd_sigstate_unlock (ss);
|
1999-03-08 21:02:22 +00:00
|
|
|
|
|
|
|
|
if (err)
|
|
|
|
|
return (*rpc) (port);
|
|
|
|
|
|
|
|
|
|
err = (*rpc) (ctty);
|
|
|
|
|
if (err == EBACKGROUND)
|
1995-02-18 01:27:10 +00:00
|
|
|
{
|
1999-03-08 21:02:22 +00:00
|
|
|
if (_hurd_orphaned)
|
|
|
|
|
/* Our process group is orphaned, so we never generate a
|
|
|
|
|
signal; we just fail. */
|
|
|
|
|
err = EIO;
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
/* Send a SIGTTOU signal to our process group.
|
1997-02-15 04:31:36 +00:00
|
|
|
|
1999-03-08 21:02:22 +00:00
|
|
|
We must remember here not to clobber ERR, since
|
|
|
|
|
the loop condition below uses it to recall that
|
|
|
|
|
we should retry after a stop. */
|
1995-02-18 01:27:10 +00:00
|
|
|
|
1999-03-08 21:02:22 +00:00
|
|
|
__USEPORT (CTTYID, _hurd_sig_post (0, SIGTTOU, port));
|
|
|
|
|
/* XXX what to do if error here? */
|
1995-02-18 01:27:10 +00:00
|
|
|
|
1999-03-08 21:02:22 +00:00
|
|
|
/* At this point we should have just run the handler for
|
|
|
|
|
SIGTTOU or resumed after being stopped. Now this is
|
|
|
|
|
still a "system call", so check to see if we should
|
|
|
|
|
restart it. */
|
hurd: Global signal disposition
This adds _hurd_sigstate_set_global_rcv used by libpthread to enable
POSIX-confirming behavior of signals on a per-thread basis.
This also provides a sigstate destructor _hurd_sigstate_delete, and a
global process signal state, which needs to be locked and check when
global disposition is enabled, thus the addition of _hurd_sigstate_lock
_hurd_sigstate_actions _hurd_sigstate_pending _hurd_sigstate_unlock helpers.
This also updates all the glibc code accordingly.
This also drops support for get_int(INIT_SIGMASK), which did not make sense
any more since we do not have a single signal thread any more.
During fork/spawn, this also reinitializes the child global sigstate's
lock. That 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 anyway (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.
2019-12-29 16:59:55 +00:00
|
|
|
_hurd_sigstate_lock (ss);
|
|
|
|
|
actions = _hurd_sigstate_actions (ss);
|
|
|
|
|
if (!(actions[SIGTTOU].sa_flags & SA_RESTART))
|
1999-03-08 21:02:22 +00:00
|
|
|
err = EINTR;
|
hurd: Global signal disposition
This adds _hurd_sigstate_set_global_rcv used by libpthread to enable
POSIX-confirming behavior of signals on a per-thread basis.
This also provides a sigstate destructor _hurd_sigstate_delete, and a
global process signal state, which needs to be locked and check when
global disposition is enabled, thus the addition of _hurd_sigstate_lock
_hurd_sigstate_actions _hurd_sigstate_pending _hurd_sigstate_unlock helpers.
This also updates all the glibc code accordingly.
This also drops support for get_int(INIT_SIGMASK), which did not make sense
any more since we do not have a single signal thread any more.
During fork/spawn, this also reinitializes the child global sigstate's
lock. That 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 anyway (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.
2019-12-29 16:59:55 +00:00
|
|
|
_hurd_sigstate_unlock (ss);
|
1999-03-08 21:02:22 +00:00
|
|
|
}
|
1995-02-18 01:27:10 +00:00
|
|
|
}
|
1999-03-08 21:02:22 +00:00
|
|
|
/* If the last RPC generated a SIGTTOU, loop to try it again. */
|
|
|
|
|
} while (err == EBACKGROUND);
|
1995-02-18 01:27:10 +00:00
|
|
|
|
1999-03-08 21:02:22 +00:00
|
|
|
return err;
|
|
|
|
|
}
|
1995-02-18 01:27:10 +00:00
|
|
|
}
|
