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

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

The 03/31/2023 22:36, stsp wrote:
> 31.03.2023 22:12, Szabolcs Nagy пишет:
> > loading from special place and loading into special place
> > are different things.
> 
> These are related.
> File-based mmaps leave you no chance
> of preserving the destination mapping,

"preserving" the "destination mapping" (?)
a new requirement..

> > your dlmem design it passes down a user callback that runs
> > under dynamic linker locks to map segments. the interface
> > contract of this callback is not documented, so it can
> > deadlock
> 
> Good point.
> But this is a documentation issue, right?
> Not too much is needed: in the simple case
> you only do anonymous mmap() in a callback.
> In a more difficult case (my use-case) I do
> shm_open(), ftruncate() and mmap().
> Of course I need to document that any libdl
> functions are disallowed, is this correct?

that is not correct. (see below)

> >   and exposes dynamic linker internals (makes
> > implementation changes harder later).
> 
> Could you please clarify that part?
> typedef void *
> (dlmem_premap_t) (void *mappref, size_t maplength, size_t mapalign,
>               void *cookie);
> 
> This only passes things needed for an initial
> mmap(). The single mmap() that just defines
> the mapping address.
> What internals do you mean?

the segments of an elf file can be mmapped in many ways,
there is no such thing as initial mmap (there need not
be a mapping that covers all segments and there is no
ordering requirement for the mappings or which mapping
is file backed etc) your callback exposes a particular
behaviour.

and libc apis are exposed to not use locks that have
lock ordering requirement wrt the dynamic linker
internal lock. (e.g. we could add such a lock in mmap
or shm_open since they are not required to be as-safe.
so your callback can deadlock in a future glibc).

and it's not just locks but any unusual libc internal
state that becomes observable via the callback.
(the callback runs when the dynamic linker may be in
inconsistent internal state. why do you assume that
shm_open or other libc apis work in that case? this
is a new requirement that has to be documented.)

> Also please note that the callback is optional
> and is not needed for 99% of the interesting
> cases possible with dlmem().

it does not matter if it's 99% or 99.999%, what matters
is that if we expose an api then that has to work
*forever* under all potential usage and we have to
keep *supporting* it with all the api&abi constraints.

giving examples is not a *proof* that the api works.

> > if all you want is force mapping below 4G then you should
> > have asked for an RTLD_ flag (which may not be useful
> > enough or may not be supportable on all relevant targets,
> > but at least does not need significant loader changes).
> There is already such flag.

x86 specific flag.

> Unfortunately my setup is much more
> complicated than that: I need to force
> the mapping under 4Gb AND I need to
> force it into the shared buffer which I
> then mmap() to another address...

you didnt explain this in the rationale of the patches.

but it seems what you want is not suitable for libc.
you have to write your own loader to do this.