All of lore.kernel.org
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: Boris Burkov <boris@bur.io>,
	linux-btrfs@vger.kernel.org, kernel-team@fb.com
Cc: oe-kbuild-all@lists.linux.dev
Subject: Re: [PATCH v2 2/3] btrfs: unit tests for pending extent walking functions
Date: Sun, 25 Jan 2026 13:56:06 +0800	[thread overview]
Message-ID: <202601251336.2XHEOqJO-lkp@intel.com> (raw)
In-Reply-To: <efc4b5a3fbcbc7473afc228badd3e1306298bf33.1769290938.git.boris@bur.io>

Hi Boris,

kernel test robot noticed the following build warnings:

[auto build test WARNING on kdave/for-next]
[also build test WARNING on linus/master v6.19-rc6 next-20260123]
[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/Boris-Burkov/btrfs-fix-EEXIST-abort-due-to-non-consecutive-gaps-in-chunk-allocation/20260125-054609
base:   https://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-next
patch link:    https://lore.kernel.org/r/efc4b5a3fbcbc7473afc228badd3e1306298bf33.1769290938.git.boris%40bur.io
patch subject: [PATCH v2 2/3] btrfs: unit tests for pending extent walking functions
config: arm-randconfig-r072-20260125 (https://download.01.org/0day-ci/archive/20260125/202601251336.2XHEOqJO-lkp@intel.com/config)
compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project 9b8addffa70cee5b2acc5454712d9cf78ce45710)
smatch version: v0.5.0-8994-gd50c5a4c
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260125/202601251336.2XHEOqJO-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/202601251336.2XHEOqJO-lkp@intel.com/

All warnings (new ones prefixed by >>):

>> fs/btrfs/volumes.c:1529:6: warning: no previous prototype for function 'btrfs_first_pending_extent' [-Wmissing-prototypes]
    1529 | bool btrfs_first_pending_extent(struct btrfs_device *device, u64 start, u64 len,
         |      ^
   fs/btrfs/volumes.c:1529:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
    1529 | bool btrfs_first_pending_extent(struct btrfs_device *device, u64 start, u64 len,
         | ^
         | static 
>> fs/btrfs/volumes.c:1570:6: warning: no previous prototype for function 'btrfs_find_hole_in_pending_extents' [-Wmissing-prototypes]
    1570 | bool btrfs_find_hole_in_pending_extents(struct btrfs_device *device, u64 *start, u64 *len,
         |      ^
   fs/btrfs/volumes.c:1570:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
    1570 | bool btrfs_find_hole_in_pending_extents(struct btrfs_device *device, u64 *start, u64 *len,
         | ^
         | static 
   2 warnings generated.


vim +/btrfs_first_pending_extent +1529 fs/btrfs/volumes.c

  1510	
  1511	/*
  1512	 * Find the first pending extent intersecting a range.
  1513	 *
  1514	 * @device: the device to search
  1515	 * @start: start of the range to check
  1516	 * @len: length of the range to check
  1517	 * @pending_start: output pointer for the start of the found pending extent
  1518	 * @pending_end: output pointer for the end of the found pending extent (inclusive)
  1519	 *
  1520	 * Search for a pending chunk allocation that intersects the half-open range
  1521	 * [start, start + len).
  1522	 *
  1523	 * Return: true if a pending extent was found, false otherwise.
  1524	 * If the return value is true, store the first pending extent in
  1525	 * [*pending_start, *pending_end]. Otherwise, the two output variables
  1526	 * may still be modified, to something outside the range and should not
  1527	 * be used.
  1528	 */
> 1529	bool btrfs_first_pending_extent(struct btrfs_device *device, u64 start, u64 len,
  1530					u64 *pending_start, u64 *pending_end)
  1531	{
  1532		lockdep_assert_held(&device->fs_info->chunk_mutex);
  1533	
  1534		if (btrfs_find_first_extent_bit(&device->alloc_state, start,
  1535						pending_start, pending_end,
  1536						CHUNK_ALLOCATED, NULL)) {
  1537	
  1538			if (in_range(*pending_start, start, len) ||
  1539			    in_range(start, *pending_start,
  1540				     *pending_end + 1 - *pending_start)) {
  1541				return true;
  1542			}
  1543		}
  1544		return false;
  1545	}
  1546	
  1547	/*
  1548	 * Find the first real hole accounting for pending extents.
  1549	 *
  1550	 * @device: the device containing the candidate hole
  1551	 * @start: input/output pointer for the hole start position
  1552	 * @len: input/output pointer for the hole length
  1553	 * @min_hole_size: the size of hole we are looking for
  1554	 *
  1555	 * Given a potential hole specified by [*start, *start + *len), check for pending
  1556	 * chunk allocations within that range. If pending extents are found, the hole is
  1557	 * adjusted to represent the first true free space that is large enough when
  1558	 * accounting for pending chunks.
  1559	 *
  1560	 * Note that this function must handle various cases involving non
  1561	 * consecutive pending extents.
  1562	 *
  1563	 * Returns: true if a suitable hole was found and false otherwise.
  1564	 * If the return value is true, then *start and *len are set to represent the hole.
  1565	 * If the return value is false, then *start is set to the largest hole we
  1566	 * found and *len is set to its length.
  1567	 * If there are no holes at all, then *start is set to the end of the range and
  1568	 * *len is set to 0.
  1569	 */
> 1570	bool btrfs_find_hole_in_pending_extents(struct btrfs_device *device, u64 *start, u64 *len,
  1571						u64 min_hole_size)
  1572	{
  1573		u64 pending_start, pending_end;
  1574		u64 end;
  1575		u64 max_hole_start = 0;
  1576		u64 max_hole_len = 0;
  1577	
  1578		lockdep_assert_held(&device->fs_info->chunk_mutex);
  1579	
  1580		if (*len == 0)
  1581			return false;
  1582	
  1583		end = *start + *len - 1;
  1584	
  1585		/*
  1586		 * Loop until we either see a large enough hole or check every pending
  1587		 * extent overlapping the candidate hole.
  1588		 * At every hole that we observe, record it if it is the new max.
  1589		 * At the end of the iteration, set the output variables to the max hole.
  1590		 */
  1591		while (true) {
  1592			if (btrfs_first_pending_extent(device, *start, *len, &pending_start, &pending_end)) {
  1593				/*
  1594				 * Case 1: the pending extent overlaps the start of
  1595				 * candidate hole. That means the true hole is after the
  1596				 * pending extent, but we need to find the next pending
  1597				 * extent to properly size the hole. In the next loop,
  1598				 * we will reduce to case 2 or 3.
  1599				 * e.g.,
  1600				 *   |----pending A----|    real hole     |----pending B----|
  1601				 *            |           candidate hole        |
  1602				 *         *start                              end
  1603				 */
  1604				if (pending_start <= *start) {
  1605					*start = pending_end + 1;
  1606					goto next;
  1607				}
  1608				/*
  1609				 * Case 2: The pending extent starts after *start (and overlaps
  1610				 * [*start, end), so the first hole just goes up to the start
  1611				 * of the pending extent.
  1612				 * e.g.,
  1613				 *   |    real hole    |----pending A----|
  1614				 *   |       candidate hole     |
  1615				 * *start                      end
  1616				 *
  1617				 */
  1618				*len = pending_start - *start;
  1619				if (*len > max_hole_len) {
  1620					max_hole_start = *start;
  1621					max_hole_len = *len;
  1622				}
  1623				if (*len >= min_hole_size)
  1624					break;
  1625				/*
  1626				 * If the hole wasn't big enough, then we advance past
  1627				 * the pending extent and keep looking.
  1628				 */
  1629				*start = pending_end + 1;
  1630				goto next;
  1631			} else {
  1632				/*
  1633				 * Case 3: There is no pending extent overlapping the
  1634				 * range [*start, *start + *len - 1], so the only remaining
  1635				 * hole is the remaining range.
  1636				 * e.g.,
  1637				 *   |       candidate hole           |
  1638				 *   |          real hole             |
  1639				 * *start                            end
  1640				 */
  1641	
  1642				if (*len > max_hole_len) {
  1643					max_hole_start = *start;
  1644					max_hole_len = *len;
  1645				}
  1646				break;
  1647			}
  1648	next:
  1649			if (*start > end)
  1650				break;
  1651			*len = end - *start + 1;
  1652		}
  1653		if (max_hole_len) {
  1654			*start = max_hole_start;
  1655			*len = max_hole_len;
  1656		} else {
  1657			*start = end + 1;
  1658			*len = 0;
  1659		}
  1660		return max_hole_len >= min_hole_size;
  1661	}
  1662	

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

  parent reply	other threads:[~2026-01-25  5:56 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-24 21:43 [PATCH v2 0/3] pending chunk allocation EEXIST fix Boris Burkov
2026-01-24 21:43 ` [PATCH v2 1/3] btrfs: fix EEXIST abort due to non-consecutive gaps in chunk allocation Boris Burkov
2026-01-24 21:43 ` [PATCH v2 2/3] btrfs: unit tests for pending extent walking functions Boris Burkov
2026-01-25  4:09   ` kernel test robot
2026-01-25  5:33   ` kernel test robot
2026-01-25  5:56   ` kernel test robot [this message]
2026-01-25 15:31   ` kernel test robot
2026-01-24 21:43 ` [PATCH v2 3/3] btrfs: forward declare btrfs_fs_info in volumes.h 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=202601251336.2XHEOqJO-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=boris@bur.io \
    --cc=kernel-team@fb.com \
    --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.