Bug 12114 - Adding priority inheritance to malloc locking
Summary: Adding priority inheritance to malloc locking
Status: NEW
Alias: None
Product: glibc
Classification: Unclassified
Component: malloc (show other bugs)
Version: 2.8
: P2 normal
Target Milestone: ---
Assignee: Carlos O'Donell
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-12 22:11 UTC by Ben Jackson
Modified: 2014-06-30 07:50 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments
Patch to add libptmalloc to glibc 2.7, not proposed to directly apply to glibc. (2.73 KB, application/octet-stream)
2010-10-12 22:11 UTC, Ben Jackson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ben Jackson 2010-10-12 22:11:41 UTC
Created attachment 5054 [details]
Patch to add libptmalloc to glibc 2.7, not proposed to directly apply to glibc.

[I circulated this on libc-help with no response.]

I work on a soft realtime system running embedded Linux.  We ran into a
problem where high priority threads experienced unexpected delays.  One
developer traced a problem to a std::queue operation and from there we
determined that malloc/free (primarily free, due to the way glibc's malloc
works) was showing very high latency jitter.

This was caused by priority inversions when there was malloc arena
contention.  We were exacerbating the problem by having several threads
start and initialize at low priority before moving up to their normal
running priority.  The thread starts all start over at the first arena
so we were experiencing many more contention events than you would for
long-running threads (though any producer/consumer type operation that
pumps memory between threads would also be subject to this if their
priorities differ).

lll_lock is implemented in terms of atomic operations and private futexes,
but it does not use the FUTEX_LOCK_PI idiom.  Converting it to do so
would be problematic (I'm happy to discuss my reasoning here, but I will
omit it in this initial description).  Instead my solution was to add
another extra-libs library to glibc that builds the regular malloc under
NOT_IN_libc which changes the mapping of __libc_lock to pthreads rather
than lll_lock.  Then I enabled PI on the __libc_lock_init calls.  This
library can be linked directly or forced with LD_PRELOAD for testing.

I'd welcome any comments on the general topic of PI locking in glibc and
malloc in particular.  Also, I started from a state of complete ignorance
about the glibc build, so any review of my attached patch would be helpful.

Here's a description of the patch broken down by major area:

Add libptmalloc to the build:

    * nptl/Makefile: Add libptmalloc to extra-libs and add malloc
      components to libptmalloc-routines.  Use vpath to ../malloc.
    * Versions.def: Add libptmalloc stanza with versions referenced
      in malloc/Versions, plus 2.2.5 due to nptl/shlib-versions (?)
    * nptl/Versions: Add libptmalloc stanza with exports copied from
      malloc/Versions.
    * nptl/shlib-versions: Copy libpthread stanza to libptmalloc without
      understanding it at all.  Required to get symbols to bind properly
      and versioned .so installation.

Make malloc build outside of libc:

    * nptl/Makefile: Add _itoa and itoa-udigits to libptmalloc-routines,
      required for mtrace.  Could have also exported them from libc as
      GLIBC_PRIVATE, but was unsure about namespace issues.  Access with
      vpath to ../stdio_common.
    * nptl/Versions: Add __libc_message, __libc_freeres to libc GLIBC_PRIVATE.
    * malloc/malloc.c: If IS_IN_libptmalloc don't remap open, mmap and friends.
    * malloc/malloc.c: Change reference to __libc_argv[0] to __progname.
    * malloc/mtrace.c: If IS_IN_libptmalloc don't remap setvbuf, fwrite.
    * stdio-common/_itoa.c: Extend existing NOT_IN_libc INTUSE fencing
      for _itoa_*_digits.

Set PTHREAD_PRIO_INHERIT for NOT_IN_libc __libc_lock_init:

    * bits/libc-lock.h: Modify all calls pthread_mutex_init to include
      pthread_mutexattr_setprotocol (&attr, PTHREAD_PRIO_INHERIT).  This
      only affects defines that are fenced for NOT_IN_libc already but it
      does affect all extra-libs __libc_lock users (to include the new
      libptmalloc, which is the main goal).

      The symbol versioning of pthread_mutexattr_setprotocol may be wrong
      because there is no __pthread_mutexattr_setprotocol and maybe I
      should have made one?
Comment 1 Carlos O'Donell 2012-02-22 14:45:03 UTC
Ben,

Are you still interested in discussing this issue about PI and malloc?

I'd be interested in hearing your reasoning for not turning on PI in the default malloc provided by glibc?

Cheers,
Carlos.