Author: adconrad Date: 2012-12-30 17:22:23 +0000 (Sun, 30 Dec 2012) New Revision: 5430
Added: glibc-package/branches/eglibc-2.16/debian/patches/hurd-i386/unsubmitted-setitimer_fix.diff glibc-package/branches/eglibc-2.16/debian/patches/hurd-i386/unsubmitted-single-hurdselect-timeout.diff Modified: glibc-package/branches/eglibc-2.16/debian/changelog glibc-package/branches/eglibc-2.16/debian/patches/hurd-i386/tg-hurdsig-global-dispositions.diff glibc-package/branches/eglibc-2.16/debian/patches/series Log: Merge 2.13-38 from unstable Modified: glibc-package/branches/eglibc-2.16/debian/changelog =================================================================== --- glibc-package/branches/eglibc-2.16/debian/changelog 2012-12-30 17:06:09 UTC (rev 5429) +++ glibc-package/branches/eglibc-2.16/debian/changelog 2012-12-30 17:22:23 UTC (rev 5430) @@ -450,7 +450,7 @@ -- Aurelien Jarno <aure...@debian.org> Tue, 20 Nov 2012 08:48:56 +0100 -eglibc (2.13-38) UNRELEASED; urgency=low +eglibc (2.13-38) unstable; urgency=low [ Adam Conrad ] * debian/patches/arm/cvs-ldconfig-cache-abi.diff: Backport upstream @@ -463,6 +463,9 @@ [ Jonathan Nieder ] * control.in/opt: correct misspelling of "Ezra" in descriptions of *-i686 variants. Thanks to Thorsten Glaser. + * patches/any/local-tst-eintr1-eagain.diff: new patch to work around + a race that lets pthread_create hit resource limits when the kernel + takes too long to clean up after joined threads. (closes: #673596) [ Samuel Thibault ] * patches/any/local-fhs-linux-paths.diff: Patch vardb path on !linux too. @@ -473,8 +476,14 @@ * libc0.3.symbols.hurd-i386: Add libpthread.so.0.3 symbols. * Add patches/hurd-i386/tg-hurdsig-boot-fix.diff to fix sigstate_is_global_rcv at boot in libpthread-based translators. + * patches/hurd-i386/tg-hurdsig-global-dispositions.diff: Update with Thomas' + fork deadlock fix. + * patches/hurd-i386/unsubmitted-single-hurdselect-timeout.diff: Temporarily + fix double select timeout on single fd. + * patches/hurd-i386/unsubmitted-setitimer_fix.diff: Fix Hurd implementation + of setitimer. - -- Adam Conrad <adcon...@0c3.net> Mon, 19 Nov 2012 14:23:26 -0700 + -- Adam Conrad <adcon...@0c3.net> Sun, 30 Dec 2012 06:06:32 -0700 eglibc (2.13-37) unstable; urgency=low Modified: glibc-package/branches/eglibc-2.16/debian/patches/hurd-i386/tg-hurdsig-global-dispositions.diff =================================================================== --- glibc-package/branches/eglibc-2.16/debian/patches/hurd-i386/tg-hurdsig-global-dispositions.diff 2012-12-30 17:06:09 UTC (rev 5429) +++ glibc-package/branches/eglibc-2.16/debian/patches/hurd-i386/tg-hurdsig-global-dispositions.diff 2012-12-30 17:22:23 UTC (rev 5430) @@ -1,4 +1,3 @@ -From: Jeremie Koenig <j...@jk.fr.eu.org> Subject: [PATCH] Global signal dispositions. Although they should not change the @@ -6,11 +5,70 @@ 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 <j...@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 <tho...@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. + --- hurd/ctty-input.c | 18 +- hurd/ctty-output.c | 18 +- @@ -831,17 +889,32 @@ /* Claim our sigstate structure and unchain the rest: the threads existed in the parent task but don't exist in this task (the child process). Delay freeing them until later -@@ -644,6 +641,10 @@ +@@ -638,6 +635,25 @@ __fork (void) + ss->next = NULL; _hurd_sigstates = ss; __mutex_unlock (&_hurd_siglock); - ++ /* Earlier on, the global sigstate may have been tainted and now needs to ++ be reinitialized. Nobody is interested in its present state anymore: ++ we're not, the signal thread will be restarted, and there are no other ++ threads. ++ ++ We can't simply allocate a fresh global sigstate here, as ++ _hurd_thread_sigstate will call malloc and that will deadlock trying ++ to determine the current thread's sigstate. */ ++#if 0 ++ _hurd_thread_sigstate_init (_hurd_global_sigstate, MACH_PORT_NULL); ++#else ++ /* Only reinitialize the lock -- otherwise we might have to do additional ++ setup as done in hurdsig.c:_hurdsig_init. */ ++ __spin_lock_init (&_hurd_global_sigstate->lock); ++#endif ++ + /* We are one of the (exactly) two threads in this new task, we + will take the task-global signals. */ + _hurd_sigstate_set_global_rcv (ss); -+ + /* Fetch our new process IDs from the proc server. No need to refetch our pgrp; it is always inherited from the parent (so - _hurd_pgrp is already correct), and the proc server will send us a --- a/sysdeps/mach/hurd/i386/sigreturn.c +++ b/sysdeps/mach/hurd/i386/sigreturn.c @@ -1,4 +1,5 @@ Copied: glibc-package/branches/eglibc-2.16/debian/patches/hurd-i386/unsubmitted-setitimer_fix.diff (from rev 5429, glibc-package/trunk/debian/patches/hurd-i386/unsubmitted-setitimer_fix.diff) =================================================================== --- glibc-package/branches/eglibc-2.16/debian/patches/hurd-i386/unsubmitted-setitimer_fix.diff (rev 0) +++ glibc-package/branches/eglibc-2.16/debian/patches/hurd-i386/unsubmitted-setitimer_fix.diff 2012-12-30 17:22:23 UTC (rev 5430) @@ -0,0 +1,34 @@ +commit c09eae7f3f6c714da378baa492414f73974f3a69 +Author: Richard Braun <rbr...@sceen.net> +Date: Wed Dec 26 16:31:14 2012 +0000 + + Fix Hurd implementation of setitimer. + + The preemptor sigcode doesn't match since the POSIX sigcode SI_TIMER is + used when SIGALRM is sent. In addition, The inline version of + hurd_preempt_signals doesn't update _hurdsig_preempted_set. For these + reasons, the preemptor would be skipped by post_signal. + + * sysdeps/mach/hurd/setitimer.c (setitimer_locked): Fix preemptor setup. + +diff --git a/sysdeps/mach/hurd/setitimer.c b/sysdeps/mach/hurd/setitimer.c +index fe057c9..8c0d92d 100644 +--- a/sysdeps/mach/hurd/setitimer.c ++++ b/sysdeps/mach/hurd/setitimer.c +@@ -192,7 +192,7 @@ setitimer_locked (const struct itimerval *new, struct itimerval *old, + run `restart_itimer' each time a SIGALRM would arrive. */ + static struct hurd_signal_preemptor preemptor = + { +- __sigmask (SIGALRM), 0, 0, ++ __sigmask (SIGALRM), SI_TIMER, SI_TIMER, + &restart_itimer, + }; + __mutex_lock (&_hurd_siglock); +@@ -200,6 +200,7 @@ setitimer_locked (const struct itimerval *new, struct itimerval *old, + { + preemptor.next = _hurdsig_preemptors; + _hurdsig_preemptors = &preemptor; ++ _hurdsig_preempted_set |= preemptor.signals; + } + __mutex_unlock (&_hurd_siglock); + Copied: glibc-package/branches/eglibc-2.16/debian/patches/hurd-i386/unsubmitted-single-hurdselect-timeout.diff (from rev 5429, glibc-package/trunk/debian/patches/hurd-i386/unsubmitted-single-hurdselect-timeout.diff) =================================================================== --- glibc-package/branches/eglibc-2.16/debian/patches/hurd-i386/unsubmitted-single-hurdselect-timeout.diff (rev 0) +++ glibc-package/branches/eglibc-2.16/debian/patches/hurd-i386/unsubmitted-single-hurdselect-timeout.diff 2012-12-30 17:22:23 UTC (rev 5430) @@ -0,0 +1,35 @@ +commit fffcbbb0b5ff8864086f7b58fdbb8aa4c71943d0 +Author: Richard Braun <rbr...@sceen.net> +Date: Mon Dec 17 09:57:41 2012 +0000 + + Fix _hurd_select for single fd sets + + The function attempts to optimize this case by performing one IPC system call + with the timeout included among the parameters, but in the absence of a reply, + it will call mach_msg again with the same timeout later, effectively doubling + the total timeout of the select/poll call. + + Remove this optimization for the time being. + + * hurd/hurdselect.c (_hurd_select): Always call __io_select with no timeout. + +--- + hurdselect.c | 5 +---- + 1 file changed, 1 insertion(+), 4 deletions(-) + +diff --git a/hurd/hurdselect.c b/hurd/hurdselect.c +index 21ba5f4..a02c7be 100644 +--- a/hurd/hurdselect.c ++++ b/hurd/hurdselect.c +@@ -236,10 +236,7 @@ _hurd_select (int nfds, + { + int type = d[i].type; + d[i].reply_port = __mach_reply_port (); +- err = __io_select (d[i].io_port, d[i].reply_port, +- /* Poll only if there's a single descriptor. */ +- (firstfd == lastfd) ? to : 0, +- &type); ++ err = __io_select (d[i].io_port, d[i].reply_port, 0, &type); + switch (err) + { + case MACH_RCV_TIMED_OUT: Modified: glibc-package/branches/eglibc-2.16/debian/patches/series =================================================================== --- glibc-package/branches/eglibc-2.16/debian/patches/series 2012-12-30 17:06:09 UTC (rev 5429) +++ glibc-package/branches/eglibc-2.16/debian/patches/series 2012-12-30 17:22:23 UTC (rev 5430) @@ -130,6 +130,8 @@ hurd-i386/cvs-mknodat.diff hurd-i386/cvs-llistxattr.diff hurd-i386/local-ulimit.diff +hurd-i386/unsubmitted-single-hurdselect-timeout.diff +hurd-i386/unsubmitted-setitimer_fix.diff i386/local-biarch.diff i386/local-cmov.diff -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1tpmae-0006oy...@vasks.debian.org