linux-ext4 - Re: [PATCH 2/6] iomap: move bdev and dax

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 18 Jun 2018 23:25:57 -0700
From:   "Darrick J. Wong" <darrick.wong@...cle.com>
To:     Christoph Hellwig <hch@....de>
Cc:     Andreas Gruenbacher <agruenba@...hat.com>,
        linux-xfs@...r.kernel.org, Dan Williams <dan.j.williams@...el.com>,
        linux-fsdevel@...r.kernel.org, cluster-devel@...hat.com,
        linux-ext4@...r.kernel.org
Subject: Re: [PATCH 2/6] iomap: move bdev and dax_dev in a union

On Thu, Jun 14, 2018 at 02:04:53PM +0200, Christoph Hellwig wrote:
> We always either ask for a block device or DAX device mapping, so we can
> use the same space for both.
> 
> Signed-off-by: Christoph Hellwig <hch@....de>
> ---
>  fs/ext2/inode.c       | 6 ++++--
>  fs/ext4/inode.c       | 6 ++++--
>  fs/xfs/xfs_iomap.c    | 6 ++++--
>  include/linux/iomap.h | 6 ++++--
>  4 files changed, 16 insertions(+), 8 deletions(-)
> 
> diff --git a/fs/ext2/inode.c b/fs/ext2/inode.c
> index 71635909df3b..8aead4e9dbc1 100644
> --- a/fs/ext2/inode.c
> +++ b/fs/ext2/inode.c
> @@ -815,9 +815,11 @@ static int ext2_iomap_begin(struct inode *inode, loff_t offset, loff_t length,
>  		return ret;
>  
>  	iomap->flags = 0;
> -	iomap->bdev = inode->i_sb->s_bdev;
>  	iomap->offset = (u64)first_block << blkbits;
> -	iomap->dax_dev = sbi->s_daxdev;
> +	if (IS_DAX(inode))
> +		iomap->dax_dev = sbi->s_daxdev;
> +	else
> +		iomap->bdev = inode->i_sb->s_bdev;
>  
>  	if (ret == 0) {
>  		iomap->type = IOMAP_HOLE;
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 2ea07efbe016..79027e99118f 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -3524,8 +3524,10 @@ static int ext4_iomap_begin(struct inode *inode, loff_t offset, loff_t length,
>  	iomap->flags = 0;
>  	if (ext4_inode_datasync_dirty(inode))
>  		iomap->flags |= IOMAP_F_DIRTY;
> -	iomap->bdev = inode->i_sb->s_bdev;
> -	iomap->dax_dev = sbi->s_daxdev;
> +	if (IS_DAX(inode))
> +		iomap->dax_dev = sbi->s_daxdev;
> +	else
> +		iomap->bdev = inode->i_sb->s_bdev;
>  	iomap->offset = (u64)first_block << blkbits;
>  	iomap->length = (u64)map.m_len << blkbits;
>  
> diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
> index c6ce6f9335b6..c9c3d0df5e4c 100644
> --- a/fs/xfs/xfs_iomap.c
> +++ b/fs/xfs/xfs_iomap.c
> @@ -70,8 +70,10 @@ xfs_bmbt_to_iomap(
>  	}
>  	iomap->offset = XFS_FSB_TO_B(mp, imap->br_startoff);
>  	iomap->length = XFS_FSB_TO_B(mp, imap->br_blockcount);
> -	iomap->bdev = xfs_find_bdev_for_inode(VFS_I(ip));
> -	iomap->dax_dev = xfs_find_daxdev_for_inode(VFS_I(ip));
> +	if (IS_DAX(VFS_I(ip)))
> +		iomap->dax_dev = xfs_find_daxdev_for_inode(VFS_I(ip));
> +	else
> +		iomap->bdev = xfs_find_bdev_for_inode(VFS_I(ip));
>  }
>  
>  xfs_extlen_t
> diff --git a/include/linux/iomap.h b/include/linux/iomap.h
> index a044a824da85..212f4d59bcbf 100644
> --- a/include/linux/iomap.h
> +++ b/include/linux/iomap.h
> @@ -53,8 +53,10 @@ struct iomap {
>  	u64			length;	/* length of mapping, bytes */
>  	u16			type;	/* type of mapping */
>  	u16			flags;	/* flags for mapping */
> -	struct block_device	*bdev;	/* block device for I/O */
> -	struct dax_device	*dax_dev; /* dax_dev for dax operations */
> +	union {
> +		struct block_device *bdev;
> +		struct dax_device   *dax_dev;

Is this going to blow up iomap_dax_zero?  It seems to use both bdev and
dax_dev on __dax_zero_page_range, which definitely uses both.

(Or did all that get rearranged when I wasn't looking?)

Also, I guess this will break iomap swapfiles since it checks
iomap->bdev which we stop supplying with this patch...
though I have no idea if DAX swapfiles are even supported.

What's the harm in supplying both pointers?

--D

> +	};
>  };
>  
>  /*
> -- 
> 2.17.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html