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.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 27945 invoked from network); 25 Jan 2021 16:07:53 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 25 Jan 2021 16:07:53 -0000 Received: (qmail 10214 invoked by uid 550); 25 Jan 2021 16:07:50 -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 10195 invoked from network); 25 Jan 2021 16:07:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1611590858; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=E3oSuIdFem4HrExMlj1cPgCqEr6/oumwjf7LjonDNEo=; b=IXCYaV+I6jbK6Ykr3XHCltt3NAeEQUaqTcdFnQyLJN1xPZOHET1Zenwhg/On7mXE+n eTOcwxlZcf9obWlVBnt248BpTmIZHCa5VWOSVnpwZ1SpVKFDANa0WhJf3rUWC4n44L9m J/F94AR5LbbhKU4wJj4tTM4aUM/nQxkPP1QhlD+gwVQ2+jrJbB5xEUYZWWJloLC5pFrR h6ATO854A2Hio4lbzamIWzTTSF29CBHeHdhdy8ZO3vsX+gxHeFxcHkmGj4frM79mhJe0 5IKcrMWyiC3nN76HGF4zsGeM3vBekr3Qxo0+4ZeWaazg1RoFDul1d7qWgoSC2kIgaH0w TZJQ== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH+AHjwLuWOHqfyyvs=" X-RZG-CLASS-ID: mo00 From: Bruno Haible To: Rich Felker Cc: musl@lists.openwall.com Date: Mon, 25 Jan 2021 17:07:36 +0100 Message-ID: <2658009.jRRjQAZNrc@omega> User-Agent: KMail/5.1.3 (Linux/4.4.0-197-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <20210125144236.GV23432@brightrain.aerifal.cx> References: <3521697.b4TYcCAa2N@omega> <20210125144236.GV23432@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [musl] insufficient checking in posix_spawn_file_actions_add{open,dup2} 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, ...). A mechanism for avoiding syscalls is the vdso [1][2]. How about adding getlimit to the vdso? Do you know why even simple syscalls like getpid() exist in the vdso only for ia64? Bruno [1] https://man7.org/linux/man-pages/man7/vdso.7.html [2] https://lwn.net/Articles/615809/