diff options
author | Jan Kara <jack@suse.cz> | 2021-01-28 19:19:45 +0100 |
---|---|---|
committer | Jan Kara <jack@suse.cz> | 2021-07-13 13:14:27 +0200 |
commit | 730633f0b7f951726e87f912a6323641f674ae34 (patch) | |
tree | 1c4a6eb5ddbc0c28e6d37a1418ec259cb6daef27 /mm/truncate.c | |
parent | c625b4cc57d078b03fd8aa4d86c99d584a1782be (diff) | |
download | linux-730633f0b7f951726e87f912a6323641f674ae34.tar.bz2 |
mm: Protect operations adding pages to page cache with invalidate_lock
Currently, serializing operations such as page fault, read, or readahead
against hole punching is rather difficult. The basic race scheme is
like:
fallocate(FALLOC_FL_PUNCH_HOLE) read / fault / ..
truncate_inode_pages_range()
<create pages in page
cache here>
<update fs block mapping and free blocks>
Now the problem is in this way read / page fault / readahead can
instantiate pages in page cache with potentially stale data (if blocks
get quickly reused). Avoiding this race is not simple - page locks do
not work because we want to make sure there are *no* pages in given
range. inode->i_rwsem does not work because page fault happens under
mmap_sem which ranks below inode->i_rwsem. Also using it for reads makes
the performance for mixed read-write workloads suffer.
So create a new rw_semaphore in the address_space - invalidate_lock -
that protects adding of pages to page cache for page faults / reads /
readahead.
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jan Kara <jack@suse.cz>
Diffstat (limited to 'mm/truncate.c')
-rw-r--r-- | mm/truncate.c | 3 |
1 files changed, 2 insertions, 1 deletions
diff --git a/mm/truncate.c b/mm/truncate.c index 0f9becee9789..44ad5e515140 100644 --- a/mm/truncate.c +++ b/mm/truncate.c @@ -412,7 +412,8 @@ EXPORT_SYMBOL(truncate_inode_pages_range); * @mapping: mapping to truncate * @lstart: offset from which to truncate * - * Called under (and serialised by) inode->i_rwsem. + * Called under (and serialised by) inode->i_rwsem and + * mapping->invalidate_lock. * * Note: When this function returns, there can be a page in the process of * deletion (inside __delete_from_page_cache()) in the specified range. Thus |