Re: [PATCH v3] bcache: Separate bch_moving_gc() from bch_btree_gc()

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

 



Hi Mingzhe,

kernel test robot noticed the following build warnings:

https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Mingzhe-Zou/bcache-Separate-bch_moving_gc-from-bch_btree_gc/20230629-194834
base:   linus/master
patch link:    https://lore.kernel.org/r/20230629114740.311-1-mingzhe.zou%40easystack.cn
patch subject: [PATCH v3] bcache: Separate bch_moving_gc() from bch_btree_gc()
config: x86_64-randconfig-m001-20230710 (https://download.01.org/0day-ci/archive/20230716/202307160359.0vHG3r40-lkp@xxxxxxxxx/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce: (https://download.01.org/0day-ci/archive/20230716/202307160359.0vHG3r40-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>
| Reported-by: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
| Closes: https://lore.kernel.org/r/202307160359.0vHG3r40-lkp@xxxxxxxxx/

New smatch warnings:
drivers/md/bcache/btree.c:1887 moving_gc_should_run() error: uninitialized symbol 'used_sectors'.

Old smatch warnings:
drivers/md/bcache/btree.c:1535 btree_gc_rewrite_node() error: 'n' dereferencing possible ERR_PTR()
drivers/md/bcache/btree.c:1551 btree_gc_rewrite_node() error: 'n' dereferencing possible ERR_PTR()

vim +/used_sectors +1887 drivers/md/bcache/btree.c

4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1856  static bool moving_gc_should_run(struct cache_set *c)
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1857  {
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1858  	struct bucket *b;
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1859  	struct cache *ca = c->cache;
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1860  	size_t moving_gc_threshold = ca->sb.bucket_size >> 2, frag_percent;
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1861  	unsigned long used_buckets = 0, frag_buckets = 0, move_buckets = 0;
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1862  	unsigned long dirty_sectors = 0, frag_sectors, used_sectors;
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1863  
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1864  	if (c->gc_stats.in_use > bch_cutoff_writeback_sync)
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1865  		return true;
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1866  
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1867  	mutex_lock(&c->bucket_lock);
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1868  	for_each_bucket(b, ca) {
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1869  		if (GC_MARK(b) != GC_MARK_DIRTY)
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1870  			continue;

Smatch is complaining that we might not enter the loop or there could be
no GC_MARK_DIRTY entries.

4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1871  
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1872  		used_buckets++;
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1873  
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1874  		used_sectors = GC_SECTORS_USED(b);
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1875  		dirty_sectors += used_sectors;
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1876  
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1877  		if (used_sectors < ca->sb.bucket_size)
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1878  			frag_buckets++;
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1879  
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1880  		if (used_sectors <= moving_gc_threshold)
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1881  			move_buckets++;
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1882  	}
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1883  	mutex_unlock(&c->bucket_lock);
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1884  
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1885  	c->fragment_nbuckets = frag_buckets;
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1886  
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29 @1887  	if (used_sectors < c->nbuckets * bch_cutoff_writeback / 100)

It's sort of weird that we are using the used_sectors value from the
last MARK_DIRTY iteration through the loop.  Should it be used_buckets?

4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1888  		return false;
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1889  
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1890  	if (move_buckets > ca->heap.size)
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1891  		return true;
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1892  
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1893  	frag_sectors = used_buckets * ca->sb.bucket_size - dirty_sectors;
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1894  	frag_percent = div_u64(frag_sectors * 100, ca->sb.bucket_size * c->nbuckets);
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1895  
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1896  	if (frag_percent >= COPY_GC_PERCENT)
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1897  		return true;
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1898  
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1899  	if (used_sectors > c->nbuckets * bch_cutoff_writeback_sync / 100)
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1900  		return true;
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1901  
4b0cf76f1e36e7 Mingzhe Zou     2023-06-29  1902  	return false;
cafe563591446c Kent Overstreet 2013-03-23  1903  }

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux ARM Kernel]     [Linux Filesystem Development]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux