[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