Linux Btrfs filesystem development
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox