From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 131038 invoked by alias); 13 Jun 2018 15:25: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 130934 invoked by uid 89); 13 Jun 2018 15:25:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx0a-001b2d01.pphosted.com Subject: Re: [PATCH] Fix race in pthread_mutex_lock while promoting to PTHREAD_MUTEX_ELISION_NP [BZ #23275] To: Florian Weimer , 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> <0ce60d10-94f5-6014-0a8c-33c9ff9d99b5@redhat.com> From: Stefan Liebler Date: Wed, 13 Jun 2018 15:25:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <0ce60d10-94f5-6014-0a8c-33c9ff9d99b5@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 x-cbid: 18061315-0028-0000-0000-000002D076A4 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18061315-0029-0000-0000-000023879997 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-06-13_06:,, signatures=0 X-SW-Source: 2018-06/txt/msg00318.txt.bz2 On 06/13/2018 11:36 AM, Florian Weimer wrote: > 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 > I've also retested tst-mutex10 without the remaining patch on multiple s390x machines. I've found out, that it depends on the used gcc (at least on s390x). On one machine, gcc 6 was used. With gcc 7 / 8, the type of the mutex was loaded from memory multiple times. With gcc 6, it is loaded only one time and thus all threads are promoting the mutex to PTHREAD_MUTEX_ELISION_NP. Then you don't see a fail. On x86_64, I've used gcc 8. Perhaps I can try other gcc versions. On power, perhaps gcc does also not reload the type of the mutex. I don't know. On s390x, I've build the whole patch and run the testsuite with various gcc versions. There was no fail in tst-mutex10. Bye. Stefan