public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: Mark Harmstone <mark@harmstone.com>, linux-btrfs@vger.kernel.org
Cc: oe-kbuild-all@lists.linux.dev, Mark Harmstone <mark@harmstone.com>
Subject: Re: [PATCH v4 15/16] btrfs: handle discarding fully-remapped block groups
Date: Tue, 28 Oct 2025 00:04:11 +0800	[thread overview]
Message-ID: <202510272322.N1S5rdDc-lkp@intel.com> (raw)
In-Reply-To: <20251024181227.32228-16-mark@harmstone.com>

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


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

  reply	other threads:[~2025-10-27 16:04 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 [this message]
2025-10-31 22:12     ` Boris Burkov
2025-11-03 16:49       ` Mark Harmstone
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=202510272322.N1S5rdDc-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=linux-btrfs@vger.kernel.org \
    --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