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 16:31:40 +0100 [thread overview]
Message-ID: <202601251610.dH67mNZI-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: i386-allnoconfig-bpf (https://download.01.org/0day-ci/archive/20260125/202601251610.dH67mNZI-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260125/202601251610.dH67mNZI-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/202601251610.dH67mNZI-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
next prev parent reply other threads:[~2026-01-25 15:32 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
2026-01-25 15:31 ` kernel test robot [this message]
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=202601251610.dH67mNZI-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox