filemap: Fix serialization adding transparent huge pages to page cache
authorAlistair Popple <apopple@nvidia.com>
Mon, 20 Jun 2022 09:05:36 +0000 (19:05 +1000)
committerMatthew Wilcox (Oracle) <willy@infradead.org>
Thu, 23 Jun 2022 16:22:00 +0000 (12:22 -0400)
commit00fa15e0d56482e32d8ca1f51d76b0ee00afb16b
treea865c40d2856c6dea026bc6b3f23a92e366a81be
parentb653db77350c7307a513b81856fe53e94cf42446
filemap: Fix serialization adding transparent huge pages to page cache

Commit 793917d997df ("mm/readahead: Add large folio readahead")
introduced support for using large folios for filebacked pages if the
filesystem supports it.

page_cache_ra_order() was introduced to allocate and add these large
folios to the page cache. However adding pages to the page cache should
be serialized against truncation and hole punching by taking
invalidate_lock. Not doing so can lead to data races resulting in stale
data getting added to the page cache and marked up-to-date. See commit
730633f0b7f9 ("mm: Protect operations adding pages to page cache with
invalidate_lock") for more details.

This issue was found by inspection but a testcase revealed it was
possible to observe in practice on XFS. Fix this by taking
invalidate_lock in page_cache_ra_order(), to mirror what is done for the
non-thp case in page_cache_ra_unbounded().

Signed-off-by: Alistair Popple <apopple@nvidia.com>
Fixes: 793917d997df ("mm/readahead: Add large folio readahead")
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
mm/readahead.c