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
