[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210125161512.GW23432@brightrain.aerifal.cx>
Date: Mon, 25 Jan 2021 11:15:12 -0500
From: Rich Felker <dalias@...c.org>
To: Bruno Haible <bruno@...sp.org>
Cc: musl@...ts.openwall.com
Subject: Re: insufficient checking in
posix_spawn_file_actions_add{open,dup2}
On Mon, Jan 25, 2021 at 05:07:36PM +0100, Bruno Haible wrote:
> Rich Felker wrote:
> > I would very much prefer not to have to enforce such a max here since
> > ... wastes a syscall in an
> > operation that should not require one.
>
> sysconf (_SC_OPEN_MAX) is equivalent to the rlim_cur value from
> getrlimit(RLIMIT_NOFILE, ...).
I'm aware of that. But I'm not convinced that the standard as written
requires any comparison against sysconf(_SC_OPEN_MAX). Is there a
general rule somewhere that {x_MAX} in the text implies a requirement
to use the dynamic runtime value if x_MAX is undefined but there's a
corresponding _SC_x_MAX? Otherwise "greater than or equal to
{OPEN_MAX}" is vacuously false when OPEN_MAX is not defined.
> A mechanism for avoiding syscalls is the vdso [1][2]. How about adding
> getlimit to the vdso?
There's an unbounded amount of stuff like this that technically could
be added to the vdso but with diminishing returns. Even if there does
turn out to be a requirement to check against the dynamic max here, I
don't think the cost is sufficient to justify added complexity.
> Do you know why even simple syscalls like getpid()
> exist in the vdso only for ia64?
In the case of getpid, because glibc does (or at least did? not sure
if they still do) cache it themselves in the TCB, adding it to vdso
offered no additional concrete benefit.
Rich
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.
