From owner-svn-src-all@freebsd.org Tue Mar 1 15:21:02 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DA734ABEAFD; Tue, 1 Mar 2016 15:21:02 +0000 (UTC) (envelope-from kib@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 90B9C1AA4; Tue, 1 Mar 2016 15:21:02 +0000 (UTC) (envelope-from kib@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id u21FL16X018353; Tue, 1 Mar 2016 15:21:01 GMT (envelope-from kib@FreeBSD.org) Received: (from kib@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id u21FL1F5018352; Tue, 1 Mar 2016 15:21:01 GMT (envelope-from kib@FreeBSD.org) Message-Id: <201603011521.u21FL1F5018352@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: kib set sender to kib@FreeBSD.org using -f From: Konstantin Belousov Date: Tue, 1 Mar 2016 15:21:01 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r296268 - head/lib/libthr/thread X-SVN-Group: head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 15:21:03 -0000 Author: kib Date: Tue Mar 1 15:21:01 2016 New Revision: 296268 URL: https://svnweb.freebsd.org/changeset/base/296268 Log: Add two comments explaining the fine points of the hash implementation. Reviewed by: emaste Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D5490 Modified: head/lib/libthr/thread/thr_pshared.c Modified: head/lib/libthr/thread/thr_pshared.c ============================================================================== --- head/lib/libthr/thread/thr_pshared.c Tue Mar 1 14:30:35 2016 (r296267) +++ head/lib/libthr/thread/thr_pshared.c Tue Mar 1 15:21:01 2016 (r296268) @@ -86,6 +86,16 @@ pshared_unlock(struct pthread *curthread _thr_ast(curthread); } +/* + * Among all processes sharing a lock only one executes + * pthread_lock_destroy(). Other processes still have the hash and + * mapped off-page. + * + * Mitigate the problem by checking the liveness of all hashed keys + * periodically. Right now this is executed on each + * pthread_lock_destroy(), but may be done less often if found to be + * too time-consuming. + */ static void pshared_gc(struct pthread *curthread) { @@ -131,6 +141,27 @@ pshared_insert(void *key, void **val) hd = &pshared_hash[PSHARED_KEY_HASH(key)]; LIST_FOREACH(h, hd, link) { + /* + * When the key already exists in the hash, we should + * return either the new (just mapped) or old (hashed) + * val, and the other val should be unmapped to avoid + * address space leak. + * + * If two threads perform lock of the same object + * which is not yet stored in the pshared_hash, then + * the val already inserted by the first thread should + * be returned, and the second val freed (order is by + * the pshared_lock()). Otherwise, if we unmap the + * value obtained from the hash, the first thread + * might operate on an unmapped off-page object. + * + * There is still an issue: if hashed key was unmapped + * and then other page is mapped at the same key + * address, the hash would return the old val. I + * decided to handle the race of simultaneous hash + * insertion, leaving the unlikely remap problem + * unaddressed. + */ if (h->key == key) { if (h->val != *val) { munmap(*val, PAGE_SIZE);