Subject: Re: setrlimit(2) strange behaviour under compat_netbsd32
To: Nicolas Joly <njoly@pasteur.fr>
From: Quentin Garnier <cube@cubidou.net>
List: current-users
Date: 11/21/2006 12:48:59
--4T94Hejb80K+e1gX
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 21, 2006 at 12:17:24PM +0100, Nicolas Joly wrote:
> On Mon, Nov 20, 2006 at 08:42:53PM +0100, Nicolas Joly wrote:
> >=20
> > I just noticed a strange setrlimit(2) behaviour under compat_netbsd32
> > (and compat_linux32) on my -current amd64 workstation ...
> >=20
> > It seems that 32bits programs, running under compat_netbsd32, using
> > setrlimit force all other programs to have their maximum data size
> > fixed at 3GB, where native 64bits apps used 8GB previously.
>=20
> I tracked this one to the `netbsd32_adjust_limits()' function (called
> when creating a new process under compat_netbsd32), where data and
> stack limits are set without checking for shared `p_limit' structure
> (p_limit->p_refcnt > 1). This explain the side effect where processes
> have their limits changed when a compat_netbsd32 (or compat_linux32)
> program is run.
>=20
> What about the attached patch, that use `dosetrlimit()' to ensure the
> needed copy-on-write behaviour for shared structure.

What bugs me here is that dosetrlimit() does a lot of stuff we don't
need at that point (like, say, returning a value), or more importantly,
don't want:  the kauth test (it uses the process's creds).

Why don't you just grab the refcnt test from dosetrlimit() before you
do the adjustments?

Good catch, by the way, and thanks a bunch for the analysis.

--=20
Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
"You could have made it, spitting out benchmarks
Owe it to yourself not to fail"
Amplifico, Spitting Out Benchmarks, Hometakes Vol. 2, 2005.

--4T94Hejb80K+e1gX
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (NetBSD)

iQEVAwUBRWLnq9goQloHrPnoAQJ2sgf/VbA7hNPmH4udVFhAZSZWLvoR6DsJ1Ym1
IPgTm8X1DmzLUi3Hdf2eJRgw686Sb6Lnp23pt5+Pn8AJogI6tv3cU5y4dDUm82At
e14pSLvWtBmKJOVRdRe2wW92ZCjjmFLlktC1aiBzHZUePpKusEkxP2ihX/blloT3
+OIj41tdEN1Rde7JH1blVsSH2p1Bl6VAHwk2sHaqSjGEDFzKKYXf5YsMlNCYF1mq
BfwtNpOLldoDvavkoTxA4Ew7tiZQiewnBVPXVS2OUqCqki3Pj1NCD91VOOEkqdVr
UTVEUHeEclOLgCNjDS6BI5qHIH/7dNCVKTjfGiJ/VSFvUaAwlnW+6w==
=/Eo7
-----END PGP SIGNATURE-----

--4T94Hejb80K+e1gX--