From: Dan Carpenter <dan.carpenter@linaro.org>
To: oe-kbuild@lists.linux.dev, Mingzhe Zou <mingzhe.zou@easystack.cn>,
colyli@suse.de, linux-bcache@vger.kernel.org
Cc: lkp@intel.com, oe-kbuild-all@lists.linux.dev,
bcache@lists.ewheeler.net, zoumingzhe@qq.com
Subject: Re: [PATCH v3] bcache: Separate bch_moving_gc() from bch_btree_gc()
Date: Mon, 17 Jul 2023 08:59:03 +0300 [thread overview]
Message-ID: <83e846fd-a4e5-4b89-8a22-ec4189335379@kadam.mountain> (raw)
In-Reply-To: <20230629114740.311-1-mingzhe.zou@easystack.cn>
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@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce: (https://download.01.org/0day-ci/archive/20230716/202307160359.0vHG3r40-lkp@intel.com/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@intel.com>
| Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
| Closes: https://lore.kernel.org/r/202307160359.0vHG3r40-lkp@intel.com/
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
prev parent reply other threads:[~2023-07-17 5:59 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-29 11:47 [PATCH v3] bcache: Separate bch_moving_gc() from bch_btree_gc() Mingzhe Zou
2023-07-17 5:59 ` Dan Carpenter [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83e846fd-a4e5-4b89-8a22-ec4189335379@kadam.mountain \
--to=dan.carpenter@linaro.org \
--cc=bcache@lists.ewheeler.net \
--cc=colyli@suse.de \
--cc=linux-bcache@vger.kernel.org \
--cc=lkp@intel.com \
--cc=mingzhe.zou@easystack.cn \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=oe-kbuild@lists.linux.dev \
--cc=zoumingzhe@qq.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).