From: Szabolcs Nagy <nsz@port70.net>
To: musl@lists.openwall.com
Subject: Re: Re: ulimit/getrlimit broken on mips
Date: Mon, 14 Apr 2014 22:36:17 +0200 [thread overview]
Message-ID: <20140414203617.GZ3034@port70.net> (raw)
In-Reply-To: <loom.20140414T170004-348@post.gmane.org>
* 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
prev parent reply other threads:[~2014-04-14 20:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-13 6:19 orc
2014-04-13 9:39 ` Szabolcs Nagy
2014-04-14 15:00 ` Thorsten Glaser
2014-04-14 20:36 ` Szabolcs Nagy [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140414203617.GZ3034@port70.net \
--to=nsz@port70.net \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).