[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260824114833.GL3542221@port70.net>
Date: Mon, 24 Aug 2026 13:48:33 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: Skye Soss <skye@...s.website>
Cc: musl <musl@...ts.openwall.com>
Subject: Re: [PATCH] add linux-specific close_range syscall wrapper
* Skye Soss <skye@...s.website> [2026-08-23 22:10:39 -0500]:
> This patch adds the close_range syscall wrapper.
>
> The syscall was added in Linux 5.9.
>
> There was prior discussion more than 4 years ago on this addition. This patch
> is slightly modified to put the CLOSE_RANGE_UNSHARE macro definition inside
> the _GNU_SOURCE section, as FreeBSD defines *_CLOEXEC but not *_UNSHARE.
fwiw i'd put all the flags under the same feature test macro
and consider CLOSE_RANGE_ prefix reserved for that case.
in glibc they are all under _GNU_SOURCE.
> This operation is important to support for popular software such as Python 3,
> as fallback mechanisms are much slower (https://bugs.python.org/issue38061).
> Because function availability is often checked via HAVE_ macros, this needs
> to be exposed as a wrapper function; forcing users to use syscall() is not
> good enough for configure-time detection (as done by GLib).
their fallback is getdents64(/proc/self/fd) + close, which
is not too bad (they only do full close loop if this fails).
so i would not claim "much slower".
they can also use posix_spawn_file_actions_addclosefrom_np
but i guess from musl pov that's not better.
as far as i'm concerned a plain syscall wrapper for this is
fine. (in glibc closefrom has fallback but not close_range.)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
