(cherry picked from commit 4e5c7a2176773c9a1564c6603240337b3ad6b496)
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)
the kernel uses long longs in the struct, but the documentation says they're long. so we need to fixup the mismatch between the userspace and kernelspace structs. since the struct offers a mem_unit member, we can avoid truncation by adjusting that value.
The architecture-specific assembly versions of clone did not set errno on failure, which is inconsistent with glibc. __clone still returns the error via its return value, and clone is now a wrapper that sets errno as needed. The public clone has also been moved to src/linux, as it's not directly related to the pthreads API. __clone is called by pthread_create, which does not report errors via errno. Though not strictly necessary, it's nice to avoid clobbering errno here.
it's unclear what the historical signature for this function was, but semantically, the argument should be a pointer to const, and this is what glibc uses. correct programs should not be using this function anyway, so it's unlikely to matter.
both the kernel and glibc agree that this argument is unsigned; the incorrect type ssize_t came from erroneous man pages.
this was wrong since the original commit adding inotify, and I don't see any explanation for it. not even the man pages have it wrong. it was most likely a copy-and-paste error.
the header is included only as a guard to check that the declaration and definition match, so the typo didn't cause any breakage aside from omitting this check.
the reasons are the same as for sbrk. unlike sbrk, there is no safe usage because brk does not return any useful information, so it should just fail unconditionally.