You have a subject line of 'fix gap check for unmapped_area with VM_GROWSDOWN'. I'm not sure this is quite accurate.

I don't really have time to do a deep dive (again, this is why it's so important to give a decent commit message - explaining under what _real world_ circumstances this will be used etc.).

But anyway, it seems it will only be the case if MMF_TOPDOWN is not set in the mm flags, which usually requires an mmap compatibility mode to achieve unless the arch otherwise forces it.

And these arches would be ones where the stack grows UP, right? Or at least ones where this is possible?

So already we're into specifics - either arches that grow the stack up, or ones that intentionally use the old mmap compatibility mode are affected.

This happens in:

[ pretty much all unmapped area callers ] -> vm_unmapped_area() -> unmapped_area() (if !(info->flags & VM_UNMAPPED_AREA_TOPDOWN)

Where VM_UNMAPPED_AREA_TOPDOWN is only not set in the circumstances mentioned above.

So, for this issue you claim is the case to happen, you have to:

1. Either be using a stack grows up arch, or enabling an mmap() compatibility mode. 2. Also set MAP_GROWSDOWN on the mmap() call, which is translated to VM_GROWSDOWN.

We are already far from 'fix gap check for VM_GROWSDOWN' right? I mean I don't have the time to absolutely dive into the guts of this, but I assume this is correct right?

I'm not saying we shouldn't address this, but it's VITAL to clarify what exactly it is you're tackling.

On Mon, Jan 27, 2025 at 07:55:26AM +0000, Wei Yang wrote:

Current unmapped_area() may fail to get the available area.

For example, we have a vma range like below:

0123456789abcdef
  m  m  A m  m

I don't understand this diagram at all. What is going on here? What is 'm' what is 'A' what are these values? page offsets * 0x1000?

is that a page of memory allocated at each 'm'? Is A somehow an address under consideration?

You _have_ to add a key and explanation here, my mind reading skills are much diminished in my old age... :P

Let's assume start_gap is 0x2000 and stack_guard_gap is 0x1000. And now we are looking for free area with size 0x1000 within [0x2000, 0xd000].

How can start_gap be 0x2000 when it is only ever 0x1000 at most and only applicable in x86-64 anyway?

It'd be good if you'd shown this on the diagram somehow?

Like this:

<---------> 0123456789abcdef m m A m m

But then I'm confused as to what A is once again.

Ideally you'd actually provide what the struct vm_unmapped_area_info fields actually are with other parameters and _work through_ an example.

Also you're now talking about a stack but you haven't mentioned the word 'stack' anywhere in any part of this series afaict.

'Fix case where the arch grows stacks upwards or we are in legacy mmap mode but still want to map a grows-down stack' is a LOT more specific than 'fix unmapped_area()'.

The unmapped_area_topdown() could find address at 0x8000, while unmapped_area() fails.

OK you need to WORK THROUGH why this is. You're putting all the work on me as a reviewer to go check to see if this is indeed the case. It's not a fair distribution of work.

In original code before commit 3499a13168da ("mm/mmap: use maple tree for unmapped_area{_topdown}"), the logic is:

• find a gap with total length, including alignment
• adjust start address with alignment

What we do now is:

• find a gap with total length, including alignment
• adjust start address with alignment
• then compare the left range with total length

What is 'left range'? This explanation is really hard to follow.

This is not necessary to compare with total length again after start address adjusted.

Also, it is not correct to minus 1 here. This may not trigger an issue in real world, since address are usually aligned with page size.

You aren't saying why.

Also the VMA's start is _always_ page-aligned.

Presumably the minus 1 is intentionally to amke it an inclusive value once offset by length?

Fixes: 58c5d0d6d522 ("mm/mmap: regression fix for unmapped_area{_topdown}")

Fixes it how?

Signed-off-by: Wei Yang richard.weiyang@gmail.com CC: Liam R. Howlett Liam.Howlett@Oracle.com CC: Lorenzo Stoakes lorenzo.stoakes@oracle.com CC: Vlastimil Babka vbabka@suse.cz CC: Jann Horn jannh@google.com CC: Rick Edgecombe rick.p.edgecombe@intel.com Cc: stable@vger.kernel.org

---

mm/vma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/vma.c b/mm/vma.c index 3f45a245e31b..d82fdbc710b0 100644 --- a/mm/vma.c +++ b/mm/vma.c @@ -2668,7 +2668,7 @@ unsigned long unmapped_area(struct vm_unmapped_area_info *info) gap += (info->align_offset - gap) & info->align_mask; tmp = vma_next(&vmi); if (tmp && (tmp->vm_flags & VM_STARTGAP_FLAGS)) { /* Avoid prev check if possible */

• if (vm_start_gap(tmp) < gap + length - 1) {
  

• if (vm_start_gap(tmp) < gap + info->length) {
  

Have already spent all morning on this :) Sigh.

OK so let's expand this (again - this is the kind of thing you should do for a tricky change like this).

info->start_gap is set based on stack_guard_placement() and is either PAGE_SIZE (0x1000) if VM_SHADOW_STACK is set or 0. This is only applicable in x86-64.

The align mask is likely to be PAGE_SIZE - 1 but can vary.

length = info->length + align_mask + start_gap

This takes into account the worst possible alignment overhead accounting for any following VMA also.

gap is equal to the current start of the range under consideration (via vma_iter_addr) and as well institutes the appropriate alignment and accounts for start_gap for any _prior_ VMA.

Then we try to find the vm_start_gap() for a candidate _next_ VMA, which if a stack, uses stack_guard_gap() to SUBTRACT the stack guard gap from vma->vm_start or account for the shadow stack.

Then we finally have:

if (next->vm_start - stack gap < start_of_range + [preceeding gap/alignment requirements] + [worst case length] - 1) { Try again }

Or:

start_of_range >= next->vm_start - stack gap + [preceeding gap/alignment requirements] + [worst case length] + 1

start of range v |[preceeding gap][ VMA, worst length ][following gap]<stack gap>

Surely the + 1 (which is the -1 in the original calculation) is simply accounting for the fact that the start of the range is _inclusive_?

You're proposing eliminating entirely the after-this-VMA requirements... why?

This just seems incorrect to me?

You really need to argue the case better if this has some validity, otherwise I think it's just wrong?

	low_limit = tmp->vm_end;
	vma_iter_reset(&vmi);
	goto retry;

-- 2.34.1