From: Mark Harmstone <mark@harmstone.com>
To: Boris Burkov <boris@bur.io>, kernel test robot <lkp@intel.com>
Cc: linux-btrfs@vger.kernel.org, oe-kbuild-all@lists.linux.dev
Subject: Re: [PATCH v4 15/16] btrfs: handle discarding fully-remapped block groups
Date: Mon, 3 Nov 2025 16:49:26 +0000 [thread overview]
Message-ID: <475df362-2bf8-4cfd-b85d-df4579ddc8d3@harmstone.com> (raw)
In-Reply-To: <aQU0TJLSbEXcSX1s@devvm12410.ftw0.facebook.com>
On 31/10/2025 10.12 pm, Boris Burkov wrote:
> On Tue, Oct 28, 2025 at 12:04:11AM +0800, kernel test robot wrote:
>> Hi Mark,
>>
>> kernel test robot noticed the following build warnings:
>>
>> [auto build test WARNING on kdave/for-next]
>> [also build test WARNING on next-20251027]
>> [cannot apply to linus/master v6.18-rc3]
>> [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/Mark-Harmstone/btrfs-add-definitions-and-constants-for-remap-tree/20251025-021910
>> base: https://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-next
>> patch link: https://lore.kernel.org/r/20251024181227.32228-16-mark%40harmstone.com
>> patch subject: [PATCH v4 15/16] btrfs: handle discarding fully-remapped block groups
>> config: arm-randconfig-003-20251027 (https://download.01.org/0day-ci/archive/20251027/202510272322.N1S5rdDc-lkp@intel.com/config)
>> compiler: arm-linux-gnueabi-gcc (GCC) 8.5.0
>> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251027/202510272322.N1S5rdDc-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/202510272322.N1S5rdDc-lkp@intel.com/
>>
>> Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
>> http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
>>
>> All warnings (new ones prefixed by >>):
>>
>> fs/btrfs/discard.c: In function 'btrfs_discard_workfn':
>>>> fs/btrfs/discard.c:596:6: warning: 'discard_state' may be used uninitialized in this function [-Wmaybe-uninitialized]
>> if (discard_state == BTRFS_DISCARD_BITMAPS ||
>> ^
>
> I think this gets set by peek_discard_list() so I don't think this is
> a valid warning.
You are correct. discard_state gets initialized if the return value of
peek_discard_list() is not NULL, and if it is NULL we return before we
use it.
This is an ancient version of GCC, the warning doesn't trigger on GCC 15
- presumably it has better control flow analysis. I don't think the
robot should be compiling with this warning turned on for old compiler
versions, if it's prone to false positives.
>>
>>
>> vim +/discard_state +596 fs/btrfs/discard.c
>>
>> 513
>> 514 /*
>> 515 * Discard work queue callback
>> 516 *
>> 517 * @work: work
>> 518 *
>> 519 * Find the next block_group to start discarding and then discard a single
>> 520 * region. It does this in a two-pass fashion: first extents and second
>> 521 * bitmaps. Completely discarded block groups are sent to the unused_bgs path.
>> 522 */
>> 523 static void btrfs_discard_workfn(struct work_struct *work)
>> 524 {
>> 525 struct btrfs_discard_ctl *discard_ctl;
>> 526 struct btrfs_block_group *block_group;
>> 527 enum btrfs_discard_state discard_state;
>> 528 int discard_index = 0;
>> 529 u64 trimmed = 0;
>> 530 u64 minlen = 0;
>> 531 u64 now = ktime_get_ns();
>> 532
>> 533 discard_ctl = container_of(work, struct btrfs_discard_ctl, work.work);
>> 534
>> 535 block_group = peek_discard_list(discard_ctl, &discard_state,
>> 536 &discard_index, now);
>> 537 if (!block_group)
>> 538 return;
>> 539 if (!btrfs_run_discard_work(discard_ctl)) {
>> 540 spin_lock(&discard_ctl->lock);
>> 541 btrfs_put_block_group(block_group);
>> 542 discard_ctl->block_group = NULL;
>> 543 spin_unlock(&discard_ctl->lock);
>> 544 return;
>> 545 }
>> 546 if (now < block_group->discard_eligible_time) {
>> 547 spin_lock(&discard_ctl->lock);
>> 548 btrfs_put_block_group(block_group);
>> 549 discard_ctl->block_group = NULL;
>> 550 spin_unlock(&discard_ctl->lock);
>> 551 btrfs_discard_schedule_work(discard_ctl, false);
>> 552 return;
>> 553 }
>> 554
>> 555 /* Perform discarding */
>> 556 minlen = discard_minlen[discard_index];
>> 557
>> 558 switch (discard_state) {
>> 559 case BTRFS_DISCARD_BITMAPS: {
>> 560 u64 maxlen = 0;
>> 561
>> 562 /*
>> 563 * Use the previous levels minimum discard length as the max
>> 564 * length filter. In the case something is added to make a
>> 565 * region go beyond the max filter, the entire bitmap is set
>> 566 * back to BTRFS_TRIM_STATE_UNTRIMMED.
>> 567 */
>> 568 if (discard_index != BTRFS_DISCARD_INDEX_UNUSED)
>> 569 maxlen = discard_minlen[discard_index - 1];
>> 570
>> 571 btrfs_trim_block_group_bitmaps(block_group, &trimmed,
>> 572 block_group->discard_cursor,
>> 573 btrfs_block_group_end(block_group),
>> 574 minlen, maxlen, true);
>> 575 discard_ctl->discard_bitmap_bytes += trimmed;
>> 576
>> 577 break;
>> 578 }
>> 579
>> 580 case BTRFS_DISCARD_FULLY_REMAPPED:
>> 581 btrfs_trim_fully_remapped_block_group(block_group);
>> 582 break;
>> 583
>> 584 default:
>> 585 btrfs_trim_block_group_extents(block_group, &trimmed,
>> 586 block_group->discard_cursor,
>> 587 btrfs_block_group_end(block_group),
>> 588 minlen, true);
>> 589 discard_ctl->discard_extent_bytes += trimmed;
>> 590
>> 591 break;
>> 592 }
>> 593
>> 594 /* Determine next steps for a block_group */
>> 595 if (block_group->discard_cursor >= btrfs_block_group_end(block_group)) {
>> > 596 if (discard_state == BTRFS_DISCARD_BITMAPS ||
>> 597 discard_state == BTRFS_DISCARD_FULLY_REMAPPED) {
>> 598 btrfs_finish_discard_pass(discard_ctl, block_group);
>> 599 } else {
>> 600 block_group->discard_cursor = block_group->start;
>> 601 spin_lock(&discard_ctl->lock);
>> 602 if (block_group->discard_state !=
>> 603 BTRFS_DISCARD_RESET_CURSOR)
>> 604 block_group->discard_state =
>> 605 BTRFS_DISCARD_BITMAPS;
>> 606 spin_unlock(&discard_ctl->lock);
>> 607 }
>> 608 }
>> 609
>> 610 now = ktime_get_ns();
>> 611 spin_lock(&discard_ctl->lock);
>> 612 discard_ctl->prev_discard = trimmed;
>> 613 discard_ctl->prev_discard_time = now;
>> 614 btrfs_put_block_group(block_group);
>> 615 discard_ctl->block_group = NULL;
>> 616 __btrfs_discard_schedule_work(discard_ctl, now, false);
>> 617 spin_unlock(&discard_ctl->lock);
>> 618 }
>> 619
>>
>> --
>> 0-DAY CI Kernel Test Service
>> https://github.com/intel/lkp-tests/wiki
next prev parent reply other threads:[~2025-11-03 16:49 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-24 18:12 [PATCH v4 00/16] Remap tree Mark Harmstone
2025-10-24 18:12 ` [PATCH v4 01/16] btrfs: add definitions and constants for remap-tree Mark Harmstone
2025-10-31 22:50 ` Boris Burkov
2025-11-03 12:18 ` Mark Harmstone
2025-10-24 18:12 ` [PATCH v4 02/16] btrfs: add REMAP chunk type Mark Harmstone
2025-10-24 18:12 ` [PATCH v4 03/16] btrfs: allow remapped chunks to have zero stripes Mark Harmstone
2025-10-31 21:39 ` Boris Burkov
2025-10-24 18:12 ` [PATCH v4 04/16] btrfs: remove remapped block groups from the free-space tree Mark Harmstone
2025-10-31 21:44 ` Boris Burkov
2025-11-03 12:39 ` Mark Harmstone
2025-10-24 18:12 ` [PATCH v4 05/16] btrfs: don't add metadata items for the remap tree to the extent tree Mark Harmstone
2025-10-24 18:12 ` [PATCH v4 06/16] btrfs: add extended version of struct block_group_item Mark Harmstone
2025-10-31 21:47 ` Boris Burkov
2025-10-24 18:12 ` [PATCH v4 07/16] btrfs: allow mounting filesystems with remap-tree incompat flag Mark Harmstone
2025-10-24 18:12 ` [PATCH v4 08/16] btrfs: redirect I/O for remapped block groups Mark Harmstone
2025-10-31 22:03 ` Boris Burkov
2025-10-24 18:12 ` [PATCH v4 09/16] btrfs: handle deletions from remapped block group Mark Harmstone
2025-10-31 23:05 ` Boris Burkov
2025-11-03 15:51 ` Mark Harmstone
2025-10-31 23:30 ` Boris Burkov
2025-11-04 12:30 ` Mark Harmstone
2025-10-24 18:12 ` [PATCH v4 10/16] btrfs: handle setting up relocation of block group with remap-tree Mark Harmstone
2025-10-31 23:43 ` Boris Burkov
2025-11-03 18:45 ` Mark Harmstone
2025-10-24 18:12 ` [PATCH v4 11/16] btrfs: move existing remaps before relocating block group Mark Harmstone
2025-11-01 0:02 ` Boris Burkov
2025-11-04 13:00 ` Mark Harmstone
2025-11-01 0:10 ` Boris Burkov
2025-10-24 18:12 ` [PATCH v4 12/16] btrfs: replace identity remaps with actual remaps when doing relocations Mark Harmstone
2025-11-01 0:09 ` Boris Burkov
2025-11-04 14:31 ` Mark Harmstone
2025-10-24 18:12 ` [PATCH v4 13/16] btrfs: add do_remap param to btrfs_discard_extent() Mark Harmstone
2025-11-01 0:12 ` Boris Burkov
2025-10-24 18:12 ` [PATCH v4 14/16] btrfs: allow balancing remap tree Mark Harmstone
2025-10-24 18:12 ` [PATCH v4 15/16] btrfs: handle discarding fully-remapped block groups Mark Harmstone
2025-10-27 16:04 ` kernel test robot
2025-10-31 22:12 ` Boris Burkov
2025-11-03 16:49 ` Mark Harmstone [this message]
2025-11-09 8:42 ` Philip Li
2025-10-31 22:11 ` Boris Burkov
2025-11-03 17:01 ` Mark Harmstone
2025-10-24 18:12 ` [PATCH v4 16/16] btrfs: add stripe removal pending flag Mark Harmstone
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=475df362-2bf8-4cfd-b85d-df4579ddc8d3@harmstone.com \
--to=mark@harmstone.com \
--cc=boris@bur.io \
--cc=linux-btrfs@vger.kernel.org \
--cc=lkp@intel.com \
--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