From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 29468 invoked from network); 5 Apr 2023 11:55:04 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 5 Apr 2023 11:55:04 -0000 Received: (qmail 19732 invoked by uid 550); 5 Apr 2023 11:54:59 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 19709 invoked from network); 5 Apr 2023 11:54:59 -0000 Date: Wed, 5 Apr 2023 07:54:46 -0400 From: Rich Felker To: musl@lists.openwall.com Cc: Florian Weimer Message-ID: <20230405115445.GG3298@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="hwvH6HDNit2nSK4j" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [musl] Re: [PATCH v9 0/13] implement dlmem() function (fwd) --hwvH6HDNit2nSK4j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Well this is disturbing. We probably need to fix gcc here (and a lot of code in the wild may be broken) because musl has no such locking where it doesn't belong. --hwvH6HDNit2nSK4j Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from us-smtp-delivery-124.mimecast.com ([::ffff:170.10.129.124]) by brightrain.aerifal.cx with ESMTP for dalias@libc.org; 05 Apr 2023 09:31:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1680687118; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fb6x7zT+IQGUZx6mqvTtXg0PWLJ56E9UXHGg+pBvloQ=; b=Ssf78B/pTS0UHjnDTctE212n3j3Jx0bJAemchA0sE2001plwsVsQThEmU9MDa/yz4g66/e oZ2w2dyyfgL9OAjSZTRY3LWdDnR8aWqMn4JOfvDIL5hNnTAqQfg09slY+1hJ3bQgo92/jC PYA/1zVuiaGmGQ9d6wRnYBroeq//kt4= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-201-dTMVpbyOMPCVmn9TCLegoA-1; Wed, 05 Apr 2023 05:31:57 -0400 X-MC-Unique: dTMVpbyOMPCVmn9TCLegoA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9BE2D3C0D863; Wed, 5 Apr 2023 09:31:56 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.210]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EEEA8140EBF4; Wed, 5 Apr 2023 09:31:54 +0000 (UTC) From: Florian Weimer To: Szabolcs Nagy via Libc-alpha Cc: stsp , Adhemerval Zanella Netto , janderson@rice.edu, Carlos O'Donell , Rich Felker , Szabolcs Nagy Subject: Re: [PATCH v9 0/13] implement dlmem() function References: <2f3a10fa-4f79-7f9a-6407-d227dbf31935@yandex.ru> <298b04a6-3055-b89b-59c1-4cfbe955848e@yandex.ru> <81749d04-8cdb-de0b-b88e-24347ed535ba@yandex.ru> Date: Wed, 05 Apr 2023 11:31:53 +0200 In-Reply-To: (Szabolcs Nagy via Libc-alpha's message of "Wed, 5 Apr 2023 09:51:31 +0100") Message-ID: <87fs9en08m.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable * Szabolcs Nagy via Libc-alpha: > The 04/05/2023 12:29, stsp wrote: >> - dl_iterate_phdr() seems to be calling the user >> =C2=A0 callback under dl_load_write_lock lock. > > this is a known bug. It's also not something we can fix because the libgcc unwinder has code on it that relies on this implicit loader lock to protect its internal data structures. The libgcc unwinder can be statically linked, so we can't remove the locking without adding a new symbol version. I suspect other uses of dl_iterate_phdr are similar. Thanks, Florian --hwvH6HDNit2nSK4j--