From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id D42883858D38 for ; Wed, 5 Apr 2023 09:32:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D42883858D38 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1680687120; 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=N0bkL+l30CXVr3/LF06QOwWuTgiKvG6p4XMTCA/+9wgyLznVFtpO7R7xbe9hpwwfLaa83E WFOeoTx/WVegmHmECGBXPpy9ol7wMWyjpV/CDeEXGUvAEvNc5PP3qEdz1wKftsKxsxB2YM mJ+nvqFSJuOyQv9UhqxZPLpSH9nw1p0= 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 X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * 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