Please sign in to comment.
SHM_UNLOCK: fix Unevictable pages stranded after swap
commit 2451326 upstream. Commit cc39c6a ("mm: account skipped entries to avoid looping in find_get_pages") correctly fixed an infinite loop; but left a problem that find_get_pages() on shmem would return 0 (appearing to callers to mean end of tree) when it meets a run of nr_pages swap entries. The only uses of find_get_pages() on shmem are via pagevec_lookup(), called from invalidate_mapping_pages(), and from shmctl SHM_UNLOCK's scan_mapping_unevictable_pages(). The first is already commented, and not worth worrying about; but the second can leave pages on the Unevictable list after an unusual sequence of swapping and locking. Fix that by using shmem_find_get_pages_and_swap() (then ignoring the swap) instead of pagevec_lookup(). But I don't want to contaminate vmscan.c with shmem internals, nor shmem.c with LRU locking. So move scan_mapping_unevictable_pages() into shmem.c, renaming it shmem_unlock_mapping(); and rename check_move_unevictable_page() to check_move_unevictable_pages(), looping down an array of pages, oftentimes under the same lock. Leave out the "rotate unevictable list" block: that's a leftover from when this was used for /proc/sys/vm/scan_unevictable_pages, whose flawed handling involved looking at pages at tail of LRU. Was there significance to the sequence first ClearPageUnevictable, then test page_evictable, then SetPageUnevictable here? I think not, we're under LRU lock, and have no barriers between those. Signed-off-by: Hugh Dickins <firstname.lastname@example.org> Reviewed-by: KOSAKI Motohiro <email@example.com> Cc: Minchan Kim <firstname.lastname@example.org> Cc: Rik van Riel <email@example.com> Cc: Shaohua Li <firstname.lastname@example.org> Cc: Eric Dumazet <email@example.com> Cc: Johannes Weiner <firstname.lastname@example.org> Cc: Michel Lespinasse <email@example.com> Signed-off-by: Andrew Morton <firstname.lastname@example.org> Signed-off-by: Linus Torvalds <email@example.com> Signed-off-by: Greg Kroah-Hartman <firstname.lastname@example.org>
- Loading branch information...
Showing with 81 additions and 92 deletions.