From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8326 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: nfs-utils broken with musl: "select: Bad file descriptor" Date: Tue, 18 Aug 2015 16:51:44 -0400 Message-ID: <20150818205144.GM32742@brightrain.aerifal.cx> References: <55D298BD.2030903@gmail.com> <20150818030021.GG32742@brightrain.aerifal.cx> <55D3626E.4080107@gmail.com> <20150818174915.GL32742@brightrain.aerifal.cx> <20150818182014.GA1244@nyan> <20150818191810.GA18417@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1439931127 26358 80.91.229.3 (18 Aug 2015 20:52:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 18 Aug 2015 20:52:07 +0000 (UTC) Cc: Tastky To: musl@lists.openwall.com Original-X-From: musl-return-8338-gllmg-musl=m.gmane.org@lists.openwall.com Tue Aug 18 22:52:02 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ZRnrT-0002IK-EW for gllmg-musl@m.gmane.org; Tue, 18 Aug 2015 22:51:59 +0200 Original-Received: (qmail 14158 invoked by uid 550); 18 Aug 2015 20:51:57 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 14137 invoked from network); 18 Aug 2015 20:51:57 -0000 Content-Disposition: inline In-Reply-To: <20150818191810.GA18417@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:8326 Archived-At: On Tue, Aug 18, 2015 at 09:18:10PM +0200, Szabolcs Nagy wrote: > * Felix Janda [2015-08-18 20:20:14 +0200]: > > > Rich Felker wrote: > > > On Tue, Aug 18, 2015 at 06:50:54PM +0200, Tastky wrote: > > > > Just checked with said include and everything recompiled. > > > > Unfortunately the same error persists. > > > > > > > > Running OpenWrt's command > > > > /usr/sbin/rpc.statd -p 32778 -o 32779 -F > > > > manually (following the script's prior steps, ofc) results in a loop of: > > > > > > > > sm-notify: Version 1.3.2 starting > > > > sm-notify: Already notifying clients; Exiting > > > > > > > > With strace: http://pastebin.com/raw.php?i=9ypUbmsp > > > > > > From the strace, I see that a nonsensical fd #105 is in the fd_set > > > readfds that comes from SVC_FDSET. I don't know where the latter is > > > defined or modified. > > > > It is defined in system.h (now hopefully) to be svc_fdset, which seems > > to be defined as a global variable by the rpc headers. > > > > i think this call goes wrong: > > http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=blob;f=utils/statd/rmtcall.c;hb=HEAD#l56 > > it loops for 100 iterations and if all ports are used > according to getservbyport then it FD_SET(sockfd, &SVC_FDSET); > with some random high sockfd (eg. 105) that is closed. > > ...so should getservbyport fail there? > > (according to strace it tries ports 883 to 982) I think the application's expectation is that it fail rather than returning a decimal-string-only service entity. However it looks like the code is written to handle the case where all 100 iterations fail to get an anonymous port. The problem seems to be that, when the loop stops due to hitting the iteration count rather than exiting with break, i has already been incremented past the last tmp_socket slot, so the close loop closes the fd that they actually want to use, later causing EBADF. This is purely an application bug, but it happens not to get noticed if getservbyport fails anywhere along the way, which they expect to happen in the usual case. Rich