Date: Fri, 3 Aug 2012 17:40:09 GMT From: Konstantin Belousov <kostikbel@gmail.com> To: freebsd-amd64@FreeBSD.org Subject: Re: amd64/170351: [patch] amd64: 64-bit process can't always get unlimited rlimit Message-ID: <201208031740.q73He9iQ038372@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR amd64/170351; it has been noted by GNATS. From: Konstantin Belousov <kostikbel@gmail.com> To: Ming Qiao <mqiao@juniper.net> Cc: freebsd-gnats-submit@freebsd.org Subject: Re: amd64/170351: [patch] amd64: 64-bit process can't always get unlimited rlimit Date: Fri, 3 Aug 2012 20:39:23 +0300 --4rHvg5NaBspxp64F Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 03, 2012 at 03:35:20PM +0000, Ming Qiao wrote: >=20 > >Number: 170351 > >Category: amd64 > >Synopsis: [patch] amd64: 64-bit process can't always get unlimited= rlimit > >Confidential: no > >Severity: non-critical > >Priority: low > >Responsible: freebsd-amd64 > >State: open > >Quarter: =20 > >Keywords: =20 > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Fri Aug 03 15:40:08 UTC 2012 > >Closed-Date: > >Last-Modified: > >Originator: Ming Qiao > >Release: FreeBSD 9.0-RC2 > >Organization: > Juniper Networks > >Environment: > FreeBSD neys 9.0-RC2 FreeBSD 9.0-RC2 #0: Thu Jul 26 01:27:46 UTC 2012 > root@neys:/usr/obj/usr/src/sys/GENERIC amd64 > >Description: > On the amd64 platform, if a 32-bit process ever manually set its rlimit, > none of its 64-bit child or offspring will be able to get the full 64-bit > rlimit anymore, even if they explicitly set the limit to unlimited. >=20 > Note that for the sake of simplicity, only datasize limit is referred > in this report. But the same logic applies to all other memory segment > (i.e. stacksize, etc.). >=20 > Take the following scenario as an example: > 1) Let's say we have a 32-bit process p1 whose hard limit is set to 500MB= by > calling setrlimit(). > 2) p1 then exec another 32-bit process p2. > 3) p2 set its hard limit to unlimited by calling setrlimit(). > 4) p2 exec a 64-bit process p3. > 5) check the hard limit of p3, we can see that it only has 3GB (value of > ia32_maxdsiz) instead of 32GB which is the global kernel limit (value of > maxdsiz) for a 64-bit process. >=20 > The root cause is that on step 3, p2 didn't actually set its limit to > the correct value when calling setrlimit(). Instead the limit is set to > ia32_maxdsiz since ia32_fixlimit() is called in kern_proc_setrlimit(). > >How-To-Repeat: > There are 3 test programs attached in this report: 32_p1.c, 32_p2.c, and > 64_p3.c. They can be used to reproduce the problem. >=20 > 1) Compile 32_p1.c and 32_p2.c into 32-bit binaries. Compile 64_p3.c into > 64-bit binary. > 2) Put all 3 binaries into the same directory on a machine running FreeBSD > amd64 version. > 3) Run 32_p1 which will exec 32_p2 and 64_p3. The output of 64_p3 will sh= ow > its limit is capped at ia32_maxdsiz. > >Fix: > The proposed fix is to change kern_proc_setrlimit() so that sv_fixlimit() > will not be called if the caller wants to set the new limit to RLIM_INFIN= ITY. > Please refer to the attached diff file for the proposed fix. The 'fix' is wrong and does not address the issue. Instead, it uses some arbitrary properties of the scenario you considered and adapts kernel code to suit your scenario. Your deny the correction of the infinity limit, I do not see how it can be right. The problem you described is architectural. By design, Unix resource limits cannot be increased after they were decreased, except by root. In your scenario, the limits were decreased by mere fact of running the 32bit process which have lower 'infinity' limits then 64bit processes. That said, I see two possible solutions. First is to manually set compat.ia32.max* sysctls to 0. Then you get desired behaviour for 64bit processes execed from 32bit, it seems. It does not require code change. Since you are fine with denying fix for infinity, this setting gives the same effect as the patch. Second approach (which is essentially a correction to your approach from fix.diff) is to track the fact that corresponding rlimits are set to 'ABI infinity', in some per-struct rlimit flag. Then, get/setrlimit should first test the 'ABI infinity' flag and behave as if rlimit is set to infinity for current bitness even if the actual value of rlimit is not infinity. Flag is set when rlimit is set to infinity by current ABI. The second approach would provide 'correct' fix, but it is not trivial amount of work for very rare situation (execing 64bit process from 32bit), and current behaviour of inheriting 32bit limits may be argued as right. If you want, feel free to develop such patch, I will review and commit it, but I do not want to spend efforts on developing it myself ATM. --4rHvg5NaBspxp64F Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAcDMoACgkQC3+MBN1Mb4gNuQCePkHJVJy34hUB34TjWliF/M53 V3wAn1Xito7num8GNVfJz0gw3Rb0o3Rz =InLX -----END PGP SIGNATURE----- --4rHvg5NaBspxp64F--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201208031740.q73He9iQ038372>