All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.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>, Jan Kara <jack@suse.com>,
	Matthew Wilcox <willy@linux.intel.com>,
	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>,
	XFS Developers <xfs@oss.sgi.com>
Subject: Re: [PATCH 1/2] dax: pass bdev argument to dax_clear_blocks()
Date: Sun, 7 Feb 2016 10:19:29 -0800	[thread overview]
Message-ID: <CAPcyv4jOAKeTXt0EvZzfxzqcaf+ZWrtsFeN2JFP_sf1HcTpVOw@mail.gmail.com> (raw)
In-Reply-To: <1454829553-29499-2-git-send-email-ross.zwisler@linux.intel.com>

On Sat, Feb 6, 2016 at 11:19 PM, Ross Zwisler
<ross.zwisler@linux.intel.com> wrote:
> dax_clear_blocks() needs a valid struct block_device and previously it was
> using inode->i_sb->s_bdev in all cases.  This is correct for normal inodes
> on mounted ext2, ext4 and XFS filesystems, but is incorrect for DAX raw
> block devices and for XFS real-time devices.
>
> Instead, have the caller pass in a struct block_device pointer which it
> knows to be correct.
>
> Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> ---
>  fs/dax.c               | 4 ++--
>  fs/ext2/inode.c        | 5 +++--
>  fs/xfs/xfs_aops.c      | 2 +-
>  fs/xfs/xfs_aops.h      | 1 +
>  fs/xfs/xfs_bmap_util.c | 4 +++-
>  include/linux/dax.h    | 3 ++-
>  6 files changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/fs/dax.c b/fs/dax.c
> index 227974a..4592241 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -83,9 +83,9 @@ struct page *read_dax_sector(struct block_device *bdev, sector_t n)
>   * and hence this means the stack from this point must follow GFP_NOFS
>   * semantics for all operations.
>   */
> -int dax_clear_blocks(struct inode *inode, sector_t block, long _size)
> +int dax_clear_blocks(struct inode *inode, struct block_device *bdev,
> +               sector_t block, long _size)

Since this is a bdev relative routine we should also resolve the
sector, i.e. the signature should drop the inode:

int dax_clear_sectors(struct block_device *bdev, sector_t sector, long _size)

--
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: Dan Williams <dan.j.williams@intel.com>
To: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.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>, Jan Kara <jack@suse.com>,
	Matthew Wilcox <willy@linux.intel.com>,
	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>,
	XFS Developers <xfs@oss.sgi.com>
Subject: Re: [PATCH 1/2] dax: pass bdev argument to dax_clear_blocks()
Date: Sun, 7 Feb 2016 10:19:29 -0800	[thread overview]
Message-ID: <CAPcyv4jOAKeTXt0EvZzfxzqcaf+ZWrtsFeN2JFP_sf1HcTpVOw@mail.gmail.com> (raw)
In-Reply-To: <1454829553-29499-2-git-send-email-ross.zwisler@linux.intel.com>

On Sat, Feb 6, 2016 at 11:19 PM, Ross Zwisler
<ross.zwisler@linux.intel.com> wrote:
> dax_clear_blocks() needs a valid struct block_device and previously it was
> using inode->i_sb->s_bdev in all cases.  This is correct for normal inodes
> on mounted ext2, ext4 and XFS filesystems, but is incorrect for DAX raw
> block devices and for XFS real-time devices.
>
> Instead, have the caller pass in a struct block_device pointer which it
> knows to be correct.
>
> Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> ---
>  fs/dax.c               | 4 ++--
>  fs/ext2/inode.c        | 5 +++--
>  fs/xfs/xfs_aops.c      | 2 +-
>  fs/xfs/xfs_aops.h      | 1 +
>  fs/xfs/xfs_bmap_util.c | 4 +++-
>  include/linux/dax.h    | 3 ++-
>  6 files changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/fs/dax.c b/fs/dax.c
> index 227974a..4592241 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -83,9 +83,9 @@ struct page *read_dax_sector(struct block_device *bdev, sector_t n)
>   * and hence this means the stack from this point must follow GFP_NOFS
>   * semantics for all operations.
>   */
> -int dax_clear_blocks(struct inode *inode, sector_t block, long _size)
> +int dax_clear_blocks(struct inode *inode, struct block_device *bdev,
> +               sector_t block, long _size)

