All of lore.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 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.