Re: [Bug 67651] Bisected: Lots of fragmented mmaps cause gimp to fail in 3.12 after exceeding vm_max_map_count

[Muhammad Usama Anjum]

Sorry for replying to so much older thread. The original thread:
https://lore.kernel.org/all/20140123151445.GX1574@moon/

On 1/23/14 11:27 AM, Cyrill Gorcunov wrote:
> On Wed, Jan 22, 2014 at 10:09:10PM -0800, Andrew Morton wrote:
>>>>
>>>> That being said, this could cause vma blowups for programs that are
>>>> actually using this thing.
>>>
>>> Hi Andy, indeed, this could happen. The easiest way is to ignore softdirty bit
>>> when we're trying to merge vmas and set it one new merged. I think this should
>>> be correct. Once I finish I'll send the patch.
>>
>> Hang on.  We think the problem is that gimp is generating vmas which
>> *should* be merged, but for unknown reasons they differ in
>> VM_SOFTDIRTY, yes?
> 
> Yes. One place where I forgot to set softdirty bit is setup_arg_pages. But
> it called once on elf load, so it can't cause such effect (but should be
> fixed too). Also there is do_brk where vmasoftdirty is missed too :/
> 
> Another problem is the potential scenario when we have a bunch of vmas
> and clear vma-softdirty bit on them, then we try to map new one, flags
> won't match and instead of extending old vma the new one will be created.
> I think (if only I'm not missing something) that vma-softdirty should
> be ignored in such case (ie inside is_mergeable_vma) and once vma extended
> it should be marked as dirty one. Again, I need to think and test more.
> 
>> Shouldn't we work out where we're forgetting to set VM_SOFTDIRTY? 
>> Putting bandaids over this error when we come to trying to merge the
>> vmas sounds very wrong?
> 
> I'm looking into this as well.
I've looked at it while working on adding an IOCTL to get and/or clear the
soft dirty bit for a particular region only [1]. The VM_SOFTDIRTY should be
set in the vm_flags to be tested if new allocation should be merged in
previous vma or not. With the following patch, the new allocations are
merged in the previous VMAs.

I've tested it by reverting the 34228d473efe ("mm: ignore VM_SOFTDIRTY on
VMA merging") commit and after adding the following patch, I'm seeing that
all the new allocations done through mmap() (in my testing) are merged in
the previous VMAs. The number of VMAs doesn't increase drastically which
had contributed to the crash of gimp. If I run the same test after
reverting and not including the following, the number of VMAs keep on
increasing with every mmap() syscall which proves this patch.

diff --git a/mm/mmap.c b/mm/mmap.c
index f9b96b387a6f..b132d52f6fe1 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1708,6 +1708,15 @@ unsigned long mmap_region(struct file *file,
unsigned long addr,
 		vm_flags |= VM_ACCOUNT;
 	}

+	/*
+	 * New (or expanded) vma always get soft dirty status.
+	 * Otherwise user-space soft-dirty page tracker won't
+	 * be able to distinguish situation when vma area unmapped,
+	 * then new mapped in-place (which must be aimed as
+	 * a completely new data area).
+	 */
+	vm_flags |= VM_SOFTDIRTY;
+
 	/*
 	 * Can we just expand an old mapping?
 	 */
@@ -1823,15 +1832,6 @@ unsigned long mmap_region(struct file *file,
unsigned long addr,
 	if (file)
 		uprobe_mmap(vma);

-	/*
-	 * New (or expanded) vma always get soft dirty status.
-	 * Otherwise user-space soft-dirty page tracker won't
-	 * be able to distinguish situation when vma area unmapped,
-	 * then new mapped in-place (which must be aimed as
-	 * a completely new data area).
-	 */
-	vma->vm_flags |= VM_SOFTDIRTY;
-
 	vma_set_page_prot(vma);

 	return addr;
@@ -2998,6 +2998,8 @@ static int do_brk_flags(unsigned long addr, unsigned
long len, unsigned long fla
 	if (security_vm_enough_memory_mm(mm, len >> PAGE_SHIFT))
 		return -ENOMEM;

+	flags |= VM_SOFTDIRTY;
+
 	/* Can we just expand an old private anonymous mapping? */
 	vma = vma_merge(mm, prev, addr, addr + len, flags,
 			NULL, NULL, pgoff, NULL, NULL_VM_UFFD_CTX, NULL);
@@ -3026,7 +3028,7 @@ static int do_brk_flags(unsigned long addr, unsigned
long len, unsigned long fla
 	mm->data_vm += len >> PAGE_SHIFT;
 	if (flags & VM_LOCKED)
 		mm->locked_vm += (len >> PAGE_SHIFT);
-	vma->vm_flags |= VM_SOFTDIRTY;
+
 	return 0;
 }

This patch should be included in the kernel regardless if we revert
34228d473efe or not. Thoughts?


Cyrill is correct about the following:
> Another problem is the potential scenario when we have a bunch of vmas
> and clear vma-softdirty bit on them, then we try to map new one, flags
> won't match and instead of extending old vma the new one will be created.
> I think (if only I'm not missing something) that vma-softdirty should
> be ignored in such case (ie inside is_mergeable_vma) and once vma
> extended
> it should be marked as dirty one. Again, I need to think and test more.
While implementing clear soft-dirty bit for a range of address space, I'm
facing an issue. The non-soft dirty VMA gets merged sometimes with the soft
dirty VMA. Thus the non-soft dirty VMA become dirty which is undesirable.
When discussed with the some other developers they consider it the
regression. Why the non-soft dirty page should appear as soft dirty when it
isn't soft dirty in reality? I agree with them. Should we revert
34228d473efe or find a workaround in the IOCTL?

* Revert may cause the VMAs to expand in uncontrollable situation where the
soft dirty bit of a lot of memory regions or the whole address space is
being cleared again and again. AFAIK normal process must either be only
clearing a few memory regions. So the applications should be okay. There is
still chance of regressions if some applications are already using the
soft-dirty bit. I'm not sure how to test it.

* Add a flag in the IOCTL to ignore the dirtiness of VMA. The user will
surely lose the functionality to detect reused memory regions. But the
extraneous soft-dirty pages would not appear. I'm trying to do this in the
patch series [1]. Some discussion is going on that this fails with some
mprotect use case [2]. I still need to have a look at the mprotect selftest
to see how and why this fails. I think this can be implemented after some
more work.

What are your thoughts?

> 
> 	Cyrill
> 

[1]
https://lore.kernel.org/all/20221109102303.851281-1-usama.anjum@xxxxxxxxxxxxx/
[2]
https://lore.kernel.org/all/bfcae708-db21-04b4-0bbe-712badd03071@xxxxxxxxxx/

-- 
BR,
Muhammad Usama Anjum