From: kernel test robot <lkp@intel.com>
To: fdmanana@kernel.org, linux-btrfs@vger.kernel.org
Cc: oe-kbuild-all@lists.linux.dev
Subject: Re: [PATCH 2/2] btrfs: fix memory barrier order in reloc_root_is_dead()
Date: Fri, 12 Jun 2026 22:45:13 +0200 [thread overview]
Message-ID: <202606122213.j2TtzMBn-lkp@intel.com> (raw)
In-Reply-To: <62602395bf1488aa81645ea59e22405d6c06d3f7.1781263239.git.fdmanana@suse.com>
Hi Filipe,
kernel test robot noticed the following build errors:
[auto build test ERROR on kdave/for-next]
[also build test ERROR on linus/master v7.1-rc7 next-20260612]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/fdmanana-kernel-org/btrfs-fix-reloc-root-cleanup-in-merge_reloc_roots/20260612-202603
base: https://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-next
patch link: https://lore.kernel.org/r/62602395bf1488aa81645ea59e22405d6c06d3f7.1781263239.git.fdmanana%40suse.com
patch subject: [PATCH 2/2] btrfs: fix memory barrier order in reloc_root_is_dead()
config: x86_64-rhel-9.4 (https://download.01.org/0day-ci/archive/20260612/202606122213.j2TtzMBn-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260612/202606122213.j2TtzMBn-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>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606122213.j2TtzMBn-lkp@intel.com/
All errors (new ones prefixed by >>):
fs/btrfs/relocation.c: In function 'merge_reloc_roots':
>> fs/btrfs/relocation.c:1928:41: error: implicit declaration of function 'clear_reloc_root'; did you mean 'create_reloc_root'? [-Wimplicit-function-declaration]
1928 | clear_reloc_root(root);
| ^~~~~~~~~~~~~~~~
| create_reloc_root
vim +1928 fs/btrfs/relocation.c
1867
1868 static noinline_for_stack
1869 void merge_reloc_roots(struct reloc_control *rc)
1870 {
1871 struct btrfs_fs_info *fs_info = rc->extent_root->fs_info;
1872 struct btrfs_root *root;
1873 struct btrfs_root *reloc_root;
1874 LIST_HEAD(reloc_roots);
1875 bool found = false;
1876 int ret = 0;
1877 again:
1878 root = rc->extent_root;
1879
1880 /*
1881 * this serializes us with btrfs_record_root_in_transaction,
1882 * we have to make sure nobody is in the middle of
1883 * adding their roots to the list while we are
1884 * doing this splice
1885 */
1886 mutex_lock(&fs_info->reloc_mutex);
1887 list_splice_init(&rc->reloc_roots, &reloc_roots);
1888 mutex_unlock(&fs_info->reloc_mutex);
1889
1890 while (!list_empty(&reloc_roots)) {
1891 found = true;
1892 reloc_root = list_first_entry(&reloc_roots, struct btrfs_root, root_list);
1893
1894 root = btrfs_get_fs_root(fs_info, reloc_root->root_key.offset,
1895 false);
1896 if (btrfs_root_refs(&reloc_root->root_item) > 0) {
1897 if (WARN_ON(IS_ERR(root))) {
1898 /*
1899 * For recovery we read the fs roots on mount,
1900 * and if we didn't find the root then we marked
1901 * the reloc root as a garbage root. For normal
1902 * relocation obviously the root should exist in
1903 * memory. However there's no reason we can't
1904 * handle the error properly here just in case.
1905 */
1906 ret = PTR_ERR(root);
1907 goto out;
1908 }
1909 if (WARN_ON(root->reloc_root != reloc_root)) {
1910 /*
1911 * This can happen if on-disk metadata has some
1912 * corruption, e.g. bad reloc tree key offset.
1913 */
1914 ret = -EINVAL;
1915 goto out;
1916 }
1917 ret = merge_reloc_root(rc, root);
1918 btrfs_put_root(root);
1919 if (ret) {
1920 if (list_empty(&reloc_root->root_list))
1921 list_add_tail(&reloc_root->root_list,
1922 &reloc_roots);
1923 goto out;
1924 }
1925 } else {
1926 if (!IS_ERR(root)) {
1927 if (root->reloc_root == reloc_root) {
> 1928 clear_reloc_root(root);
1929 /* Drop the ref for root->reloc_root. */
1930 btrfs_put_root(reloc_root);
1931 }
1932 btrfs_put_root(root);
1933 }
1934
1935 list_del_init(&reloc_root->root_list);
1936 /* Don't forget to queue this reloc root for cleanup */
1937 list_add_tail(&reloc_root->reloc_dirty_list,
1938 &rc->dirty_subvol_roots);
1939 }
1940 }
1941
1942 if (found) {
1943 found = false;
1944 goto again;
1945 }
1946 out:
1947 if (ret) {
1948 btrfs_handle_fs_error(fs_info, ret, NULL);
1949 free_reloc_roots(&reloc_roots);
1950
1951 /* new reloc root may be added */
1952 mutex_lock(&fs_info->reloc_mutex);
1953 list_splice_init(&rc->reloc_roots, &reloc_roots);
1954 mutex_unlock(&fs_info->reloc_mutex);
1955 free_reloc_roots(&reloc_roots);
1956 }
1957
1958 /*
1959 * We used to have
1960 *
1961 * BUG_ON(!RB_EMPTY_ROOT(&rc->reloc_root_tree.rb_root));
1962 *
1963 * here, but it's wrong. If we fail to start the transaction in
1964 * prepare_to_merge() we will have only 0 ref reloc roots, none of which
1965 * have actually been removed from the reloc_root_tree rb tree. This is
1966 * fine because we're bailing here, and we hold a reference on the root
1967 * for the list that holds it, so these roots will be cleaned up when we
1968 * do the reloc_dirty_list afterwards. Meanwhile the root->reloc_root
1969 * will be cleaned up on unmount.
1970 *
1971 * The remaining nodes will be cleaned up by put_reloc_control().
1972 */
1973 }
1974
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
next prev parent reply other threads:[~2026-06-12 20:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-12 12:13 [PATCH 0/2] btrfs: fix incorrect barrier usage in relocation fdmanana
2026-06-12 12:13 ` [PATCH 1/2] btrfs: fix reloc root cleanup in merge_reloc_roots() fdmanana
2026-06-12 12:13 ` [PATCH 2/2] btrfs: fix memory barrier order in reloc_root_is_dead() fdmanana
2026-06-12 19:13 ` kernel test robot
2026-06-12 19:24 ` Filipe Manana
2026-06-12 20:45 ` kernel test robot [this message]
2026-06-12 17:28 ` [PATCH 0/2] btrfs: fix incorrect barrier usage in relocation Boris Burkov
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=202606122213.j2TtzMBn-lkp@intel.com \
--to=lkp@intel.com \
--cc=fdmanana@kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=oe-kbuild-all@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.