I remembered that Ross had a similar question, so it must be hard to understand. How does this comment work for both of you? + /* + * A truncate must remove COWs of pages that are removed + * from the file. If we have a struct page, the normal + * page lock mechanism prevents truncate from missing the + * COWed page. If not, the i_mmap_lock can provide the + * same guarantee. It is dropped by the caller after the + * page is safely in the page tables. + */ ________________________________________ From: Jared Hulbert [jaredeh@xxxxxxxxx] Sent: January 29, 2016 3:16 PM To: Wilcox, Matthew R Cc: linux-fsdevel@xxxxxxxxxxxxxxx; ross.zwisler@xxxxxxxxxxxxxxx Subject: Re: bug in COW no page fault? oh... Look! There it is, right where it should be. Sorry. Recovering from years of Android and VMware, please be patient. On Fri, Jan 29, 2016 at 2:36 PM, Wilcox, Matthew R <matthew.r.wilcox@xxxxxxxxx> wrote: > Because then we lock the page instead of the i_mmap_sem. The code in mm/memory.c isn't /that/ hard to understand, is it? > ________________________________________ > From: Jared Hulbert [jaredeh@xxxxxxxxx] > Sent: January 29, 2016 2:12 PM > To: Wilcox, Matthew R > Cc: linux-fsdevel@xxxxxxxxxxxxxxx; ross.zwisler@xxxxxxxxxxxxxxx > Subject: Re: bug in COW no page fault? > > Which page? The unmatched call for i_mmap_lock_read() is only called > if(!page). Ahh, are we locking for the cow_page? Okay, then why > don't we lock when page != NULL in the COW case? > > On Fri, Jan 29, 2016 at 1:53 PM, Wilcox, Matthew R > <matthew.r.wilcox@xxxxxxxxx> wrote: >> Because we need to hold the i_mmap_sem until the page is inserted into the page tables to avoid racing with truncate. Therefore it is unlocked by the MM code. >> >> Did you try this patch? It should have BUGged immediately that you hit this case. If not, you have insufficient CONFIG_DEBUG enabled. >> >> ________________________________________ >> From: Jared Hulbert [jaredeh@xxxxxxxxx] >> Sent: January 29, 2016 1:38 PM >> To: linux-fsdevel@xxxxxxxxxxxxxxx; Wilcox, Matthew R; ross.zwisler@xxxxxxxxxxxxxxx >> Subject: DAX: bug in COW no page fault? >> >> Why isn't this required? >> >> diff --git a/fs/dax.c b/fs/dax.c >> index a7f77e1..30f2abe 100644 >> --- a/fs/dax.c >> +++ b/fs/dax.c >> @@ -416,6 +416,7 @@ int __dax_fault(struct vm_area_struct *vma, struct vm_fault >> error = -EIO; >> goto out; >> } >> + i_mmap_unlock_read(mapping); >> } >> return VM_FAULT_LOCKED; >> } -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
