This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Async signal safe TLS accesses
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: Paul Pluzhnikov <ppluzhnikov at google dot com>, Andrew Hunter <ahh at google dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Sat, 30 Nov 2013 15:50:45 -0200
- Subject: Re: [PATCH] Async signal safe TLS accesses
- Authentication-results: sourceware.org; auth=none
- References: <1382477766-15770-1-git-send-email-ahh at google dot com> <Pine dot LNX dot 4 dot 64 dot 1310222145490 dot 13258 at digraph dot polyomino dot org dot uk> <CALoOobMsO6X86JFD4J7F-EL-J+xOTEOVbzH=6mwrvfCnFvw57Q at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1311052233090 dot 30260 at digraph dot polyomino dot org dot uk> <CALoOobM70-mix+=1zuDnSoK7SRqQChbL=03xBkUcFf1fyS1Mjw at mail dot gmail dot com> <CALoOobP7kdpZCZA0a7MZWCtONu81fW4H_qAWOEfpfvzxJgG_=Q at mail dot gmail dot com> <CALoOobP6rTDosadvLKhHY+deDsU-FtvyO8QX_Y4dZy716e2ATQ at mail dot gmail dot com> <CALoOobOCT-inwMZkzEr+JYT4c8qwpN-EGMPFu_kHQTpc2icj0g at mail dot gmail dot com> <CALoOobPHo7+jG0nfiZp9afC2rArLUMRYZEag21W+78UBTZF=CQ at mail dot gmail dot com> <orvbzckoif dot fsf at livre dot home> <20131129015405 dot GY24286 at brightrain dot aerifal dot cx>
On Nov 28, 2013, Rich Felker <dalias@aerifal.cx> wrote:
> On Thu, Nov 28, 2013 at 11:03:36PM -0200, Alexandre Oliva wrote:
>> Since __signal_safe_malloc is guaranteed to return just-mmapped memory,
>> and that is always zeroed out by the kernel, there's no real need for
>> __signal_safe_calloc to dirty the pages scribbling over them with
>> userland zeros; they're no different from kernel zeros ;-)
> Is this part of the interface contract, or could __signal_safe_malloc
> simply call malloc when outside of a context where malloc would be
> invoked reentrantly?
The implementation of __signal_safe_malloc in the patch I reviewed
called mmap for each allocation. Of course, if we were to optimize out
the redundant memset in __signal_safe_calloc, there should be a comment
in the __signal_safe_memalign implementation indicating that such
callers as __signal_safe_calloc expect zeroed memory.
> IMO the interface contract should be well-defined, and I don't think
> calling malloc should ever be permitted, since then using
> __signal_safe_free would not be possible from a signal handler in
> general.
If we're discussing the interfaces, we might want to add a boolean*
argument that, if non-NULL, will be set to indicate whether the memory
is all-zeroes.
It would be nice if could also make the interface leak-safe in case of
async cancellation (AFAICT that requires taking a pointer-to-pointer and
setting it, rather than returning a pointer that might be lost), but
mmap's interface itself doesn't make this sort of safety possible when
AC is enabled.
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer