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>
Showing
- Documentation/filesystems/locking.rst 43 additions, 19 deletionsDocumentation/filesystems/locking.rst
- fs/inode.c 2 additions, 0 deletionsfs/inode.c
- include/linux/fs.h 33 additions, 0 deletionsinclude/linux/fs.h
- mm/filemap.c 79 additions, 18 deletionsmm/filemap.c
- mm/readahead.c 2 additions, 0 deletionsmm/readahead.c
- mm/rmap.c 19 additions, 18 deletionsmm/rmap.c
- mm/truncate.c 2 additions, 1 deletionmm/truncate.c
Loading
Please register or sign in to comment