[1/2] block, dax: move "select DAX" from BLOCK to FS_DAX
diff mbox

Message ID 149427742346.38205.12361226658239922137.stgit@dwillia2-desk3.amr.corp.intel.com
State New
Headers show

Commit Message

Dan Williams May 8, 2017, 9:03 p.m. UTC
For configurations that do not enable DAX filesystems or drivers, do not
require the DAX core to be built.

The only core block routine that calls a DAX routine is
bdev_dax_supported(), that now fails by default as expected if FS_DAX=n,
or no DAX-capable drivers are configured.

Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
 block/Kconfig       |    1 -
 fs/Kconfig          |    1 +
 include/linux/dax.h |   37 ++++++++++++++++++++++++++++++++++---
 3 files changed, 35 insertions(+), 4 deletions(-)

Comments

kernel test robot May 8, 2017, 10:36 p.m. UTC | #1
Hi Dan,

[auto build test ERROR on linus/master]
[also build test ERROR on next-20170508]
[cannot apply to v4.11]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Dan-Williams/block-dax-move-select-DAX-from-BLOCK-to-FS_DAX/20170509-051522
config: parisc-c3000_defconfig (attached as .config)
compiler: hppa-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
        wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=parisc 

All errors (new ones prefixed by >>):

   fs/built-in.o: In function `bdev_dax_supported':
>> (.text.bdev_dax_supported+0x4c): undefined reference to `dax_get_by_host'
   fs/built-in.o: In function `bdev_dax_supported':
>> (.text.bdev_dax_supported+0x5c): undefined reference to `dax_read_lock'
   fs/built-in.o: In function `bdev_dax_supported':
>> (.text.bdev_dax_supported+0x7c): undefined reference to `dax_direct_access'
   fs/built-in.o: In function `bdev_dax_supported':
>> (.text.bdev_dax_supported+0x88): undefined reference to `dax_read_unlock'
   fs/built-in.o: In function `bdev_dax_supported':
>> (.text.bdev_dax_supported+0x90): undefined reference to `put_dax'

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
Geert Uytterhoeven May 9, 2017, 7:57 a.m. UTC | #2
Hi Dan,

On Tue, May 9, 2017 at 12:36 AM, kbuild test robot <lkp@intel.com> wrote:
> [auto build test ERROR on linus/master]
> [also build test ERROR on next-20170508]
> [cannot apply to v4.11]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url:    https://github.com/0day-ci/linux/commits/Dan-Williams/block-dax-move-select-DAX-from-BLOCK-to-FS_DAX/20170509-051522
> config: parisc-c3000_defconfig (attached as .config)
> compiler: hppa-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
>         wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         # save the attached .config to linux build tree
>         make.cross ARCH=parisc
>
> All errors (new ones prefixed by >>):
>
>    fs/built-in.o: In function `bdev_dax_supported':
>>> (.text.bdev_dax_supported+0x4c): undefined reference to `dax_get_by_host'
>    fs/built-in.o: In function `bdev_dax_supported':
>>> (.text.bdev_dax_supported+0x5c): undefined reference to `dax_read_lock'
>    fs/built-in.o: In function `bdev_dax_supported':
>>> (.text.bdev_dax_supported+0x7c): undefined reference to `dax_direct_access'
>    fs/built-in.o: In function `bdev_dax_supported':
>>> (.text.bdev_dax_supported+0x88): undefined reference to `dax_read_unlock'
>    fs/built-in.o: In function `bdev_dax_supported':
>>> (.text.bdev_dax_supported+0x90): undefined reference to `put_dax'

I ran into the same issue if CONFIG_DAX=m (it's still selected by some other
modular symbol). #if IS_ENABLED(CONFIG_DAX) is true in the modular case, so
the dummies provided by include/linux/dax.h are not used.

However, while changing it to #ifdef CONFIG_DAX allows to build vmlinux, it
leads to other issues as DAX is compiled as a module:

    drivers/dax/super.c:35: error: redefinition of ‘dax_read_lock’
    include/linux/dax.h:30: error: previous definition of
‘dax_read_lock’ was here

