[LTP] statx01 test failure/bug on i586
Cyril Hrubis
chrubis@suse.cz
Wed Nov 2 10:12:12 CET 2022
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
More information about the ltp
mailing list