Commit e0650a41 authored by Matthew Wilcox (Oracle)'s avatar Matthew Wilcox (Oracle) Committed by Andrew Morton
Browse files

mm: clean up mlock_page / munlock_page references in comments 

Change documentation and comments that refer to now-renamed functions.

Link: https://lkml.kernel.org/r/20230116192827.2146732-5-willy@infradead.org


Signed-off-by: default avatarMatthew Wilcox (Oracle) <willy@infradead.org>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
parent 672aa27d

Documentation/mm/unevictable-lru.rst

+16 −14
Original line number Diff line number Diff line
@@ -298,7 +298,7 @@ treated as a no-op and mlock_fixup() simply returns. 
If the VMA passes some filtering as described in "Filtering Special VMAs"

below, mlock_fixup() will attempt to merge the VMA with its neighbors or split

off a subset of the VMA if the range does not cover the entire VMA.  Any pages

already present in the VMA are then marked as mlocked by mlock_page() via

already present in the VMA are then marked as mlocked by mlock_folio() via

mlock_pte_range() via walk_page_range() via mlock_vma_pages_range().



Before returning from the system call, do_mlock() or mlockall() will call
@@ -373,20 +373,21 @@ Because of the VMA filtering discussed above, VM_LOCKED will not be set in 
any "special" VMAs.  So, those VMAs will be ignored for munlock.



If the VMA is VM_LOCKED, mlock_fixup() again attempts to merge or split off the

specified range.  All pages in the VMA are then munlocked by munlock_page() via

specified range.  All pages in the VMA are then munlocked by munlock_folio() via

mlock_pte_range() via walk_page_range() via mlock_vma_pages_range() - the same

function used when mlocking a VMA range, with new flags for the VMA indicating

that it is munlock() being performed.



munlock_page() uses the mlock pagevec to batch up work to be done under

lru_lock by  __munlock_page().  __munlock_page() decrements the page's

mlock_count, and when that reaches 0 it clears PG_mlocked and clears

PG_unevictable, moving the page from unevictable state to inactive LRU.

munlock_folio() uses the mlock pagevec to batch up work to be done

under lru_lock by  __munlock_folio().  __munlock_folio() decrements the

folio's mlock_count, and when that reaches 0 it clears the mlocked flag

and clears the unevictable flag, moving the folio from unevictable state

to the inactive LRU.



But in practice that may not work ideally: the page may not yet have reached

But in practice that may not work ideally: the folio may not yet have reached

"the unevictable LRU", or it may have been temporarily isolated from it.  In

those cases its mlock_count field is unusable and must be assumed to be 0: so

that the page will be rescued to an evictable LRU, then perhaps be mlocked

that the folio will be rescued to an evictable LRU, then perhaps be mlocked

again later if vmscan finds it in a VM_LOCKED VMA.
@@ -489,15 +490,16 @@ For each PTE (or PMD) being unmapped from a VMA, page_remove_rmap() calls 
munlock_vma_folio(), which calls munlock_folio() when the VMA is VM_LOCKED

(unless it was a PTE mapping of a part of a transparent huge page).



munlock_page() uses the mlock pagevec to batch up work to be done under

lru_lock by  __munlock_page().  __munlock_page() decrements the page's

mlock_count, and when that reaches 0 it clears PG_mlocked and clears

PG_unevictable, moving the page from unevictable state to inactive LRU.

munlock_folio() uses the mlock pagevec to batch up work to be done

under lru_lock by  __munlock_folio().  __munlock_folio() decrements the

folio's mlock_count, and when that reaches 0 it clears the mlocked flag

and clears the unevictable flag, moving the folio from unevictable state

to the inactive LRU.



But in practice that may not work ideally: the page may not yet have reached

But in practice that may not work ideally: the folio may not yet have reached

"the unevictable LRU", or it may have been temporarily isolated from it.  In

those cases its mlock_count field is unusable and must be assumed to be 0: so

that the page will be rescued to an evictable LRU, then perhaps be mlocked

that the folio will be rescued to an evictable LRU, then perhaps be mlocked

again later if vmscan finds it in a VM_LOCKED VMA.

mm/memory-failure.c

+1 −1
Original line number Diff line number Diff line
@@ -2167,7 +2167,7 @@ int memory_failure(unsigned long pfn, int flags) 
	}



	/*

	 * __munlock_pagevec may clear a writeback page's LRU flag without

	 * __munlock_folio() may clear a writeback page's LRU flag without

	 * page_lock. We need wait writeback completion for this page or it

	 * may trigger vfs BUG while evict inode.

	 */

mm/swap.c

+2 −2
Original line number Diff line number Diff line
@@ -201,7 +201,7 @@ static void lru_add_fn(struct lruvec *lruvec, struct folio *folio) 
	 * Is an smp_mb__after_atomic() still required here, before

	 * folio_evictable() tests the mlocked flag, to rule out the possibility

	 * of stranding an evictable folio on an unevictable LRU?  I think

	 * not, because __munlock_page() only clears the mlocked flag

	 * not, because __munlock_folio() only clears the mlocked flag

	 * while the LRU lock is held.

	 *

	 * (That is not true of __page_cache_release(), and not necessarily
@@ -216,7 +216,7 @@ static void lru_add_fn(struct lruvec *lruvec, struct folio *folio) 
		folio_set_unevictable(folio);

		/*

		 * folio->mlock_count = !!folio_test_mlocked(folio)?

		 * But that leaves __mlock_page() in doubt whether another

		 * But that leaves __mlock_folio() in doubt whether another

		 * actor has already counted the mlock or not.  Err on the

		 * safe side, underestimate, let page reclaim fix it, rather

		 * than leaving a page on the unevictable LRU indefinitely.