Re: linux-next: build failure after merge of the vfs tree
From: Carlos Maiolino
Date: Fri Jan 10 2020 - 06:04:02 EST
On Fri, Jan 10, 2020 at 05:57:29PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the vfs tree, today's linux-next build (x86_64 allnoconfig)
> failed like this:
>
> fs/inode.c:1615:5: error: redefinition of 'bmap'
> 1615 | int bmap(struct inode *inode, sector_t *block)
> | ^~~~
> In file included from fs/inode.c:7:
> include/linux/fs.h:2867:19: note: previous definition of 'bmap' was here
> 2867 | static inline int bmap(struct inode *inode, sector_t *block)
> | ^~~~
>
Oh, no, that's not the same issue I thought, and the patch applied does have the
dummy function.
/me grabs more coffee...
> ---
> fs/inode.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/fs/inode.c b/fs/inode.c
> index 9f894b25af2b..590f36daa006 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -1598,6 +1598,7 @@ void iput(struct inode *inode)
> }
> EXPORT_SYMBOL(iput);
>
> +#ifdef CONFIG_BLOCK
> /**
> * bmap - find a block number in a file
> * @inode: inode owning the block number being requested
> @@ -1621,6 +1622,7 @@ int bmap(struct inode *inode, sector_t *block)
> return 0;
> }
> EXPORT_SYMBOL(bmap);
> +#endif
Eitherway, I am not 100% sure this is the right fix for this case, I remember
some bmap() users who didn't need CONFIG_BLOCK, so we may still need to export
it without CONFIG_BLOCK.
Can you please send me your configuration?
Thanks.
>
> /*
> * With relative atime, only update atime if the previous atime is
> --
> 2.24.0
>
> --
> Cheers,
> Stephen Rothwell
--
Carlos