From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 28802 invoked from network); 25 Jan 2021 16:15:30 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 25 Jan 2021 16:15:30 -0000 Received: (qmail 14242 invoked by uid 550); 25 Jan 2021 16:15:25 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 14220 invoked from network); 25 Jan 2021 16:15:24 -0000 Date: Mon, 25 Jan 2021 11:15:12 -0500 From: Rich Felker To: Bruno Haible Cc: musl@lists.openwall.com Message-ID: <20210125161512.GW23432@brightrain.aerifal.cx> References: <3521697.b4TYcCAa2N@omega> <20210125144236.GV23432@brightrain.aerifal.cx> <2658009.jRRjQAZNrc@omega> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2658009.jRRjQAZNrc@omega> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] 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