summaryrefslogtreecommitdiff
path: root/tools/lib/python/kdoc
diff options
context:
space:
mode:
authorLorenzo Stoakes (ARM) <ljs@kernel.org>2026-10-19 16:57:48 +0100
committerAndrew Morton <akpm@linux-foundation.org>2026-10-24 01:56:39 -0700
commit65e722a74df992719676ead85a9e93fb2b5a0983 (patch)
tree232cf55d8c92856ab92e7b1375e91c75ef9d89e1 /tools/lib/python/kdoc
parent34e753f8d927069785f6b675f5769da5da4ef78e (diff)
mm/mremap: correctly uncharge accountable VMAs in error path
The mremap error path is a fragile and unwieldy beast - it reverses the page table move then updates vma_remap_struct state to swap VMA, length and address between old and new VMAs in copy_vma_and_data(). If the mremap() operation didn't specify MREMAP_DONTUNMAP then its caller, move_vma(), invokes unmap_source_vma(), which unmaps the new VMA rather than the old one. For accountable VMAs when MREMAP_DONTUNMAP is not specified, unmap_source_vma() unsets VMA_ACCOUNT_BIT during this unmap in order that only the delta of a VMA expansion is charged (performed by vrm_calc_charge() earlier). Therefore nothing uncharges the expanded VMA size, and there is a permanent leak in global Committed_AS. Resolve the issue by uncharging when MREMAP_DONTUNMAP is not specified. Link: https://lore.kernel.org/20261019-other-mremap-charge-leak-v1-1-d94477fe6545@kernel.org Fixes: fdbef6149135 ("mm/mremap: don't account pages in vma_to_resize()") Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Cc: Liam R. Howlett <liam@infradead.org> Cc: Vlastimil Babka <vbabka@kernel.org> Cc: Jann Horn <jannh@google.com> Cc: Pedro Falcato <pfalcato@suse.de> Cc: Brian Geffon <bgeffon@google.com> Cc: Dmitry Safonov <0x7f454c46@gmail.com> Cc: <stable@vger.kernel.org>
Diffstat (limited to 'tools/lib/python/kdoc')
0 files changed, 0 insertions, 0 deletions