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@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>