This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Async signal safe TLS accesses

On Nov 28, 2013, Rich Felker <> 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
You must be the change you wish to see in the world. -- Gandhi
Be Free! --   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]