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