linux-kernel - Re: [PATCH] fs: ext4: fix uninitialized symbols

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <202510111521.OLlwqh7d-lkp@intel.com>
Date: Sat, 11 Oct 2025 15:48:00 +0800
From: kernel test robot <lkp@...el.com>
To: Ranganath V N <vnranganath.20@...il.com>, tytso@....edu,
	adilger.kernel@...ger.ca
Cc: oe-kbuild-all@...ts.linux.dev, linux-ext4@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	linux-kernel-mentees@...ts.linuxfoundation.org,
	skhan@...uxfoundation.org, david.hunter.linux@...il.com,
	khalid@...nel.org, Ranganath V N <vnranganath.20@...il.com>
Subject: Re: [PATCH] fs: ext4: fix uninitialized symbols

Hi Ranganath,

kernel test robot noticed the following build warnings:

[auto build test WARNING on tytso-ext4/dev]
[also build test WARNING on linus/master v6.17 next-20251010]
[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/Ranganath-V-N/fs-ext4-fix-uninitialized-symbols/20251010-065232
base:   https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git dev
patch link:    https://lore.kernel.org/r/20251008171614.12129-1-vnranganath.20%40gmail.com
patch subject: [PATCH] fs: ext4: fix uninitialized symbols
config: i386-randconfig-063-20251011 (https://download.01.org/0day-ci/archive/20251011/202510111521.OLlwqh7d-lkp@intel.com/config)
compiler: gcc-13 (Debian 13.3.0-16) 13.3.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251011/202510111521.OLlwqh7d-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@...el.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202510111521.OLlwqh7d-lkp@intel.com/

sparse warnings: (new ones prefixed by >>)
>> fs/ext4/inode.c:3547:34: sparse: sparse: incorrect type in initializer (different base types) @@     expected unsigned long long [usertype] next_pblk @@     got void * @@
   fs/ext4/inode.c:3547:34: sparse:     expected unsigned long long [usertype] next_pblk
   fs/ext4/inode.c:3547:34: sparse:     got void *

vim +3547 fs/ext4/inode.c

  3540	
  3541	static int ext4_map_blocks_atomic_write_slow(handle_t *handle,
  3542				struct inode *inode, struct ext4_map_blocks *map)
  3543	{
  3544		ext4_lblk_t m_lblk = map->m_lblk;
  3545		unsigned int m_len = map->m_len;
  3546		unsigned int mapped_len = 0, m_flags = 0;
> 3547		ext4_fsblk_t next_pblk = NULL;
  3548		bool check_next_pblk = false;
  3549		int ret = 0;
  3550	
  3551		WARN_ON_ONCE(!ext4_has_feature_bigalloc(inode->i_sb));
  3552	
  3553		/*
  3554		 * This is a slow path in case of mixed mapping. We use
  3555		 * EXT4_GET_BLOCKS_CREATE_ZERO flag here to make sure we get a single
  3556		 * contiguous mapped mapping. This will ensure any unwritten or hole
  3557		 * regions within the requested range is zeroed out and we return
  3558		 * a single contiguous mapped extent.
  3559		 */
  3560		m_flags = EXT4_GET_BLOCKS_CREATE_ZERO;
  3561	
  3562		do {
  3563			ret = ext4_map_blocks(handle, inode, map, m_flags);
  3564			if (ret < 0 && ret != -ENOSPC)
  3565				goto out_err;
  3566			/*
  3567			 * This should never happen, but let's return an error code to
  3568			 * avoid an infinite loop in here.
  3569			 */
  3570			if (ret == 0) {
  3571				ret = -EFSCORRUPTED;
  3572				ext4_warning_inode(inode,
  3573					"ext4_map_blocks() couldn't allocate blocks m_flags: 0x%x, ret:%d",
  3574					m_flags, ret);
  3575				goto out_err;
  3576			}
  3577			/*
  3578			 * With bigalloc we should never get ENOSPC nor discontiguous
  3579			 * physical extents.
  3580			 */
  3581			if ((check_next_pblk && next_pblk != map->m_pblk) ||
  3582					ret == -ENOSPC) {
  3583				ext4_warning_inode(inode,
  3584					"Non-contiguous allocation detected: expected %llu, got %llu, "
  3585					"or ext4_map_blocks() returned out of space ret: %d",
  3586					next_pblk, map->m_pblk, ret);
  3587				ret = -EFSCORRUPTED;
  3588				goto out_err;
  3589			}
  3590			next_pblk = map->m_pblk + map->m_len;
  3591			check_next_pblk = true;
  3592	
  3593			mapped_len += map->m_len;
  3594			map->m_lblk += map->m_len;
  3595			map->m_len = m_len - mapped_len;
  3596		} while (mapped_len < m_len);
  3597	
  3598		/*
  3599		 * We might have done some work in above loop, so we need to query the
  3600		 * start of the physical extent, based on the origin m_lblk and m_len.
  3601		 * Let's also ensure we were able to allocate the required range for
  3602		 * mixed mapping case.
  3603		 */
  3604		map->m_lblk = m_lblk;
  3605		map->m_len = m_len;
  3606		map->m_flags = 0;
  3607	
  3608		ret = ext4_map_blocks(handle, inode, map,
  3609				      EXT4_GET_BLOCKS_QUERY_LAST_IN_LEAF);
  3610		if (ret != m_len) {
  3611			ext4_warning_inode(inode,
  3612				"allocation failed for atomic write request m_lblk:%u, m_len:%u, ret:%d\n",
  3613				m_lblk, m_len, ret);
  3614			ret = -EINVAL;
  3615		}
  3616		return ret;
  3617	
  3618	out_err:
  3619		/* reset map before returning an error */
  3620		map->m_lblk = m_lblk;
  3621		map->m_len = m_len;
  3622		map->m_flags = 0;
  3623		return ret;
  3624	}
  3625	

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