[PATCH] dm: writecache: add DAX dependency

[PATCH] dm: writecache: add DAX dependency

[Arnd Bergmann]

The new dm-writecache driver inconditionally uses the dax
subsystem, leading to link errors in some configurations:

drivers/md/dm-writecache.o: In function `writecache_ctr':
dm-writecache.c:(.text+0x1fdc): undefined reference to `dax_read_lock'
dm-writecache.c:(.text+0x2004): undefined reference to `dax_direct_access'
dm-writecache.c:(.text+0x21cc): undefined reference to `dax_read_unlock'

It seems wrong to require DAX in order to build the writecache
driver, but that at least avoids randconfig build errors.

Fixes: bb15b431d650 ("dm: add writecache target")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/md/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
index 852c7ebe2902..f8ecf2da1edf 100644
--- a/drivers/md/Kconfig
+++ b/drivers/md/Kconfig
@@ -338,6 +338,7 @@ config DM_CACHE_SMQ
 config DM_WRITECACHE
 	tristate "Writecache target"
 	depends on BLK_DEV_DM
+	depends on DAX
 	---help---
 	   The writecache target caches writes on persistent memory or SSD.
 	   It is intended for databases or other programs that need extremely
-- 
2.9.0

Re: [PATCH] dm: writecache: add DAX dependency

[Dan Williams]

On Mon, May 28, 2018 at 8:38 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The new dm-writecache driver inconditionally uses the dax
> subsystem, leading to link errors in some configurations:
>
> drivers/md/dm-writecache.o: In function `writecache_ctr':
> dm-writecache.c:(.text+0x1fdc): undefined reference to `dax_read_lock'
> dm-writecache.c:(.text+0x2004): undefined reference to `dax_direct_access'
> dm-writecache.c:(.text+0x21cc): undefined reference to `dax_read_unlock'
>
> It seems wrong to require DAX in order to build the writecache
> driver, but that at least avoids randconfig build errors.
>
> Fixes: bb15b431d650 ("dm: add writecache target")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  drivers/md/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
> index 852c7ebe2902..f8ecf2da1edf 100644
> --- a/drivers/md/Kconfig
> +++ b/drivers/md/Kconfig
> @@ -338,6 +338,7 @@ config DM_CACHE_SMQ
>  config DM_WRITECACHE
>         tristate "Writecache target"
>         depends on BLK_DEV_DM
> +       depends on DAX

This should probably be depends on DAX && DAX_DRIVER as we at least
need pmem or dcssblk enabled to provide a dax capable block device for
DM to claim.

Re: dm: writecache: add DAX dependency

[Mike Snitzer]

On Mon, May 28 2018 at  2:18pm -0400,
Dan Williams <dan.j.williams@intel.com> wrote:

> On Mon, May 28, 2018 at 8:38 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > The new dm-writecache driver inconditionally uses the dax
> > subsystem, leading to link errors in some configurations:
> >
> > drivers/md/dm-writecache.o: In function `writecache_ctr':
> > dm-writecache.c:(.text+0x1fdc): undefined reference to `dax_read_lock'
> > dm-writecache.c:(.text+0x2004): undefined reference to `dax_direct_access'
> > dm-writecache.c:(.text+0x21cc): undefined reference to `dax_read_unlock'
> >
> > It seems wrong to require DAX in order to build the writecache
> > driver, but that at least avoids randconfig build errors.
> >
> > Fixes: bb15b431d650 ("dm: add writecache target")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> >  drivers/md/Kconfig | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
> > index 852c7ebe2902..f8ecf2da1edf 100644
> > --- a/drivers/md/Kconfig
> > +++ b/drivers/md/Kconfig
> > @@ -338,6 +338,7 @@ config DM_CACHE_SMQ
> >  config DM_WRITECACHE
> >         tristate "Writecache target"
> >         depends on BLK_DEV_DM
> > +       depends on DAX
> 
> This should probably be depends on DAX && DAX_DRIVER as we at least
> need pmem or dcssblk enabled to provide a dax capable block device for
> DM to claim.

But dm-writecache is meant to be used for normal SSD even if PMEM isn't
available in the kernel.

Re: [PATCH] dm: writecache: add DAX dependency

[Ross Zwisler]

On Mon, May 28, 2018 at 05:38:10PM +0200, Arnd Bergmann wrote:
> The new dm-writecache driver inconditionally uses the dax
			       unconditionally

> subsystem, leading to link errors in some configurations:
> 
> drivers/md/dm-writecache.o: In function `writecache_ctr':
> dm-writecache.c:(.text+0x1fdc): undefined reference to `dax_read_lock'
> dm-writecache.c:(.text+0x2004): undefined reference to `dax_direct_access'
> dm-writecache.c:(.text+0x21cc): undefined reference to `dax_read_unlock'
> 
> It seems wrong to require DAX in order to build the writecache
> driver, but that at least avoids randconfig build errors.
> 
> Fixes: bb15b431d650 ("dm: add writecache target")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  drivers/md/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
> index 852c7ebe2902..f8ecf2da1edf 100644
> --- a/drivers/md/Kconfig
> +++ b/drivers/md/Kconfig
> @@ -338,6 +338,7 @@ config DM_CACHE_SMQ
>  config DM_WRITECACHE
>  	tristate "Writecache target"
>  	depends on BLK_DEV_DM
> +	depends on DAX
>  	---help---
>  	   The writecache target caches writes on persistent memory or SSD.
>  	   It is intended for databases or other programs that need extremely

I think the right way to handle this is to instead wrap all the DAX code in
dm-writecache in "#if IS_ENABLED(CONFIG_DAX_DRIVER)" blocks and provide stubs
for the non-DAX case.  This prevents you from having to pull in all the
generic DAX code unnecessarily.

In looking at the file I think this is just the persistent_memory_claim()
function.

I'll send out a patch once I've tested a bit.

- Ross

[PATCH] dm-writecache: fix compilation issue with !DAX

[Ross Zwisler]

As reported by Arnd (https://lkml.org/lkml/2018/5/28/1697), dm-writecache
will fail with link errors in configs where DAX isn't present:

drivers/md/dm-writecache.o: In function `writecache_ctr':
dm-writecache.c:(.text+0x1fdc): undefined reference to `dax_read_lock'
dm-writecache.c:(.text+0x2004): undefined reference to `dax_direct_access'
dm-writecache.c:(.text+0x21cc): undefined reference to `dax_read_unlock'

Fix this by following the lead of the other DM modules and wrapping calls
to the generic DAX code in #if IS_ENABLED(CONFIG_DAX_DRIVER) blocks.

We also expand the failure case for the 'p' (persistent memory) flag so
that fails on both architectures that don't support persistent memory and
on kernels that don't have DAX support configured.  This prevents us from
ever hitting the BUG() in the persistent_memory_claim() stub.

Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reported-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/md/dm-writecache.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/md/dm-writecache.c b/drivers/md/dm-writecache.c
index 92af65fdf4af..1c2b53ae1a96 100644
--- a/drivers/md/dm-writecache.c
+++ b/drivers/md/dm-writecache.c
@@ -253,6 +253,7 @@ static void wc_unlock(struct dm_writecache *wc)
 	mutex_unlock(&wc->lock);
 }
 
+#if IS_ENABLED(CONFIG_DAX_DRIVER)
 static int persistent_memory_claim(struct dm_writecache *wc)
 {
 	int r;
@@ -337,6 +338,12 @@ static int persistent_memory_claim(struct dm_writecache *wc)
 err1:
 	return r;
 }
