Re: don't let mmap allocate down to zero

[Hugh Dickins <hugh@veritas.com>]

On Fri, 28 Jan 2005, Rik van Riel wrote:
> On Thu, 27 Jan 2005, William Lee Irwin III wrote:
> 
> > You seem to be on about something else, e.g. only forbidding the vma
> > allocator to return a vma starting at 0 when not specifically requested.
> > In that case vma->vm_start < mm->brk and similar are all fine.
> 
> Yes.

Prohibiting "addr < mm->brk" (unless FIXED) seems arbitrary policy to me,
and at variance with the comment "would break NULL pointer detection".
Why have you chosen to prohibit all that rather than just "!addr"?
(Other than to stoke up this controversy you expect ;)

But I have to admit that it's much less arbitrary policy than the
TASK_UNMAPPED_BASE used when going bottom up - I much prefer your
your mm->brk test to that.

I had imagined that top down (non-FIXED) would continue to make
more space available, the space below the text, just cutting off
at PAGE_SIZE.  There was a more serious lower limit on ARM under
discussion before, but ARM doesn't use top down so far as I can see.

Perhaps you're coming from experience of various buggy apps
that get into difficulties if mmaps are found below mm->brk?
I'm not sure that we should be cutting others' address space to
make life easier for those, they should be ADDR_COMPAT_LAYOUT.
Part (all?) of the point of topdown was to make more address
space available, wasn't it?

arch/ppc64/mm/hugetlbpage.c (odd place to find it) has its own
arch_get_unmapped_area_topdown, should be given a similar fix.

Hugh