[LTP] statx01 test failure/bug on i586

[LTP] statx01 test failure/bug on i586

[Vitaly Chikunov]

Hello,

We got statx01 failure on LTP 20220930 for runs on i586 arch.

  statx01.c:98: TPASS: statx(AT_FDCWD, test_file, 0, 0, &buff)
  statx01.c:105: TPASS: stx_uid(0) is correct
  statx01.c:111: TPASS: stx_gid(0) is correct
  statx01.c:117: TPASS: stx_size(256) is correct
  statx01.c:125: TPASS: stx_mode(33188) is correct
  statx01.c:131: TPASS: stx_blocks(8) is valid
  statx01.c:138: TPASS: stx_nlink(1) is correct
  statx01.c:82: TFAIL: statx.stx_mnt_id(23) is different from mount_id(13820440305888919575) in /proc/self/mountinfo
  statx01.c:88: TPASS: /proc/9494/fdinfo/3 mnt_id: = 23
  statx01.c:156: TPASS: statx(AT_FDCWD, mntpoint/blk_dev, 0, 0, &buff)
  statx01.c:163: TPASS: stx_rdev_major(8) is correct
  statx01.c:171: TPASS: stx_rdev_minor(1) is correct

Value "13820440305888919575" hints there may be integer overflow.

On Tue, Nov 01, 2022 at 06:31:20PM +0300, Dmitry V. Levin wrote:
> $ grep -Fwn mnt_id testcases/kernel/syscalls/statx/statx01.c
> 20: * - mnt_id
> 58:	uint64_t mnt_id;
> 68:		if (sscanf(line, "%ld %*d %d:%d", &mnt_id, &line_mjr, &line_mnr) != 3)
> ...

On 32-bit systems sscanf of %ld would leave higher part of mnt_id
uninitialized, resulting in false positive test failure.

Thanks,


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] statx01 test failure/bug on i586

[Cyril Hrubis]

Hi!
>   statx01.c:98: TPASS: statx(AT_FDCWD, test_file, 0, 0, &buff)
>   statx01.c:105: TPASS: stx_uid(0) is correct
>   statx01.c:111: TPASS: stx_gid(0) is correct
>   statx01.c:117: TPASS: stx_size(256) is correct
>   statx01.c:125: TPASS: stx_mode(33188) is correct
>   statx01.c:131: TPASS: stx_blocks(8) is valid
>   statx01.c:138: TPASS: stx_nlink(1) is correct
>   statx01.c:82: TFAIL: statx.stx_mnt_id(23) is different from mount_id(13820440305888919575) in /proc/self/mountinfo
>   statx01.c:88: TPASS: /proc/9494/fdinfo/3 mnt_id: = 23
>   statx01.c:156: TPASS: statx(AT_FDCWD, mntpoint/blk_dev, 0, 0, &buff)
>   statx01.c:163: TPASS: stx_rdev_major(8) is correct
>   statx01.c:171: TPASS: stx_rdev_minor(1) is correct
> 
> Value "13820440305888919575" hints there may be integer overflow.
> 
> On Tue, Nov 01, 2022 at 06:31:20PM +0300, Dmitry V. Levin wrote:
> > $ grep -Fwn mnt_id testcases/kernel/syscalls/statx/statx01.c
> > 20: * - mnt_id
> > 58:	uint64_t mnt_id;
> > 68:		if (sscanf(line, "%ld %*d %d:%d", &mnt_id, &line_mjr, &line_mnr) != 3)
> > ...
> 
> On 32-bit systems sscanf of %ld would leave higher part of mnt_id
> uninitialized, resulting in false positive test failure.

The scanf format string should be obviously fixed so that it uses PRIu64
for the mnt_id. Will you send a patch?

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp