Date: Wed, 31 Jan 2018 00:51:58 +0300 (MSK) From: Alexander Monakov <amonakov@...ras.ru> To: musl@...ts.openwall.com Subject: Re: [PATCH] faccessat: fix error code on setreXid failure 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? > > - 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)? > > --- 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. The loop will be gone if the pipe method is re-introduced. Alexander
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.