From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Jan Kara <jack@suse.cz>,
Dave Hansen <dave.hansen@linux.intel.com>,
"J. Bruce Fields" <bfields@fieldses.org>,
Linux MM <linux-mm@kvack.org>,
Andreas Dilger <adilger.kernel@dilger.ca>,
"H. Peter Anvin" <hpa@zytor.com>,
Jeff Layton <jlayton@poochiereds.net>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
X86 ML <x86@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Matthew Wilcox <willy@linux.intel.com>,
Ross Zwisler <ross.zwisler@linux.intel.com>,
linux-ext4 <linux-ext4@vger.kernel.org>,
XFS Developers <xfs@oss.sgi.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Thomas Gleixner <tglx@linutronix.de>,
Theodore Ts'o <tytso@mit.edu>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Jan Kara <jack@suse.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Matthew Wilcox <matthew.r.wilcox@intel.com>
Subject: Re: [PATCH v7 1/9] dax: fix NULL pointer dereference in __dax_dbg()
Date: Thu, 7 Jan 2016 15:16:06 -0700 [thread overview]
Message-ID: <20160107221606.GB20802@linux.intel.com> (raw)
In-Reply-To: <CAPcyv4i_xfihzc_LKYiz_XuTVVCMSf5dsJQE8g7-NURe170p7g@mail.gmail.com>
On Thu, Jan 07, 2016 at 07:17:22AM -0800, Dan Williams wrote:
> On Thu, Jan 7, 2016 at 1:34 AM, Jan Kara <jack@suse.cz> wrote:
> > On Wed 06-01-16 11:14:09, Dan Williams wrote:
> >> On Wed, Jan 6, 2016 at 10:00 AM, Ross Zwisler
> >> <ross.zwisler@linux.intel.com> wrote:
> >> > __dax_dbg() currently assumes that bh->b_bdev is non-NULL, passing it into
> >> > bdevname() where is is dereferenced. This assumption isn't always true -
> >> > when called for reads of holes, ext4_dax_mmap_get_block() returns a buffer
> >> > head where bh->b_bdev is never set. I hit this BUG while testing the DAX
> >> > PMD fault path.
> >> >
> >> > Instead, verify that we have a valid bh->b_bdev, else just say "unknown"
> >> > for the block device.
> >> >
> >> > Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> >> > Cc: Dan Williams <dan.j.williams@intel.com>
> >> > ---
> >> > fs/dax.c | 7 ++++++-
> >> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >> >
> >> > diff --git a/fs/dax.c b/fs/dax.c
> >> > index 7af8797..03cc4a3 100644
> >> > --- a/fs/dax.c
> >> > +++ b/fs/dax.c
> >> > @@ -563,7 +563,12 @@ static void __dax_dbg(struct buffer_head *bh, unsigned long address,
> >> > {
> >> > if (bh) {
> >> > char bname[BDEVNAME_SIZE];
> >> > - bdevname(bh->b_bdev, bname);
> >> > +
> >> > + if (bh->b_bdev)
> >> > + bdevname(bh->b_bdev, bname);
> >> > + else
> >> > + snprintf(bname, BDEVNAME_SIZE, "unknown");
> >> > +
> >> > pr_debug("%s: %s addr: %lx dev %s state %lx start %lld "
> >> > "length %zd fallback: %s\n", fn, current->comm,
> >> > address, bname, bh->b_state, (u64)bh->b_blocknr,
> >>
> >> I'm assuming there's no danger of a such a buffer_head ever being used
> >> for the bdev parameter to dax_map_atomic()? Shouldn't we also/instead
> >> go fix ext4 to not send partially filled buffer_heads?
> >
> > No. The real problem is a long-standing abuse of struct buffer_head to be
> > used for passing block mapping information (it's on my todo list to remove
> > that at least from DAX code and use cleaner block mapping interface but
> > first I want basic DAX functionality to settle down to avoid unnecessary
> > conflicts). Filesystem is not supposed to touch bh->b_bdev. If you need
> > that filled in, set it yourself in before passing bh to the block mapping
> > function.
> >
>
> Ok, makes sense.
>
> Ross, can you fix this instead by unconditionally looking up the bdev
> rather that saying "unknown". The bdev should always be retrievable.
Sure, will do.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
WARNING: multiple messages have this Message-ID (diff)
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Jan Kara <jack@suse.cz>,
Ross Zwisler <ross.zwisler@linux.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
"J. Bruce Fields" <bfields@fieldses.org>,
Theodore Ts'o <tytso@mit.edu>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Andrew Morton <akpm@linux-foundation.org>,
Dave Chinner <david@fromorbit.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Ingo Molnar <mingo@redhat.com>, Jan Kara <jack@suse.com>,
Jeff Layton <jlayton@poochiereds.net>,
Matthew Wilcox <matthew.r.wilcox@intel.com>,
Matthew Wilcox <willy@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-ext4 <linux-ext4@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
X86 ML <x86@kernel.org>, XFS Developers <xfs@oss.sgi.com>
Subject: Re: [PATCH v7 1/9] dax: fix NULL pointer dereference in __dax_dbg()
Date: Thu, 7 Jan 2016 15:16:06 -0700 [thread overview]
Message-ID: <20160107221606.GB20802@linux.intel.com> (raw)
In-Reply-To: <CAPcyv4i_xfihzc_LKYiz_XuTVVCMSf5dsJQE8g7-NURe170p7g@mail.gmail.com>
On Thu, Jan 07, 2016 at 07:17:22AM -0800, Dan Williams wrote:
> On Thu, Jan 7, 2016 at 1:34 AM, Jan Kara <jack@suse.cz> wrote:
> > On Wed 06-01-16 11:14:09, Dan Williams wrote:
> >> On Wed, Jan 6, 2016 at 10:00 AM, Ross Zwisler
> >> <ross.zwisler@linux.intel.com> wrote:
> >> > __dax_dbg() currently assumes that bh->b_bdev is non-NULL, passing it into
> >> > bdevname() where is is dereferenced. This assumption isn't always true -
> >> > when called for reads of holes, ext4_dax_mmap_get_block() returns a buffer
> >> > head where bh->b_bdev is never set. I hit this BUG while testing the DAX
> >> > PMD fault path.
> >> >
> >> > Instead, verify that we have a valid bh->b_bdev, else just say "unknown"
> >> > for the block device.
> >> >
> >> > Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> >> > Cc: Dan Williams <dan.j.williams@intel.com>
> >> > ---
> >> > fs/dax.c | 7 ++++++-
> >> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >> >
> >> > diff --git a/fs/dax.c b/fs/dax.c
> >> > index 7af8797..03cc4a3 100644
> >> > --- a/fs/dax.c
> >> > +++ b/fs/dax.c
> >> > @@ -563,7 +563,12 @@ static void __dax_dbg(struct buffer_head *bh, unsigned long address,
> >> > {
> >> > if (bh) {
> >> > char bname[BDEVNAME_SIZE];
> >> > - bdevname(bh->b_bdev, bname);
> >> > +
> >> > + if (bh->b_bdev)
> >> > + bdevname(bh->b_bdev, bname);
> >> > + else
> >> > + snprintf(bname, BDEVNAME_SIZE, "unknown");
> >> > +
> >> > pr_debug("%s: %s addr: %lx dev %s state %lx start %lld "
> >> > "length %zd fallback: %s\n", fn, current->comm,
> >> > address, bname, bh->b_state, (u64)bh->b_blocknr,
> >>
> >> I'm assuming there's no danger of a such a buffer_head ever being used
> >> for the bdev parameter to dax_map_atomic()? Shouldn't we also/instead
> >> go fix ext4 to not send partially filled buffer_heads?
> >
> > No. The real problem is a long-standing abuse of struct buffer_head to be
> > used for passing block mapping information (it's on my todo list to remove
> > that at least from DAX code and use cleaner block mapping interface but
> > first I want basic DAX functionality to settle down to avoid unnecessary
> > conflicts). Filesystem is not supposed to touch bh->b_bdev. If you need
> > that filled in, set it yourself in before passing bh to the block mapping
> > function.
> >
>
> Ok, makes sense.
>
> Ross, can you fix this instead by unconditionally looking up the bdev
> rather that saying "unknown". The bdev should always be retrievable.
Sure, will do.
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Jan Kara <jack@suse.cz>,
Ross Zwisler <ross.zwisler@linux.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
"J. Bruce Fields" <bfields@fieldses.org>,
"Theodore Ts'o" <tytso@mit.edu>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Andrew Morton <akpm@linux-foundation.org>,
Dave Chinner <david@fromorbit.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Ingo Molnar <mingo@redhat.com>, Jan Kara <jack@suse.com>,
Jeff Layton <jlayton@poochiereds.net>,
Matthew Wilcox <matthew.r.wilcox@intel.com>,
Matthew Wilcox <willy@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-ext4 <linux-ext4@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@ml01.01.org>,
X86 ML <x86@kernel.org>, XFS Developers <xfs@oss.sgi.com>
Subject: Re: [PATCH v7 1/9] dax: fix NULL pointer dereference in __dax_dbg()
Date: Thu, 7 Jan 2016 15:16:06 -0700 [thread overview]
Message-ID: <20160107221606.GB20802@linux.intel.com> (raw)
In-Reply-To: <CAPcyv4i_xfihzc_LKYiz_XuTVVCMSf5dsJQE8g7-NURe170p7g@mail.gmail.com>
On Thu, Jan 07, 2016 at 07:17:22AM -0800, Dan Williams wrote:
> On Thu, Jan 7, 2016 at 1:34 AM, Jan Kara <jack@suse.cz> wrote:
> > On Wed 06-01-16 11:14:09, Dan Williams wrote:
> >> On Wed, Jan 6, 2016 at 10:00 AM, Ross Zwisler
> >> <ross.zwisler@linux.intel.com> wrote:
> >> > __dax_dbg() currently assumes that bh->b_bdev is non-NULL, passing it into
> >> > bdevname() where is is dereferenced. This assumption isn't always true -
> >> > when called for reads of holes, ext4_dax_mmap_get_block() returns a buffer
> >> > head where bh->b_bdev is never set. I hit this BUG while testing the DAX
> >> > PMD fault path.
> >> >
> >> > Instead, verify that we have a valid bh->b_bdev, else just say "unknown"
> >> > for the block device.
> >> >
> >> > Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> >> > Cc: Dan Williams <dan.j.williams@intel.com>
> >> > ---
> >> > fs/dax.c | 7 ++++++-
> >> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >> >
> >> > diff --git a/fs/dax.c b/fs/dax.c
> >> > index 7af8797..03cc4a3 100644
> >> > --- a/fs/dax.c
> >> > +++ b/fs/dax.c
> >> > @@ -563,7 +563,12 @@ static void __dax_dbg(struct buffer_head *bh, unsigned long address,
> >> > {
> >> > if (bh) {
> >> > char bname[BDEVNAME_SIZE];
> >> > - bdevname(bh->b_bdev, bname);
> >> > +
> >> > + if (bh->b_bdev)
> >> > + bdevname(bh->b_bdev, bname);
> >> > + else
> >> > + snprintf(bname, BDEVNAME_SIZE, "unknown");
> >> > +
> >> > pr_debug("%s: %s addr: %lx dev %s state %lx start %lld "
> >> > "length %zd fallback: %s\n", fn, current->comm,
> >> > address, bname, bh->b_state, (u64)bh->b_blocknr,
> >>
> >> I'm assuming there's no danger of a such a buffer_head ever being used
> >> for the bdev parameter to dax_map_atomic()? Shouldn't we also/instead
> >> go fix ext4 to not send partially filled buffer_heads?
> >
> > No. The real problem is a long-standing abuse of struct buffer_head to be
> > used for passing block mapping information (it's on my todo list to remove
> > that at least from DAX code and use cleaner block mapping interface but
> > first I want basic DAX functionality to settle down to avoid unnecessary
> > conflicts). Filesystem is not supposed to touch bh->b_bdev. If you need
> > that filled in, set it yourself in before passing bh to the block mapping
> > function.
> >
>
> Ok, makes sense.
>
> Ross, can you fix this instead by unconditionally looking up the bdev
> rather that saying "unknown". The bdev should always be retrievable.
Sure, will do.
next prev parent reply other threads:[~2016-01-07 22:16 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-06 18:00 [PATCH v7 0/9] DAX fsync/msync support Ross Zwisler
2016-01-06 18:00 ` Ross Zwisler
2016-01-06 18:00 ` Ross Zwisler
2016-01-06 18:00 ` Ross Zwisler
2016-01-06 18:00 ` [PATCH v7 1/9] dax: fix NULL pointer dereference in __dax_dbg() Ross Zwisler
2016-01-06 18:00 ` Ross Zwisler
2016-01-06 18:00 ` Ross Zwisler
2016-01-06 18:00 ` Ross Zwisler
2016-01-06 19:14 ` Dan Williams
2016-01-06 19:14 ` Dan Williams
2016-01-06 19:14 ` Dan Williams
2016-01-07 9:34 ` Jan Kara
2016-01-07 9:34 ` Jan Kara
2016-01-07 9:34 ` Jan Kara
2016-01-07 9:34 ` Jan Kara
2016-01-07 15:17 ` Dan Williams
2016-01-07 15:17 ` Dan Williams
2016-01-07 15:17 ` Dan Williams
2016-01-07 15:17 ` Dan Williams
2016-01-07 22:16 ` Ross Zwisler [this message]
2016-01-07 22:16 ` Ross Zwisler
2016-01-07 22:16 ` Ross Zwisler
2016-01-07 23:10 ` Dave Chinner
2016-01-07 23:10 ` Dave Chinner
2016-01-07 23:10 ` Dave Chinner
2016-01-07 23:39 ` Ross Zwisler
2016-01-07 23:39 ` Ross Zwisler
2016-01-07 23:39 ` Ross Zwisler
2016-01-07 23:39 ` Ross Zwisler
2016-01-06 18:00 ` [PATCH v7 2/9] dax: fix conversion of holes to PMDs Ross Zwisler
2016-01-06 18:00 ` Ross Zwisler
2016-01-06 18:00 ` Ross Zwisler
2016-01-06 19:04 ` Dan Williams
2016-01-06 19:04 ` Dan Williams
2016-01-06 19:04 ` Dan Williams
2016-01-06 19:04 ` Dan Williams
2016-01-07 22:34 ` Ross Zwisler
2016-01-07 22:34 ` Ross Zwisler
2016-01-07 22:34 ` Ross Zwisler
2016-01-08 4:18 ` Ross Zwisler
2016-01-08 4:18 ` Ross Zwisler
2016-01-08 4:18 ` Ross Zwisler
2016-01-08 4:18 ` Ross Zwisler
2016-01-07 13:22 ` Jan Kara
2016-01-07 13:22 ` Jan Kara
2016-01-07 13:22 ` Jan Kara
2016-01-07 22:11 ` Ross Zwisler
2016-01-07 22:11 ` Ross Zwisler
2016-01-07 22:11 ` Ross Zwisler
2016-01-11 12:23 ` Jan Kara
2016-01-11 12:23 ` Jan Kara
2016-01-11 12:23 ` Jan Kara
2016-01-06 18:00 ` [PATCH v7 3/9] pmem: add wb_cache_pmem() to the PMEM API Ross Zwisler
2016-01-06 18:00 ` Ross Zwisler
2016-01-06 18:00 ` Ross Zwisler
2016-01-06 18:00 ` [PATCH v7 4/9] dax: support dirty DAX entries in radix tree Ross Zwisler
2016-01-06 18:00 ` Ross Zwisler
2016-01-06 18:00 ` Ross Zwisler
2016-01-06 18:00 ` [PATCH v7 5/9] mm: add find_get_entries_tag() Ross Zwisler
2016-01-06 18:00 ` Ross Zwisler
2016-01-06 18:00 ` Ross Zwisler
2016-01-06 18:01 ` [PATCH v7 6/9] dax: add support for fsync/msync Ross Zwisler
2016-01-06 18:01 ` Ross Zwisler
2016-01-06 18:01 ` Ross Zwisler
2016-01-06 18:01 ` [PATCH v7 7/9] ext2: call dax_pfn_mkwrite() for DAX fsync/msync Ross Zwisler
2016-01-06 18:01 ` Ross Zwisler
2016-01-06 18:01 ` Ross Zwisler
2016-01-06 18:01 ` [PATCH v7 8/9] ext4: " Ross Zwisler
2016-01-06 18:01 ` Ross Zwisler
2016-01-06 18:01 ` Ross Zwisler
2016-01-06 18:01 ` [PATCH v7 9/9] xfs: " Ross Zwisler
2016-01-06 18:01 ` Ross Zwisler
2016-01-06 18:01 ` Ross Zwisler
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=20160107221606.GB20802@linux.intel.com \
--to=ross.zwisler@linux.intel.com \
--cc=adilger.kernel@dilger.ca \
--cc=akpm@linux-foundation.org \
--cc=bfields@fieldses.org \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jack@suse.com \
--cc=jack@suse.cz \
--cc=jlayton@poochiereds.net \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=matthew.r.wilcox@intel.com \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@linux.intel.com \
--cc=x86@kernel.org \
--cc=xfs@oss.sgi.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.