[LTP] statx01 test failure/bug on i586

Vitaly Chikunov vt@altlinux.org
Tue Nov 1 17:07:44 CET 2022


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,



More information about the ltp mailing list