From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ross Zwisler Subject: Re: [PATCH v2] dax: fix NULL pointer in __dax_pmd_fault() Date: Tue, 22 Sep 2015 15:17:16 -0600 Message-ID: <20150922211716.GA32623@linux.intel.com> References: <1442950582-10140-1-git-send-email-ross.zwisler@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Ross Zwisler , Andrew Morton , "linux-kernel@vger.kernel.org" , Alexander Viro , Matthew Wilcox , linux-fsdevel , "Kirill A. Shutemov" , "linux-nvdimm@lists.01.org" , Dave Chinner , Linux MM To: Dan Williams , @linux.intel.com Return-path: Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org 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 > 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 > > Reported-by: Dan Williams > > Taking into account the comment below, > > Reviewed-by: Dan Williams > > > --- > > 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: email@kvack.org