From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4881 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: ulimit/getrlimit broken on mips Date: Mon, 14 Apr 2014 22:36:17 +0200 Message-ID: <20140414203617.GZ3034@port70.net> References: <4a6ae836-4e98-495a-8f94-05130a76f52a@email.android.com> <20140413093942.GX3034@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1397507796 31892 80.91.229.3 (14 Apr 2014 20:36:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Apr 2014 20:36:36 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4885-gllmg-musl=m.gmane.org@lists.openwall.com Mon Apr 14 22:36:31 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WZncE-00061g-0F for gllmg-musl@plane.gmane.org; Mon, 14 Apr 2014 22:36:30 +0200 Original-Received: (qmail 5786 invoked by uid 550); 14 Apr 2014 20:36:28 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 5778 invoked from network); 14 Apr 2014 20:36:28 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4881 Archived-At: * Thorsten Glaser [2014-04-14 15:00:35 +0000]: > Szabolcs Nagy 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