svn commit: r196558 - head/usr.bin/look

[John Baldwin]

On Saturday 29 August 2009 4:35:16 pm Alan Cox wrote:
> 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.

Yes, I think you are correct.

-- 
John Baldwin