Yes, calling into optional modular code from builtin code in fs/blockdev.c is
tricky ;-(  Perhaps you can make bdev_dax_supported() a small wrapper
that calls into the real code through a function pointer, when the DAX module
is available?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
Dan Williams May 9, 2017, 2:11 p.m. UTC | #3
On Tue, May 9, 2017 at 12:57 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Dan,
>
> On Tue, May 9, 2017 at 12:36 AM, kbuild test robot <lkp@intel.com> wrote:
>> [auto build test ERROR on linus/master]
>> [also build test ERROR on next-20170508]
>> [cannot apply to v4.11]
>> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>>
>> url:    https://github.com/0day-ci/linux/commits/Dan-Williams/block-dax-move-select-DAX-from-BLOCK-to-FS_DAX/20170509-051522
>> config: parisc-c3000_defconfig (attached as .config)
>> compiler: hppa-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
>> reproduce:
>>         wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>>         chmod +x ~/bin/make.cross
>>         # save the attached .config to linux build tree
>>         make.cross ARCH=parisc
>>
>> All errors (new ones prefixed by >>):
>>
>>    fs/built-in.o: In function `bdev_dax_supported':
>>>> (.text.bdev_dax_supported+0x4c): undefined reference to `dax_get_by_host'
>>    fs/built-in.o: In function `bdev_dax_supported':
>>>> (.text.bdev_dax_supported+0x5c): undefined reference to `dax_read_lock'
>>    fs/built-in.o: In function `bdev_dax_supported':
>>>> (.text.bdev_dax_supported+0x7c): undefined reference to `dax_direct_access'
>>    fs/built-in.o: In function `bdev_dax_supported':
>>>> (.text.bdev_dax_supported+0x88): undefined reference to `dax_read_unlock'
>>    fs/built-in.o: In function `bdev_dax_supported':
>>>> (.text.bdev_dax_supported+0x90): undefined reference to `put_dax'
>
> I ran into the same issue if CONFIG_DAX=m (it's still selected by some other
> modular symbol). #if IS_ENABLED(CONFIG_DAX) is true in the modular case, so
> the dummies provided by include/linux/dax.h are not used.
>
> However, while changing it to #ifdef CONFIG_DAX allows to build vmlinux, it
> leads to other issues as DAX is compiled as a module:
>
>     drivers/dax/super.c:35: error: redefinition of ‘dax_read_lock’
>     include/linux/dax.h:30: error: previous definition of
> ‘dax_read_lock’ was here
>
> Yes, calling into optional modular code from builtin code in fs/blockdev.c is
> tricky ;-(  Perhaps you can make bdev_dax_supported() a small wrapper
> that calls into the real code through a function pointer, when the DAX module
> is available?

In fact, that is close to what I did for v2, and it passed a full run
through the kbuild robot. I'll send it out shortly.

Patch
diff mbox

diff --git a/block/Kconfig b/block/Kconfig
index 93da7fc3f254..e9f780f815f5 100644
--- a/block/Kconfig
+++ b/block/Kconfig
@@ -6,7 +6,6 @@  menuconfig BLOCK
        default y
        select SBITMAP
        select SRCU
-       select DAX
        help
 	 Provide block layer support for the kernel.
 
diff --git a/fs/Kconfig b/fs/Kconfig
index 83eab52fb3f6..b0e42b6a96b9 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -39,6 +39,7 @@  config FS_DAX
 	depends on MMU
 	depends on !(ARM || MIPS || SPARC)
 	select FS_IOMAP
+	select DAX
 	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/include/linux/dax.h b/include/linux/dax.h
index d3158e74a59e..e3fa0ad5a12d 100644
--- a/include/linux/dax.h
+++ b/include/linux/dax.h
@@ -18,17 +18,48 @@  struct dax_operations {
 			void **, pfn_t *);
 };
 
+#if IS_ENABLED(CONFIG_DAX)
 int dax_read_lock(void);
 void dax_read_unlock(int id);
 struct dax_device *dax_get_by_host(const char *host);
+void put_dax(struct dax_device *dax_dev);
+long dax_direct_access(struct dax_device *dax_dev, pgoff_t pgoff, long nr_pages,
+		void **kaddr, pfn_t *pfn);
+#else
+static inline int dax_read_lock(void)
+{
+	/* all dax operations inside this lock will fail below */
+	return 0;
+}
+
+static inline void dax_read_unlock(int id)
+{
+}
+
+static inline struct dax_device *dax_get_by_host(const char *host)
+{
+	return NULL;
+}
+
+static inline void put_dax(struct dax_device *dax_dev)
+{
+}
+
+static inline long dax_direct_access(struct dax_device *dax_dev, pgoff_t pgoff,
+		long nr_pages, void **kaddr, pfn_t *pfn)
+{
+	/* avoid 'uninitialized variable' warnings for @kaddr and @pfn */
+	*pfn = (pfn_t) { .val = ULLONG_MAX };
+	*kaddr = (void *) ULONG_MAX;
+
+	return -EOPNOTSUPP;
+}
+#endif
 struct dax_device *alloc_dax(void *private, const char *host,
 		const struct dax_operations *ops);
-void put_dax(struct dax_device *dax_dev);
 bool dax_alive(struct dax_device *dax_dev);
 void kill_dax(struct dax_device *dax_dev);
 void *dax_get_private(struct dax_device *dax_dev);
-long dax_direct_access(struct dax_device *dax_dev, pgoff_t pgoff, long nr_pages,
-		void **kaddr, pfn_t *pfn);
 
 /*
  * We use lowest available bit in exceptional entry for locking, one bit for