| Message ID | 1442950582-10140-1-git-send-email-ross.zwisler@linux.intel.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
[ adding Andrew ] On Tue, Sep 22, 2015 at 12:36 PM, Ross Zwisler <ross.zwisler@linux.intel.com> wrote: > The following commit: > > commit 46c043ede471 ("mm: take i_mmap_lock in unmap_mapping_range() for > DAX") > > moved some code in __dax_pmd_fault() that was responsible for zeroing > newly allocated PMD pages. The new location didn't properly set up > 'kaddr', though, so when run this code resulted in a NULL pointer BUG. > > Fix this by getting the correct 'kaddr' via bdev_direct_access(). > > Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com> > Reported-by: Dan Williams <dan.j.williams@intel.com> Taking into account the comment below, Reviewed-by: Dan Williams <dan.j.williams@intel.com> > --- > fs/dax.c | 13 ++++++++++++- > 1 file changed, 12 insertions(+), 1 deletion(-) > > diff --git a/fs/dax.c b/fs/dax.c > index 7ae6df7..bcfb14b 100644 > --- a/fs/dax.c > +++ b/fs/dax.c > @@ -569,8 +569,20 @@ int __dax_pmd_fault(struct vm_area_struct *vma, unsigned long address, > if (!buffer_size_valid(&bh) || bh.b_size < PMD_SIZE) > goto fallback; > > + sector = bh.b_blocknr << (blkbits - 9); > + > if (buffer_unwritten(&bh) || buffer_new(&bh)) { > int i; > + > + length = bdev_direct_access(bh.b_bdev, sector, &kaddr, &pfn, > + bh.b_size); > + if (length < 0) { > + result = VM_FAULT_SIGBUS; > + goto out; > + } > + if ((length < PMD_SIZE) || (pfn & PG_PMD_COLOUR)) > + goto fallback; > + Hmm, we don't need the PG_PMD_COLOUR check since we aren't using the pfn in this path, right?
On Tue, Sep 22, 2015 at 01:51:04PM -0700, Dan Williams wrote: > [ adding Andrew ] > > On Tue, Sep 22, 2015 at 12:36 PM, Ross Zwisler > <ross.zwisler@linux.intel.com> wrote: > > The following commit: > > > > commit 46c043ede471 ("mm: take i_mmap_lock in unmap_mapping_range() for > > DAX") > > > > moved some code in __dax_pmd_fault() that was responsible for zeroing > > newly allocated PMD pages. The new location didn't properly set up > > 'kaddr', though, so when run this code resulted in a NULL pointer BUG. > > > > Fix this by getting the correct 'kaddr' via bdev_direct_access(). > > > > Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com> > > Reported-by: Dan Williams <dan.j.williams@intel.com> > > Taking into account the comment below, > > Reviewed-by: Dan Williams <dan.j.williams@intel.com> > > > --- > > fs/dax.c | 13 ++++++++++++- > > 1 file changed, 12 insertions(+), 1 deletion(-) > > > > diff --git a/fs/dax.c b/fs/dax.c > > index 7ae6df7..bcfb14b 100644 > > --- a/fs/dax.c > > +++ b/fs/dax.c > > @@ -569,8 +569,20 @@ int __dax_pmd_fault(struct vm_area_struct *vma, unsigned long address, > > if (!buffer_size_valid(&bh) || bh.b_size < PMD_SIZE) > > goto fallback; > > > > + sector = bh.b_blocknr << (blkbits - 9); > > + > > if (buffer_unwritten(&bh) || buffer_new(&bh)) { > > int i; > > + > > + length = bdev_direct_access(bh.b_bdev, sector, &kaddr, &pfn, > > + bh.b_size); > > + if (length < 0) { > > + result = VM_FAULT_SIGBUS; > > + goto out; > > + } > > + if ((length < PMD_SIZE) || (pfn & PG_PMD_COLOUR)) > > + goto fallback; > > + > > Hmm, we don't need the PG_PMD_COLOUR check since we aren't using the > pfn in this path, right? I think we care, because we'll end up bailing anyway at the later PG_PMD_COLOUR check before we actually insert the pfn via vmf_insert_pfn_pmd(). If we don't check the alignment we'll do 2 MiB worth of zeroing to the media, then later fall back to PTE faults.
On Tue, Sep 22, 2015 at 2:17 PM, Ross Zwisler <ross.zwisler@linux.intel.com> wrote: > On Tue, Sep 22, 2015 at 01:51:04PM -0700, Dan Williams wrote: >> [ adding Andrew ] >> >> On Tue, Sep 22, 2015 at 12:36 PM, Ross Zwisler >> <ross.zwisler@linux.intel.com> wrote: >> > The following commit: >> > >> > commit 46c043ede471 ("mm: take i_mmap_lock in unmap_mapping_range() for >> > DAX") >> > >> > moved some code in __dax_pmd_fault() that was responsible for zeroing >> > newly allocated PMD pages. The new location didn't properly set up >> > 'kaddr', though, so when run this code resulted in a NULL pointer BUG. >> > >> > Fix this by getting the correct 'kaddr' via bdev_direct_access(). >> > >> > Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com> >> > Reported-by: Dan Williams <dan.j.williams@intel.com> >> >> Taking into account the comment below, >> >> Reviewed-by: Dan Williams <dan.j.williams@intel.com> >> >> > --- >> > fs/dax.c | 13 ++++++++++++- >> > 1 file changed, 12 insertions(+), 1 deletion(-) >> > >> > diff --git a/fs/dax.c b/fs/dax.c >> > index 7ae6df7..bcfb14b 100644 >> > --- a/fs/dax.c >> > +++ b/fs/dax.c >> > @@ -569,8 +569,20 @@ int __dax_pmd_fault(struct vm_area_struct *vma, unsigned long address, >> > if (!buffer_size_valid(&bh) || bh.b_size < PMD_SIZE) >> > goto fallback; >> > >> > + sector = bh.b_blocknr << (blkbits - 9); >> > + >> > if (buffer_unwritten(&bh) || buffer_new(&bh)) { >> > int i; >> > + >> > + length = bdev_direct_access(bh.b_bdev, sector, &kaddr, &pfn, >> > + bh.b_size); >> > + if (length < 0) { >> > + result = VM_FAULT_SIGBUS; >> > + goto out; >> > + } >> > + if ((length < PMD_SIZE) || (pfn & PG_PMD_COLOUR)) >> > + goto fallback; >> > + >> >> Hmm, we don't need the PG_PMD_COLOUR check since we aren't using the >> pfn in this path, right? > > I think we care, because we'll end up bailing anyway at the later > PG_PMD_COLOUR check before we actually insert the pfn via > vmf_insert_pfn_pmd(). If we don't check the alignment we'll do 2 MiB worth of > zeroing to the media, then later fall back to PTE faults. Ok, good point.
diff --git a/fs/dax.c b/fs/dax.c index 7ae6df7..bcfb14b 100644 --- a/fs/dax.c +++ b/fs/dax.c @@ -569,8 +569,20 @@ int __dax_pmd_fault(struct vm_area_struct *vma, unsigned long address, if (!buffer_size_valid(&bh) || bh.b_size < PMD_SIZE) goto fallback; + sector = bh.b_blocknr << (blkbits - 9); + if (buffer_unwritten(&bh) || buffer_new(&bh)) { int i; + + length = bdev_direct_access(bh.b_bdev, sector, &kaddr, &pfn, + bh.b_size); + if (length < 0) { + result = VM_FAULT_SIGBUS; + goto out; + } + if ((length < PMD_SIZE) || (pfn & PG_PMD_COLOUR)) + goto fallback; + for (i = 0; i < PTRS_PER_PMD; i++) clear_pmem(kaddr + i * PAGE_SIZE, PAGE_SIZE); wmb_pmem(); @@ -623,7 +635,6 @@ int __dax_pmd_fault(struct vm_area_struct *vma, unsigned long address, result = VM_FAULT_NOPAGE; spin_unlock(ptl); } else { - sector = bh.b_blocknr << (blkbits - 9); length = bdev_direct_access(bh.b_bdev, sector, &kaddr, &pfn, bh.b_size); if (length < 0) {
The following commit: commit 46c043ede471 ("mm: take i_mmap_lock in unmap_mapping_range() for DAX") moved some code in __dax_pmd_fault() that was responsible for zeroing newly allocated PMD pages. The new location didn't properly set up 'kaddr', though, so when run this code resulted in a NULL pointer BUG. Fix this by getting the correct 'kaddr' via bdev_direct_access(). Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com> Reported-by: Dan Williams <dan.j.williams@intel.com> --- fs/dax.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)