| Message ID | 149427742346.38205.12361226658239922137.stgit@dwillia2-desk3.amr.corp.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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
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.
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
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(-)