r5430 - in glibc-package/branches/eglibc-2.16/debian: . patches patches/hurd-i386
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 <aurel32@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 <adconrad@0c3.net> Mon, 19 Nov 2012 14:23:26 -0700
+ -- Adam Conrad <adconrad@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 <jk@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 <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.
+
---
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 <rbraun@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 <rbraun@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
Reply to: