On Tue, May 9, 2017 at 12:57 AM, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > Hi Dan, > > On Tue, May 9, 2017 at 12:36 AM, kbuild test robot <lkp@xxxxxxxxx> 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.
