From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=U52X=74=yandex.ru=stsp2@sourceware.org>
Received: from forward500c.mail.yandex.net (forward500c.mail.yandex.net [178.154.239.208])
	by sourceware.org (Postfix) with ESMTPS id 306723858C50
	for <libc-alpha@sourceware.org>; Wed,  5 Apr 2023 07:30:03 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 306723858C50
Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=yandex.ru
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=yandex.ru
Received: from mail-nwsmtp-smtp-production-main-45.sas.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-45.sas.yp-c.yandex.net [IPv6:2a02:6b8:c08:6413:0:640:1bc4:0])
	by forward500c.mail.yandex.net (Yandex) with ESMTP id A58385F4C3;
	Wed,  5 Apr 2023 10:29:58 +0300 (MSK)
Received: by mail-nwsmtp-smtp-production-main-45.sas.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id sTJvmY6WuGk0-eoup7ISu;
	Wed, 05 Apr 2023 10:29:56 +0300
X-Yandex-Fwd: 1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1680679796;
	bh=U9vS24GtzLWTgU4xgRSk4Dz6mDnWlOgFQzUWxLo8DUQ=;
	h=In-Reply-To:From:Date:References:To:Subject:Message-ID;
	b=s8yXSZlEOmOvb3msYJtP0r1fledDSuXEBkAm1QYLFszK7zqu5VL6fdL06lqr8DfvX
	 O0r3O7p2wTldIAx6tmUMeJVdkW2BKbhmw5OUCzGq3stOvVHXG2xoxP5v+ZlAo+dpOH
	 Cp4tIcf0FKzccWI3hCp/DspI64i4REfLcui2tJP8=
Authentication-Results: mail-nwsmtp-smtp-production-main-45.sas.yp-c.yandex.net; dkim=pass header.i=@yandex.ru
Message-ID: <81749d04-8cdb-de0b-b88e-24347ed535ba@yandex.ru>
Date: Wed, 5 Apr 2023 12:29:53 +0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.7.1
Subject: Re: [PATCH v9 0/13] implement dlmem() function
Content-Language: en-US
To: Szabolcs Nagy <szabolcs.nagy@arm.com>,
 Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>,
 libc-alpha@sourceware.org, janderson@rice.edu,
 Carlos O'Donell <carlos@redhat.com>, Rich Felker <dalias@libc.org>
References: <20230318165110.3672749-1-stsp2@yandex.ru>
 <a08c9579-e25a-298c-6cd2-d355d32fa7e7@linaro.org>
 <e19ed6a5-67c4-f6c4-9392-b162ffb41209@yandex.ru> <ZCbP+K63XLFDxYYE@arm.com>
 <2f3a10fa-4f79-7f9a-6407-d227dbf31935@yandex.ru> <ZCcUleo68cmjAHoI@arm.com>
 <f0d8f6c1-2b73-550e-4bcf-ebdf84b3b9b2@yandex.ru> <ZCqktritFnXN8Rgv@arm.com>
 <298b04a6-3055-b89b-59c1-4cfbe955848e@yandex.ru> <ZCrAFxOrADRz2Wej@arm.com>
From: stsp <stsp2@yandex.ru>
In-Reply-To: <ZCrAFxOrADRz2Wej@arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,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: <libc-alpha.sourceware.org>

Hi Szabolcs,

03.04.2023 17:01, Szabolcs Nagy пишет:
> a user callback must not run in a context where libc
> internals are exposed (e.g. under internal locks).
I checked that part a bit more, and so far
my findings are (let me know if they are wrong):
- That code indeed works under dl_load_lock,
   but it calls audit callbacks rather freely, and
   I don't see it releasing the lock before calling
   the user audit callbacks.

- dl_iterate_phdr() seems to be calling the user
   callback under dl_load_write_lock lock.

So my callback is called in a same context
where audit callbacks are called, and also
other callbacks seem to have no problem
being called under various locks.

So in that sense why my callback is different,
or what am I missing?