Date: Fri, 20 Apr 2012 21:55:43 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Robert Millan <rmh@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: Increase DFLDSIZ on amd64? Message-ID: <20120420185543.GU2358@deviant.kiev.zoral.com.ua> In-Reply-To: <CAOfDtXOqj6ozTSGCiUZ3HCfXwx%2B6aTwtj7bZ1rxQwz32iEb1kA@mail.gmail.com> References: <CAOfDtXMSQ_iT8zQKjrQ-4AxFDtNoNNj-7-=kXGT6RdOMOtyXUA@mail.gmail.com> <CAGE5yCqQ=_XysKwQcdu2DUeycp33TzRd0H0FwT-ufitQpGzXPw@mail.gmail.com> <CAOfDtXOqj6ozTSGCiUZ3HCfXwx%2B6aTwtj7bZ1rxQwz32iEb1kA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--mL1UijcviCmf7HKk
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Apr 20, 2012 at 08:47:45PM +0200, Robert Millan wrote:
> Hi Peter,
>=20
> El 19 d???abril de 2012 0:23, Peter Wemm <peter@wemm.org> ha escrit:
> > Hmm. =9AIn login,conf, we have:
> > :datasize=3Dunlimited:
> > .. which causes the datasize limit to be pushed to 32G by default at
> > login/cron/sshd/etc.
>=20
> Well, Debian has a similar facility, but I don't think this solves the
> problem, as it only covers processes that descend from a login shell.
> What about daemons?
>=20
> > Also, malloc doesn't use this pool on amd64 - it comes straight out of
> > mmap MAP_ANON page blocks. =9AThe only that should be hitting it ever
> > would be things that call the old sbrk(3) interface directly. =9AMalloc
> > shouldn't be hitting it.
>=20
> I hit trouble with the dynamic linker:
>=20
> # cat test.c
> char buf[1024*1024*1024];
> int
> main ()
> {
> }
> # gcc test.c -o test
> # ./test
> Abort trap: 6
>=20
> Not sure about other things but IMHO it's a valid reason to increase
> the default to match with the one set by userland.
Just for record, this is not an issue with dynamic linker.
Kernel image activator returns error if data segment size is larger
then RLIMIT_DATA value, see imgact_elf.c:901.
Then, since the address space of the program which called execve(2)
is already destroyed when segment mapping is performed, kernel has no
other choice and kills the process.
--mL1UijcviCmf7HKk
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (FreeBSD)
iEYEARECAAYFAk+RsS8ACgkQC3+MBN1Mb4gV/QCgqnjq1Q4d+q9YQQpS0jKzQQCX
t+MAoJFJjPzL88TLITx4TtVnU1DsYHcr
=5kdP
-----END PGP SIGNATURE-----
--mL1UijcviCmf7HKk--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120420185543.GU2358>