From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12432 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] faccessat: fix error code on setreXid failure Date: Tue, 30 Jan 2018 17:07:37 -0500 Message-ID: <20180130220737.GN1627@brightrain.aerifal.cx> References: <20180130203237.4580-1-amonakov@ispras.ru> <20180130213353.GM1627@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1517349984 14756 195.159.176.226 (30 Jan 2018 22:06:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Jan 2018 22:06:24 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-12448-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jan 30 23:06:19 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1ege2F-0001Yn-Do for gllmg-musl@m.gmane.org; Tue, 30 Jan 2018 23:05:47 +0100 Original-Received: (qmail 5154 invoked by uid 550); 30 Jan 2018 22: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: Original-Received: (qmail 5132 invoked from network); 30 Jan 2018 22:07:49 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:12432 Archived-At: On Wed, Jan 31, 2018 at 12:51:58AM +0300, Alexander Monakov wrote: > On Tue, 30 Jan 2018, Rich Felker wrote: > > > > AFAIK wait4 can also return due to Stopped status or trace-related > > reasons, not just exit. That was the motivation I think. > > We know we are not tracing this child, and stop notifications are only > delivered if WUNTRACED is given in flags, aren't they? I'm not sure what can happen if it's all running under strace -f or something. And I'm not sure what the conditions for stop notifications are. If it's assured that they can't happen then maybe the loop can be removed. > > > - the code seems to assume that the zombie will not be auto-collected even if > > > SIGCHLD disposition is set to SIG_IGN; this sounds logical, but not explicitly > > > documented as far as I can tell; > > > > Indeed, I'm not sure, but I don't know any good fix. > > Bring back the pipe (similar to how posix_spawn receives the status)? Ah yes. > > > --- a/src/unistd/faccessat.c > > > +++ b/src/unistd/faccessat.c > > > @@ -25,7 +25,7 @@ static int checker(void *p) > > > int i; > > > if (__syscall(SYS_setregid, __syscall(SYS_getegid), -1) > > > || __syscall(SYS_setreuid, __syscall(SYS_geteuid), -1)) > > > - __syscall(SYS_exit, 1); > > > + return sizeof errors/sizeof *errors - 1; > > > ret = __syscall(SYS_faccessat, c->fd, c->filename, c->amode, 0); > > > for (i=0; i < sizeof errors/sizeof *errors - 1 && ret!=errors[i]; i++); > > > return i; > > > > Looks ok except it encodes an assumption that EBUSY is last. It might > > make more sense to goto the errno-searching loop. > > Well, the loop also implicitly encodes that assumption anyway: it stops > at the last entry regardless if it matches, making EBUSY the fallback code > for unrecognized SYS_faccessat return values. Indeed. > The loop will be gone if the pipe method is re-introduced. Maybe this is the right approach. Anyone else have opinions on it? This would just mean reverting the most recent commit to it then possibly fixing other issues you found, right? Rich