From patchwork Tue Aug 5 15:43:03 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bernard Ogden X-Patchwork-Id: 376734 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 0F05C14007D for ; Wed, 6 Aug 2014 01:43:19 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; q=dns; s=default; b=Js 82hNlky5J4K/3T2m0dLHL2+2C/B9scwLt7jPvvaJs4YEjQgWbaqIJvbbsXDhMpvr vlCxzFzWeoFXW6i5O9mZozes2WWveZZT5z8phca+Be8wusOVb6s58USIvongFKCJ EKIaCtv3ThIvnl46wnBk8Arql35zr+w19DfyyAyeE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; s=default; bh=CJMX/4vE 1/Muln66+sRMhfJA740=; b=eyz1xKp4FfJp/gaujpqDXDZottq8rRhqOVAbMJY4 NqDOXTeKZh8LLO0jxB9/Ub5AjE0pcNo3aDKitdqDYtcHk/qnYoC8h/ZAXbP8AOqS KSOzEB/RlP4C+KXMOBeYxbALIRPbxiXr1TYNltwri5159SI93SZzfmBqF4P7Q99b yA0= Received: (qmail 30286 invoked by alias); 5 Aug 2014 15:43:14 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 30275 invoked by uid 89); 5 Aug 2014 15:43:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-we0-f182.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; bh=4PpB39HMk9S1lXm2u3rV7uL57UdhAkgxsu3lQQAZAfk=; b=Z6kxFR9ydoyhl7JexV+fZavKHTLXGbvKV7pZgQvquY1oeFVYlWUgarSYEKy3XfNz6O itW7UpH62GOEvCG2tGoA+w9WCkEdZGI9X1/Lfz1uBTZX9UuSJ6MhhFkjlP71rqX6y33T IKUrrjdXwR5d/Mee0/9d/GQJ/5AZyYO+DglxlOuHRk61YDk3bZeIDACl0KsDOAkhRm9t 8jRtbmqGkTVebx8laE/7sviF8SNLaN16YSeHmAbMGh/t+GlN3JxPePhQhLjuanUfBwmk MI1Ew/icanixyRgBS4sxeo37xE3qvfSTMcI19Kz23YwbLG5hDfaUyySHXIIgnlyA/KmW HY8w== X-Gm-Message-State: ALoCoQnU+QdssUDyXTuWfrwwEC+NxjPBEUyb1++lq8QARJYjaZjWzzlijB6cG4IOoVt9ajh9y4Uj X-Received: by 10.194.185.113 with SMTP id fb17mr6900746wjc.117.1407253389437; Tue, 05 Aug 2014 08:43:09 -0700 (PDT) From: Bernard Ogden Subject: [PATCH][BZ #16892] Check value of futex before updating in __lll_timedlock Message-Id: <1D01BCB7-8B02-415F-9244-58C15296B799@linaro.org> Date: Tue, 5 Aug 2014 16:43:03 +0100 To: "GNU C. Library" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) __lll_timedlock in generic lowlevellock.h sets futex to 1 without checking that it is already 0. This can create 2 performance problems (analysis by Carlos O'Donell): 1) Up to N threads can fail to sleep when they ought to have done, where N is the number of threads expecting futex==2. For example: * T1 calls __lll_timedlock setting futex to 1 and taking the lock. * T2 calls __lll_timedlock setting futex to 1 but does not take the lock. * T2 calls __lll_timedlock_wait and sets the futex to 2 and does not gain the lock. * T3 calls __lll_timedlock setting futex to 1 but does not take the lock. * T2 calls lll_futex_time_wait but fails with -EWOULDBLOCK because T3 reset futex to 1. -> One inflight thread (T2), and one spurious failed futex wait syscall. * T2 again sets the futex to 2 and does not gain the lock. * ... T2 and T3 go on to call futex wait syscall and both sleep. 2) __lll_unlock only wakes if futex was > 1 prior to release. Thus it can happen that __lll_timedlock keeps setting futex from 2 to 1 just prior to __lll_unlock calls, preventing waiters from being awoken. This certainly affects m68k, arm and aarch64 - sh may also be affected but it's a little harder to tell as its written in asm. We fix this by changing an atomic_exchange_acq to atomic_compare_and_exchange_bool_acq. This bug previously affected arm, aarch64, m68k and sh/sh4. Since mips switched to the generic lowlevellock.h, it is also affected. Applying this patch will fix arm, aarch64 and mips. m68k and sh would need to switch to the generic header to get the fix. Change is pretty simple, but has been built and tested on arm. OK? 2014-08-05 Bernard Ogden [BZ #16892] * sysdeps/nptl/lowlevellock.h: Use atomic_compare_and_exchange_bool_acq rather than atomic_exchange_acq in __lll_timedlock. diff --git a/sysdeps/nptl/lowlevellock.h b/sysdeps/nptl/lowlevellock.h index 548a9c8..06ccde5 100644 --- a/sysdeps/nptl/lowlevellock.h +++ b/sysdeps/nptl/lowlevellock.h @@ -93,7 +93,8 @@ extern int __lll_robust_timedlock_wait (int *futex, const struct timespec *, int *__futex = (futex); \ int __val = 0; \ \ - if (__glibc_unlikely (atomic_exchange_acq (__futex, 1))) \ + if (__glibc_unlikely \ + (atomic_compare_and_exchange_bool_acq (__futex, 1, 0))) \ __val = __lll_timedlock_wait (__futex, abstime, private); \ __val; \ })