From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 Cc: libc-alpha@sourceware.org, Ben Woodard , "Mark W. Krentel" , Jonathon Anderson , Xiaozhu Meng 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> From: Adhemerval Zanella 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-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, 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 16:34:04 -0000 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 >