From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
To: stsp <stsp2@yandex.ru>, libc-alpha@sourceware.org
Subject: Re: [PATCH 02/13] elf: switch _dl_map_segment() to anonymous mapping
Date: Wed, 29 Mar 2023 15:29:57 -0300 [thread overview]
Message-ID: <0ecd46af-74d2-a1ea-cd3f-88c7c9886c21@linaro.org> (raw)
In-Reply-To: <bd4d120b-0408-e5eb-893a-86409c890a90@yandex.ru>
On 29/03/23 15:00, stsp wrote:
>
> 29.03.2023 22:01, Adhemerval Zanella Netto пишет:
>> glibc code guidelines [1] suggest to explicit define the types, so
>> 'unsigned int' here.
>
> Fixed locally this and a few other
> similar instances. Queued to v10.
>
>
>> [1] https://sourceware.org/glibc/wiki/Style_and_Conventions
>>
>>> +
>>> +#ifdef MAP_DENYWRITE
>>> + /* Tell mmap() that we are mapping solib. This flag enables things
>>> + like LD_PREFER_MAP_32BIT_EXEC. */
>>> + map_flags |= MAP_DENYWRITE;
>>> +#endif
>> Why do you need o add MAP_DENYWRITE? They are complete ignored by Linux,
>
> But its not ignored in glibc, see
>
> sysdeps/unix/sysv/linux/x86_64/64/mmap_internal.h
>
> Without that flag PREFER_MAP_32BIT_EXEC
> test fails.
Because elf/dl-load.h already defines MAP_COPY that handles it, so why
not use it instead?
>
>
>> So basically it would add another mmap on program loading. For instance, loading
>> a simple empty main programs:
>
> Yes, that's true.
> Is this a problem?
>
>
Yes, Linux limits a maximum mmap both per process [1]. This code increase both
the total mapping requires and runtime cost to setup a new shared library.
[1] https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/sysctl/vm.rst#max_map_count
>> And it also slight change the mapping, using the same program:
>>
>> * Before:
>>
>> 0x7ffff7dc2000 0x7ffff7de8000 0x26000 0x0 r--p /home/azanella/Projects/glibc/build/x86_64-linux-gnu/libc.so
>> 0x7ffff7de8000 0x7ffff7f54000 0x16c000 0x26000 r-xp /home/azanella/Projects/glibc/build/x86_64-linux-gnu/libc.so
>> 0x7ffff7f54000 0x7ffff7faa000 0x56000 0x192000 r--p /home/azanella/Projects/glibc/build/x86_64-linux-gnu/libc.so
>> 0x7ffff7faa000 0x7ffff7fab000 0x1000 0x1e8000 ---p /home/azanella/Projects/glibc/build/x86_64-linux-gnu/libc.so
>> 0x7ffff7fab000 0x7ffff7faf000 0x4000 0x1e8000 r--p /home/azanella/Projects/glibc/build/x86_64-linux-gnu/libc.so
>> 0x7ffff7faf000 0x7ffff7fb1000 0x2000 0x1ec000 rw-p /home/azanella/Projects/glibc/build/x86_64-linux-gnu/libc.so
>>
>> * With this patch:
>>
>> 0x7ffff7dc1000 0x7ffff7de7000 0x26000 0x0 r--p /home/azanella/Projects/glibc/build/x86_64-linux-gnu/libc.so
>> 0x7ffff7de7000 0x7ffff7f53000 0x16c000 0x26000 r-xp /home/azanella/Projects/glibc/build/x86_64-linux-gnu/libc.so
>> 0x7ffff7f53000 0x7ffff7fa9000 0x56000 0x192000 r--p /home/azanella/Projects/glibc/build/x86_64-linux-gnu/libc.so
>> 0x7ffff7fa9000 0x7ffff7faa000 0x1000 0x0 ---p
>> 0x7ffff7faa000 0x7ffff7fae000 0x4000 0x1e8000 r--p /home/azanella/Projects/glibc/build/x86_64-linux-gnu/libc.so
>> 0x7ffff7fae000 0x7ffff7fb0000 0x2000 0x1ec000 rw-p /home/azanella/Projects/glibc/build/x86_64-linux-gnu/libc.so
>
> Mm, was staring on this for a while,
> and file offsets and perms looks the
> same. What differences do you mean
> exactly?
The PROT_NONE mapping now does not have a file associated:
0x7ffff7fa9000 0x7ffff7faa000 0x1000 0x0 ---p
This is not a problem itself, but again this change decrease the information
that some tools might use to analyze the memory mapping.
>
>> So I am not seeing any advantage of this refactor: it slight increase the
>> number of syscalls for library loading and changes the 'debuggability' of
>> resulting shared library maps.
>
> This is not a "pure refactor", but a preparation
> to dlmem(). dlmem() allows the user to pre-map
> the memory area (optionally), so in the subsequent
> patches I first call the user's callback, and if its
> not there or doesn't want to pre-map, then I call
> _dl_load_segment() for doing the same thing as
> a fall-back.
>
> Do you want me to squash also that patch
> into the one that actually needs it?
>
No need, this patch as-is is nack. This patch has only cons: it increases runtime
cost for generic case, increase the minimum number of mmap segment a shared library
required, and decrease debuggability.
next prev parent reply other threads:[~2023-03-29 18:30 UTC|newest]
Thread overview: 107+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-18 16:50 [PATCH v9 0/13] implement dlmem() function Stas Sergeev
2023-03-18 16:50 ` [PATCH 01/13] elf: strdup() l_name if no realname [BZ #30100] Stas Sergeev
2023-03-29 13:54 ` Adhemerval Zanella Netto
2023-03-29 14:12 ` stsp
2023-03-29 14:19 ` Adhemerval Zanella Netto
2023-03-29 14:28 ` stsp
2023-03-29 14:30 ` Adhemerval Zanella Netto
2023-03-29 14:33 ` stsp
2023-03-18 16:50 ` [PATCH 02/13] elf: switch _dl_map_segment() to anonymous mapping Stas Sergeev
2023-03-29 17:01 ` Adhemerval Zanella Netto
2023-03-29 18:00 ` stsp
2023-03-29 18:29 ` Adhemerval Zanella Netto [this message]
2023-03-29 18:46 ` stsp
2023-03-29 19:17 ` Adhemerval Zanella Netto
2023-03-29 19:43 ` stsp
2023-03-18 16:51 ` [PATCH 03/13] elf: dont pass fd to _dl_process_pt_xx Stas Sergeev
2023-03-29 17:10 ` Adhemerval Zanella Netto
2023-03-30 16:08 ` stsp
2023-03-30 20:46 ` Adhemerval Zanella Netto
2023-03-31 12:02 ` Szabolcs Nagy
2023-03-31 12:54 ` Adhemerval Zanella Netto
2023-03-31 14:04 ` stsp
2023-03-18 16:51 ` [PATCH 04/13] elf: split _dl_map_object_from_fd() into reusable parts Stas Sergeev
2023-03-18 16:51 ` [PATCH 05/13] elf: split open_verify() " Stas Sergeev
2023-03-18 16:51 ` [PATCH 06/13] elf: load elf hdr fully in open_verify() Stas Sergeev
2023-03-18 16:51 ` [PATCH 07/13] elf: convert pread64 to callback in do_open_verify() Stas Sergeev
2023-03-18 16:51 ` [PATCH 08/13] elf: convert _dl_map_segments's mmap() to a callback Stas Sergeev
2023-03-18 16:51 ` [PATCH 09/13] elf: call _dl_map_segment() via premap callback Stas Sergeev
2023-03-18 16:51 ` [PATCH 10/13] elf: convert _dl_map_object to a callback Stas Sergeev
2023-03-18 16:51 ` [PATCH 11/13] elf: split _dl_check_loaded() from _dl_map_object Stas Sergeev
2023-03-18 16:51 ` [PATCH 12/13] dlfcn,elf: implement dlmem() [BZ #11767] Stas Sergeev
2023-03-29 13:45 ` Carlos O'Donell
2023-03-29 13:51 ` stsp
2023-03-29 14:10 ` Jonathon Anderson
2023-03-29 14:20 ` stsp
2023-03-29 14:31 ` Adhemerval Zanella Netto
2023-03-29 15:01 ` stsp
2023-03-29 14:35 ` Carlos O'Donell
2023-03-29 14:50 ` stsp
2023-03-29 15:20 ` Carlos O'Donell
2023-03-29 15:34 ` stsp
2023-03-30 8:09 ` stsp
2023-03-18 16:51 ` [PATCH 13/13] dlfcn,elf: impl DLMEM_DONTREPLACE dlmem() flag Stas Sergeev
2023-03-29 12:32 ` [PATCH v9 0/13] implement dlmem() function Adhemerval Zanella Netto
2023-03-29 13:10 ` stsp
2023-03-29 13:18 ` stsp
2023-03-31 12:20 ` Szabolcs Nagy
2023-03-31 13:51 ` stsp
2023-03-31 14:49 ` Rich Felker
2023-03-31 14:56 ` stsp
2023-03-31 14:58 ` Rich Felker
2023-03-31 15:03 ` stsp
2023-03-31 14:44 ` stsp
2023-03-31 15:12 ` stsp
2023-03-31 17:12 ` Szabolcs Nagy
2023-03-31 17:36 ` stsp
2023-04-01 9:28 ` stsp
2023-04-03 10:04 ` Szabolcs Nagy
2023-04-03 10:43 ` stsp
2023-04-03 12:01 ` Szabolcs Nagy
2023-04-03 13:07 ` stsp
2023-04-05 7:29 ` stsp
2023-04-05 8:51 ` Szabolcs Nagy
2023-04-05 9:26 ` stsp
2023-04-05 9:31 ` Florian Weimer
2023-04-12 17:23 ` stsp
2023-04-12 18:00 ` stsp
2023-04-12 18:20 ` Rich Felker
2023-04-12 18:46 ` stsp
2023-04-12 19:52 ` Zack Weinberg
2023-04-12 19:07 ` stsp
2023-04-13 10:01 ` stsp
2023-04-13 12:38 ` Szabolcs Nagy
2023-04-13 15:59 ` stsp
2023-04-13 18:09 ` Adhemerval Zanella Netto
2023-04-13 18:59 ` stsp
2023-04-13 19:12 ` Adhemerval Zanella Netto
2023-04-13 19:29 ` stsp
2023-04-13 20:02 ` Adhemerval Zanella Netto
2023-04-13 20:21 ` stsp
2023-04-13 20:57 ` stsp
2023-04-14 7:07 ` stsp
2023-04-14 7:36 ` stsp
2023-04-14 11:30 ` stsp
2023-04-14 19:04 ` proof for dlmem() (Re: [PATCH v9 0/13] implement dlmem() function) stsp
2023-05-01 23:11 ` Zack Weinberg
2023-05-02 5:48 ` stsp
2023-05-08 16:00 ` stsp
2023-05-02 6:24 ` stsp
2023-05-08 15:10 ` [PATCH v9 0/13] implement dlmem() function stsp
2023-03-31 18:47 ` stsp
2023-03-31 19:00 ` stsp
2023-03-29 13:17 ` Carlos O'Donell
2023-03-29 13:26 ` stsp
2023-03-29 17:03 ` stsp
2023-03-29 18:13 ` Carlos O'Donell
2023-03-29 18:29 ` stsp
2023-03-31 11:04 ` stsp
2023-04-13 21:17 ` Carlos O'Donell
2023-04-13 21:58 ` stsp
2023-04-13 22:08 ` stsp
2023-04-13 22:50 ` stsp
2023-04-14 16:15 ` Autoconf maintenance (extremely tangential to Re: [PATCH v9 0/13] implement dlmem() function) Zack Weinberg
2023-04-14 20:24 ` Carlos O'Donell
2023-04-14 20:40 ` Zack Weinberg
2023-05-08 15:05 ` [PATCH v9 0/13] implement dlmem() function stsp
2023-05-19 7:26 ` stsp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0ecd46af-74d2-a1ea-cd3f-88c7c9886c21@linaro.org \
--to=adhemerval.zanella@linaro.org \
--cc=libc-alpha@sourceware.org \
--cc=stsp2@yandex.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).