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 9C44E3858D3C for ; Thu, 26 Aug 2021 18:19:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9C44E3858D3C Received: by mail-qk1-x733.google.com with SMTP id f22so4418352qkm.5 for ; Thu, 26 Aug 2021 11:19:56 -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=qnX1Az9s+aqzTLIhGx1cVYBXF4oHCsHzGNMNmXXEIm0=; b=hBlywcGAmcdi++Biw5zfwHuQdIpzud8AITJz7HyLXHF4XqKBnh/xTZaCDyxQtn6wqm djyQvmmoUABrTUK/vEldpkBIo/EdDUD0eUeB0iHIq9mt+QiPMigMJneS0KrzKziZhQlV 7er54hYT8aT7+TsGtzyawql4NBfyxu1XmE5SNPzdnWM3/txT8rFmbS4lE/xhXB72j8EC m3IQPMusOA0/G7Q7HbEF2/OjKFN8urG+NKqNAMLPpOabhnkqCdd5Fc2L21TWh3xpWgIF 6YcbD/yszZAeVzJy23UJW3jZ5c/a9ab+SwKz/uhF08tgOZM/iyjedGMvv0FJAtPQ8GPi LqIQ== X-Gm-Message-State: AOAM532ATEo+ikErii/DAdCUBFy4ffsCc2i9McwQt28RUI+Y0ZUQUzFt 6pB3Ty0EX9qyGYMI1o7FP3nZeoSPSuhjJA== X-Google-Smtp-Source: ABdhPJw849V1n0THauYFXDiwLy8kAkWjawL95o5EfnJTFgdGYwjXrB/l2yICOc/8OtsRaYPRhnwE4Q== X-Received: by 2002:a05:620a:179e:: with SMTP id ay30mr5079955qkb.333.1630001995974; Thu, 26 Aug 2021 11:19:55 -0700 (PDT) Received: from ?IPv6:2804:431:c7ca:1a68:4e82:9e7c:b7e4:7f3? ([2804:431:c7ca:1a68:4e82:9e7c:b7e4:7f3]) by smtp.gmail.com with ESMTPSA id p22sm3008356qkj.16.2021.08.26.11.19.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Aug 2021 11:19:55 -0700 (PDT) Subject: Re: [PATCH v2 00/19] Fix various NPTL synchronization issues To: Florian Weimer Cc: libc-alpha@sourceware.org References: <20210823195047.543237-1-adhemerval.zanella@linaro.org> <87a6l45kl7.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Message-ID: Date: Thu, 26 Aug 2021 15:19:53 -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: <87a6l45kl7.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=-7.5 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.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Thu, 26 Aug 2021 18:20:07 -0000 On 26/08/2021 11:47, Florian Weimer wrote: > * Adhemerval Zanella: > >> This is an update of my previous set to fix some NPTL issues [1]. >> The main changes are: >> >> - Rebased against master and adjusted the __clone_internal usage. >> - Adapted Florian's ESRCH fixes [2] >> - Add fixes for various function that access the 'tid'. >> >> Patch 01 to 03 are general nptl fixes and they are independent of the >> other fixes. >> >> Patch 04 is the main change of this patchset, it uses a different >> field instead of the pthread 'tid' to synchrnonize the internal >> thread state (BZ#19951). >> >> It allows to both move the thread setxid internal state out of >> 'cancelhandling' (used on setuid() call in multi-thread information), >> and remove the EXITING_BIT and TERMINATED_BIT (since 'joinstate' now >> track such it). This is done on patch 05 and 06. >> >> Patches 08 and 09 fixes two long standing issues regarding >> pthread_kill() and thread exit (BZ#12889 and BZ#19193). Now that] >> 'tid' is setting explicitly by pthread_create(), a simple lock can be >> used instead of more complex futex operation. >> >> Patches 10 to 18 extend the same 'tid' access fix to other pthread >> functions that uses the member. > > I don't think this series of patches is suitable for backport to glibc > 2.34 once completed. The libpthreaddb changes look particularly > cumbersome because you'll need two versions of the library depending > which coredumps you are investigating. However, I expect that we need > to fix the pthread_cancel race in glibc 2.34. I thin for fix the pthread_cancel race on glibc 2.34 only the fix for BZ#19951 along with your patch should be suffice. I don't think this is cumbersome, but I didn't considered the coredump (which I also don't think it should be blocker though). > > I can send my previous attempt with a straightforward lock (and perhaps > with the callback-based function removed). > > However, I'd like to know what people think about relying on signal > unblocking delivering the signal that was sent to the thread itself. > Do we need to special-case the pthread_self case or not? > > Thanks, > Florian >