[brauner-github:vfs-6.19.iomap 20/25] fs/iomap/buffered-io.c:870:37: error: incompatible pointer to integer conversion passing 'u64 *' (aka 'unsigned long long *') to parameter of type 'u64' (aka 'unsigned long long'); remove &

[brauner-github:vfs-6.19.iomap 20/25] fs/iomap/buffered-io.c:870:37: error: incompatible pointer to integer conversion passing 'u64 *' (aka 'unsigned long long *') to parameter of type 'u64' (aka 'unsigned long long'); remove &

[kernel test robot]

tree:   https://github.com/brauner/linux.git vfs-6.19.iomap
head:   d61f6a3dc4f623b16ed43dd6113f594403b35211
commit: b50d39532fdab9126c794139babaec5798e79567 [20/25] iomap: optional zero range dirty folio processing
config: x86_64-buildonly-randconfig-003-20251021 (https://download.01.org/0day-ci/archive/20251021/202510210751.8T3mTZMw-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251021/202510210751.8T3mTZMw-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/202510210751.8T3mTZMw-lkp@intel.com/

All errors (new ones prefixed by >>):

>> fs/iomap/buffered-io.c:870:37: error: incompatible pointer to integer conversion passing 'u64 *' (aka 'unsigned long long *') to parameter of type 'u64' (aka 'unsigned long long'); remove & [-Wint-conversion]
     870 |                 status = iomap_iter_advance(iter, &len);
         |                                                   ^~~~
   include/linux/iomap.h:251:53: note: passing argument to parameter 'count' here
     251 | int iomap_iter_advance(struct iomap_iter *iter, u64 count);
         |                                                     ^
   1 error generated.


vim +870 fs/iomap/buffered-io.c

   804	
   805	/*
   806	 * Grab and prepare a folio for write based on iter state. Returns the folio,
   807	 * offset, and length. Callers can optionally pass a max length *plen,
   808	 * otherwise init to zero.
   809	 */
   810	static int iomap_write_begin(struct iomap_iter *iter,
   811			const struct iomap_write_ops *write_ops, struct folio **foliop,
   812			size_t *poffset, u64 *plen)
   813	{
   814		const struct iomap *srcmap = iomap_iter_srcmap(iter);
   815		loff_t pos;
   816		u64 len = min_t(u64, SIZE_MAX, iomap_length(iter));
   817		struct folio *folio;
   818		int status = 0;
   819	
   820		len = min_not_zero(len, *plen);
   821		*foliop = NULL;
   822		*plen = 0;
   823	
   824		if (fatal_signal_pending(current))
   825			return -EINTR;
   826	
   827		folio = __iomap_get_folio(iter, write_ops, len);
   828		if (IS_ERR(folio))
   829			return PTR_ERR(folio);
   830	
   831		/*
   832		 * No folio means we're done with a batch. We still have range to
   833		 * process so return and let the caller iterate and refill the batch.
   834		 */
   835		if (!folio) {
   836			WARN_ON_ONCE(!iter->fbatch);
   837			return 0;
   838		}
   839	
   840		/*
   841		 * Now we have a locked folio, before we do anything with it we need to
   842		 * check that the iomap we have cached is not stale. The inode extent
   843		 * mapping can change due to concurrent IO in flight (e.g.
   844		 * IOMAP_UNWRITTEN state can change and memory reclaim could have
   845		 * reclaimed a previously partially written page at this index after IO
   846		 * completion before this write reaches this file offset) and hence we
   847		 * could do the wrong thing here (zero a page range incorrectly or fail
   848		 * to zero) and corrupt data.
   849		 */
   850		if (write_ops && write_ops->iomap_valid) {
   851			bool iomap_valid = write_ops->iomap_valid(iter->inode,
   852								 &iter->iomap);
   853			if (!iomap_valid) {
   854				iter->iomap.flags |= IOMAP_F_STALE;
   855				status = 0;
   856				goto out_unlock;
   857			}
   858		}
   859	
   860		/*
   861		 * The folios in a batch may not be contiguous. If we've skipped
   862		 * forward, advance the iter to the pos of the current folio. If the
   863		 * folio starts beyond the end of the mapping, it may have been trimmed
   864		 * since the lookup for whatever reason. Return a NULL folio to
   865		 * terminate the op.
   866		 */
   867		if (folio_pos(folio) > iter->pos) {
   868			len = min_t(u64, folio_pos(folio) - iter->pos,
   869					 iomap_length(iter));
 > 870			status = iomap_iter_advance(iter, &len);
   871			if (status || !len)
   872				goto out_unlock;
   873		}
   874	
   875		pos = iomap_trim_folio_range(iter, folio, poffset, &len);
   876	
   877		if (srcmap->type == IOMAP_INLINE)
   878			status = iomap_write_begin_inline(iter, folio);
   879		else if (srcmap->flags & IOMAP_F_BUFFER_HEAD)
   880			status = __block_write_begin_int(folio, pos, len, NULL, srcmap);
   881		else
   882			status = __iomap_write_begin(iter, write_ops, len, folio);
   883	
   884		if (unlikely(status))
   885			goto out_unlock;
   886	
   887		*foliop = folio;
   888		*plen = len;
   889		return 0;
   890	
   891	out_unlock:
   892		__iomap_put_folio(iter, write_ops, 0, folio);
   893		return status;
   894	}
   895	

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

Re: [brauner-github:vfs-6.19.iomap 20/25] fs/iomap/buffered-io.c:870:37: error: incompatible pointer to integer conversion passing 'u64 *' (aka 'unsigned long long *') to parameter of type 'u64' (aka 'unsigned long long'); remove &

[Brian Foster]

On Tue, Oct 21, 2025 at 07:26:24AM +0800, kernel test robot wrote:
> tree:   https://github.com/brauner/linux.git vfs-6.19.iomap
> head:   d61f6a3dc4f623b16ed43dd6113f594403b35211
> commit: b50d39532fdab9126c794139babaec5798e79567 [20/25] iomap: optional zero range dirty folio processing
> config: x86_64-buildonly-randconfig-003-20251021 (https://download.01.org/0day-ci/archive/20251021/202510210751.8T3mTZMw-lkp@intel.com/config)
> compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251021/202510210751.8T3mTZMw-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/202510210751.8T3mTZMw-lkp@intel.com/
> 
> All errors (new ones prefixed by >>):
> 
> >> fs/iomap/buffered-io.c:870:37: error: incompatible pointer to integer conversion passing 'u64 *' (aka 'unsigned long long *') to parameter of type 'u64' (aka 'unsigned long long'); remove & [-Wint-conversion]
>      870 |                 status = iomap_iter_advance(iter, &len);
>          |                                                   ^~~~
>    include/linux/iomap.h:251:53: note: passing argument to parameter 'count' here
>      251 | int iomap_iter_advance(struct iomap_iter *iter, u64 count);
>          |                                                     ^
>    1 error generated.
> 

Ugh.. I guess this is because I didn't have Joanne's "iomap: simplify
iomap_iter_advance()" locally. Something like the diff below should
address it. Note that I won't have time to test properly until tomorrow
so this is compile tested only, but pretty straightforward.

BTW I'm not aware if this was published anywhere before now in the v6.19
branch, so if there's a general branch that is preferred to use for
pending iomap work or whatever let me know and I'll move over to it.

Brian

--- 8< ---

diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
index 72196e5021b1..a5a9caae602e 100644
--- a/fs/iomap/buffered-io.c
+++ b/fs/iomap/buffered-io.c
@@ -867,7 +867,9 @@ static int iomap_write_begin(struct iomap_iter *iter,
 	if (folio_pos(folio) > iter->pos) {
 		len = min_t(u64, folio_pos(folio) - iter->pos,
 				 iomap_length(iter));
-		status = iomap_iter_advance(iter, &len);
+		status = iomap_iter_advance(iter, len);
+		if (!status)
+			len = iomap_length(iter);
 		if (status || !len)
 			goto out_unlock;
 	}