<div dir="ltr">Can you rebase this to current master, which has glibc 2.26?<div><br></div><div>Ross</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 11 August 2017 at 04:16, Zhixiong Chi <span dir="ltr"><<a href="mailto:zhixiong.chi@windriver.com" target="_blank">zhixiong.chi@windriver.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The patch in this Bugzilla entry was requested by a customer:<br>
<a href="https://sourceware.org/bugzilla/show_bug.cgi?id=4578" rel="noreferrer" target="_blank">https://sourceware.org/<wbr>bugzilla/show_bug.cgi?id=4578</a><br>
<a href="https://www.sourceware.org/bugzilla/show_bug.cgi?id=19282" rel="noreferrer" target="_blank">https://www.sourceware.org/<wbr>bugzilla/show_bug.cgi?id=19282</a><br>
<br>
If a thread happens to hold dl_load_lock and have r_state set to RT_ADD or<br>
RT_DELETE at the time another thread calls fork(), then the child exit code<br>
from fork (in nptl/sysdeps/unix/sysv/linux/<wbr>fork.c in our case) re-initializes<br>
dl_load_lock but does not restore r_state to RT_CONSISTENT. If the child<br>
subsequently requires ld.so functionality before calling exec(), then the<br>
assertion will fire.<br>
<br>
The patch acquires dl_load_lock on entry to fork() and releases it on exit<br>
from the parent path. The child path is initialized as currently done.<br>
This is essentially pthreads_atfork, but forced to be first because the<br>
acquisition of dl_load_lock must happen before malloc_atfork is active<br>
to avoid a deadlock.<br>
<br>
The __libc_fork() code reset dl_load_lock, but it also needed to reset<br>
dl_load_write_lock.<br>
<br>
Signed-off-by: Zhixiong Chi <<a href="mailto:zhixiong.chi@windriver.com">zhixiong.chi@windriver.com</a>><br>
---<br>
.../0001-Bug-4578-add-ld.so-<wbr>lock-while-fork.patch | 57 ++++++++++++++++++++++<br>
...bc-reset-dl-load-write-<wbr>lock-after-forking.patch | 37 ++++++++++++++<br>
meta/recipes-core/glibc/<a href="http://glibc_2.25.90.bb" rel="noreferrer" target="_blank">glibc_<wbr>2.25.90.bb</a> | 2 +<br>
3 files changed, 96 insertions(+)<br>
create mode 100644 meta/recipes-core/glibc/glibc/<wbr>0001-Bug-4578-add-ld.so-lock-<wbr>while-fork.patch<br>
create mode 100644 meta/recipes-core/glibc/glibc/<wbr>0001-glibc-reset-dl-load-<wbr>write-lock-after-forking.patch<br>
<br>
diff --git a/meta/recipes-core/glibc/<wbr>glibc/0001-Bug-4578-add-ld.so-<wbr>lock-while-fork.patch b/meta/recipes-core/glibc/<wbr>glibc/0001-Bug-4578-add-ld.so-<wbr>lock-while-fork.patch<br>
new file mode 100644<br>
index 0000000..ab82866<br>
--- /dev/null<br>
+++ b/meta/recipes-core/glibc/<wbr>glibc/0001-Bug-4578-add-ld.so-<wbr>lock-while-fork.patch<br>
@@ -0,0 +1,57 @@<br>
+The patch in this Bugzilla entry was requested by a customer:<br>
+ <a href="https://sourceware.org/bugzilla/show_bug.cgi?id=4578" rel="noreferrer" target="_blank">https://sourceware.org/<wbr>bugzilla/show_bug.cgi?id=4578</a><br>
+<br>
+If a thread happens to hold dl_load_lock and have r_state set to RT_ADD or<br>
+RT_DELETE at the time another thread calls fork(), then the child exit code<br>
+from fork (in nptl/sysdeps/unix/sysv/linux/<wbr>fork.c in our case) re-initializes<br>
+dl_load_lock but does not restore r_state to RT_CONSISTENT. If the child<br>
+subsequently requires ld.so functionality before calling exec(), then the<br>
+assertion will fire.<br>
+<br>
+The patch acquires dl_load_lock on entry to fork() and releases it on exit<br>
+from the parent path. The child path is initialized as currently done.<br>
+This is essentially pthreads_atfork, but forced to be first because the<br>
+acquisition of dl_load_lock must happen before malloc_atfork is active<br>
+to avoid a deadlock.<br>
+The patch has not yet been integrated upstream.<br>
+<br>
+Upstream-Status: Pending [ Not Author See bugzilla]<br>
+<br>
+Signed-off-by: Raghunath Lolur <<a href="mailto:Raghunath.Lolur@kpit.com">Raghunath.Lolur@kpit.com</a>><br>
+Signed-off-by: Yuanjie Huang <<a href="mailto:yuanjie.huang@windriver.com">yuanjie.huang@windriver.com</a>><br>
+Signed-off-by: Zhixiong Chi <<a href="mailto:zhixiong.chi@windriver.com">zhixiong.chi@windriver.com</a>><br>
+<br>
+Index: git/sysdeps/nptl/fork.c<br>
+=============================<wbr>==============================<wbr>========<br>
+--- git.orig/sysdeps/nptl/fork.c 2017-08-03 16:02:<a href="tel:15.674704080" value="+15674704080">15.674704080</a> +0800<br>
++++ git/sysdeps/nptl/fork.c 2017-08-04 18:15:02.463362015 +0800<br>
+@@ -25,6 +25,7 @@<br>
+ #include <tls.h><br>
+ #include <hp-timing.h><br>
+ #include <ldsodefs.h><br>
++#include <libc-lock.h><br>
+ #include <stdio-lock.h><br>
+ #include <atomic.h><br>
+ #include <nptl/pthreadP.h><br>
+@@ -60,6 +61,10 @@<br>
+ but our current fork implementation is not. */<br>
+ bool multiple_threads = THREAD_GETMEM (THREAD_SELF, header.multiple_threads);<br>
+<br>
++ /* grab ld.so lock BEFORE switching to malloc_atfork */<br>
++ __rtld_lock_lock_recursive (GL(dl_load_lock));<br>
++ __rtld_lock_lock_recursive (GL(dl_load_write_lock));<br>
++<br>
+ /* Run all the registered preparation handlers. In reverse order.<br>
+ While doing this we build up a list of all the entries. */<br>
+ struct fork_handler *runp;<br>
+@@ -258,6 +263,10 @@<br>
+<br>
+ allp = allp->next;<br>
+ }<br>
++<br>
++ /* unlock ld.so last, because we locked it first */<br>
++ __rtld_lock_unlock_recursive (GL(dl_load_write_lock));<br>
++ __rtld_lock_unlock_recursive (GL(dl_load_lock));<br>
+ }<br>
+<br>
+ return pid;<br>
diff --git a/meta/recipes-core/glibc/<wbr>glibc/0001-glibc-reset-dl-<wbr>load-write-lock-after-forking.<wbr>patch b/meta/recipes-core/glibc/<wbr>glibc/0001-glibc-reset-dl-<wbr>load-write-lock-after-forking.<wbr>patch<br>
new file mode 100644<br>
index 0000000..777b253<br>
--- /dev/null<br>
+++ b/meta/recipes-core/glibc/<wbr>glibc/0001-glibc-reset-dl-<wbr>load-write-lock-after-forking.<wbr>patch<br>
@@ -0,0 +1,37 @@<br>
+From a6bb73d1cfd20a73fbbe6076008376<wbr>fb87879d1b Mon Sep 17 00:00:00 2001<br>
+From: Yuanjie Huang <<a href="mailto:yuanjie.huang@windriver.com">yuanjie.huang@windriver.com</a>><br>
+Date: Thu, 18 Aug 2016 17:59:13 +0800<br>
+Subject: [PATCH] reset dl_load_write_lock after forking<br>
+<br>
+The patch in this Bugzilla entry was requested by a customer:<br>
+<br>
+ <a href="https://www.sourceware.org/bugzilla/show_bug.cgi?id=19282" rel="noreferrer" target="_blank">https://www.sourceware.org/<wbr>bugzilla/show_bug.cgi?id=19282</a><br>
+<br>
+The __libc_fork() code reset dl_load_lock, but it also needed to reset<br>
+dl_load_write_lock. The patch has not yet been integrated upstream.<br>
+<br>
+Upstream-Status: Pending [ Not Author See bugzilla]<br>
+<br>
+Signed-off-by: Damodar Sonone <<a href="mailto:damodar.sonone@kpit.com">damodar.sonone@kpit.com</a>><br>
+Signed-off-by: Yuanjie Huang <<a href="mailto:yuanjie.huang@windriver.com">yuanjie.huang@windriver.com</a>><br>
+---<br>
+ sysdeps/nptl/fork.c | 3 ++-<br>
+ 1 file changed, 2 insertions(+), 1 deletion(-)<br>
+<br>
+diff --git a/sysdeps/nptl/fork.c b/sysdeps/nptl/fork.c<br>
+index 2b9ae4b..3d0b8da 100644<br>
+--- a/sysdeps/nptl/fork.c<br>
++++ b/sysdeps/nptl/fork.c<br>
+@@ -174,8 +174,9 @@ __libc_fork (void)<br>
+ /* Reset locks in the I/O code. */<br>
+ _IO_list_resetlock ();<br>
+<br>
+- /* Reset the lock the dynamic loader uses to protect its data. */<br>
++ /* Reset the locks the dynamic loader uses to protect its data. */<br>
+ __rtld_lock_initialize (GL(dl_load_lock));<br>
++ __rtld_lock_initialize (GL(dl_load_write_lock));<br>
+<br>
+ /* Run the handlers registered for the child. */<br>
+ while (allp != NULL)<br>
+--<br>
+1.9.1<br>
diff --git a/meta/recipes-core/glibc/<a href="http://glibc_2.25.90.bb" rel="noreferrer" target="_blank">glib<wbr>c_2.25.90.bb</a> b/meta/recipes-core/glibc/<a href="http://glibc_2.25.90.bb" rel="noreferrer" target="_blank">glib<wbr>c_2.25.90.bb</a><br>
index caf1ff4..1335407 100644<br>
--- a/meta/recipes-core/glibc/<a href="http://glibc_2.25.90.bb" rel="noreferrer" target="_blank">glib<wbr>c_2.25.90.bb</a><br>
+++ b/meta/recipes-core/glibc/<a href="http://glibc_2.25.90.bb" rel="noreferrer" target="_blank">glib<wbr>c_2.25.90.bb</a><br>
@@ -41,6 +41,8 @@ SRC_URI = "${GLIBC_GIT_URI};branch=${<wbr>SRCBRANCH};name=glibc \<br>
file://0023-Define-DUMMY_<wbr>LOCALE_T-if-not-defined.patch \<br>
file://0024-elf-dl-deps.c-<wbr>Make-_dl_build_local_scope-<wbr>breadth-fir.patch \<br>
file://0025-locale-fix-hard-<wbr>coded-reference-to-gcc-E.patch \<br>
+ file://0001-glibc-reset-dl-<wbr>load-write-lock-after-forking.<wbr>patch \<br>
+ file://0001-Bug-4578-add-ld.<wbr>so-lock-while-fork.patch \<br>
"<br>
<br>
NATIVESDKFIXES ?= ""<br>
<span class="HOEnZb"><font color="#888888">--<br>
1.9.1<br>
<br>
--<br>
______________________________<wbr>_________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org">Openembedded-core@lists.<wbr>openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/<wbr>mailman/listinfo/openembedded-<wbr>core</a><br>
</font></span></blockquote></div><br></div>