Re: [PATCH v9 0/13] implement dlmem() function

[Szabolcs Nagy <szabolcs.nagy@arm.com>]

The 04/05/2023 12:29, stsp wrote:
> 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.

this is a known bug.

(audit is special because it is not an api for applications
but for tooling that hooks into dynamic linker internals,
it has its own abi versioning so we can break the abi more
easily and those tools are expected to cope with it. it is
necessarily exposing internals, so new hooks are more likely
acceptable there, but that's not true for apis designed for
application use.)

a much bigger issue is calling user ctors under the
dynamic linker lock which did cause issues in practice.

another issue is calling malloc under locks when malloc
can be interposed (likewise it caused issues in practice).

i did not say glibc was clean from these problems, but
that does not mean we want to add more to it.

> 
> 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.

they have problems.

in any case dlmem has way too many issues beyond
the locking one, the fact that you don't document
nor understand the issues around the huge interface
boundary it creates does not help either.

to successfully propose a new api you need to use
the same rigor as posix or c standardization would.