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=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,NICE_REPLY_A, PDS_RDNS_DYNAMIC_FP,RCVD_IN_DNSWL_MED,RDNS_DYNAMIC,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.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 9CDD61F8C6 for ; Thu, 15 Jul 2021 13:41:25 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id BF38F3985034 for ; Thu, 15 Jul 2021 13:41:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BF38F3985034 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1626356484; bh=lVko1JwbhiBIgoWP603ljlUtO0NSZTxOUy2tA76tYmU=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=r0hbmdChgCtRnZUFEOmupA6i7e1Gz2H84pxYl+otOjmFdE8n8OFRVxgzrJcW6vVh/ CaGMppO9CLSM1F4sBTpWaKaC659eiSy0CXAMoYjb4jEU2gtd0/cJpwKrBp/5Vr1zmQ KzmdvdLQ1ZJ4q4WBb+vWcraTVQEvGD5xmJcWD7Nc= Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) by sourceware.org (Postfix) with ESMTPS id 321B33988436 for ; Thu, 15 Jul 2021 13:40:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 321B33988436 Received: by mail-pj1-x102e.google.com with SMTP id d9-20020a17090ae289b0290172f971883bso6290744pjz.1 for ; Thu, 15 Jul 2021 06:40:14 -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=lVko1JwbhiBIgoWP603ljlUtO0NSZTxOUy2tA76tYmU=; b=c+Och6hZtQOdI7r7b97CZLCVFDg0Op0vnhRupu7U7hrVXnzh6oaQWDbwcvXO4EW+8a R7wtOgz5M00/Db9T7Q2DVfLrLGJVFKRGOdfvQI3qwI1uVI5yRJ5TCBzuLry0SiH5AdBB KjC7aihxOvpRpR7u15wLNRnZOP9jyejUylu3nbEV/0krZKiPb8CD+E2/6tUkb8GCcdKz Ql/l6IPJ4+GRUl0XMnvM3KMVbCFwwU8ZOsnjrVVYnH4p2kpQfAogNreYv/VbFHWMwfWv 1TnhqCLaUEZz9WbymaSt1fQM5oM19MWWfgnCgOkR+yFTWi/veQdHmRIPu2zW6TREMM6M +Lhg== X-Gm-Message-State: AOAM533q1gfLrLfb/IQZ6tw/azdJFvPIc2S/zbQ+vKkumpB/x2pqtqix uMmKgkJxM2JAGZX0Dvu+k8gQ0HEhC9r5Nw== X-Google-Smtp-Source: ABdhPJz652iorTyDEupRmOx+ZQR809A1f7MGH2/L5+mz36TyWcaz2shrXvwa2NSYqwt/jMPaxHdQ/w== X-Received: by 2002:a17:90a:5896:: with SMTP id j22mr3822703pji.125.1626356412754; Thu, 15 Jul 2021 06:40:12 -0700 (PDT) Received: from [192.168.1.108] ([177.194.59.218]) by smtp.gmail.com with ESMTPSA id x10sm7007441pgj.73.2021.07.15.06.40.11 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jul 2021 06:40:12 -0700 (PDT) Subject: Re: [PATCH v3] elf: Fix DTV gap reuse logic (BZ #27135) To: libc-alpha@sourceware.org References: <20210709135001.505521-1-adhemerval.zanella@linaro.org> <20210709150512.GT14854@arm.com> <0c977f4a-248d-c035-a615-852adee670a1@linaro.org> <76323d51-f54d-29c1-1a72-3b439c521f44@redhat.com> <2ad90aa2-bae0-803e-8099-c91fd6641236@linux.ibm.com> Message-ID: <63d00704-decf-e421-49e3-050a4caee159@linaro.org> Date: Thu, 15 Jul 2021 10:40:10 -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: <2ad90aa2-bae0-803e-8099-c91fd6641236@linux.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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 Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On 15/07/2021 10:36, Stefan Liebler via Libc-alpha wrote: > On 14/07/2021 20:11, Adhemerval Zanella via Libc-alpha wrote: >> >> >> On 14/07/2021 13:57, Carlos O'Donell wrote: >>> On 7/14/21 9:52 AM, Adhemerval Zanella wrote: >>>> >>>> >>>> On 09/07/2021 12:05, Szabolcs Nagy wrote: >>>>> The 07/09/2021 10:50, Adhemerval Zanella wrote: >>>>>> Changes from previous version: >>>>>> >>>>>> - Fix commit message and add a line about the bug fixes. >>>>>> - Use atomic operation while setting the slotinfo. >>>>>> - Use test_verbose on tst-tls20.c. >>>>>> >>>>>> --- >>>>>> >>>>>> This is updated version of the 572bd547d57a (reverted by 40ebfd016ad2) >>>>>> that fixes the _dl_next_tls_modid issues. >>>>>> >>>>>> This issue with 572bd547d57a patch is the DTV entry will be only >>>>>> update on dl_open_worker() with the update_tls_slotinfo() call after >>>>>> all dependencies are being processed by _dl_map_object_deps(). However >>>>>> _dl_map_object_deps() itself might call _dl_next_tls_modid(), and since >>>>>> the _dl_tls_dtv_slotinfo_list::map is not yet set the entry will be >>>>>> wrongly reused. >>>>>> >>>>>> This patch fixes by renaming the _dl_next_tls_modid() function to >>>>>> _dl_assign_tls_modid() and by passing the link_map so it can set >>>>>> the slotinfo value so a so subsequente _dl_next_tls_modid() call will >>>>>> see the entry as allocated. >>>>> >>>>> this paragraph still has 'so a so subsequente' >>>>> and i would add the bug number into the first sentence. >>>> >>>> Fixed. >>>> >>>>> >>>>>> >>>>>> The intermediary value is cleared up on remove_slotinfo() for the case >>>>>> a library fails to load with RTLD_NOW. >>>>>> >>>>>> This patch fixes BZ #27135. >>>>>> >>>>>> Checked on x86_64-linux-gnu. >>>>> >>>>> the patch looks ok to me, with the commit message >>>>> and the comment issue below fixed. >>>>> >>>>> Reviewed-by: Szabolcs Nagy >>>> >>>> Carlos, is it for push? >>> >>> It's a non-ABI bug fix, so we can push it. Thanks for asking. >>> >> >> And it is in, let's hope it does not brake anything again ;) >> > > Hi Adhemerval, > > I'm getting a segfault on s390x in elf/tst-tls20. It is at the end of > do_test() when the stack-protector-canary is compared. > > I'm also getting such an error on x86_64, > $ /configure --prefix=/usr --enable-stack-protector=strong > $ make > $ make subdirs=elf check > $ make t=elf/tst-tls20 test > ... > *** stack smashing detected ***: terminated > make[2]: Leaving directory 'glibc/elf' > FAIL: elf/tst-tls20 > original exit status 1 > Didn't expect signal from child: got `Aborted' > > > If configuring without --enable-stack-protector=strong, then > elf/tst-tls20 succeeds. > > Can you please have a look? Let me check.