Since this is a bdev relative routine we should also resolve the
sector, i.e. the signature should drop the inode:

int dax_clear_sectors(struct block_device *bdev, sector_t sector, long _size)

WARNING: multiple messages have this Message-ID (diff)
From: Dan Williams <dan.j.williams@intel.com>
To: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Theodore Ts'o <tytso@mit.edu>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	XFS Developers <xfs@oss.sgi.com>, Linux MM <linux-mm@kvack.org>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Jan Kara <jack@suse.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Matthew Wilcox <willy@linux.intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 1/2] dax: pass bdev argument to dax_clear_blocks()
Date: Sun, 7 Feb 2016 10:19:29 -0800	[thread overview]
Message-ID: <CAPcyv4jOAKeTXt0EvZzfxzqcaf+ZWrtsFeN2JFP_sf1HcTpVOw@mail.gmail.com> (raw)
In-Reply-To: <1454829553-29499-2-git-send-email-ross.zwisler@linux.intel.com>

On Sat, Feb 6, 2016 at 11:19 PM, Ross Zwisler
<ross.zwisler@linux.intel.com> wrote:
> dax_clear_blocks() needs a valid struct block_device and previously it was
> using inode->i_sb->s_bdev in all cases.  This is correct for normal inodes
> on mounted ext2, ext4 and XFS filesystems, but is incorrect for DAX raw
> block devices and for XFS real-time devices.
>
> Instead, have the caller pass in a struct block_device pointer which it
> knows to be correct.
>
> Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> ---
>  fs/dax.c               | 4 ++--
>  fs/ext2/inode.c        | 5 +++--
>  fs/xfs/xfs_aops.c      | 2 +-
>  fs/xfs/xfs_aops.h      | 1 +
>  fs/xfs/xfs_bmap_util.c | 4 +++-
>  include/linux/dax.h    | 3 ++-
>  6 files changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/fs/dax.c b/fs/dax.c
> index 227974a..4592241 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -83,9 +83,9 @@ struct page *read_dax_sector(struct block_device *bdev, sector_t n)
>   * and hence this means the stack from this point must follow GFP_NOFS
>   * semantics for all operations.
>   */
> -int dax_clear_blocks(struct inode *inode, sector_t block, long _size)
> +int dax_clear_blocks(struct inode *inode, struct block_device *bdev,
> +               sector_t block, long _size)

Since this is a bdev relative routine we should also resolve the
sector, i.e. the signature should drop the inode:

