public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
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
> 
> 

  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