On Thu, Oct 26, 2023 at 6:15 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > On Thu, Oct 26, 2023 at 5:37 PM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > > > On Thu, Oct 26, 2023, at 15:49, kernel test robot wrote: > > > tree: > > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git > > > master > > > head: 2ef7141596eed0b4b45ef18b3626f428a6b0a822 > > > commit: dfaf653dc41557548b2e75e6cd837071f7c63289 [14416/15220] > > > exportfs: make ->encode_fh() a mandatory method for NFS export > > > config: hexagon-randconfig-r015-20211224 > > > (https://download.01.org/0day-ci/archive/20231026/202310262151.renqMvme-lkp@xxxxxxxxx/config) > > > compiler: clang version 16.0.4 > > > (https://github.com/llvm/llvm-project.git > > > ae42196bc493ffe877a7e3dff8be32035dea4d07) > > > reproduce (this is a W=1 build): > > > (https://download.01.org/0day-ci/archive/20231026/202310262151.renqMvme-lkp@xxxxxxxxx/reproduce) > > > > > > If you fix the issue in a separate patch/commit (i.e. not just a new > > > version of > > > the same patch/commit), kindly add following tags > > > | Reported-by: kernel test robot <lkp@xxxxxxxxx> > > > | Closes: > > > https://lore.kernel.org/oe-kbuild-all/202310262151.renqMvme-lkp@xxxxxxxxx/ > > > > > > All errors (new ones prefixed by >>): > > > > > >>> fs/exportfs/expfs.c:357:5: error: expected identifier or '(' > > > int generic_encode_ino32_fh(struct inode *inode, __u32 *fh, int > > > *max_len, > > > ^ > > > include/linux/exportfs.h:286:33: note: expanded from macro > > > > This bit is trivially fixed by allowing the protoype to > > be visible for CONFIG_EXPORTFS=m > > > > --- a/include/linux/exportfs.h > > +++ b/include/linux/exportfs.h > > @@ -314,7 +314,7 @@ extern struct dentry *exportfs_decode_fh(struct vfsmount *mnt, struct fid *fid, > > /* > > * Generic helpers for filesystems. > > */ > > -#ifdef CONFIG_EXPORTFS > > +#if IS_ENABLED(CONFIG_EXPORTFS) > > int generic_encode_ino32_fh(struct inode *inode, __u32 *fh, int *max_len, > > struct inode *parent); > > #else > > > > but then we instead get link failures when the callers are > > built-in: > > > > x86_64-linux-ld: fs/ext4/super.o:(.rodata+0x11a0): undefined reference to `generic_encode_ino32_fh' > > x86_64-linux-ld: fs/ext2/super.o:(.rodata+0x3a0): undefined reference to `generic_encode_ino32_fh' > > x86_64-linux-ld: fs/fat/nfs.o:(.rodata+0x120): undefined reference to `generic_encode_ino32_fh' > > x86_64-linux-ld: fs/ntfs3/super.o:(.rodata+0x2a0): undefined reference to `generic_encode_ino32_fh' > > x86_64-linux-ld: fs/befs/linuxvfs.o:(.rodata+0x240): undefined reference to `generic_encode_ino32_fh' > > > > Could this function just be move to fs/libfs.c or similar? > > It could, but it is quite annoying to have to build the function when no code > should be calling it. > > IMO, it would be better to make CONFIG_EXPORTFS a bool. > fs/exportfs/expfs.c is quite small and CONFIG_EXPORTFS=m > doesn't seem to be worthwhile. Forget it. I missed the fact that the problem is that none of the filesystem properly select EXPORTFS. I will see if I want to fix that or give up and move the helper to fs/libfs.c. Thanks, Amir.
