git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Fredrik Kuivinen <frekui@gmail.com>
To: Nicolas Pitre <nico@fluxnic.net>
Cc: Shawn Pearce <spearce@spearce.org>,
	Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org, Johannes Sixt <j6t@kdbg.org>
Subject: Re: [PATCH] Make xmalloc and xrealloc thread-safe
Date: Sat, 27 Mar 2010 14:26:20 +0100	[thread overview]
Message-ID: <4c8ef71003270626y45685e69j28ccb8a8738b9083@mail.gmail.com> (raw)
In-Reply-To: <alpine.LFD.2.00.1003241613020.694@xanadu.home>

On Wed, Mar 24, 2010 at 21:22, Nicolas Pitre <nico@fluxnic.net> wrote:
> By providing a hook for the routine responsible for trying to free some
> memory on malloc failure, we can ensure that the  called routine is
> protected by the appropriate locks when threads are in play.
>
> The obvious offender here was pack-objects which was calling xmalloc()
> within threads while release_pack_memory() is not thread safe.
>
> Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
> ---
>
> On Wed, 24 Mar 2010, Shawn Pearce wrote:
>
>> On Wed, Mar 24, 2010 at 11:54 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
>> > Another solution could be for xmalloc() to use a function pointer for
>> > the method to use on malloc error path, which would default to a
>> > function calling release_pack_memory(size, -1).  Then pack-objects.c
>> > would override the default with its own to acquire the read_mutex around
>> > the call to release_pack_memory().  That is probably the easiest
>> > solution for now.
>>
>> Yea, that sounds like the most reasonable solution right now.
>
> So here it is.
>
> Note: there was a dubious usage of fd when calling release_pack_memory()
> in xmmap() which is now removed.
>
> diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
> index 9780258..65f797f 100644
> --- a/builtin/pack-objects.c
> +++ b/builtin/pack-objects.c
> @@ -1522,6 +1522,13 @@ static void find_deltas(struct object_entry **list, unsigned *list_size,
>
>  #ifndef NO_PTHREADS
>
> +static void try_to_free_from_threads(size_t size)
> +{
> +       read_lock();
> +       release_pack_memory(size, -1);
> +       read_unlock();
> +}
> +

Will this really work in all cases? In the find_deltas -> try_delta ->
read_sha1_file -> ... -> xmalloc call path, the mutex is already
locked when we get to xmalloc. As the mutex is of the default type
(NULL is passed as the mutex attribute argument to
pthread_mutex_init), it is undefined behaviour to lock the mutex again
(see http://www.opengroup.org/onlinepubs/007908799/xsh/pthread_mutexattr_gettype.html
)

I just realised that builtin/grep.c also needs a fix for its use of xmalloc.

- Fredrik

  parent reply	other threads:[~2010-03-27 13:26 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20100323161713.3183.57927.stgit@fredrik-laptop>
2010-03-23 17:31 ` [PATCH 1/2] Make xmalloc and xrealloc thread-safe Fredrik Kuivinen
2010-03-23 18:43   ` Shawn O. Pearce
2010-03-23 21:21     ` Fredrik Kuivinen
2010-03-23 23:50       ` Nicolas Pitre
2010-03-24 15:23         ` Fredrik Kuivinen
2010-03-24 17:53           ` Nicolas Pitre
2010-03-24 18:22             ` Shawn Pearce
2010-03-24 18:44               ` Junio C Hamano
2010-03-24 18:54               ` Nicolas Pitre
2010-03-24 19:57                 ` Shawn Pearce
2010-03-24 20:22                   ` [PATCH] " Nicolas Pitre
2010-03-24 20:28                     ` Shawn O. Pearce
2010-03-24 21:02                       ` Nicolas Pitre
2010-03-24 21:11                         ` Junio C Hamano
2010-03-24 21:28                       ` Junio C Hamano
2010-03-27 13:26                     ` Fredrik Kuivinen [this message]
2010-03-27 18:59                       ` Nicolas Pitre
2010-03-31  6:57                         ` Fredrik Kuivinen
2010-04-07  2:57                       ` [PATCH v2] " Nicolas Pitre
2010-04-07  3:16                         ` Shawn O. Pearce
2010-04-07  4:51                           ` Nicolas Pitre
2010-04-07 12:29                             ` Shawn Pearce
2010-04-07 13:17                               ` Nicolas Pitre
2010-04-07 14:30                                 ` Shawn Pearce
2010-04-07 14:47                                   ` Nicolas Pitre
2010-04-07 14:45                                 ` Fredrik Kuivinen
2010-04-07 15:08                                   ` Nicolas Pitre
2010-04-07 16:13                                     ` Fredrik Kuivinen
2010-04-07 16:44                                       ` Erik Faye-Lund
2010-04-07 18:37                                       ` Nicolas Pitre
2010-04-07 15:27                                   ` Sverre Rabbelier
2010-04-07 16:15                                     ` Fredrik Kuivinen
2010-04-07 16:17                                   ` Junio C Hamano
2010-04-07 18:49                                   ` Johannes Sixt
2010-04-08  7:15                                   ` [PATCH] Thread-safe xmalloc and xrealloc needs a recursive mutex Johannes Sixt
2010-04-08  8:42                                     ` Fredrik Kuivinen
2010-04-07  5:21                           ` [PATCH v2] Make xmalloc and xrealloc thread-safe Junio C Hamano
2010-03-23 17:31 ` [PATCH 2/2] Make sha1_to_hex thread-safe Fredrik Kuivinen
2010-03-23 20:23   ` Johannes Sixt

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=4c8ef71003270626y45685e69j28ccb8a8738b9083@mail.gmail.com \
    --to=frekui@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j6t@kdbg.org \
    --cc=nico@fluxnic.net \
    --cc=spearce@spearce.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).