From owner-freebsd-current Tue Sep 3 14:47:42 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C64D37B400; Tue, 3 Sep 2002 14:47:39 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD7CC43E42; Tue, 3 Sep 2002 14:47:38 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.4) with ESMTP id g83LlZPQ020493; Tue, 3 Sep 2002 14:47:35 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.4/Submit) id g83LlZoC020492; Tue, 3 Sep 2002 14:47:35 -0700 (PDT) (envelope-from dillon) Date: Tue, 3 Sep 2002 14:47:35 -0700 (PDT) From: Matthew Dillon Message-Id: <200209032147.g83LlZoC020492@apollo.backplane.com> To: Peter Wemm Cc: John Baldwin , Thomas Moestl , current@FreeBSD.ORG, des@FreeBSD.ORG, ticso@cicely5.cicely.de, Alexander Kabaev , ticso@cicely.de Subject: Re: alpha tinderbox failure - kernel is broken. References: <20020903214122.4F2822A893@canning.wemm.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :> + 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message