lkml.org 
[lkml]   [2021]   [Dec]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subject[goldwynr:iomap 23/33] fs/btrfs/file.c:1704:29: error: 'bi' redeclared as different kind of symbol
tree:   https://github.com/goldwynr/linux iomap
head: 30c74a8c201365178cae26d0d7aefa120c3245ab
commit: 31240db6a699e846f0d73f27d4b32d0e95bb08dc [23/33] btrfs: Set extents delalloc in iomap_end
config: m68k-allmodconfig (https://download.01.org/0day-ci/archive/20211230/202112301347.2emBGOuh-lkp@intel.com/config)
compiler: m68k-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/goldwynr/linux/commit/31240db6a699e846f0d73f27d4b32d0e95bb08dc
git remote add goldwynr https://github.com/goldwynr/linux
git fetch --no-tags goldwynr iomap
git checkout 31240db6a699e846f0d73f27d4b32d0e95bb08dc
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=m68k SHELL=/bin/bash fs/btrfs/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

Note: the goldwynr/iomap HEAD 30c74a8c201365178cae26d0d7aefa120c3245ab builds fine.
It only hurts bisectability.

All errors (new ones prefixed by >>):

fs/btrfs/file.c: In function 'btrfs_buffered_iomap_end':
>> fs/btrfs/file.c:1704:29: error: 'bi' redeclared as different kind of symbol
1704 | struct btrfs_iomap *bi = iomap->private;
| ^~
fs/btrfs/file.c:1701:69: note: previous definition of 'bi' with type 'struct btrfs_iomap *'
1701 | loff_t length, ssize_t written, struct btrfs_iomap *bi)
| ~~~~~~~~~~~~~~~~~~~~^~
>> fs/btrfs/file.c:1704:34: error: 'iomap' undeclared (first use in this function)
1704 | struct btrfs_iomap *bi = iomap->private;
| ^~~~~
fs/btrfs/file.c:1704:34: note: each undeclared identifier is reported only once for each function it appears in


vim +/bi +1704 fs/btrfs/file.c

1699
1700 static int btrfs_buffered_iomap_end(struct inode *inode, loff_t pos,
1701 loff_t length, ssize_t written, struct btrfs_iomap *bi)
1702 {
1703 struct btrfs_fs_info *fs_info = btrfs_sb(inode->i_sb);
> 1704 struct btrfs_iomap *bi = iomap->private;
1705 int ret = 0;
1706 size_t release_bytes = 0;
1707 u64 start = round_down(pos, fs_info->sectorsize);
1708 u64 written_block_end = round_up(pos + written, fs_info->sectorsize) - 1;
1709 u64 block_end = round_up(pos + length, fs_info->sectorsize) - 1;
1710
1711 int extra_bits = 0;
1712
1713 if (written == 0) {
1714 release_bytes = bi->reserved_bytes;
1715 } else if (written < length) {
1716 release_bytes = block_end - written_block_end + 1;
1717 }
1718
1719 if (bi->metadata_only)
1720 extra_bits |= EXTENT_NORESERVE;
1721
1722 clear_extent_bit(&BTRFS_I(inode)->io_tree, start, written_block_end,
1723 EXTENT_DELALLOC | EXTENT_DO_ACCOUNTING | EXTENT_DEFRAG,
1724 0, 0, &bi->cached_state);
1725
1726 ret = btrfs_set_extent_delalloc(BTRFS_I(inode), start,
1727 written_block_end, extra_bits, &bi->cached_state);
1728
1729 /* In case of error, release everything in btrfs_iomap_release() */
1730 if (ret < 0)
1731 release_bytes = bi->reserved_bytes;
1732
1733 /*
1734 * If we have not locked the extent range, because the range's
1735 * start offset is >= i_size, we might still have a non-NULL
1736 * cached extent state, acquired while marking the extent range
1737 * as delalloc. Therefore free any possible cached extent state
1738 * to avoid a memory leak.
1739 */
1740 if (bi->extents_locked)
1741 unlock_extent_cached(&BTRFS_I(inode)->io_tree,
1742 bi->lockstart, bi->lockend,
1743 &bi->cached_state);
1744 else
1745 free_extent_state(bi->cached_state);
1746
1747 btrfs_delalloc_release_extents(BTRFS_I(inode), bi->reserved_bytes);
1748 if (bi->metadata_only)
1749 btrfs_check_nocow_unlock(BTRFS_I(inode));
1750
1751 btrfs_iomap_release(inode, pos, release_bytes, bi);
1752
1753 return 0;
1754 }
1755

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

\
 
 \ /
  Last update: 2021-12-30 06:12    [W:0.088 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site