From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 79631 invoked by alias); 13 Jun 2018 09:36:45 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 79620 invoked by uid 89); 13 Jun 2018 09:36:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Subject: Re: [PATCH] Fix race in pthread_mutex_lock while promoting to PTHREAD_MUTEX_ELISION_NP [BZ #23275] To: Stefan Liebler , GNU C Library Cc: tuliom@linux.vnet.ibm.com References: <4851b1b3-2fd5-75c2-cc5e-68519e373df2@redhat.com> <6538b117-5f58-181c-a52c-4c668ac4deb4@linux.ibm.com> From: Florian Weimer Message-ID: <0ce60d10-94f5-6014-0a8c-33c9ff9d99b5@redhat.com> Date: Wed, 13 Jun 2018 09:36:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <6538b117-5f58-181c-a52c-4c668ac4deb4@linux.ibm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2018-06/txt/msg00297.txt.bz2 On 06/13/2018 11:18 AM, Stefan Liebler wrote: > On 06/13/2018 10:41 AM, Florian Weimer wrote: >> On 06/12/2018 04:24 PM, Stefan Liebler wrote: >>> The new testcase tst-mutex10 is triggering the race on s390x and >>> intel. Presumably also on power, but I don't have access to a power >>> machine with lock-elision. At least the code for power is the same as >>> on the other two architectures. Can somebody test it on power? >> >> I tried the test case on a machine with: >> >> Model:                 2.0 (pvr 004d 0200) >> Model name:            POWER8 (raw), altivec supported >> >> AT_HWCAP:        true_le archpmu vsx arch_2_06 dfp ic_snoop smt mmu >> fpu altivec ppc64 ppc32 >> AT_HWCAP2:       htm-nosc vcrypto tar isel ebb dscr htm arch_2_07 >> >> Presumably, that should have lock elision support? > Unfortunately, I don't know. > @Tulio: Can you answer this question? > > To be sure, can you use gdb and step into pthread_mutex_lock in order to > check if the elision path is used depending on __pthread_force_elision. > Ensure, that elision is enabled: > (gdb) set environment GLIBC_TUNABLES glibc.elision.enable=1 __pthread_force_elision is 1. >> If I apply the test (and only the test) to commit >> a745c837cb51c2efe8900740548cb68ec2a2f7ab, the resulting glibc does not >> show a test failure. > I assume, that nptl/Makefile contains: > tst-mutex10-ENV = GLIBC_TUNABLES=glibc.elision.enable=1 Yes it does. > You can use the tst-mutex10 arguments --iterations (default is 1000000) > and --threads (default is 3). Perhaps we have to increase those values > for power. At least on my s390x/x86_64 machine, those default values do > trigger a test failure as pthread_mutex_destroy is returning EBUSY. I played around with various settings, but I could not get a test failure. Only a test timeout because the 50-second timeout is eventually not large enough. glibc is compiled with assertions enabled. Thanks, Florian