[Bug 200138] [PATCH] Fixed per-thread 'specific' array allocation conflict incurred in libthr by some foreign malloc libraries

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Fri May 15 08:41:19 UTC 2015


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200138

--- Comment #20 from commit-hook at freebsd.org ---
A commit references this bug:

Author: kib
Date: Fri May 15 08:40:18 UTC 2015
New revision: 282948
URL: https://svnweb.freebsd.org/changeset/base/282948

Log:
  Some third-party malloc(3) implementations use pthread_setspecific(3)
  to handle per-thread information.  Since our pthread_setspecific()
  implementation calls calloc(3) to allocate per-thread specific data
  storage, things get complicated.

  Switch the allocator to use bare mmap(2).  There is some loss of the
  allocated page, since e.g. on amd64, PTHREAD_KEYS_MAX * sizeof(struct
  pthread_specific_elem) is 3K (it actually spans whole page due to
  padding), but I believe it is more acceptable than additional code for
  specialized allocator().

  The alternatives would either to make the specific data array be part of
  the struct thread, or use internal bindings to call the libc malloc,
  avoiding interposing.

  Also do the style pass over the thr_spec.c, esp. simplify the
  conditionals nesting by returning early when an error detected.
  Remove trivial comments.

  Found by:    yuri at rawbw.com
  PR:    200138
  Sponsored by:    The FreeBSD Foundation
  MFC after:    2 weeks

Changes:
  head/lib/libthr/thread/thr_spec.c

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-threads mailing list