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.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,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 C8AA01F8C7 for ; Thu, 26 Aug 2021 14:48:00 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 62F573857C51 for ; Thu, 26 Aug 2021 14:47:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 62F573857C51 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1629989279; bh=vRaBjn/opyAmdX+rlbwOJZX+07DBUzowfsvHYo5fUaU=; h=To:Subject:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=kysTQt87vxB4eGA7YdO//TDirMzJsIYaMn2pCNE4HkWjk8QjGcM6QwRWBRe9ggyM+ 3dvOtVp1dLYQ5SoPFTEWdHEaYG87SsyLqYOmuLK2RIdoOJmR1OEm8GJKEvvoo2VqTa 7Wmr9JQIatOBwVa6U2h7ul9ymeQz2p29d5HtsqZc= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 512F23858034 for ; Thu, 26 Aug 2021 14:47:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 512F23858034 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-346-MzjO0rShMpmWajnGyYouDA-1; Thu, 26 Aug 2021 10:47:35 -0400 X-MC-Unique: MzjO0rShMpmWajnGyYouDA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id EF1AD1940929; Thu, 26 Aug 2021 14:47:34 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.194.140]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1BF551A26A; Thu, 26 Aug 2021 14:47:33 +0000 (UTC) To: Adhemerval Zanella Subject: Re: [PATCH v2 00/19] Fix various NPTL synchronization issues References: <20210823195047.543237-1-adhemerval.zanella@linaro.org> Date: Thu, 26 Aug 2021 16:47:32 +0200 In-Reply-To: <20210823195047.543237-1-adhemerval.zanella@linaro.org> (Adhemerval Zanella's message of "Mon, 23 Aug 2021 16:50:28 -0300") Message-ID: <87a6l45kl7.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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: Florian Weimer via Libc-alpha Reply-To: Florian Weimer Cc: libc-alpha@sourceware.org Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" * 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 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