Skip to content

expand_downwards: don't require the gap if !vm_prev

Oleg Nesterov lkml 1 version Applied

Status from this message: [merged] expand_downwards-dont-require-the-gap-if-vm_prev.patch removed from -mm tree

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest1 patch 13 repliesApplied 1/1

Patches in v1 All 1 applied

#Subject and filesSizeRepliesApplied
1/1expand_downwards: don't require the gap if !vm_prevmm/mmap.c+3 -71 replyApplied

Reviews trailers per patch

The patch has a Reviewed-by or Acked-by.

PatchMichal Hocko
1/1A-b

Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.

Read the v1 thread

Cover letter [PATCH 0/1] expand_downwards: don't require the gap if !vm_prev

See the patch, but actually I have another question...

Now that the stack-guard-page has gone, why do we need to allow to grow into the previous VM_GROWSDOWN vma? IOW, why we can not simply remove the VM_GROWSDOWN check in expand_downwards() ?

Yes, this is what the kernel did before the recent changes. But afaics only because the kernel could not know if the vma->vm_start page is actually guard or not.

IOW, iiuc before the recent change it was not simple to _disallow_ this, and that is why it worked. Just for example, suppose an application does

	addr = mmap(MAP_GROWSDOWN);
	mprotect(addr, PAGE_SIZE, PROT_NONE);
	*(addr + PAGE_SIZE) = 0;

and of course this should not fail.

But the the kernel could not know if vm_start == addr + PAGE_SIZE is the "valid" address, or this vma was expanded before and vm_start is the stack guard.

Yes, we can probably check anon_vma's as the comment suggests, but imo we we can just remove the VM_GROWSDOWN case unconditionally.

Oleg.

Read the cover letter in its thread