lkml.org 
[lkml]   [2016]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/2] dax: pass bdev argument to dax_clear_blocks()
On Sun, Feb 07, 2016 at 10:19:29AM -0800, Dan Williams wrote:
> 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)

The inode is still needed because dax_clear_blocks() needs inode->i_blkbits.
Unless there is some easy way to get this from the bdev that I'm not seeing?

\
 
 \ /
  Last update: 2016-02-08 03:21    [W:0.165 / U:1.368 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site