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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id A81593857001 for ; Tue, 22 Jun 2021 15:36:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A81593857001 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-501-sIL42pjROTGyGTeE6SlMPg-1; Tue, 22 Jun 2021 11:36:25 -0400 X-MC-Unique: sIL42pjROTGyGTeE6SlMPg-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6A2F5804141; Tue, 22 Jun 2021 15:36:24 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-112-211.ams2.redhat.com [10.36.112.211]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7EEC45C1D1; Tue, 22 Jun 2021 15:36:22 +0000 (UTC) From: Florian Weimer To: John Mellor-Crummey Cc: Adhemerval Zanella , libc-alpha@sourceware.org, Ben Woodard , "Mark W. Krentel" , Jonathon Anderson , Xiaozhu Meng Subject: Re: A collection of LD_AUDIT bugs that are important for tools (with better formatting for this list) References: <8A8FF420-8316-4A22-AC4D-DA1F2D5625A5@rice.edu> <2fc830b9-35da-9b94-369f-4df683078a5c@linaro.org> <8735tguubc.fsf@oldenburg.str.redhat.com> <5F849F6D-0BB7-4D6F-9FC8-9F73A4E012F3@rice.edu> <87tulqe2mc.fsf@oldenburg.str.redhat.com> <96DC1048-EA3C-4DF5-BF16-A567F7C56BDE@rice.edu> Date: Tue, 22 Jun 2021 17:36:20 +0200 In-Reply-To: <96DC1048-EA3C-4DF5-BF16-A567F7C56BDE@rice.edu> (John Mellor-Crummey's message of "Tue, 22 Jun 2021 10:04:43 -0500") Message-ID: <87o8bxdi8b.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 15:36:31 -0000 * John Mellor-Crummey: >> On Jun 22, 2021, at 3:15 AM, Florian Weimer wrote: >> You can already see this non-interceptable thread creation behavior >> today (in glibc 2.33 and earlier) with thrd_create, which does not >> result in a pthread_create call, either, despite creating a new thread >> as if by pthread_create. > > Having a non-interposable thrd_create is a problem for us too, though=20 > we haven=E2=80=99t yet seen it in practice in HPC applications (or maybe = it happened > and we were just unaware!). I meant that thrd_create needs to be intercepted separately. This will still work. >> Going back to trheading, I find it a bit curious that you intercept >> pthread_create, but not pthread_join. How do you detect thread exit? I >> assume you are interested in that event, too. Merely wrapping the >> thread start routine is insufficient because there are other ways for a >> thread to exit besides returning from the start routine and calling >> pthread_exit (e.g., thread cancellation and unwinding). > > We use pthread_cleanup_push to add a routine that will be called when a t= hread > exits. Okay, that should work, although some application-supplied TLS destructors will run later than that. Thanks, Florian