From 29417d292bd0fa174d20360326abaf6444a23c3b Mon Sep 17 00:00:00 2001 From: Lorenzo Stoakes Date: Sun, 30 Apr 2023 21:19:17 +0100 Subject: mm/mmap/vma_merge: always check invariants We may still have inconsistent input parameters even if we choose not to merge and the vma_merge() invariant checks are useful for checking this with no production runtime cost (these are only relevant when CONFIG_DEBUG_VM is specified). Therefore, perform these checks regardless of whether we merge. This is relevant, as a recent issue (addressed in commit "mm/mempolicy: Correctly update prev when policy is equal on mbind") in the mbind logic was only picked up in the 6.2.y stable branch where these assertions are performed prior to determining mergeability. Had this remained the same in mainline this issue may have been picked up faster, so moving forward let's always check them. Link: https://lkml.kernel.org/r/df548a6ae3fa135eec3b446eb3dae8eb4227da97.1682885809.git.lstoakes@gmail.com Signed-off-by: Lorenzo Stoakes Acked-by: Vlastimil Babka Reviewed-by: David Hildenbrand Reviewed-by: Liam R. Howlett Signed-off-by: Andrew Morton --- mm/mmap.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'mm') diff --git a/mm/mmap.c b/mm/mmap.c index 5522130ae606..13678edaa22c 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -960,17 +960,17 @@ struct vm_area_struct *vma_merge(struct vma_iterator *vmi, struct mm_struct *mm, merge_next = true; } + /* Verify some invariant that must be enforced by the caller. */ + VM_WARN_ON(prev && addr <= prev->vm_start); + VM_WARN_ON(curr && (addr != curr->vm_start || end > curr->vm_end)); + VM_WARN_ON(addr >= end); + if (!merge_prev && !merge_next) return NULL; /* Not mergeable. */ res = vma = prev; remove = remove2 = adjust = NULL; - /* Verify some invariant that must be enforced by the caller. */ - VM_WARN_ON(prev && addr <= prev->vm_start); - VM_WARN_ON(curr && (addr != curr->vm_start || end > curr->vm_end)); - VM_WARN_ON(addr >= end); - /* Can we merge both the predecessor and the successor? */ if (merge_prev && merge_next && is_mergeable_anon_vma(prev->anon_vma, next->anon_vma, NULL)) { -- cgit v1.2.3 From d824ec2a154677f63c56cc71ffe4578274f6e32e Mon Sep 17 00:00:00 2001 From: Jan Kara Date: Fri, 28 Apr 2023 14:41:40 +0200 Subject: mm: do not reclaim private data from pinned page If the page is pinned, there's no point in trying to reclaim it. Furthermore if the page is from the page cache we don't want to reclaim fs-private data from the page because the pinning process may be writing to the page at any time and reclaiming fs private info on a dirty page can upset the filesystem (see link below). Link: https://lore.kernel.org/linux-mm/20180103100430.GE4911@quack2.suse.cz Link: https://lkml.kernel.org/r/20230428124140.30166-1-jack@suse.cz Signed-off-by: Jan Kara Reviewed-by: Matthew Wilcox (Oracle) Reviewed-by: Lorenzo Stoakes Reviewed-by: Christoph Hellwig Reviewed-by: John Hubbard Acked-by: David Hildenbrand Acked-by: Peter Xu Cc: Signed-off-by: Andrew Morton --- mm/vmscan.c | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'mm') diff --git a/mm/vmscan.c b/mm/vmscan.c index 5bde07409303..d257916f39e5 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1967,6 +1967,16 @@ retry: } } + /* + * Folio is unmapped now so it cannot be newly pinned anymore. + * No point in trying to reclaim folio if it is pinned. + * Furthermore we don't want to reclaim underlying fs metadata + * if the folio is pinned and thus potentially modified by the + * pinning process as that may upset the filesystem. + */ + if (folio_maybe_dma_pinned(folio)) + goto activate_locked; + mapping = folio_mapping(folio); if (folio_test_dirty(folio)) { /* -- cgit v1.2.3