Re: [linux-next:master 14416/15220] fs/exportfs/expfs.c:357:5: error: expected identifier or '('

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Thanks,
Amir.





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux