ulimit/getrlimit broken on mips

ulimit/getrlimit broken on mips

[orc]

On mips (eb), musl linked binary which asks kernel with getrlimit(RLIMIT_NOFILE) gets RLIM_INFINITY, but /proc/pid/limits and uClibc binary show correct limits. I can't see what number is asked because landley's strace does not know about prlimit64 and target is embedded system.
Origin of problem is from my program which asks system for sysconf(_SC_OPEN_MAX) and gets 0x7fffffff.

Re: ulimit/getrlimit broken on mips

[Szabolcs Nagy]

* orc <orc@sibserver.ru> [2014-04-13 14:19:22 +0800]:
> On mips (eb), musl linked binary which asks kernel with getrlimit(RLIMIT_NOFILE) gets RLIM_INFINITY, but /proc/pid/limits and uClibc binary show correct limits. I can't see what number is asked because landley's strace does not know about prlimit64 and target is embedded system.
> Origin of problem is from my program which asks system for sysconf(_SC_OPEN_MAX) and gets 0x7fffffff.

yes it seems mips is special..

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/mips/include/uapi/asm/resource.h

Re: ulimit/getrlimit broken on mips

[Thorsten Glaser]

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.

bye,
//mirabilos

Re: Re: ulimit/getrlimit broken on mips

[Szabolcs Nagy]

* Thorsten Glaser <tg@debian.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