Date: Mon, 14 Apr 2014 22:36:17 +0200 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Subject: Re: Re: ulimit/getrlimit broken on mips * Thorsten Glaser <tg@...ian.org> [2014-04-14 15:00:35 +0000]: > Szabolcs Nagy <nsz <at> port70.net> writes: > > > > Origin of problem is from my program which asks system for > sysconf(_SC_OPEN_MAX) and gets 0x7fffffff. > > > > yes it seems mips is special.. > > yeah :( > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665897 > > Apparently, not just MIPS, but that???s where it???s most visible. (alpha and sparc are affected too but those are pretty much dead) as far as i can tell glibc is still broken (when prlimit64 is not available get/setrlimit logic is wrong) the kernel is more broken though: limits are sometimes compared with < inside the kernel which is wrong if infinity is represented by a value in the middle of the valid range (kernel accepts limits > 0x7fffffff on mips) (eg right in do_prlimit the kernel checks if (new_rlim->rlim_cur > new_rlim->rlim_max) return -EINVAL; this triggers if the limit is set with setrlimit, but not when it is set with prlimit64 because that uses different logic) it's even worse that on 32bit archs the limits are maintained as 32bit inside the kernel which is broken for at least RLIMIT_FSIZE and makes prlimit64 syscall less useful in general
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.