From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757168AbaGVTvr (ORCPT ); Tue, 22 Jul 2014 15:51:47 -0400 Received: from mga09.intel.com ([134.134.136.24]:15061 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756872AbaGVTso (ORCPT ); Tue, 22 Jul 2014 15:48:44 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,711,1400050800"; d="scan'208";a="547369369" From: Matthew Wilcox To: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Matthew Wilcox , willy@linux.intel.com Subject: [PATCH v8 01/22] Fix XIP fault vs truncate race Date: Tue, 22 Jul 2014 15:47:49 -0400 Message-Id: <78c38d32aa62db1bb86315cf3e287b24be900c5e.1406058387.git.matthew.r.wilcox@intel.com> X-Mailer: git-send-email 2.0.0 In-Reply-To: References: In-Reply-To: References: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 Reviewed-by: Jan Kara --- 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; + if (unlikely(vmf->pgoff >= size)) { + mutex_unlock(&mapping->i_mmap_mutex); + return VM_FAULT_SIGBUS; + } err = vm_insert_mixed(vma, (unsigned long)vmf->virtual_address, xip_pfn); + mutex_unlock(&mapping->i_mmap_mutex); if (err == -ENOMEM) return VM_FAULT_OOM; /* @@ -285,16 +294,27 @@ found: } if (error != -ENODATA) goto out; + + /* 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; + if (unlikely(vmf->pgoff >= size)) { + ret = VM_FAULT_SIGBUS; + goto unlock; + } /* not shared and writable, use xip_sparse_page() */ page = xip_sparse_page(); if (!page) - goto out; + goto unlock; err = vm_insert_page(vma, (unsigned long)vmf->virtual_address, page); if (err == -ENOMEM) - goto out; + goto unlock; ret = VM_FAULT_NOPAGE; +unlock: + mutex_unlock(&mapping->i_mmap_mutex); out: write_seqcount_end(&xip_sparse_seq); mutex_unlock(&xip_sparse_mutex); -- 2.0.0 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Wilcox Subject: [PATCH v8 01/22] Fix XIP fault vs truncate race Date: Tue, 22 Jul 2014 15:47:49 -0400 Message-ID: <78c38d32aa62db1bb86315cf3e287b24be900c5e.1406058387.git.matthew.r.wilcox@intel.com> References: Cc: Matthew Wilcox , willy@linux.intel.com To: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Return-path: In-Reply-To: In-Reply-To: References: Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org 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 Reviewed-by: Jan Kara --- 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; + if (unlikely(vmf->pgoff >= size)) { + mutex_unlock(&mapping->i_mmap_mutex); + return VM_FAULT_SIGBUS; + } err = vm_insert_mixed(vma, (unsigned long)vmf->virtual_address, xip_pfn); + mutex_unlock(&mapping->i_mmap_mutex); if (err == -ENOMEM) return VM_FAULT_OOM; /* @@ -285,16 +294,27 @@ found: } if (error != -ENODATA) goto out; + + /* 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; + if (unlikely(vmf->pgoff >= size)) { + ret = VM_FAULT_SIGBUS; + goto unlock; + } /* not shared and writable, use xip_sparse_page() */ page = xip_sparse_page(); if (!page) - goto out; + goto unlock; err = vm_insert_page(vma, (unsigned long)vmf->virtual_address, page); if (err == -ENOMEM) - goto out; + goto unlock; ret = VM_FAULT_NOPAGE; +unlock: + mutex_unlock(&mapping->i_mmap_mutex); out: write_seqcount_end(&xip_sparse_seq); mutex_unlock(&xip_sparse_mutex); -- 2.0.0 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org