diff options
author | Dave Chinner <dchinner@redhat.com> | 2015-02-23 21:43:37 +1100 |
---|---|---|
committer | Dave Chinner <david@fromorbit.com> | 2015-02-23 21:43:37 +1100 |
commit | 653c60b633a9019a54a80d64b5ed33ecb214823c (patch) | |
tree | 833b977a047a36b07e49524ba3afb295cf140287 /fs/xfs/xfs_pnfs.h | |
parent | c517d838eb7d07bbe9507871fab3931deccff539 (diff) | |
download | linux-next-653c60b633a9019a54a80d64b5ed33ecb214823c.tar.gz |
xfs: introduce mmap/truncate lock
Right now we cannot serialise mmap against truncate or hole punch
sanely. ->page_mkwrite is not able to take locks that the read IO
path normally takes (i.e. the inode iolock) because that could
result in lock inversions (read - iolock - page fault - page_mkwrite
- iolock) and so we cannot use an IO path lock to serialise page
write faults against truncate operations.
Instead, introduce a new lock that is used *only* in the
->page_mkwrite path that is the equivalent of the iolock. The lock
ordering in a page fault is i_mmaplock -> page lock -> i_ilock,
and so in truncate we can i_iolock -> i_mmaplock and so lock out
new write faults during the process of truncation.
Because i_mmap_lock is outside the page lock, we can hold it across
all the same operations we hold the i_iolock for. The only
difference is that we never hold the i_mmaplock in the normal IO
path and so do not ever have the possibility that we can page fault
inside it. Hence there are no recursion issues on the i_mmap_lock
and so we can use it to serialise page fault IO against inode
modification operations that affect the IO path.
This patch introduces the i_mmaplock infrastructure, lockdep
annotations and initialisation/destruction code. Use of the new lock
will be in subsequent patches.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Diffstat (limited to 'fs/xfs/xfs_pnfs.h')
0 files changed, 0 insertions, 0 deletions