Re: [PATCH] mm: correctly handle errors during VMA merging

[Vlastimil Babka <vbabka@suse.cz>]

On 07/26/2016 10:53 AM, Kirill A. Shutemov wrote:
> On Tue, Jul 26, 2016 at 08:34:03AM +0200, Vegard Nossum wrote:
>> In other words, it is possible to run into a memory allocation error
>> *after* part of the merging work has already been done. In this case,
>> we probably shouldn't return an error back to userspace anyway (since
>> it would not reflect the partial work that was done).
>>
>> I *think* the solution might be to simply ignore the errors from
>> vma_adjust() and carry on with distinct VMAs for adjacent regions that
>> might otherwise have been represented with a single VMA.
>
> I don't like this.
>
> At least, vma_adjust() should be able to handle mering more than three
> vmas together on next call if memory pressure gone. I would keep virtual
> address space fragmentation within reasonable.
>
> I think this wouldn't be easy to validate...

As I said, this shouldn't happen unless the process is being killed 
already. Otherwise the allocation behaves like __GFP_NOFAIL. We could 
also make it explicitly __GFP_NOFAIL but that might only complicate OOM 
situations.

>> I have a reproducer that runs into the bug within a few seconds when
>> fault injection is enabled -- with the patch I no longer see any
>> problems.
>>
>> The patch and resulting code admittedly look odd and I'm *far* from
>> an expert on mm internals, so feel free to propose counter-patches and
>
> One idea is to pre-allocate anon_vma, if remove_next == 2 before merging
> started and use it on second iteration instead of allocation it in
> anon_vma_clone().

It's not just anon_vma, but also anon_vma_chains, their number is not 
constant.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>