From: Oren Laadan <orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
To: Nathan Lynch <nathanl-V7BBcbaFuwjMbYB6QlFGEg@public.gmane.org>
Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Subject: Re: [PATCH 4/4] restart thread-safety: avoid malloc in ckpt_msg()
Date: Wed, 04 Aug 2010 19:56:47 -0400 [thread overview]
Message-ID: <4C59FE3F.6090803@cs.columbia.edu> (raw)
In-Reply-To: <1280964604.9502.16.camel@localhost>
On 08/04/2010 07:30 PM, Nathan Lynch wrote:
> On Fri, 2010-07-30 at 13:08 -0400, Oren Laadan wrote:
>> We use clone and eclone directly and not through glibc, therefore
>> must explicitly care about thread-safety of malloc.
>>
>> This patch removes the use of malloc in ckpt_msg() and instead
>> allocate a buffer on the stack. Also convert calls to strerr() to
>> to calls to strerr_r() which are thread-safe.
>
> Well, strerror_r is safe only for code that uses glibc/libpthread
> interfaces to create threads, right?
>
> Furthermore, strerror_r has different behaviors depending on whether
> you're using the XSI- or GNU-specified version. My local strerror(3)
> man page says:
>
> "The GNU-specific strerror_r() returns a pointer to a string containing
> the error message. This may be either a pointer to a string that the
> function stores in buf, or a pointer to some (immutable) static string
> (in which case buf is unused)."
>
> And I'm seeing garbage output from ckpt_perror() with this patch
> applied, implying that the GNU version is in use and that it is electing
> not to modify the supplied buffer.
Doh ... I should have known better.
Ok from the manpage:
"""
Feature Test Macro Requirements for glibc (see
feature_test_macros(7)):
The XSI-compliant version of strerror_r() is provided if:
(_POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600) && !_GNU_SOURCE
Otherwise, the GNU-specific version is provided.
"""
so how about:
#if (_POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600) && !_GNU_SOURCE
use-XSI
#else
use-GNU
#endif
>
> Surely strerror(errno) is "good enough" for error paths?
Heh .. given that errno can already be scrambled between threads...
Oren.
prev parent reply other threads:[~2010-08-04 23:56 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-26 18:37 user-cr thread safety Nathan Lynch
2010-07-29 14:56 ` Oren Laadan
[not found] ` <4C51968D.3000301-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2010-07-29 17:37 ` Nathan Lynch
2010-07-29 22:14 ` Oren Laadan
2010-07-30 17:08 ` [PATCH 1/4] restart: check for overflow when counting (nested) vpids Oren Laadan
2010-07-30 17:08 ` [PATCH 2/4] restart thread safety: remove malloc from ckpt_fork_child Oren Laadan
2010-07-30 17:08 ` [PATCH 3/4] restart thread safety: remove malloc from genstack Oren Laadan
[not found] ` <1280509713-6745-3-git-send-email-orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2010-07-30 18:46 ` Matt Helsley
[not found] ` <20100730184641.GB3426-52DBMbEzqgQ/wnmkkaCWp/UQ3DHhIser@public.gmane.org>
2010-07-30 18:57 ` Oren Laadan
2010-08-04 23:08 ` Nathan Lynch
2010-07-30 17:08 ` [PATCH 4/4] restart thread-safety: avoid malloc in ckpt_msg() Oren Laadan
[not found] ` <1280509713-6745-4-git-send-email-orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2010-08-04 23:30 ` Nathan Lynch
2010-08-04 23:56 ` Oren Laadan [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C59FE3F.6090803@cs.columbia.edu \
--to=orenl-eqauephvms7envbuuze7ea@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=nathanl-V7BBcbaFuwjMbYB6QlFGEg@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.