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
