From: Andrew Morton <akpm@linux-foundation.org>
To: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: linux-kernel@vger.kernel.org,
Alexander Viro <viro@zeniv.linux.org.uk>,
Matthew Wilcox <willy@linux.intel.com>,
linux-fsdevel@vger.kernel.org,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
linux-nvdimm@ml01.01.org, Dan Williams <dan.j.williams@intel.com>,
Dave Chinner <david@fromorbit.com>
Subject: Re: [PATCH v2] dax: fix NULL pointer in __dax_pmd_fault()
Date: Tue, 22 Sep 2015 14:13:33 -0700 [thread overview]
Message-ID: <20150922141333.c28e3c5d800267937ca7b29a@linux-foundation.org> (raw)
In-Reply-To: <1442950582-10140-1-git-send-email-ross.zwisler@linux.intel.com>
On Tue, 22 Sep 2015 13:36:22 -0600 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().
Why the heck didn't gcc warn?
I had a fiddle:
--- a/fs/dax.c~a
+++ a/fs/dax.c
@@ -529,15 +529,18 @@ int __dax_pmd_fault(struct vm_area_struc
unsigned long pmd_addr = address & PMD_MASK;
bool write = flags & FAULT_FLAG_WRITE;
long length;
- void __pmem *kaddr;
+ void *kaddr;
pgoff_t size, pgoff;
sector_t block, sector;
unsigned long pfn;
int result = 0;
+// printk("%p\n", kaddr);
+
/* Fall back to PTEs if we're going to COW */
if (write && !(vma->vm_flags & VM_SHARED))
return VM_FAULT_FALLBACK;
+ printk("%p\n", kaddr);
/* If the PMD would extend outside the VMA */
if (pmd_addr < vma->vm_start)
return VM_FAULT_FALLBACK;
gcc warns about the first printk, but not about the second. So that
"if (...) return ..." seems to have defeated gcc uninitialized-var
detection. wtf?
> --- 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();
hm, that's a lot of copy-n-paste. Do we really need to run
bdev_direct_access() twice? Will `kaddr' and `pfn' change?
next prev parent reply other threads:[~2015-09-22 21:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-22 19:36 Ross Zwisler
2015-09-22 20:51 ` Dan Williams
[not found] ` <20150922211716.GA32623@linux.intel.com>
2015-09-22 21:26 ` Dan Williams
2015-09-22 21:13 ` Andrew Morton [this message]
2015-09-22 21:25 ` Dan Williams
2015-09-22 23:30 ` Dave Chinner
2015-09-23 3:00 ` Dan Williams
2015-09-23 9:04 ` Dave Chinner
2015-09-24 8:50 ` Boaz Harrosh
2015-09-24 16:06 ` Dan Williams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150922141333.c28e3c5d800267937ca7b29a@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=david@fromorbit.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@ml01.01.org \
--cc=ross.zwisler@linux.intel.com \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®