On Tue, Jun 23, 2020 at 11:54:39AM +0300, Amir Goldstein wrote: > On Tue, Jun 23, 2020 at 8:21 AM Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > > > From: Dave Chinner <dchinner@xxxxxxxxxx> > > > > The page faultround path ->map_pages is implemented in XFS via > > filemap_map_pages(). This function checks that pages found in page > > cache lookups have not raced with truncate based invalidation by > > checking page->mapping is correct and page->index is within EOF. > > > > However, we've known for a long time that this is not sufficient to > > protect against races with invalidations done by operations that do > > not change EOF. e.g. hole punching and other fallocate() based > > direct extent manipulations. The way we protect against these > > races is we wrap the page fault operations in a XFS_MMAPLOCK_SHARED > > lock so they serialise against fallocate and truncate before calling > > into the filemap function that processes the fault. > > > > Do the same for XFS's ->map_pages implementation to close this > > potential data corruption issue. > > > > Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx> > > Reviewed-by: Amir Goldstein <amir73il@xxxxxxxxx> > > I wonder... should xfs_file_fadvise(POSIX_FADV_WILLNEED) also be taking > XFS_MMAPLOCK_SHARED instead of XFS_IOLOCK_SHARED? No. The MMAPLOCK is only to be used in the page fault path because we can't use the IOLOCK in that path or we will deadlock. i.e. MMAPLOCK is exclusively for IO path locking in page fault contexts, IOLOCK is exclusively for IO path locking in syscall and kernel task contexts. > Not that it matters that much? Using the right lock for the IO context actually matters a lot :) Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
