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 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.