* Re: [PATCH v2] dax: fix NULL pointer in __dax_pmd_fault() [not found] <1442950582-10140-1-git-send-email-ross.zwisler@linux.intel.com> @ 2015-09-22 20:51 ` Dan Williams 2015-09-22 21:17 ` Ross Zwisler 0 siblings, 1 reply; 3+ messages in thread From: Dan Williams @ 2015-09-22 20:51 UTC (permalink / raw) To: Ross Zwisler, Andrew Morton Cc: linux-kernel, Alexander Viro, Matthew Wilcox, linux-fsdevel, Kirill A. Shutemov, linux-nvdimm, Dave Chinner, Linux MM [ 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? -- 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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH v2] dax: fix NULL pointer in __dax_pmd_fault() 2015-09-22 20:51 ` [PATCH v2] dax: fix NULL pointer in __dax_pmd_fault() Dan Williams @ 2015-09-22 21:17 ` Ross Zwisler 2015-09-22 21:26 ` Dan Williams 0 siblings, 1 reply; 3+ messages in thread From: Ross Zwisler @ 2015-09-22 21:17 UTC (permalink / raw) To: Dan Williams, Cc: Ross Zwisler, Andrew Morton, linux-kernel, Alexander Viro, Matthew Wilcox, linux-fsdevel, Kirill A. Shutemov, linux-nvdimm, Dave Chinner, Linux MM 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. -- 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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH v2] dax: fix NULL pointer in __dax_pmd_fault() 2015-09-22 21:17 ` Ross Zwisler @ 2015-09-22 21:26 ` Dan Williams 0 siblings, 0 replies; 3+ messages in thread From: Dan Williams @ 2015-09-22 21:26 UTC (permalink / raw) To: Ross Zwisler, Dan Williams, Andrew Morton, linux-kernel, Alexander Viro, Matthew Wilcox, linux-fsdevel, Kirill A. Shutemov, linux-nvdimm, Dave Chinner, Linux MM 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. -- 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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-09-22 21:26 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <1442950582-10140-1-git-send-email-ross.zwisler@linux.intel.com>
2015-09-22 20:51 ` [PATCH v2] dax: fix NULL pointer in __dax_pmd_fault() Dan Williams
2015-09-22 21:17 ` Ross Zwisler
2015-09-22 21:26 ` Dan Williams
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox