From owner-freebsd-hackers Tue Feb 16 17:53: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (Postfix) with SMTP id 588EA110A0 for ; Tue, 16 Feb 1999 17:52:32 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 26855 invoked from network); 17 Feb 1999 01:52:29 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 17 Feb 1999 01:52:29 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id UAA00758; Tue, 16 Feb 1999 20:52:28 -0500 (EST) Message-Id: <199902170152.UAA00758@y.dyson.net> Subject: Re: vm_page_zero_fill In-Reply-To: <199902162246.PAA08400@usr08.primenet.com> from Terry Lambert at "Feb 16, 99 10:46:46 pm" To: tlambert@primenet.com (Terry Lambert) Date: Tue, 16 Feb 1999 20:52:28 -0500 (EST) Cc: dyson@iquest.net, toasty@home.dragondata.com, mike@smith.net.au, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert said: > > > Perhaps a change that would allow for malloc()'ed and new'ed memory to be > > > able to take memory from the to-be-zero'ed list would be better, although > > > that may be more work than I'm looking for.... > > > > That *might* be reasonable. A special sbrk or somesuch. That sbrk > > would make a non-prezeroed map entry. vm_fault would just avoid > > doing the zero. > > Expecting sbrk'ed pages to be zero filled is just *wrong*. > Actually, you have to support that on most practical architectures. > > Sorry, but there is a *reason* that there are seperate malloc(3) > and calloc(3) routines. The former is seperate from the latter > because uncleared pages are supposed to occur faster, and because > there was an expectation that the malloc(3) could return space > already allocated to the process. Indeed, the ANSI C specification > practically *prohibits* breaking memory back to the system, since > it *requires* that a free'd region of a given size be re-malloc'able > without a check of the malloc return code (though it doesn't > guarantee contents). > > malloc and calloc are different. Memory is often recycled in the address space when using malloc. sbrk is a security violation if the pages aren't prezeroed (or defined to be something other than data in other processes or freed data from the kernel :-)). -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message