Date: Sat, 29 Aug 2009 15:35:16 -0500 From: Alan Cox <alc@cs.rice.edu> To: John Baldwin <jhb@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Colin Percival <cperciva@freebsd.org> Subject: Re: svn commit: r196558 - head/usr.bin/look Message-ID: <4A999104.9030809@cs.rice.edu> In-Reply-To: <200908260734.12893.jhb@freebsd.org> References: <200908260330.n7Q3U61l047845@svn.freebsd.org> <200908260734.12893.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > On Tuesday 25 August 2009 11:30:06 pm Colin Percival wrote: > >> Author: cperciva >> Date: Wed Aug 26 03:30:06 2009 >> New Revision: 196558 >> URL: http://svn.freebsd.org/changeset/base/196558 >> >> Log: >> Don't try to mmap the contents of empty files. This behaviour was harmless >> prior to r195693, since historical behaviour of mmap(2) was to silently >> ignore length-zero mmap requests; but mmap now returns EINVAL, which caused >> look(1) to emit an error message and fail. >> > > FWIW, it did not silently ignore the request. Instead it rounded the size up > to a page and mapped a page of data. However, if you then passed that pointer > with a length of 0 to munmap() munmap() would fail. > > I don't believe that your claim is correct; round_page(0) == 0. Thus, the value of "size" that would be passed to vm_mmap() would be 0, which would cause it to immediately return "0", indicating success. In this case, I believe that the virtual address that would be returned by mmap(2) would always be the "hint address" for where it should start looking for free space, which would be the end of the heap/data segment, unless the application specified its own hint. In short, and the reason why I'm correcting you here, is to make clear that we needn't worry about earlier versions of FreeBSD that don't implement this change "leaking" or wasting memory from misuse of mmap(2) in this way. Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A999104.9030809>