public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Boris Burkov <boris@bur.io>
To: kernel test robot <lkp@intel.com>
Cc: Mark Harmstone <mark@harmstone.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: Fri, 31 Oct 2025 15:12:28 -0700	[thread overview]
Message-ID: <aQU0TJLSbEXcSX1s@devvm12410.ftw0.facebook.com> (raw)
In-Reply-To: <202510272322.N1S5rdDc-lkp@intel.com>

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.

> 
> 
> 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-31 22:12 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 [this message]
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=aQU0TJLSbEXcSX1s@devvm12410.ftw0.facebook.com \
    --to=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