From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-4.3 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 0E38A1F8C6 for ; Tue, 22 Jun 2021 16:34:25 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E35D9385742A for ; Tue, 22 Jun 2021 16:34:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E35D9385742A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1624379663; bh=fJKfXbfb7UcrASHRkLFrVOxYaAl80EWx3vpIgKcLEus=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=ZPZfhzOWI76d8CrHWMSveVcbAeg5/PK5s6kzozmIJRyV62H3YMAggcxwX1U48hICK ePl+1h+KN8pyz4wihSv1J0OKMrpfejnG+k527XrsvDKQUhhVjQxWWZq33FrhzdKY7t ifCkdVcXeVAKqbj4S0YXOEYwRjbQrG7m1uxLMIZw= Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) by sourceware.org (Postfix) with ESMTPS id 801B03857416 for ; Tue, 22 Jun 2021 16:34:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 801B03857416 Received: by mail-qk1-x72e.google.com with SMTP id bj15so39255274qkb.11 for ; Tue, 22 Jun 2021 09:34:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fJKfXbfb7UcrASHRkLFrVOxYaAl80EWx3vpIgKcLEus=; b=dTm0vxKFTEfy8gxxGDOkO2aZkjLEgmRXoSud4cnnJMF3urvRf3dQ3yQeZR4WpjoUn7 Fd/rcPYbTvYMy4vT/Dfl/vvlGyuXaEYPc0KJyyjaEPDtOUGZjFRua14pBA9ZrZt4/m3d j4hA4RRWXHVah4TnhHOUPgP5Jq+YNwWHNEcihXkduxtiwGZgWuYPbp7H7s7AJ8e7+TJQ 7TGPxicqQyzPQJeuI65mTaph07Dpg8QYs/qvolu+pPNR+I6J6qtszm2k99NvCp0sLsjc u4g3psNwz30Oibg/dSjgS/xFV3RYiYasYc+zFAZr1aAqxajnsu1REIgg2M48FZXTH8Iu SFgw== X-Gm-Message-State: AOAM533jsYCsSDnZ7X0hbHcnaq84jdqdaIEguj5wraxIjB3r4PEKZqsj w/8nf+GxCQGfHyEHZ6bCUpBDdQ== X-Google-Smtp-Source: ABdhPJzAd5E7aWVewx51mCfkT0/p5F7oSdXHv/FD6JyzDLCeBAJ5iGoUFM4fWjOOFAe0m7MSmL+oEg== X-Received: by 2002:a05:620a:893:: with SMTP id b19mr5173967qka.121.1624379640838; Tue, 22 Jun 2021 09:34:00 -0700 (PDT) Received: from [192.168.1.108] ([177.194.59.218]) by smtp.gmail.com with ESMTPSA id b132sm13469053qkg.116.2021.06.22.09.33.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Jun 2021 09:34:00 -0700 (PDT) Subject: Re: A collection of LD_AUDIT bugs that are important for tools (with better formatting for this list) To: John Mellor-Crummey , Florian Weimer 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> <87o8bxdi8b.fsf@oldenburg.str.redhat.com> <8055B154-337B-4B30-9036-056AB5750766@rice.edu> Message-ID: <62c763ab-2303-85d8-df11-f929a0ef1c0d@linaro.org> Date: Tue, 22 Jun 2021 13:33:57 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <8055B154-337B-4B30-9036-056AB5750766@rice.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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: , From: Adhemerval Zanella via Libc-alpha Reply-To: Adhemerval Zanella Cc: Xiaozhu Meng , libc-alpha@sourceware.org, "Mark W. Krentel" Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On 22/06/2021 13:17, John Mellor-Crummey wrote: > Florian, > > >> On Jun 22, 2021, at 10:36 AM, Florian Weimer wrote: >> >> * 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 >>> we haven’t 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. > > Got it. > > Would you recommend intercepting clone instead of trying > to intercept pthread_create and thrd_create? > > That should avoid trouble interposing pthread_create. Interposing 'clone' falls in the same category, the syscall is issued directly within de clode. Currently, you need to interpose both pthread_create and thrd_create. Florian has suggested we allow pthread_create to be interposable (meaning glibc will issue a plt call on each usage). We can do it for clone instead, it would have the advantage to hide the multiple architecture different kernel ABIs. > >> >>>> 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 thread >>> exits. >> >> Okay, that should work, although some application-supplied TLS >> destructors will run later than that. > > For our tools, we need to shut down profiling when a thread is finishing. That > can and should be done before the thread really gets torn down. We have > learned the hard way that we need to turn off profiling before TLS destruction starts. > > -- > John Mellor-Crummey Professor > Dept of Computer Science Rice University > email: johnmc@rice.edu phone: 713-348-5179 >