From: Rich Felker <dalias@libc.org>
To: "Alex Xu (Hello71)" <alex_y_xu@yahoo.ca>
Cc: musl@lists.openwall.com
Subject: Re: [musl] [PATCH] don't set errno in free
Date: Thu, 21 Jan 2021 11:27:34 -0500 [thread overview]
Message-ID: <20210121162734.GO23432@brightrain.aerifal.cx> (raw)
In-Reply-To: <20210121140240.83405-1-alex_y_xu@yahoo.ca>
On Thu, Jan 21, 2021 at 09:02:40AM -0500, Alex Xu (Hello71) wrote:
> busybox echo fails if free sets errno, which madvise does on old
> kernels.
> ---
> src/malloc/mallocng/free.c | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/src/malloc/mallocng/free.c b/src/malloc/mallocng/free.c
> index 40745f97..82836815 100644
> --- a/src/malloc/mallocng/free.c
> +++ b/src/malloc/mallocng/free.c
> @@ -119,7 +119,13 @@ void free(void *p)
> if (((uintptr_t)(start-1) ^ (uintptr_t)end) >= 2*PGSZ && g->last_idx) {
> unsigned char *base = start + (-(uintptr_t)start & (PGSZ-1));
> size_t len = (end-base) & -PGSZ;
> - if (len) madvise(base, len, MADV_FREE);
> + if (len) {
> + // madvise(..., MADV_FREE) returns -EINVAL on old kernels
> + // POSIX.1-202x requires free() to not modify errno on success
> + int e = errno;
> + madvise(base, len, MADV_FREE);
> + errno = e;
> + }
> }
glue.h is already responsible for wiring up madvise appropriately
(namespace-safe), so we could just change it to make a raw syscall
instead of the function call to __madvise. This would be slightly less
costly at runtime, but is kinda non-obvious to the reader (especially
if the name is retained) and not as friendly to using mallocng
standalone outside musl.
> // atomic free without locking if this is neither first or last slot
> @@ -139,5 +145,9 @@ void free(void *p)
> wrlock();
> struct mapinfo mi = nontrivial_free(g, idx);
> unlock();
> - if (mi.len) munmap(mi.base, mi.len);
> + // POSIX.1-202x requires free() to not modify errno on success
> + // munmap should succeed but no harm checking it again
> + if (mi.len)
> + if (munmap(mi.base, mi.len))
> + a_crash();
> }
> --
> 2.30.0
This is utterly wrong and will crash correct programs. Unmapping
memory can create 2 (temporarily 3) VMAs from one, thereby exceeding
the VMA limit and failing. In this case you have to just accept the
memory leak; you can't kill the valid program because the kernel is
incapable of handling its request in a way that doesn't waste memory.
You also can't do a raw syscall here, because munmap must wait for the
vmlock. So some additional work to save/restore errno is needed, or
else we need to expose a non-errno-using version of __munmap and use
it.
Rich
prev parent reply other threads:[~2021-01-21 16:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20210121140240.83405-1-alex_y_xu.ref@yahoo.ca>
2021-01-21 14:02 ` Alex Xu (Hello71)
2021-01-21 15:50 ` Natanael Copa
2021-01-21 16:18 ` Rich Felker
2021-01-21 16:20 ` Florian Weimer
2021-01-21 16:31 ` Natanael Copa
2021-01-21 16:27 ` Rich Felker [this message]
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=20210121162734.GO23432@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=alex_y_xu@yahoo.ca \
--cc=musl@lists.openwall.com \
/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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
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 NNTP newsgroup(s).