+#else
+static int persistent_memory_claim(struct dm_writecache *wc)
+{
+	BUG();
+}
+#endif
 
 static void persistent_memory_release(struct dm_writecache *wc)
 {
@@ -1901,16 +1908,17 @@ static int writecache_ctr(struct dm_target *ti, unsigned argc, char **argv)
 	if (!strcasecmp(string, "s")) {
 		wc->pmem_mode = false;
 	} else if (!strcasecmp(string, "p")) {
-#ifdef CONFIG_ARCH_HAS_PMEM_API
+#if defined(CONFIG_ARCH_HAS_PMEM_API) && IS_ENABLED(CONFIG_DAX_DRIVER)
 		wc->pmem_mode = true;
 		wc->writeback_fua = true;
 #else
 		/*
-		 * If the architecture doesn't support persistent memory, this
-		 * driver can only be used in SSD-only mode.
+		 * If the architecture doesn't support persistent memory or
+		 * the kernel doesn't support any DAX drivers, this driver can
+		 * only be used in SSD-only mode.
 		 */
 		r = -EOPNOTSUPP;
-		ti->error = "Persistent memory not supported on this architecture";
+		ti->error = "Persistent memory or DAX not supported on this system";
 		goto bad;
 #endif
 	} else {
-- 
2.14.3

Re: dm-writecache: fix compilation issue with !DAX

[Mike Snitzer]

On Tue, May 29 2018 at  1:52pm -0400,
Ross Zwisler <ross.zwisler@linux.intel.com> wrote:

> As reported by Arnd (https://lkml.org/lkml/2018/5/28/1697), dm-writecache
> will fail with link errors in configs where DAX isn't present:
> 
> drivers/md/dm-writecache.o: In function `writecache_ctr':
> dm-writecache.c:(.text+0x1fdc): undefined reference to `dax_read_lock'
> dm-writecache.c:(.text+0x2004): undefined reference to `dax_direct_access'
> dm-writecache.c:(.text+0x21cc): undefined reference to `dax_read_unlock'
> 
> Fix this by following the lead of the other DM modules and wrapping calls
> to the generic DAX code in #if IS_ENABLED(CONFIG_DAX_DRIVER) blocks.
> 
> We also expand the failure case for the 'p' (persistent memory) flag so
> that fails on both architectures that don't support persistent memory and
> on kernels that don't have DAX support configured.  This prevents us from
> ever hitting the BUG() in the persistent_memory_claim() stub.
> 
> Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> Reported-by: Arnd Bergmann <arnd@arndb.de>

Thanks, I've picked this up.

Mike

Re: dm-writecache: fix compilation issue with !DAX

[Dan Williams]

On Tue, May 29, 2018 at 11:08 AM, Mike Snitzer <snitzer@redhat.com> wrote:
> On Tue, May 29 2018 at  1:52pm -0400,
> Ross Zwisler <ross.zwisler@linux.intel.com> wrote:
>
>> As reported by Arnd (https://lkml.org/lkml/2018/5/28/1697), dm-writecache
>> will fail with link errors in configs where DAX isn't present:
>>
>> drivers/md/dm-writecache.o: In function `writecache_ctr':
>> dm-writecache.c:(.text+0x1fdc): undefined reference to `dax_read_lock'
>> dm-writecache.c:(.text+0x2004): undefined reference to `dax_direct_access'
>> dm-writecache.c:(.text+0x21cc): undefined reference to `dax_read_unlock'
>>
>> Fix this by following the lead of the other DM modules and wrapping calls
>> to the generic DAX code in #if IS_ENABLED(CONFIG_DAX_DRIVER) blocks.
>>
>> We also expand the failure case for the 'p' (persistent memory) flag so
>> that fails on both architectures that don't support persistent memory and
>> on kernels that don't have DAX support configured.  This prevents us from
>> ever hitting the BUG() in the persistent_memory_claim() stub.
>>
>> Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
>> Reported-by: Arnd Bergmann <arnd@arndb.de>
>
> Thanks, I've picked this up.

...I assume you're also going to let the 'pmem api' discussion resolve
before this all goes upstream?

Re: dm-writecache: fix compilation issue with !DAX

[Mike Snitzer]

On Tue, May 29 2018 at  2:40pm -0400,
Dan Williams <dan.j.williams@intel.com> wrote:

> On Tue, May 29, 2018 at 11:08 AM, Mike Snitzer <snitzer@redhat.com> wrote:
> > On Tue, May 29 2018 at  1:52pm -0400,
> > Ross Zwisler <ross.zwisler@linux.intel.com> wrote:
> >
> >> As reported by Arnd (https://lkml.org/lkml/2018/5/28/1697), dm-writecache
> >> will fail with link errors in configs where DAX isn't present:
> >>
> >> drivers/md/dm-writecache.o: In function `writecache_ctr':
> >> dm-writecache.c:(.text+0x1fdc): undefined reference to `dax_read_lock'
> >> dm-writecache.c:(.text+0x2004): undefined reference to `dax_direct_access'
> >> dm-writecache.c:(.text+0x21cc): undefined reference to `dax_read_unlock'
> >>
> >> Fix this by following the lead of the other DM modules and wrapping calls
> >> to the generic DAX code in #if IS_ENABLED(CONFIG_DAX_DRIVER) blocks.
> >>
> >> We also expand the failure case for the 'p' (persistent memory) flag so
> >> that fails on both architectures that don't support persistent memory and
> >> on kernels that don't have DAX support configured.  This prevents us from
> >> ever hitting the BUG() in the persistent_memory_claim() stub.
> >>
> >> Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> >> Reported-by: Arnd Bergmann <arnd@arndb.de>
> >
> > Thanks, I've picked this up.
> 
> ...I assume you're also going to let the 'pmem api' discussion resolve
> before this all goes upstream?

Yeah, I'm going to pivot back to that and put time to it shortly.  If
dm-writecache has to wait another cycle (so 4.19 inclusion), while
unfortunate, it wouldn't be the end of the world.

I look forward to your continued help, thanks.
Mike

Re: [PATCH] dm: writecache: add DAX dependency

[Mikulas Patocka]

On Mon, 28 May 2018, Arnd Bergmann wrote:

> The new dm-writecache driver inconditionally uses the dax
> subsystem, leading to link errors in some configurations:
> 
> drivers/md/dm-writecache.o: In function `writecache_ctr':
> dm-writecache.c:(.text+0x1fdc): undefined reference to `dax_read_lock'
> dm-writecache.c:(.text+0x2004): undefined reference to `dax_direct_access'
> dm-writecache.c:(.text+0x21cc): undefined reference to `dax_read_unlock'
> 
> It seems wrong to require DAX in order to build the writecache
> driver, but that at least avoids randconfig build errors.
> 
> Fixes: bb15b431d650 ("dm: add writecache target")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  drivers/md/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
> index 852c7ebe2902..f8ecf2da1edf 100644
> --- a/drivers/md/Kconfig
> +++ b/drivers/md/Kconfig
> @@ -338,6 +338,7 @@ config DM_CACHE_SMQ
>  config DM_WRITECACHE
>  	tristate "Writecache target"
>  	depends on BLK_DEV_DM
> +	depends on DAX
>  	---help---
>  	   The writecache target caches writes on persistent memory or SSD.
>  	   It is intended for databases or other programs that need extremely
> -- 
> 2.9.0

dm-writecache may be used without DAX in SSD-only mode.

So, I'd fix this by changing the code in dm-writecache.c to

#if !defined(CONFIG_ARCH_HAS_PMEM_API) || !defined(CONFIG_DAX)
#define DM_WRITECACHE_ONLY_SSD
#endif

Mikulas

Re: [PATCH] dm-writecache: fix compilation issue with !DAX

[Mikulas Patocka]

On Tue, 29 May 2018, Ross Zwisler wrote:

> As reported by Arnd (https://lkml.org/lkml/2018/5/28/1697), dm-writecache
> will fail with link errors in configs where DAX isn't present:
> 
> drivers/md/dm-writecache.o: In function `writecache_ctr':
> dm-writecache.c:(.text+0x1fdc): undefined reference to `dax_read_lock'
> dm-writecache.c:(.text+0x2004): undefined reference to `dax_direct_access'
> dm-writecache.c:(.text+0x21cc): undefined reference to `dax_read_unlock'
> 
> Fix this by following the lead of the other DM modules and wrapping calls
> to the generic DAX code in #if IS_ENABLED(CONFIG_DAX_DRIVER) blocks.
> 
> We also expand the failure case for the 'p' (persistent memory) flag so
> that fails on both architectures that don't support persistent memory and
> on kernels that don't have DAX support configured.  This prevents us from
> ever hitting the BUG() in the persistent_memory_claim() stub.
> 
> Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  drivers/md/dm-writecache.c | 16 ++++++++++++----
>  1 file changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/md/dm-writecache.c b/drivers/md/dm-writecache.c
> index 92af65fdf4af..1c2b53ae1a96 100644
> --- a/drivers/md/dm-writecache.c
> +++ b/drivers/md/dm-writecache.c
> @@ -253,6 +253,7 @@ static void wc_unlock(struct dm_writecache *wc)
>  	mutex_unlock(&wc->lock);
>  }
>  
> +#if IS_ENABLED(CONFIG_DAX_DRIVER)

We already have #if(n)def DM_WRITECACHE_ONLY_SSD

There is no need to use another macro for the same purpose.

Mikulas

>  static int persistent_memory_claim(struct dm_writecache *wc)
>  {
>  	int r;
> @@ -337,6 +338,12 @@ static int persistent_memory_claim(struct dm_writecache *wc)
>  err1:
>  	return r;
>  }
> +#else
> +static int persistent_memory_claim(struct dm_writecache *wc)
> +{
> +	BUG();
> +}
> +#endif
>  
>  static void persistent_memory_release(struct dm_writecache *wc)
>  {
> @@ -1901,16 +1908,17 @@ static int writecache_ctr(struct dm_target *ti, unsigned argc, char **argv)
>  	if (!strcasecmp(string, "s")) {
>  		wc->pmem_mode = false;
>  	} else if (!strcasecmp(string, "p")) {
> -#ifdef CONFIG_ARCH_HAS_PMEM_API
> +#if defined(CONFIG_ARCH_HAS_PMEM_API) && IS_ENABLED(CONFIG_DAX_DRIVER)
>  		wc->pmem_mode = true;
>  		wc->writeback_fua = true;
>  #else
>  		/*
> -		 * If the architecture doesn't support persistent memory, this
> -		 * driver can only be used in SSD-only mode.
> +		 * If the architecture doesn't support persistent memory or
> +		 * the kernel doesn't support any DAX drivers, this driver can
> +		 * only be used in SSD-only mode.
>  		 */
>  		r = -EOPNOTSUPP;
> -		ti->error = "Persistent memory not supported on this architecture";
> +		ti->error = "Persistent memory or DAX not supported on this system";
>  		goto bad;
>  #endif
>  	} else {
> -- 
> 2.14.3
> 

Re: dm-writecache: fix compilation issue with !DAX

[Mike Snitzer]

On Wed, May 30 2018 at  8:22am -0400,
Mikulas Patocka <mpatocka@redhat.com> wrote:

> 
> 
> On Tue, 29 May 2018, Ross Zwisler wrote:
> 
> > As reported by Arnd (https://lkml.org/lkml/2018/5/28/1697), dm-writecache
> > will fail with link errors in configs where DAX isn't present:
> > 
> > drivers/md/dm-writecache.o: In function `writecache_ctr':
> > dm-writecache.c:(.text+0x1fdc): undefined reference to `dax_read_lock'
> > dm-writecache.c:(.text+0x2004): undefined reference to `dax_direct_access'
> > dm-writecache.c:(.text+0x21cc): undefined reference to `dax_read_unlock'
> > 
> > Fix this by following the lead of the other DM modules and wrapping calls
> > to the generic DAX code in #if IS_ENABLED(CONFIG_DAX_DRIVER) blocks.
> > 
> > We also expand the failure case for the 'p' (persistent memory) flag so
> > that fails on both architectures that don't support persistent memory and
> > on kernels that don't have DAX support configured.  This prevents us from
> > ever hitting the BUG() in the persistent_memory_claim() stub.
> > 
> > Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> > Reported-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> >  drivers/md/dm-writecache.c | 16 ++++++++++++----
> >  1 file changed, 12 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/md/dm-writecache.c b/drivers/md/dm-writecache.c
> > index 92af65fdf4af..1c2b53ae1a96 100644
> > --- a/drivers/md/dm-writecache.c
> > +++ b/drivers/md/dm-writecache.c
> > @@ -253,6 +253,7 @@ static void wc_unlock(struct dm_writecache *wc)
> >  	mutex_unlock(&wc->lock);
> >  }
> >  
> > +#if IS_ENABLED(CONFIG_DAX_DRIVER)
> 
> We already have #if(n)def DM_WRITECACHE_ONLY_SSD
> 
> There is no need to use another macro for the same purpose.

I removed DM_WRITECACHE_ONLY_SSD because it wasn't needed, this is the
split out commit that I have since folded in:
https://git.kernel.org/pub/scm/linux/kernel/git/snitzer/linux.git/commit/?h=dm-4.18-writecache-wip&id=e7fd3d1c05659f7e1295178290fbdaebf36becdc

Ross's patch effectively builds ontop of that.

Mike