Messages in this thread | | | Date | Wed, 23 Jul 2014 14:21:56 +0300 | From | "Kirill A. Shutemov" <> | Subject | Re: [PATCH v8 01/22] Fix XIP fault vs truncate race |
| |
On Tue, Jul 22, 2014 at 03:47:49PM -0400, Matthew Wilcox wrote: > Pagecache faults recheck i_size after taking the page lock to ensure that > the fault didn't race against a truncate. We don't have a page to lock > in the XIP case, so use the i_mmap_mutex instead. It is locked in the > truncate path in unmap_mapping_range() after updating i_size. So while > we hold it in the fault path, we are guaranteed that either i_size has > already been updated in the truncate path, or that the truncate will > subsequently call zap_page_range_single() and so remove the mapping we > have just inserted. > > There is a window of time in which i_size has been reduced and the > thread has a mapping to a page which will be removed from the file, > but this is harmless as the page will not be allocated to a different > purpose before the thread's access to it is revoked. > > Signed-off-by: Matthew Wilcox <matthew.r.wilcox@intel.com> > Reviewed-by: Jan Kara <jack@suse.cz> > --- > mm/filemap_xip.c | 24 ++++++++++++++++++++++-- > 1 file changed, 22 insertions(+), 2 deletions(-) > > diff --git a/mm/filemap_xip.c b/mm/filemap_xip.c > index d8d9fe3..c8d23e9 100644 > --- a/mm/filemap_xip.c > +++ b/mm/filemap_xip.c > @@ -260,8 +260,17 @@ again: > __xip_unmap(mapping, vmf->pgoff); > > found: > + /* We must recheck i_size under i_mmap_mutex */ > + mutex_lock(&mapping->i_mmap_mutex); > + size = (i_size_read(inode) + PAGE_CACHE_SIZE - 1) >> > + PAGE_CACHE_SHIFT;
round_up() ?
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
-- Kirill A. Shutemov
| |