On 32 bit mips the kernel uses -1UL/2 to mark RLIM_INFINITY (and this is the definition in the userspace api), but since it is in the middle of the valid range of limits and limits are often compared with relational operators, various kernel side logic is broken if larger than -1UL/2 limits are used. So we truncate the limits to -1UL/2 in get/setrlimit and prlimit. Even if the kernel side logic consistently treated -1UL/2 as greater than any other limit value, there wouldn't be any clean workaround that allowed using large limits: * using -1UL/2 as RLIM_INFINITY in userspace would mean different infinity value for get/setrlimt and prlimit (where infinity is always -1ULL) and userspace logic could break easily (just like the kernel is broken now) and more special case code would be needed for mips. * translating -1UL/2 kernel side value to -1ULL in userspace would mean that -1UL/2 limit cannot be set (eg. -1UL/2+1 had to be passed to the kernel instead). (cherry picked from commit 8258014fd1e34e942a549c88c7e022a00445c352)
on x32, this change allows programs which use syscall() with pointers or 64-bit values as arguments to work correctly, i.e. without truncation or incorrect sign extension. on all other supported archs, syscall_arg_t is defined as long, so this change is a no-op.
the incorrect error codes also made their way into errno when __ptsname_r was called by plain ptsname, which reports errors via errno rather than a return value.
the incorrect check for crossing device boundaries was preventing nftw from traversing anything except the initially provided pathname.
our getcwd already (as an extension) supports allocation of a buffer when the buffer argument is a null pointer, so there's no need to duplicate the allocation logic in this wrapper function. duplicating it is actually harmful in that it doubles the stack usage from PATH_MAX to 2*PATH_MAX.
loop condition was incorrect and confusing and caused an infinite loop when (broken) applications reaped the pid from a signal handler or another thread before wordexp's call to waitpid could do so.
when WRDE_NOSPACE is returned, the we_wordv and we_wordc members must be valid, because the interface contract allows them to return partial results. in the case of zero results (due either to resource exhaustion or a zero-word input) the we_wordv array still should contain a terminating null pointer and the initial we_offs null pointers. this is impossible on resource exhaustion, so a correct application must presumably check for a null pointer in we_wordv; POSIX however seems to ignore the issue. the previous code may have crashed under this situation.
avoid using exit status to determine if a shell error occurred, since broken programs may install SIGCHLD handlers which reap all zombies, including ones that don't belong to them. using clone and __WCLONE does not seem to work for avoiding this problem since exec resets the exit signal to SIGCHLD. instead, the new code uses a dummy word at the beginning of the shell's output, which is ignored, to determine whether the command was executed successfully. this also fixes a corner case where a word string containing zero words was interpreted as a single zero-length word rather than no words at all. POSIX does not seem to require this case to be supported anyway, though. in addition, the new code uses the correct retry idiom for waitpid to ensure that spurious STOP/CONT signals in the child and/or EINTR in the parent do not prevent successful wait for the child, and blocks signals in the child.