Date: Fri, 15 May 2015 08:41:18 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 200138] [PATCH] Fixed per-thread 'specific' array allocation conflict incurred in libthr by some foreign malloc libraries Message-ID: <bug-200138-16-AsoQsVk5mA@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-200138-16@https.bugs.freebsd.org/bugzilla/> References: <bug-200138-16@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200138 --- Comment #20 from commit-hook@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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-200138-16-AsoQsVk5mA>