Linux EXT4 FS development
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: Jan Kara <jack@suse.cz>
Cc: oe-kbuild-all@lists.linux.dev, linux-ext4@vger.kernel.org,
	"Theodore Ts'o" <tytso@mit.edu>
Subject: [tytso-ext4:dev 54/56] fs/ext4/inode.c:3711:29: warning: unused variable 'bpg'
Date: Fri, 07 Aug 2026 03:38:26 +0800	[thread overview]
Message-ID: <202608070336.Nq0yndDZ-lkp@intel.com> (raw)

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git dev
head:   d77b9f1b037ed1e9102d7b200bfc90f74e1c84bf
commit: 0db01f3b86bb23f9bc7a757e3a850963c615887e [54/56] ext4: teach ext4_meta_trans_blocks() about number of allocated extents
config: powerpc-allmodconfig (https://download.01.org/0day-ci/archive/20260807/202608070336.Nq0yndDZ-lkp@intel.com/config)
compiler: powerpc64-linux-gcc (GCC) 16.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260807/202608070336.Nq0yndDZ-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/202608070336.Nq0yndDZ-lkp@intel.com/

All warnings (new ones prefixed by >>):

   fs/ext4/inode.c: In function 'ext4_iomap_alloc':
>> fs/ext4/inode.c:3711:29: warning: unused variable 'bpg' [-Wunused-variable]
    3711 |                         int bpg = EXT4_BLOCKS_PER_GROUP(inode->i_sb);
         |                             ^~~


vim +/bpg +3711 fs/ext4/inode.c

  3680	
  3681	static int ext4_iomap_alloc(struct inode *inode, struct ext4_map_blocks *map,
  3682				    unsigned int flags)
  3683	{
  3684		handle_t *handle;
  3685		int ret, dio_credits, m_flags = 0, retries = 0;
  3686		bool force_commit = false;
  3687	
  3688		if (flags & IOMAP_NOWAIT)
  3689			return -EAGAIN;
  3690	
  3691		/*
  3692		 * Trim the mapping request to the maximum value that we can map at
  3693		 * once for direct I/O.
  3694		 */
  3695		if (map->m_len > DIO_MAX_BLOCKS)
  3696			map->m_len = DIO_MAX_BLOCKS;
  3697	
  3698		/*
  3699		 * journal credits estimation for atomic writes. We call
  3700		 * ext4_map_blocks(), to find if there could be a mixed mapping. If yes,
  3701		 * then let's assume the no. of pextents required can be m_len i.e.
  3702		 * every alternate block can be unwritten and hole.
  3703		 */
  3704		if (flags & IOMAP_ATOMIC) {
  3705			unsigned int orig_mlen = map->m_len;
  3706	
  3707			ret = ext4_map_blocks(NULL, inode, map, 0);
  3708			if (ret < 0)
  3709				return ret;
  3710			if (map->m_len < orig_mlen) {
> 3711				int bpg = EXT4_BLOCKS_PER_GROUP(inode->i_sb);
  3712	
  3713				map->m_len = orig_mlen;
  3714				dio_credits = ext4_meta_trans_blocks(inode, map->m_len,
  3715								     map->m_len, 0);
  3716			} else {
  3717				dio_credits = ext4_chunk_trans_blocks(inode,
  3718								      map->m_len);
  3719			}
  3720		} else {
  3721			dio_credits = ext4_chunk_trans_blocks(inode, map->m_len);
  3722		}
  3723	
  3724	retry:
  3725		/*
  3726		 * Either we allocate blocks and then don't get an unwritten extent, so
  3727		 * in that case we have reserved enough credits. Or, the blocks are
  3728		 * already allocated and unwritten. In that case, the extent conversion
  3729		 * fits into the credits as well.
  3730		 */
  3731		handle = ext4_journal_start(inode, EXT4_HT_MAP_BLOCKS, dio_credits);
  3732		if (IS_ERR(handle))
  3733			return PTR_ERR(handle);
  3734	
  3735		/*
  3736		 * DAX and direct I/O are the only two operations that are currently
  3737		 * supported with IOMAP_WRITE.
  3738		 */
  3739		WARN_ON(!(flags & (IOMAP_DAX | IOMAP_DIRECT)));
  3740		if (flags & IOMAP_DAX)
  3741			m_flags = EXT4_GET_BLOCKS_CREATE_ZERO;
  3742		/*
  3743		 * We use i_size instead of i_disksize here because delalloc writeback
  3744		 * can complete at any point during the I/O and subsequently push the
  3745		 * i_disksize out to i_size. This could be beyond where direct I/O is
  3746		 * happening and thus expose allocated blocks to direct I/O reads.
  3747		 */
  3748		else if (EXT4_LBLK_TO_B(inode, map->m_lblk) >= i_size_read(inode))
  3749			m_flags = EXT4_GET_BLOCKS_CREATE;
  3750		else if (ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS))
  3751			m_flags = EXT4_GET_BLOCKS_CREATE_UNWRIT_EXT;
  3752	
  3753		if (flags & IOMAP_ATOMIC)
  3754			ret = ext4_map_blocks_atomic_write(handle, inode, map, m_flags,
  3755							   &force_commit);
  3756		else
  3757			ret = ext4_map_blocks(handle, inode, map, m_flags);
  3758	
  3759		/*
  3760		 * We cannot fill holes in indirect tree based inodes as that could
  3761		 * expose stale data in the case of a crash. Use the magic error code
  3762		 * to fallback to buffered I/O.
  3763		 */
  3764		if (!m_flags && !ret)
  3765			ret = -ENOTBLK;
  3766	
  3767		ext4_journal_stop(handle);
  3768		if (ret == -ENOSPC && ext4_should_retry_alloc(inode->i_sb, &retries))
  3769			goto retry;
  3770	
  3771		/*
  3772		 * Force commit the current transaction if the allocation spans a mixed
  3773		 * mapping range. This ensures any pending metadata updates (like
  3774		 * unwritten to written extents conversion) in this range are in
  3775		 * consistent state with the file data blocks, before performing the
  3776		 * actual write I/O. If the commit fails, the whole I/O must be aborted
  3777		 * to prevent any possible torn writes.
  3778		 */
  3779		if (ret > 0 && force_commit) {
  3780			int ret2;
  3781	
  3782			ret2 = ext4_force_commit(inode->i_sb);
  3783			if (ret2)
  3784				return ret2;
  3785		}
  3786	
  3787		return ret;
  3788	}
  3789	

--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

                 reply	other threads:[~2026-08-06 19:39 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=202608070336.Nq0yndDZ-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=oe-kbuild-all@lists.linux.dev \
    --cc=tytso@mit.edu \
    /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