From: Al Viro <viro@ZenIV.linux.org.uk>
To: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Jeff Layton <jlayton@poochiereds.net>,
linux-nvdimm@ml01.01.org, linux-kernel@vger.kernel.org,
xfs@oss.sgi.com, "J. Bruce Fields" <bfields@fieldses.org>,
Jan Kara <jack@suse.com>,
linux-fsdevel@vger.kernel.org,
Matthew Wilcox <willy@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Dan Williams <dan.j.williams@intel.com>
Subject: Re: [PATCH] dax: allow DAX to look up an inode's block device
Date: Tue, 2 Feb 2016 23:19:31 +0000 [thread overview]
Message-ID: <20160202231931.GR17997@ZenIV.linux.org.uk> (raw)
In-Reply-To: <1454454702-11889-1-git-send-email-ross.zwisler@linux.intel.com>
On Tue, Feb 02, 2016 at 04:11:42PM -0700, Ross Zwisler wrote:
> However, for raw block devices and for XFS with a real-time device, the
> value in inode->i_sb->s_bdev is not correct. With the code as it is
> currently written, an fsync or msync to a DAX enabled raw block device will
> cause a NULL pointer dereference kernel BUG. For this to work correctly we
> need to ask the block device or filesystem what struct block_device is
> appropriate for our inode.
>
> To that end, add a get_bdev(struct inode *) entry point to struct
> super_operations. If this function pointer is non-NULL, this notifies DAX
> that it needs to use it to look up the correct block_device. If
> i_sb->get_bdev() is NULL DAX will default to inode->i_sb->s_bdev.
Umm... It assumes that bdev will stay pinned for as long as inode is
referenced, presumably? If so, that needs to be documented (and verified
for existing fs instances). In principle, multi-disk fs might want to
support things like "silently move the inodes backed by that disk to other
ones"...
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: linux-kernel@vger.kernel.org,
"J. Bruce Fields" <bfields@fieldses.org>,
Andrew Morton <akpm@linux-foundation.org>,
Dan Williams <dan.j.williams@intel.com>,
Dave Chinner <david@fromorbit.com>, Jan Kara <jack@suse.com>,
Jeff Layton <jlayton@poochiereds.net>,
Matthew Wilcox <willy@linux.intel.com>,
linux-fsdevel@vger.kernel.org, linux-nvdimm@ml01.01.org,
xfs@oss.sgi.com
Subject: Re: [PATCH] dax: allow DAX to look up an inode's block device
Date: Tue, 2 Feb 2016 23:19:31 +0000 [thread overview]
Message-ID: <20160202231931.GR17997@ZenIV.linux.org.uk> (raw)
In-Reply-To: <1454454702-11889-1-git-send-email-ross.zwisler@linux.intel.com>
On Tue, Feb 02, 2016 at 04:11:42PM -0700, Ross Zwisler wrote:
> However, for raw block devices and for XFS with a real-time device, the
> value in inode->i_sb->s_bdev is not correct. With the code as it is
> currently written, an fsync or msync to a DAX enabled raw block device will
> cause a NULL pointer dereference kernel BUG. For this to work correctly we
> need to ask the block device or filesystem what struct block_device is
> appropriate for our inode.
>
> To that end, add a get_bdev(struct inode *) entry point to struct
> super_operations. If this function pointer is non-NULL, this notifies DAX
> that it needs to use it to look up the correct block_device. If
> i_sb->get_bdev() is NULL DAX will default to inode->i_sb->s_bdev.
Umm... It assumes that bdev will stay pinned for as long as inode is
referenced, presumably? If so, that needs to be documented (and verified
for existing fs instances). In principle, multi-disk fs might want to
support things like "silently move the inodes backed by that disk to other
ones"...
next prev parent reply other threads:[~2016-02-02 23:19 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-02 23:11 [PATCH] dax: allow DAX to look up an inode's block device Ross Zwisler
2016-02-02 23:11 ` Ross Zwisler
2016-02-02 23:11 ` Ross Zwisler
2016-02-02 23:19 ` Al Viro [this message]
2016-02-02 23:19 ` Al Viro
2016-02-02 23:36 ` Jared Hulbert
2016-02-02 23:36 ` Jared Hulbert
2016-02-02 23:41 ` Dan Williams
2016-02-02 23:41 ` Dan Williams
2016-02-03 0:33 ` Jared Hulbert
2016-02-03 0:33 ` Jared Hulbert
2016-02-03 7:54 ` Dave Chinner
2016-02-02 23:38 ` Dan Williams
2016-02-02 23:38 ` Dan Williams
2016-02-02 23:39 ` Dan Williams
2016-02-02 23:39 ` Dan Williams
2016-02-02 23:52 ` Matthew Wilcox
2016-02-02 23:52 ` Matthew Wilcox
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=20160202231931.GR17997@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=akpm@linux-foundation.org \
--cc=bfields@fieldses.org \
--cc=dan.j.williams@intel.com \
--cc=jack@suse.com \
--cc=jlayton@poochiereds.net \
--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=willy@linux.intel.com \
--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.