From: Philip Li <philip.li@intel.com>
To: Mark Harmstone <mark@harmstone.com>
Cc: Boris Burkov <boris@bur.io>, kernel test robot <lkp@intel.com>,
<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: Sun, 9 Nov 2025 16:42:41 +0800 [thread overview]
Message-ID: <aRBUAUiaObMAS706@rli9-mobl> (raw)
In-Reply-To: <475df362-2bf8-4cfd-b85d-df4579ddc8d3@harmstone.com>
On Mon, Nov 03, 2025 at 04:49:26PM +0000, Mark Harmstone wrote:
> 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.
Thanks for the suggestion, I will update the bot to avoid sending out this
directly. Sorry for the false positive.
>
> > >
> > >
> > > 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-09 8:42 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
2025-11-09 8:42 ` Philip Li [this message]
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=aRBUAUiaObMAS706@rli9-mobl \
--to=philip.li@intel.com \
--cc=boris@bur.io \
--cc=linux-btrfs@vger.kernel.org \
--cc=lkp@intel.com \
--cc=mark@harmstone.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