Date: Tue, 3 Sep 2002 14:47:35 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Peter Wemm <peter@wemm.org> Cc: John Baldwin <jhb@FreeBSD.ORG>, Thomas Moestl <tmoestl@gmx.net>, current@FreeBSD.ORG, des@FreeBSD.ORG, ticso@cicely5.cicely.de, Alexander Kabaev <ak03@gte.com>, ticso@cicely.de Subject: Re: alpha tinderbox failure - kernel is broken. Message-ID: <200209032147.g83LlZoC020492@apollo.backplane.com> References: <20020903214122.4F2822A893@canning.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:> + data_addr = seg_addr;
:> }
:
:I don't think we can do this (the last section), it is quite legal to have
:more than one non-text PT_LOAD segment. if the last one was very small,
:we'd end up with an artificially low 'data_size' which would make for
:interesting RLIMIT_DATA enforcement.
:
:Cheers,
:-Peter
:--
:Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
Well, this represents a reversion to what the data and text calculations
were before any of my commits. I think that the best bet is to revert
that part of the calculation completely rather then revert it only
half way. From what I understand there is usually only one data
segment in an ELF binary anyway. I am also worried that the kernel
may be using the vmspace data start and size in other ways and, really,
the safest solution for now is to revert it so data_start + data_size
yields the end of data in the last loaded data segment (which is also
the highest addressed data segment according to the ELF spec).
We can always put it back in later. I will also note that
RLIMIT_DATA is not really all that useful a resource limit.
It's there basically to protect against runaway malloc()s but
it does not in any way limit the amount of memory a program
actually uses since mmap() is not counted. RLIMIT_VMEM is
the ultimate memory resource limit.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200209032147.g83LlZoC020492>