[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140414203617.GZ3034@port70.net>
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.
