Subject: Re: setrlimit(2) strange behaviour under compat_netbsd32
To: Nicolas Joly <>
From: Quentin Garnier <>
List: current-users
Date: 11/21/2006 12:48:59
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.
> 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.
> 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.

Quentin Garnier - -
"You could have made it, spitting out benchmarks
Owe it to yourself not to fail"
Amplifico, Spitting Out Benchmarks, Hometakes Vol. 2, 2005.

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.4.5 (NetBSD)