All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Theodore Ts'o <tytso@mit.edu>, Arnd Bergmann <arnd@arndb.de>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	Matthew Wilcox <mawilcox@microsoft.com>,
	linux-kernel@vger.kernel.org, linux-nvdimm@lists.01.org,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	linux-fsdevel@vger.kernel.org, Jan Kara <jack@suse.cz>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-ext4@vger.kernel.org, Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH] dax: fix build warnings with FS_DAX and !FS_IOMAP
Date: Wed, 11 Jan 2017 09:15:23 +0100	[thread overview]
Message-ID: <20170111081523.GA16116@quack2.suse.cz> (raw)
In-Reply-To: <1484087383-29478-1-git-send-email-ross.zwisler@linux.intel.com>

On Tue 10-01-17 15:29:43, Ross Zwisler wrote:
> As reported by Arnd:
> 
> https://lkml.org/lkml/2017/1/10/756
> 
> Compiling with the following configuration:
> 
>   # CONFIG_EXT2_FS is not set
>   # CONFIG_EXT4_FS is not set
>   # CONFIG_XFS_FS is not set
>   # CONFIG_FS_IOMAP depends on the above filesystems, as is not set
>   CONFIG_FS_DAX=y
> 
> generates build warnings about unused functions in fs/dax.c:
> 
> fs/dax.c:878:12: warning: ‘dax_insert_mapping’ defined but not used [-Wunused-function]
>  static int dax_insert_mapping(struct address_space *mapping,
>             ^~~~~~~~~~~~~~~~~~
> fs/dax.c:572:12: warning: ‘copy_user_dax’ defined but not used [-Wunused-function]
>  static int copy_user_dax(struct block_device *bdev, sector_t sector, size_t size,
>             ^~~~~~~~~~~~~
> fs/dax.c:542:12: warning: ‘dax_load_hole’ defined but not used [-Wunused-function]
>  static int dax_load_hole(struct address_space *mapping, void **entry,
>             ^~~~~~~~~~~~~
> fs/dax.c:312:14: warning: ‘grab_mapping_entry’ defined but not used [-Wunused-function]
>  static void *grab_mapping_entry(struct address_space *mapping, pgoff_t index,
>               ^~~~~~~~~~~~~~~~~~
> 
> Now that the struct buffer_head based DAX fault paths and I/O path have
> been removed we really depend on iomap support being present for DAX.  Make
> this explicit by selecting FS_IOMAP if we compile in DAX support.
> 
> This allows us to remove conditional selections of FS_IOMAP when FS_DAX was
> present for ext2 and ext4, and to remove an #ifdef in fs/dax.c.
> 
> Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Jan Kara <jack@suse.cz>
> Cc: Christoph Hellwig <hch@lst.de>

Looks good. I agree that DAX without FS_IOMAP does not make sense. You can
add:

Reviewed-by: Jan Kara <jack@suse.cz>

								Honza
> ---
>  fs/Kconfig      | 1 +
>  fs/dax.c        | 2 --
>  fs/ext2/Kconfig | 1 -
>  fs/ext4/Kconfig | 1 -
>  4 files changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/fs/Kconfig b/fs/Kconfig
> index c2a377c..83eab52 100644
> --- a/fs/Kconfig
> +++ b/fs/Kconfig
> @@ -38,6 +38,7 @@ config FS_DAX
>  	bool "Direct Access (DAX) support"
>  	depends on MMU
>  	depends on !(ARM || MIPS || SPARC)
> +	select FS_IOMAP
>  	help
>  	  Direct Access (DAX) can be used on memory-backed block devices.
>  	  If the block device supports DAX and the filesystem supports DAX,
> diff --git a/fs/dax.c b/fs/dax.c
> index 5c74f60..083b950 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -969,7 +969,6 @@ int __dax_zero_page_range(struct block_device *bdev, sector_t sector,
>  }
>  EXPORT_SYMBOL_GPL(__dax_zero_page_range);
>  
> -#ifdef CONFIG_FS_IOMAP
>  static sector_t dax_iomap_sector(struct iomap *iomap, loff_t pos)
>  {
>  	return iomap->blkno + (((pos & PAGE_MASK) - iomap->offset) >> 9);
> @@ -1407,4 +1406,3 @@ int dax_iomap_pmd_fault(struct vm_area_struct *vma, unsigned long address,
>  }
>  EXPORT_SYMBOL_GPL(dax_iomap_pmd_fault);
>  #endif /* CONFIG_FS_DAX_PMD */
> -#endif /* CONFIG_FS_IOMAP */
> diff --git a/fs/ext2/Kconfig b/fs/ext2/Kconfig
> index 36bea5a..c634874e 100644
> --- a/fs/ext2/Kconfig
> +++ b/fs/ext2/Kconfig
> @@ -1,6 +1,5 @@
>  config EXT2_FS
>  	tristate "Second extended fs support"
> -	select FS_IOMAP if FS_DAX
>  	help
>  	  Ext2 is a standard Linux file system for hard disks.
>  
> diff --git a/fs/ext4/Kconfig b/fs/ext4/Kconfig
> index 7b90691..e38039f 100644
> --- a/fs/ext4/Kconfig
> +++ b/fs/ext4/Kconfig
> @@ -37,7 +37,6 @@ config EXT4_FS
>  	select CRC16
>  	select CRYPTO
>  	select CRYPTO_CRC32C
> -	select FS_IOMAP if FS_DAX
>  	help
>  	  This is the next generation of the ext3 filesystem.
>  
> -- 
> 2.7.4
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

WARNING: multiple messages have this Message-ID (diff)
From: Jan Kara <jack@suse.cz>
To: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	"Theodore Ts'o" <tytso@mit.edu>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Christoph Hellwig <hch@lst.de>,
	Dan Williams <dan.j.williams@intel.com>, Jan Kara <jack@suse.cz>,
	Matthew Wilcox <mawilcox@microsoft.com>,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-nvdimm@ml01.01.org, Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH] dax: fix build warnings with FS_DAX and !FS_IOMAP
Date: Wed, 11 Jan 2017 09:15:23 +0100	[thread overview]
Message-ID: <20170111081523.GA16116@quack2.suse.cz> (raw)
In-Reply-To: <1484087383-29478-1-git-send-email-ross.zwisler@linux.intel.com>

On Tue 10-01-17 15:29:43, Ross Zwisler wrote:
> As reported by Arnd:
> 
> https://lkml.org/lkml/2017/1/10/756
> 
> Compiling with the following configuration:
> 
>   # CONFIG_EXT2_FS is not set
>   # CONFIG_EXT4_FS is not set
>   # CONFIG_XFS_FS is not set
>   # CONFIG_FS_IOMAP depends on the above filesystems, as is not set
>   CONFIG_FS_DAX=y
> 
> generates build warnings about unused functions in fs/dax.c:
> 
> fs/dax.c:878:12: warning: ‘dax_insert_mapping’ defined but not used [-Wunused-function]
>  static int dax_insert_mapping(struct address_space *mapping,
>             ^~~~~~~~~~~~~~~~~~
> fs/dax.c:572:12: warning: ‘copy_user_dax’ defined but not used [-Wunused-function]
>  static int copy_user_dax(struct block_device *bdev, sector_t sector, size_t size,
>             ^~~~~~~~~~~~~
> fs/dax.c:542:12: warning: ‘dax_load_hole’ defined but not used [-Wunused-function]
>  static int dax_load_hole(struct address_space *mapping, void **entry,
>             ^~~~~~~~~~~~~
> fs/dax.c:312:14: warning: ‘grab_mapping_entry’ defined but not used [-Wunused-function]
>  static void *grab_mapping_entry(struct address_space *mapping, pgoff_t index,
>               ^~~~~~~~~~~~~~~~~~
> 
> Now that the struct buffer_head based DAX fault paths and I/O path have
> been removed we really depend on iomap support being present for DAX.  Make
> this explicit by selecting FS_IOMAP if we compile in DAX support.
> 
> This allows us to remove conditional selections of FS_IOMAP when FS_DAX was
> present for ext2 and ext4, and to remove an #ifdef in fs/dax.c.
> 
> Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Jan Kara <jack@suse.cz>
> Cc: Christoph Hellwig <hch@lst.de>

Looks good. I agree that DAX without FS_IOMAP does not make sense. You can
add:

Reviewed-by: Jan Kara <jack@suse.cz>

								Honza
> ---
>  fs/Kconfig      | 1 +
>  fs/dax.c        | 2 --
>  fs/ext2/Kconfig | 1 -
>  fs/ext4/Kconfig | 1 -
>  4 files changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/fs/Kconfig b/fs/Kconfig
> index c2a377c..83eab52 100644
> --- a/fs/Kconfig
> +++ b/fs/Kconfig
> @@ -38,6 +38,7 @@ config FS_DAX
>  	bool "Direct Access (DAX) support"
>  	depends on MMU
>  	depends on !(ARM || MIPS || SPARC)
> +	select FS_IOMAP
>  	help
>  	  Direct Access (DAX) can be used on memory-backed block devices.
>  	  If the block device supports DAX and the filesystem supports DAX,
> diff --git a/fs/dax.c b/fs/dax.c
> index 5c74f60..083b950 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -969,7 +969,6 @@ int __dax_zero_page_range(struct block_device *bdev, sector_t sector,
>  }
>  EXPORT_SYMBOL_GPL(__dax_zero_page_range);
>  
> -#ifdef CONFIG_FS_IOMAP
>  static sector_t dax_iomap_sector(struct iomap *iomap, loff_t pos)
>  {
>  	return iomap->blkno + (((pos & PAGE_MASK) - iomap->offset) >> 9);
> @@ -1407,4 +1406,3 @@ int dax_iomap_pmd_fault(struct vm_area_struct *vma, unsigned long address,
>  }
>  EXPORT_SYMBOL_GPL(dax_iomap_pmd_fault);
>  #endif /* CONFIG_FS_DAX_PMD */
> -#endif /* CONFIG_FS_IOMAP */
> diff --git a/fs/ext2/Kconfig b/fs/ext2/Kconfig
> index 36bea5a..c634874e 100644
> --- a/fs/ext2/Kconfig
> +++ b/fs/ext2/Kconfig
> @@ -1,6 +1,5 @@
>  config EXT2_FS
>  	tristate "Second extended fs support"
> -	select FS_IOMAP if FS_DAX
>  	help
>  	  Ext2 is a standard Linux file system for hard disks.
>  
> diff --git a/fs/ext4/Kconfig b/fs/ext4/Kconfig
> index 7b90691..e38039f 100644
> --- a/fs/ext4/Kconfig
> +++ b/fs/ext4/Kconfig
> @@ -37,7 +37,6 @@ config EXT4_FS
>  	select CRC16
>  	select CRYPTO
>  	select CRYPTO_CRC32C
> -	select FS_IOMAP if FS_DAX
>  	help
>  	  This is the next generation of the ext3 filesystem.
>  
> -- 
> 2.7.4
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

WARNING: multiple messages have this Message-ID (diff)
From: Jan Kara <jack@suse.cz>
To: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	Theodore Ts'o <tytso@mit.edu>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Christoph Hellwig <hch@lst.de>,
	Dan Williams <dan.j.williams@intel.com>, Jan Kara <jack@suse.cz>,
	Matthew Wilcox <mawilcox@microsoft.com>,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-nvdimm@lists.01.org, Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH] dax: fix build warnings with FS_DAX and !FS_IOMAP
Date: Wed, 11 Jan 2017 09:15:23 +0100	[thread overview]
Message-ID: <20170111081523.GA16116@quack2.suse.cz> (raw)
In-Reply-To: <1484087383-29478-1-git-send-email-ross.zwisler@linux.intel.com>

On Tue 10-01-17 15:29:43, Ross Zwisler wrote:
> As reported by Arnd:
> 
> https://lkml.org/lkml/2017/1/10/756
> 
> Compiling with the following configuration:
> 
>   # CONFIG_EXT2_FS is not set
>   # CONFIG_EXT4_FS is not set
>   # CONFIG_XFS_FS is not set
>   # CONFIG_FS_IOMAP depends on the above filesystems, as is not set
>   CONFIG_FS_DAX=y
> 
> generates build warnings about unused functions in fs/dax.c:
> 
> fs/dax.c:878:12: warning: ‘dax_insert_mapping’ defined but not used [-Wunused-function]
>  static int dax_insert_mapping(struct address_space *mapping,
>             ^~~~~~~~~~~~~~~~~~
> fs/dax.c:572:12: warning: ‘copy_user_dax’ defined but not used [-Wunused-function]
>  static int copy_user_dax(struct block_device *bdev, sector_t sector, size_t size,
>             ^~~~~~~~~~~~~
> fs/dax.c:542:12: warning: ‘dax_load_hole’ defined but not used [-Wunused-function]
>  static int dax_load_hole(struct address_space *mapping, void **entry,
>             ^~~~~~~~~~~~~
> fs/dax.c:312:14: warning: ‘grab_mapping_entry’ defined but not used [-Wunused-function]
>  static void *grab_mapping_entry(struct address_space *mapping, pgoff_t index,
>               ^~~~~~~~~~~~~~~~~~
> 
> Now that the struct buffer_head based DAX fault paths and I/O path have
> been removed we really depend on iomap support being present for DAX.  Make
> this explicit by selecting FS_IOMAP if we compile in DAX support.
> 
> This allows us to remove conditional selections of FS_IOMAP when FS_DAX was
> present for ext2 and ext4, and to remove an #ifdef in fs/dax.c.
> 
> Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Jan Kara <jack@suse.cz>
> Cc: Christoph Hellwig <hch@lst.de>

Looks good. I agree that DAX without FS_IOMAP does not make sense. You can
add:

Reviewed-by: Jan Kara <jack@suse.cz>

								Honza
> ---
>  fs/Kconfig      | 1 +
>  fs/dax.c        | 2 --
>  fs/ext2/Kconfig | 1 -
>  fs/ext4/Kconfig | 1 -
>  4 files changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/fs/Kconfig b/fs/Kconfig
> index c2a377c..83eab52 100644
> --- a/fs/Kconfig
> +++ b/fs/Kconfig
> @@ -38,6 +38,7 @@ config FS_DAX
>  	bool "Direct Access (DAX) support"
>  	depends on MMU
>  	depends on !(ARM || MIPS || SPARC)
> +	select FS_IOMAP
>  	help
>  	  Direct Access (DAX) can be used on memory-backed block devices.
>  	  If the block device supports DAX and the filesystem supports DAX,
> diff --git a/fs/dax.c b/fs/dax.c
> index 5c74f60..083b950 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -969,7 +969,6 @@ int __dax_zero_page_range(struct block_device *bdev, sector_t sector,
>  }
>  EXPORT_SYMBOL_GPL(__dax_zero_page_range);
>  
> -#ifdef CONFIG_FS_IOMAP
>  static sector_t dax_iomap_sector(struct iomap *iomap, loff_t pos)
>  {
>  	return iomap->blkno + (((pos & PAGE_MASK) - iomap->offset) >> 9);
> @@ -1407,4 +1406,3 @@ int dax_iomap_pmd_fault(struct vm_area_struct *vma, unsigned long address,
>  }
>  EXPORT_SYMBOL_GPL(dax_iomap_pmd_fault);
>  #endif /* CONFIG_FS_DAX_PMD */
> -#endif /* CONFIG_FS_IOMAP */
> diff --git a/fs/ext2/Kconfig b/fs/ext2/Kconfig
> index 36bea5a..c634874e 100644
> --- a/fs/ext2/Kconfig
> +++ b/fs/ext2/Kconfig
> @@ -1,6 +1,5 @@
>  config EXT2_FS
>  	tristate "Second extended fs support"
> -	select FS_IOMAP if FS_DAX
>  	help
>  	  Ext2 is a standard Linux file system for hard disks.
>  
> diff --git a/fs/ext4/Kconfig b/fs/ext4/Kconfig
> index 7b90691..e38039f 100644
> --- a/fs/ext4/Kconfig
> +++ b/fs/ext4/Kconfig
> @@ -37,7 +37,6 @@ config EXT4_FS
>  	select CRC16
>  	select CRYPTO
>  	select CRYPTO_CRC32C
> -	select FS_IOMAP if FS_DAX
>  	help
>  	  This is the next generation of the ext3 filesystem.
>  
> -- 
> 2.7.4
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

WARNING: multiple messages have this Message-ID (diff)
From: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
To: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: Theodore Ts'o <tytso-3s7WtUTddSA@public.gmane.org>,
	Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
	"Darrick J. Wong"
	<darrick.wong-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>,
	Matthew Wilcox <mawilcox-0li6OtcxBFHby3iVrkZq2A@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org,
	Andreas Dilger
	<adilger.kernel-m1MBpc4rdrD3fQ9qLvQP4Q@public.gmane.org>,
	Alexander Viro
	<viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
	linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>,
	Andrew Morton
	<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
Subject: Re: [PATCH] dax: fix build warnings with FS_DAX and !FS_IOMAP
Date: Wed, 11 Jan 2017 09:15:23 +0100	[thread overview]
Message-ID: <20170111081523.GA16116@quack2.suse.cz> (raw)
In-Reply-To: <1484087383-29478-1-git-send-email-ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>

On Tue 10-01-17 15:29:43, Ross Zwisler wrote:
> As reported by Arnd:
> 
> https://lkml.org/lkml/2017/1/10/756
> 
> Compiling with the following configuration:
> 
>   # CONFIG_EXT2_FS is not set
>   # CONFIG_EXT4_FS is not set
>   # CONFIG_XFS_FS is not set
>   # CONFIG_FS_IOMAP depends on the above filesystems, as is not set
>   CONFIG_FS_DAX=y
> 
> generates build warnings about unused functions in fs/dax.c:
> 
> fs/dax.c:878:12: warning: ‘dax_insert_mapping’ defined but not used [-Wunused-function]
>  static int dax_insert_mapping(struct address_space *mapping,
>             ^~~~~~~~~~~~~~~~~~
> fs/dax.c:572:12: warning: ‘copy_user_dax’ defined but not used [-Wunused-function]
>  static int copy_user_dax(struct block_device *bdev, sector_t sector, size_t size,
>             ^~~~~~~~~~~~~
> fs/dax.c:542:12: warning: ‘dax_load_hole’ defined but not used [-Wunused-function]
>  static int dax_load_hole(struct address_space *mapping, void **entry,
>             ^~~~~~~~~~~~~
> fs/dax.c:312:14: warning: ‘grab_mapping_entry’ defined but not used [-Wunused-function]
>  static void *grab_mapping_entry(struct address_space *mapping, pgoff_t index,
>               ^~~~~~~~~~~~~~~~~~
> 
> Now that the struct buffer_head based DAX fault paths and I/O path have
> been removed we really depend on iomap support being present for DAX.  Make
> this explicit by selecting FS_IOMAP if we compile in DAX support.
> 
> This allows us to remove conditional selections of FS_IOMAP when FS_DAX was
> present for ext2 and ext4, and to remove an #ifdef in fs/dax.c.
> 
> Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Jan Kara <jack@suse.cz>
> Cc: Christoph Hellwig <hch@lst.de>

Looks good. I agree that DAX without FS_IOMAP does not make sense. You can
add:

Reviewed-by: Jan Kara <jack@suse.cz>

								Honza
> ---
>  fs/Kconfig      | 1 +
>  fs/dax.c        | 2 --
>  fs/ext2/Kconfig | 1 -
>  fs/ext4/Kconfig | 1 -
>  4 files changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/fs/Kconfig b/fs/Kconfig
> index c2a377c..83eab52 100644
> --- a/fs/Kconfig
> +++ b/fs/Kconfig
> @@ -38,6 +38,7 @@ config FS_DAX
>  	bool "Direct Access (DAX) support"
>  	depends on MMU
>  	depends on !(ARM || MIPS || SPARC)
> +	select FS_IOMAP
>  	help
>  	  Direct Access (DAX) can be used on memory-backed block devices.
>  	  If the block device supports DAX and the filesystem supports DAX,
> diff --git a/fs/dax.c b/fs/dax.c
> index 5c74f60..083b950 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -969,7 +969,6 @@ int __dax_zero_page_range(struct block_device *bdev, sector_t sector,
>  }
>  EXPORT_SYMBOL_GPL(__dax_zero_page_range);
>  
> -#ifdef CONFIG_FS_IOMAP
>  static sector_t dax_iomap_sector(struct iomap *iomap, loff_t pos)
>  {
>  	return iomap->blkno + (((pos & PAGE_MASK) - iomap->offset) >> 9);
> @@ -1407,4 +1406,3 @@ int dax_iomap_pmd_fault(struct vm_area_struct *vma, unsigned long address,
>  }
>  EXPORT_SYMBOL_GPL(dax_iomap_pmd_fault);
>  #endif /* CONFIG_FS_DAX_PMD */
> -#endif /* CONFIG_FS_IOMAP */
> diff --git a/fs/ext2/Kconfig b/fs/ext2/Kconfig
> index 36bea5a..c634874e 100644
> --- a/fs/ext2/Kconfig
> +++ b/fs/ext2/Kconfig
> @@ -1,6 +1,5 @@
>  config EXT2_FS
>  	tristate "Second extended fs support"
> -	select FS_IOMAP if FS_DAX
>  	help
>  	  Ext2 is a standard Linux file system for hard disks.
>  
> diff --git a/fs/ext4/Kconfig b/fs/ext4/Kconfig
> index 7b90691..e38039f 100644
> --- a/fs/ext4/Kconfig
> +++ b/fs/ext4/Kconfig
> @@ -37,7 +37,6 @@ config EXT4_FS
>  	select CRC16
>  	select CRYPTO
>  	select CRYPTO_CRC32C
> -	select FS_IOMAP if FS_DAX
>  	help
>  	  This is the next generation of the ext3 filesystem.
>  
> -- 
> 2.7.4
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

  reply	other threads:[~2017-01-11  8:15 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-28 21:12 [PATCH] dax: try to avoid unused function warnings Arnd Bergmann
2016-11-28 21:24 ` Ross Zwisler
2016-11-28 22:13   ` Dan Williams
2016-11-28 22:51     ` Ross Zwisler
2016-11-28 23:08       ` Dan Williams
2016-11-29  2:10         ` Dave Chinner
2017-01-10 16:15   ` Arnd Bergmann
2017-01-10 19:44     ` Ross Zwisler
2017-01-10 22:29     ` [PATCH] dax: fix build warnings with FS_DAX and !FS_IOMAP Ross Zwisler
2017-01-10 22:29       ` Ross Zwisler
2017-01-10 22:29       ` Ross Zwisler
2017-01-10 22:29       ` Ross Zwisler
2017-01-11  8:15       ` Jan Kara [this message]
2017-01-11  8:15         ` Jan Kara
2017-01-11  8:15         ` Jan Kara
2017-01-11  8:15         ` Jan Kara
2017-01-11  9:02       ` Christoph Hellwig
2017-01-11  9:02         ` Christoph Hellwig
2017-01-11  9:02         ` Christoph Hellwig

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=20170111081523.GA16116@quack2.suse.cz \
    --to=jack@suse.cz \
    --cc=adilger.kernel@dilger.ca \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=darrick.wong@oracle.com \
    --cc=hch@lst.de \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=mawilcox@microsoft.com \
    --cc=ross.zwisler@linux.intel.com \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    /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.