2022-06-08 00:49:59

by kernel test robot

[permalink] [raw]
Subject: [linux-next:master 728/1207] fs/xfs/xfs_file.c:1266:31: sparse: sparse: incorrect type in return expression (different base types)

tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head: 73d0e32571a0786151eb72634f1a4c5891166176
commit: d5f5b32dee7c09e3152cbbce45c73f0b1ea7d94c [728/1207] xfs: support CoW in fsdax mode
config: x86_64-rhel-8.3-kselftests (https://download.01.org/0day-ci/archive/20220607/[email protected]/config)
compiler: gcc-11 (Debian 11.3.0-1) 11.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.4-18-g56afb504-dirty
# https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=d5f5b32dee7c09e3152cbbce45c73f0b1ea7d94c
git remote add linux-next https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
git fetch --no-tags linux-next master
git checkout d5f5b32dee7c09e3152cbbce45c73f0b1ea7d94c
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=x86_64 SHELL=/bin/bash fs/xfs/

If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot <[email protected]>


sparse warnings: (new ones prefixed by >>)
>> fs/xfs/xfs_file.c:1266:31: sparse: sparse: incorrect type in return expression (different base types) @@ expected int @@ got restricted vm_fault_t @@
fs/xfs/xfs_file.c:1266:31: sparse: expected int
fs/xfs/xfs_file.c:1266:31: sparse: got restricted vm_fault_t
>> fs/xfs/xfs_file.c:1260:1: sparse: sparse: symbol 'xfs_dax_fault' was not declared. Should it be static?
>> fs/xfs/xfs_file.c:1314:21: sparse: sparse: incorrect type in assignment (different base types) @@ expected restricted vm_fault_t [usertype] ret @@ got int @@
fs/xfs/xfs_file.c:1314:21: sparse: expected restricted vm_fault_t [usertype] ret
fs/xfs/xfs_file.c:1314:21: sparse: got int

Please review and possibly fold the followup patch.

vim +1266 fs/xfs/xfs_file.c

1257
1258 #ifdef CONFIG_FS_DAX
1259 int
> 1260 xfs_dax_fault(
1261 struct vm_fault *vmf,
1262 enum page_entry_size pe_size,
1263 bool write_fault,
1264 pfn_t *pfn)
1265 {
> 1266 return dax_iomap_fault(vmf, pe_size, pfn, NULL,
1267 (write_fault && !vmf->cow_page) ?
1268 &xfs_dax_write_iomap_ops :
1269 &xfs_read_iomap_ops);
1270 }
1271 #else
1272 int
1273 xfs_dax_fault(
1274 struct vm_fault *vmf,
1275 enum page_entry_size pe_size,
1276 bool write_fault,
1277 pfn_t *pfn)
1278 {
1279 return 0;
1280 }
1281 #endif
1282
1283 /*
1284 * Locking for serialisation of IO during page faults. This results in a lock
1285 * ordering of:
1286 *
1287 * mmap_lock (MM)
1288 * sb_start_pagefault(vfs, freeze)
1289 * invalidate_lock (vfs/XFS_MMAPLOCK - truncate serialisation)
1290 * page_lock (MM)
1291 * i_lock (XFS - extent map serialisation)
1292 */
1293 static vm_fault_t
1294 __xfs_filemap_fault(
1295 struct vm_fault *vmf,
1296 enum page_entry_size pe_size,
1297 bool write_fault)
1298 {
1299 struct inode *inode = file_inode(vmf->vma->vm_file);
1300 struct xfs_inode *ip = XFS_I(inode);
1301 vm_fault_t ret;
1302
1303 trace_xfs_filemap_fault(ip, pe_size, write_fault);
1304
1305 if (write_fault) {
1306 sb_start_pagefault(inode->i_sb);
1307 file_update_time(vmf->vma->vm_file);
1308 }
1309
1310 if (IS_DAX(inode)) {
1311 pfn_t pfn;
1312
1313 xfs_ilock(XFS_I(inode), XFS_MMAPLOCK_SHARED);
> 1314 ret = xfs_dax_fault(vmf, pe_size, write_fault, &pfn);
1315 if (ret & VM_FAULT_NEEDDSYNC)
1316 ret = dax_finish_sync_fault(vmf, pe_size, pfn);
1317 xfs_iunlock(XFS_I(inode), XFS_MMAPLOCK_SHARED);
1318 } else {
1319 if (write_fault) {
1320 xfs_ilock(XFS_I(inode), XFS_MMAPLOCK_SHARED);
1321 ret = iomap_page_mkwrite(vmf,
1322 &xfs_buffered_write_iomap_ops);
1323 xfs_iunlock(XFS_I(inode), XFS_MMAPLOCK_SHARED);
1324 } else {
1325 ret = filemap_fault(vmf);
1326 }
1327 }
1328
1329 if (write_fault)
1330 sb_end_pagefault(inode->i_sb);
1331 return ret;
1332 }
1333

--
0-DAY CI Kernel Test Service
https://01.org/lkp


2022-06-08 06:16:36

by Andrew Morton

[permalink] [raw]
Subject: Re: [linux-next:master 728/1207] fs/xfs/xfs_file.c:1266:31: sparse: sparse: incorrect type in return expression (different base types)

On Tue, 7 Jun 2022 15:09:18 +0800 kernel test robot <[email protected]> wrote:

> tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> head: 73d0e32571a0786151eb72634f1a4c5891166176
> commit: d5f5b32dee7c09e3152cbbce45c73f0b1ea7d94c [728/1207] xfs: support CoW in fsdax mode
> config: x86_64-rhel-8.3-kselftests (https://download.01.org/0day-ci/archive/20220607/[email protected]/config)
> compiler: gcc-11 (Debian 11.3.0-1) 11.3.0
> reproduce:
> # apt-get install sparse
> # sparse version: v0.6.4-18-g56afb504-dirty
> # https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=d5f5b32dee7c09e3152cbbce45c73f0b1ea7d94c
> git remote add linux-next https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> git fetch --no-tags linux-next master
> git checkout d5f5b32dee7c09e3152cbbce45c73f0b1ea7d94c
> # save the config file
> mkdir build_dir && cp config build_dir/.config
> make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=x86_64 SHELL=/bin/bash fs/xfs/
>
> If you fix the issue, kindly add following tag where applicable
> Reported-by: kernel test robot <[email protected]>
>
>
> sparse warnings: (new ones prefixed by >>)
> >> fs/xfs/xfs_file.c:1266:31: sparse: sparse: incorrect type in return expression (different base types) @@ expected int @@ got restricted vm_fault_t @@
> fs/xfs/xfs_file.c:1266:31: sparse: expected int
> fs/xfs/xfs_file.c:1266:31: sparse: got restricted vm_fault_t
> >> fs/xfs/xfs_file.c:1260:1: sparse: sparse: symbol 'xfs_dax_fault' was not declared. Should it be static?
> >> fs/xfs/xfs_file.c:1314:21: sparse: sparse: incorrect type in assignment (different base types) @@ expected restricted vm_fault_t [usertype] ret @@ got int @@
> fs/xfs/xfs_file.c:1314:21: sparse: expected restricted vm_fault_t [usertype] ret
> fs/xfs/xfs_file.c:1314:21: sparse: got int
>
> Please review and possibly fold the followup patch.

Well yes, the followup patch
(https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/xfs-support-cow-in-fsdax-mode-fix.patch)
will most definitely be folded.

Can you suggest how this can be communicated to the robot in order to
suppress this notification? A Fixes: won't work, as neither of these
patches have yet been promoted to a "stable" state. Their hashes will
change.

2022-06-08 08:28:00

by Philip Li

[permalink] [raw]
Subject: Re: [kbuild-all] Re: [linux-next:master 728/1207] fs/xfs/xfs_file.c:1266:31: sparse: sparse: incorrect type in return expression (different base types)

On Tue, Jun 07, 2022 at 04:05:46PM -0700, Andrew Morton wrote:
> On Tue, 7 Jun 2022 15:09:18 +0800 kernel test robot <[email protected]> wrote:
>
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> > head: 73d0e32571a0786151eb72634f1a4c5891166176
> > commit: d5f5b32dee7c09e3152cbbce45c73f0b1ea7d94c [728/1207] xfs: support CoW in fsdax mode
> > config: x86_64-rhel-8.3-kselftests (https://download.01.org/0day-ci/archive/20220607/[email protected]/config)
> > compiler: gcc-11 (Debian 11.3.0-1) 11.3.0
> > reproduce:
> > # apt-get install sparse
> > # sparse version: v0.6.4-18-g56afb504-dirty
> > # https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=d5f5b32dee7c09e3152cbbce45c73f0b1ea7d94c
> > git remote add linux-next https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> > git fetch --no-tags linux-next master
> > git checkout d5f5b32dee7c09e3152cbbce45c73f0b1ea7d94c
> > # save the config file
> > mkdir build_dir && cp config build_dir/.config
> > make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=x86_64 SHELL=/bin/bash fs/xfs/
> >
> > If you fix the issue, kindly add following tag where applicable
> > Reported-by: kernel test robot <[email protected]>
> >
> >
> > sparse warnings: (new ones prefixed by >>)
> > >> fs/xfs/xfs_file.c:1266:31: sparse: sparse: incorrect type in return expression (different base types) @@ expected int @@ got restricted vm_fault_t @@
> > fs/xfs/xfs_file.c:1266:31: sparse: expected int
> > fs/xfs/xfs_file.c:1266:31: sparse: got restricted vm_fault_t
> > >> fs/xfs/xfs_file.c:1260:1: sparse: sparse: symbol 'xfs_dax_fault' was not declared. Should it be static?
> > >> fs/xfs/xfs_file.c:1314:21: sparse: sparse: incorrect type in assignment (different base types) @@ expected restricted vm_fault_t [usertype] ret @@ got int @@
> > fs/xfs/xfs_file.c:1314:21: sparse: expected restricted vm_fault_t [usertype] ret
> > fs/xfs/xfs_file.c:1314:21: sparse: got int
> >
> > Please review and possibly fold the followup patch.
>
> Well yes, the followup patch
> (https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/xfs-support-cow-in-fsdax-mode-fix.patch)
> will most definitely be folded.

Sorry, currently we disable the auto patch, this sentence "Please review and possibly fold the followup patch"
is misleading. We will not have follow up patch before we can have human to
do a check.

>
> Can you suggest how this can be communicated to the robot in order to
> suppress this notification? A Fixes: won't work, as neither of these
> patches have yet been promoted to a "stable" state. Their hashes will
> change.

Got it, we also think the Fixes tag in the proposed patch brings confusion
if the "bad" commit is in development state. So far, we haven't exposed a
way to feedback the "Fixes: won't work", but we will work on some level
of mail based communication in 2nd half this year, which can simplify the
communication like this.

Anyway, we now disable the auto patch to avoid bring confusion and sometimes
wrong patch without human check.

> _______________________________________________
> kbuild-all mailing list -- [email protected]
> To unsubscribe send an email to [email protected]