int dax_clear_sectors(struct block_device *bdev, sector_t sector, long _size)

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2016-02-07 18:19 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-07  7:19 [PATCH 0/2] DAX bdev fixes - move flushing calls to FS Ross Zwisler
2016-02-07  7:19 ` Ross Zwisler
2016-02-07  7:19 ` Ross Zwisler
2016-02-07  7:19 ` [PATCH 1/2] dax: pass bdev argument to dax_clear_blocks() Ross Zwisler
2016-02-07  7:19   ` Ross Zwisler
2016-02-07  7:19   ` Ross Zwisler
2016-02-07 18:19   ` Dan Williams [this message]
2016-02-07 18:19     ` Dan Williams
2016-02-07 18:19     ` Dan Williams
2016-02-08  1:46     ` Ross Zwisler
2016-02-08  1:46       ` Ross Zwisler
2016-02-08  1:46       ` Ross Zwisler
2016-02-08  4:29       ` Ross Zwisler
2016-02-08  4:29         ` Ross Zwisler
2016-02-08  4:29         ` Ross Zwisler
2016-02-07 22:03   ` Dave Chinner
2016-02-07 22:03     ` Dave Chinner
2016-02-07 22:03     ` Dave Chinner
2016-02-08  1:44     ` Ross Zwisler
2016-02-08  1:44       ` Ross Zwisler
2016-02-08  1:44       ` Ross Zwisler
2016-02-08  5:17       ` Dave Chinner
2016-02-08  5:17         ` Dave Chinner
2016-02-08  5:17         ` Dave Chinner
2016-02-08 15:34         ` Ross Zwisler
2016-02-08 15:34           ` Ross Zwisler
2016-02-08 15:34           ` Ross Zwisler
2016-02-08 15:34           ` Ross Zwisler
2016-02-07  7:19 ` [PATCH 2/2] dax: move writeback calls into the filesystems Ross Zwisler
2016-02-07  7:19   ` Ross Zwisler
2016-02-07  7:19   ` Ross Zwisler
2016-02-07  7:19   ` Ross Zwisler
2016-02-07 19:13   ` Dan Williams
2016-02-07 19:13     ` Dan Williams
2016-02-07 19:13     ` Dan Williams
2016-02-07 21:50     ` Dave Chinner
2016-02-07 21:50       ` Dave Chinner
2016-02-07 21:50       ` Dave Chinner
2016-02-08  8:18       ` Dan Williams
2016-02-08  8:18         ` Dan Williams
2016-02-08  8:18         ` Dan Williams
2016-02-08  8:18         ` Dan Williams
2016-02-08 20:18         ` Dave Chinner
2016-02-08 20:18           ` Dave Chinner
2016-02-08 20:18           ` Dave Chinner
2016-02-08 20:55           ` Dan Williams
2016-02-08 20:55             ` Dan Williams
2016-02-08 20:55             ` Dan Williams
2016-02-08 20:58             ` Jeff Moyer
2016-02-08 20:58               ` Jeff Moyer
2016-02-08 20:58               ` Jeff Moyer
2016-02-08 20:58               ` Jeff Moyer
2016-02-08 22:05               ` Dan Williams
2016-02-08 22:05                 ` Dan Williams
2016-02-08 22:05                 ` Dan Williams
2016-02-09  9:43             ` Jan Kara
2016-02-09  9:43               ` Jan Kara
2016-02-09  9:43               ` Jan Kara
2016-02-09 16:01               ` Jan Kara
2016-02-09 16:01                 ` Jan Kara
2016-02-09 16:01                 ` Jan Kara
2016-02-09 16:01                 ` Jan Kara
2016-02-09 18:06                 ` Ross Zwisler
2016-02-09 18:06                   ` Ross Zwisler
2016-02-09 18:06                   ` Ross Zwisler
2016-02-09 18:06                   ` Ross Zwisler
2016-02-08 18:31     ` Ross Zwisler
2016-02-08 18:31       ` Ross Zwisler
2016-02-08 18:31       ` Ross Zwisler
2016-02-08 19:23       ` Dan Williams
2016-02-08 19:23         ` Dan Williams
2016-02-08 19:23         ` Dan Williams
2016-02-08 10:48   ` Jan Kara
2016-02-08 10:48     ` Jan Kara
2016-02-08 10:48     ` Jan Kara
2016-02-08 16:12     ` Ross Zwisler
2016-02-08 16:12       ` Ross Zwisler
2016-02-08 16:12       ` 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=CAPcyv4jOAKeTXt0EvZzfxzqcaf+ZWrtsFeN2JFP_sf1HcTpVOw@mail.gmail.com \
    --to=dan.j.williams@intel.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=akpm@linux-foundation.org \
    --cc=david@fromorbit.com \
    --cc=jack@suse.com \
    --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=ross.zwisler@linux.intel.com \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    --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.