From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4600 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: What does this code do? Date: Sat, 22 Feb 2014 09:59:07 -0500 Message-ID: <20140222145907.GC184@brightrain.aerifal.cx> References: <20140222143536.GA5438@diogenes.samsung.router> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1393081154 18681 80.91.229.3 (22 Feb 2014 14:59:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 22 Feb 2014 14:59:14 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4604-gllmg-musl=m.gmane.org@lists.openwall.com Sat Feb 22 15:59:20 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WHE2y-0007sc-1u for gllmg-musl@plane.gmane.org; Sat, 22 Feb 2014 15:59:20 +0100 Original-Received: (qmail 32302 invoked by uid 550); 22 Feb 2014 14:59:19 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 32288 invoked from network); 22 Feb 2014 14:59:19 -0000 Content-Disposition: inline In-Reply-To: <20140222143536.GA5438@diogenes.samsung.router> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4600 Archived-At: On Sat, Feb 22, 2014 at 03:35:43PM +0100, Jens Eichendorff wrote: > While skimming some parts of the musl libc I have come across the > following weird line in `src/thread/__wait.c': > > if (priv) priv = 128; priv=0; > > whereby `priv' is then bitwise OR-ed to the FUTEX_WAIT operation > constant to a futex syscall. Does this code exist to avoid > optimizations, do optimizations, or just add waiting time? What does it > do and what is the `priv' parameter of __wait() for? Excuse me if this > is a really stupid question, I'm not very familiar with somewhat > low-level code. > > Looking through the git logs this is part of the initial import commit, > so I could not find any comments to why this was done. It's not a stupid question at all. This is simply a silly way of disabling support for private-futex mode, which is not presently working. Private futex mode is a feature added to the kernel somewhere during the mid 2.6 series (if I recall right) that only works for futexes within a single process, not shared between processes, by using the virtual address directly as the futex key rather than keying the futex by the underlying backing for the mapping. It allows for a much faster path in kernel-space (avoids taking a global lock and possibly sleeping) and possibly also eliminates some ugly failure cases (which in principle should not exist, but the kernel is broken like that...). Unfortunately, since we want to support both old and new kernels (where old kernels lack it), we need a way to fallback to not using private futex mode if it's not supported. Also, the synchronization object needs to accurately reflect whether the application requested it be process-shared, so that we can avoid using private futex mode when it's not valid to do so. Making the fallback reasonably efficient is not easy; we want to cache the result, but storing it globally would incur synchronization cost and GOT access cost on each futex operation (potentially expensive in bloat as well as time) while storing it in TLS would incur thread-pointer access time (very slow on some archs) for each operation and have the risk of threads mismatching each other's choices due to spurious failures by the kernel (not sure if these exist or not) that could lead to deadlocks. So adding support, while it's been an agenda item for a long time, requires nontrivial work/research on how to do it right (note: I'm not convinced glibc does it right). Hope this answers your question! Rich