This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] malloc: Run fork handler as late as possible [BZ #19431]
- From: Florian Weimer <fweimer at redhat dot com>
- To: Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 10 May 2016 15:55:14 +0200
- Subject: Re: [PATCH] malloc: Run fork handler as late as possible [BZ #19431]
- Authentication-results: sourceware.org; auth=none
- References: <56BBAF3D dot 5030905 at redhat dot com> <1455559833 dot 20971 dot 11 dot camel at localhost dot localdomain> <56C5EE32 dot 1020605 at redhat dot com> <1460485015 dot 3869 dot 267 dot camel at localhost dot localdomain> <570D4944 dot 7070501 at redhat dot com> <1460552111 dot 3869 dot 362 dot camel at localhost dot localdomain> <570E5362 dot 7070300 at redhat dot com> <87lh3ivxlr dot fsf at totoro dot br dot ibm dot com>
On 05/10/2016 03:41 PM, Tulio Magno Quites Machado Filho wrote:
Hi Florian,
Florian Weimer <fweimer@redhat.com> writes:
2016-04-13 Florian Weimer <fweimer@redhat.com>
[BZ #19431]
Run the malloc fork handler as late as possible to avoid deadlocks.
* malloc/malloc-internal.h: New file.
* malloc/malloc.c: Include it.
* malloc/arena.c (ATFORK_MEM): Remove.
(__malloc_fork_lock_parent): Rename from ptmalloc_lock_all.
Update comment.
(__malloc_fork_unlock_parent): Rename from ptmalloc_unlock_all.
(__malloc_fork_unlock_child): Rename from ptmalloc_unlock_all2.
Remove outdated comment.
(ptmalloc_init): Do not call thread_atfork. Remove
thread_atfork_static.
* malloc/tst-malloc-fork-deadlock.c: New file.
* Makefile (tests): Add tst-malloc-fork-deadlock.
(tst-malloc-fork-deadlock): Link against libpthread.
* manual/memory.texi (Aligned Memory Blocks): Update safety
annotation comments.
* sysdeps/nptl/fork.c (__libc_fork): Call
__malloc_fork_lock_parent, __malloc_fork_unlock_parent,
__malloc_fork_unlock_child.
* sysdeps/mach/hurd/fork.c (__fork): Likewise.
Did you notice any intermittent on malloc/tst-mallocfork after this patch?
No, but we saw a failure once on i686 *before* this patch went in.
The child is getting into a deadlock if the signal arrives before the parent
is able to complete __malloc_fork_unlock_parent().
But this could have happened before as well, right?
Thanks,
Florian