Date: Mon, 3 Jun 1996 11:28:46 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: alex@FreeBSD.ORG Cc: pjf@cts.com, bde@FreeBSD.ORG, dyson@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: bugs Message-ID: <199606031828.LAA25340@phaeton.artisoft.com> In-Reply-To: <199606022225.RAA23224@zen.nash.org> from "Alex Nash" at Jun 2, 96 05:25:42 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Richard Stevens (APUE) has the following notes on truncate (see page > 92): > > These two functions are provided by SVR4 and 4.3+BSD. They are not > part of POSIX.1 or XPG3. > > SVR4 truncates or extends a file. 4.3+BSD only truncates a file with > these functions -- they can't be used to extend a file. > > As far as mmap is concerned, you cannot write beyond 'len' bytes as > specified in the call to mmap. (In reality, under FreeBSD 2.1R you > can write up to the next 4K page and get away with it. Linux 1.2.13 > is even less stringent.) I believe that writing up to the 4k boundry works for every OS. The question is whether to allow extension so that data in the 4k after the former EOF is relevant or simply discarded. I would be for prohibiting extension of files in the mmap boundry, if this is important to you, with an extended madvise(). The point is that memory protection is enforced via a "guard page" following the mapped region, so you only have a page granularity on protection and therefore mapping. One alternative (I don't know if anyone does this) is to take the fault by incorrectly marking the partial page, and enforcing the write based on either doing it anyway or refusing it with a fault depending on the byte offset. Obviously, this is not a good strategy for all MMU implementations, so you would damage system portability by requiring it. This is a finer grained version of how you must implement kernel space write address range faulting for processors that don't handle the write protect attribute properly in kernel mode (ie: the 386). Obviously, in any case, the BSD interface that extends the file is not the mmap, it's the write that occurs after the mmap, and the page boundry issue is one on the end of an extended file between the odd location and the next page boundry. There is a similar bug in FreeBSD having to do with map-start offsets for non-zero offset copies (cp uses mmap). I reported the bug about three weeks ago on -current as a question about correct behaviour. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606031828.LAA25340>