From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 245EF3858C5F for ; Fri, 12 May 2023 10:33:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 245EF3858C5F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1683887591; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=S4EHBMUmzBh2Pc7er9Sune/K0xyyNA67UPsCG90VyiU=; b=QyMdXB/aUZRWvlvjm6yTAg5ySgN78kelwcO5dZfcolyS+ODusMTDMKWOcIvGGX39/Zvbnw bVqyIvTtoi4lDdgLm49GWNyD3bjVN4chEnTYgf/d2Ma9IgzWCu2mwpOZrbMZIBixxu3KnO ENDFO76F/N3QwjlycxYRAx9+mkPWJ1w= Received: from mail-lf1-f69.google.com (mail-lf1-f69.google.com [209.85.167.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-222-udUIRV3OM5ug5jc1dETiXg-1; Fri, 12 May 2023 06:33:09 -0400 X-MC-Unique: udUIRV3OM5ug5jc1dETiXg-1 Received: by mail-lf1-f69.google.com with SMTP id 2adb3069b0e04-4f13ecb8f01so5198121e87.1 for ; Fri, 12 May 2023 03:33:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683887588; x=1686479588; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=y71ICoHd53B/FvG1Vg+7X+F5xrojovXMAs7n7Ne8XsY=; b=QLJfUzSvEdgu3Dsy3a1/itiyVsASUQiInlqepyAxgxlnpPaffBu+pMuabIVhfqsXop lUUZj0z1GtLHezYxEjz0XMugJGV7obF3NwCJ9dvho7/aYgtMWc2Yv5XL+hriyS4qd57t njiPDc6XZH/9EhKzLrXlcZFLZWJUUOKYEKvPVpeT7KSyudPYZHhWUNWpeP2DowQD3xJS Kk7wf9T6w7i0eQEoyHB+4XcKrqLVh4x9+Mz4R7UlW5AcjxIKCnlXNkKuEKcxRfZaQMyS QC5Y66msEzIcdIzPgbt4EJ3UCwq4WqoLOKvzCkdj8tp/OE/ak4sfS709Ld5fAzMXIG0K 0xug== X-Gm-Message-State: AC+VfDz3tlzFIW6oOyT1VQFWeVUd9viYUA4rr42Gg21lAicmGWdjUwyO 2rnPi1CgDK0svzooeIcKNgQTuyE4fM1Un8zvMw3zPGgb24UbzA+5SkvGI0HAVHSRTNIXmhnCNbh wtM7ionAT9yUZlKlRwAIwVYd5GfgC0/zrYQ== X-Received: by 2002:ac2:55ae:0:b0:4eb:20e:6aec with SMTP id y14-20020ac255ae000000b004eb020e6aecmr3694315lfg.40.1683887588467; Fri, 12 May 2023 03:33:08 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ766Y2uxT3ZihlMigvWySNJj1m7gOyK90QhxMip4A1u7do1QRS7xAzABpiSpK+N5rWDzg7v6Jk48g5oX0BUkWI= X-Received: by 2002:ac2:55ae:0:b0:4eb:20e:6aec with SMTP id y14-20020ac255ae000000b004eb020e6aecmr3694306lfg.40.1683887588093; Fri, 12 May 2023 03:33:08 -0700 (PDT) MIME-Version: 1.0 References: <20230510112009.633444-1-jwakely@redhat.com> In-Reply-To: From: Jonathan Wakely Date: Fri, 12 May 2023 11:32:56 +0100 Message-ID: Subject: Re: [PATCH v2] libstdc++: Do not use pthread_mutex_clocklock with ThreadSanitizer To: Mike Crowe Cc: "libstdc++" , gcc Patches , Thomas Rodgers X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="00000000000087c16205fb7ca1c7" X-Spam-Status: No, score=-13.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --00000000000087c16205fb7ca1c7 Content-Type: text/plain; charset="UTF-8" On Fri, 12 May 2023 at 11:30, Mike Crowe wrote: > On Thursday 11 May 2023 at 21:52:22 +0100, Jonathan Wakely wrote: > > On Thu, 11 May 2023 at 13:42, Jonathan Wakely > wrote: > > > > > > > > > > > On Thu, 11 May 2023 at 13:19, Mike Crowe wrote: > > > > > >> However, ... > > >> > > >> > > diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4 > > >> > > index 89e7f5f5f45..e2700b05ec3 100644 > > >> > > --- a/libstdc++-v3/acinclude.m4 > > >> > > +++ b/libstdc++-v3/acinclude.m4 > > >> > > @@ -4284,7 +4284,7 @@ > > >> AC_DEFUN([GLIBCXX_CHECK_PTHREAD_COND_CLOCKWAIT], [ > > >> > > [glibcxx_cv_PTHREAD_COND_CLOCKWAIT=no]) > > >> > > ]) > > >> > > if test $glibcxx_cv_PTHREAD_COND_CLOCKWAIT = yes; then > > >> > > - AC_DEFINE(_GLIBCXX_USE_PTHREAD_COND_CLOCKWAIT, 1, [Define if > > >> > > pthread_cond_clockwait is available in .]) > > >> > > + AC_DEFINE(_GLIBCXX_USE_PTHREAD_COND_CLOCKWAIT, > > >> (_GLIBCXX_TSAN==0), > > >> > > [Define if pthread_cond_clockwait is available in .]) > > >> > > fi > > >> > > >> TSan does appear to have an interceptor for pthread_cond_clockwait, > even > > >> if > > >> it lacks the others. Does this mean that this part is unnecessary? > > >> > > > > > > Ah good point, thanks. I grepped for clocklock but not clockwait. > > > > > > > In fact it seems like we don't need to change > > _GLIBCXX_USE_PTHREAD_RWLOCK_CLOCKLOCK either, because I don't get any > tsan > > warnings for that. It doesn't have interceptors for > > pthread_rwlock_{rd,wr}lock, but it doesn't complain anyway (maybe it's > > simply not instrumenting the rwlock functions at all?!) > > It looks like TSan does have interceptors for pthread_rwlock_timedrdlock > etc. I can't explain why this doesn't cause problems when libstdc++ uses > pthread_rwlock_clockrdlock etc. > I think glibc has renamed the rwlock functions, and so the interceptors no longer work. # ifdef __USE_XOPEN2K /* Try to acquire read lock for RWLOCK or return after specfied time. */ # ifndef __USE_TIME_BITS64 extern int pthread_rwlock_timedrdlock (pthread_rwlock_t *__restrict __rwlock, const struct timespec *__restrict __abstime) __THROWNL __nonnull ((1, 2)); # else # ifdef __REDIRECT_NTHNL extern int __REDIRECT_NTHNL (pthread_rwlock_timedrdlock, (pthread_rwlock_t *__restrict __rwlock, const struct timespec *__restrict __abstime), __pthread_rwlock_timedrdlock64) __nonnull ((1, 2)); # else # define pthread_rwlock_timedrdlock __pthread_rwlock_timedrdlock64 # endif # endif # endif If glibc is really providing a function called __pthread_rwlock_timedrdlock64 then will tsan be able to intercept that? > > So I'm now retesting with this version of the patch, which only touches > the > > USE_PTHREAD_LOCKLOCK macro. > > > > Please take another look, thanks. > > > commit 4fc14825c125eece32980df21d09da35e3d5bac6 > > Author: Jonathan Wakely > > Date: Tue May 9 09:30:48 2023 > > > > libstdc++: Do not use pthread_mutex_clocklock with ThreadSanitizer > > > > As noted in https://github.com/llvm/llvm-project/issues/62623 there > are > > no tsan interceptors for some of the new POSIX-1:202x APIs added by > > https://austingroupbugs.net/view.php?id=1216 so tsan gives false > > positive warnings for try_lock_for on timed mutexes. > > > > Disable the uses of the new pthread_mutex_clocklock API when tsan is > > active. This changes the semantics of the try_lock_for functions, > > because it can change which clock is used for the wait. This means > those > > functions might be affected by system clock adjustments when tsan is > > used, when they would not be affected otherwise. > > > > libstdc++-v3/ChangeLog: > > > > * acinclude.m4 (GLIBCXX_CHECK_PTHREAD_MUTEX_CLOCKLOCK): > Define > > _GLIBCXX_USE_PTHREAD_MUTEX_CLOCKLOCK in terms of > _GLIBCXX_TSAN. > > * configure: Regenerate. > > > > diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4 > > index 89e7f5f5f45..dce3d16aa5c 100644 > > --- a/libstdc++-v3/acinclude.m4 > > +++ b/libstdc++-v3/acinclude.m4 > > @@ -4314,7 +4314,7 @@ AC_DEFUN([GLIBCXX_CHECK_PTHREAD_MUTEX_CLOCKLOCK], [ > > [glibcxx_cv_PTHREAD_MUTEX_CLOCKLOCK=no]) > > ]) > > if test $glibcxx_cv_PTHREAD_MUTEX_CLOCKLOCK = yes; then > > - AC_DEFINE(_GLIBCXX_USE_PTHREAD_MUTEX_CLOCKLOCK, 1, [Define if > pthread_mutex_clocklock is available in .]) > > + AC_DEFINE(_GLIBCXX_USE_PTHREAD_MUTEX_CLOCKLOCK, (_GLIBCXX_TSAN==0), > [Define if pthread_mutex_clocklock is available in .]) > > fi > > > > CXXFLAGS="$ac_save_CXXFLAGS" > > LGTM. > > Mike. > > --00000000000087c16205fb7ca1c7--