From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) by sourceware.org (Postfix) with ESMTPS id 8BD2E3857830 for ; Tue, 1 Jun 2021 13:08:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8BD2E3857830 Received: by mail-qk1-x733.google.com with SMTP id j184so14115895qkd.6 for ; Tue, 01 Jun 2021 06:08:18 -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:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Lb0ZzJCngzUk5NQ4bo5HbEoZ/OOeWY0T6qZzX4IoAzY=; b=ujxuhKsWKqa4VenLIgfw2DaUI15UV9UDsUofGUU8o/s/RsmtY2uZulayToik7PBI9a 0sSe8eBk2MUDgj78ZYqKf33SS18ZfwV5BRiUCFRr9JH0bAMGm+39q8vFtlOAv1ZXFLXC 8yawhM7fQIzAdheVt0Erl3rvv0d5feVgX8sPQBuOtBMq89xOricwwwHfnzMXNosJDleM 1QZIr4KOk2GejtdoTChpDLPzQ/3HlfqnqK6bRFmB3vBV/v4waxnvxEY/fUg7bfWTJ0an pma9+zwd1En6wVRGwzTjEYdAVTOCNR6fFAeD4/ZIDhNR3uMNJQQSgKLAYiQcXeEIoaKJ BYdA== X-Gm-Message-State: AOAM532PRb1+ZJU33PxIX/3eY9B5VivlurBqVF8jHOnhFTUHWmfnah1N idrtcJWDb9scxn7OpYtwI7LFpz6lat2ObA== X-Google-Smtp-Source: ABdhPJzghLNdo+wiolQhBJ3BHsV76QUX5TsNfoAiKRCymrJ/RO8gm4cO4/P3AffCIz3iTU54cWsZ7w== X-Received: by 2002:a37:b0f:: with SMTP id 15mr2496351qkl.210.1622552897917; Tue, 01 Jun 2021 06:08:17 -0700 (PDT) Received: from [192.168.1.4] ([177.194.59.218]) by smtp.gmail.com with ESMTPSA id o5sm11009075qkl.25.2021.06.01.06.08.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Jun 2021 06:08:17 -0700 (PDT) Subject: Re: [PATCH v2 2/9] nptl: Deallocate the thread stack on setup failure (BZ #19511) To: Florian Weimer , Adhemerval Zanella via Libc-alpha References: <20210527172823.3461314-1-adhemerval.zanella@linaro.org> <20210527172823.3461314-3-adhemerval.zanella@linaro.org> <87r1hm6l4g.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Message-ID: <69aac17c-75e1-5b80-7df7-1dc09dea18b4@linaro.org> Date: Tue, 1 Jun 2021 10:08:15 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <87r1hm6l4g.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.6 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, 01 Jun 2021 13:08:21 -0000 On 01/06/2021 05:32, Florian Weimer wrote: > * Adhemerval Zanella via Libc-alpha: > >> @@ -424,17 +409,22 @@ start_thread (void *arg) >> have ownership (see CONCURRENCY NOTES above). */ >> if (__glibc_unlikely (pd->stopped_start)) >> { >> /* Get the lock the parent locked to force synchronization. */ >> lll_lock (pd->lock, LLL_PRIVATE); >> >> /* We have ownership of PD now. */ >> + if (pd->setup_failed == 1) >> + { >> + /* In the case of a failed setup, the created thread will be >> + responsible to free up the allocated resources. The >> + detached mode ensure it won't be joined and it will trigger >> + the required cleanup. */ >> + pd->joinid = pd; >> + __do_cancel (); >> + } >> >> /* And give it up right away. */ >> lll_unlock (pd->lock, LLL_PRIVATE); >> } > > I don't think this is quite right. The failed thread should not linger > around after pthread_create has reported failure to the caller. It's > better than what we had before, so maybe we should use this version and > clean it up further later. Agreed, but I think this is really an improvement over current strategy as I commented earlier [1]. I think to proper fix would move the lock prior any initialization so we don't need to run any unwinding operations, skip directly to INTERNAL_SYSCALL_CALL (exit, 0), and let the parent join the thread and do the resource deallocation. > > At the point of the __do_cancel call, unwinding may not yet initialized, > so the implied dlopen happens on a potentially very small stack. It > should be possible to replace it with a goto to the cleanup code. Or > maybe put the cleanup code into a separate function and call it here and > on the regular cleanup path. > > Apart from that, it looks fine to me. The __do_cancel is not done really in asynchronous mode, so it will use the allocated thread stack for the dlopen. But I think with a better strategy to move the 'struct thread' lock earlier than any initialization will avoid such issue. > > Thanks, > Florian > [1] https://sourceware.org/pipermail/libc-alpha/2021-May/126879.html