The ustat01 and ustat02 syscall tests are failing on my environment when the root filesystem is Btrfs. While the test metadata acknowledges this as a "known-fail," the test currently results in a TFAIL, which causes regressions in automated CI/CD pipelines.
In ustat02, this is particularly problematic because the expected EFAULT return value is masked by EINVAL because the kernel's device ID check on Btrfs takes precedence over the memory address check.
ustat01.c:29: TFAIL: ustat(2) failed: EINVAL (22)
HINT: You _MAY_ be hit by known kernel failures:
ustat() is known to fail with EINVAL on Btrfs, see https://lore.kernel.org/linux-btrfs/e7e867b8-b57a-7eb2-2432-1627bd3a88fb@toxicpanda.com/
Summary:
passed 0
failed 1
broken 0
skipped 0
warnings 0
ustat02.c:43: TPASS: ustat(2) expected failure: EINVAL (22)
ustat02.c:45: TFAIL: ustat(2) failed to produce expected error; 14, errno: EFAULT: EINVAL (22)
HINT: You _MAY_ be hit by known kernel failures:
ustat() is known to fail with EINVAL on Btrfs, see https://lore.kernel.org/linux-btrfs/e7e867b8-b57a-7eb2-2432-1627bd3a88fb@toxicpanda.com/
Summary:
passed 1
failed 1
broken 0
skipped 0
warnings 0
The ustat01 and ustat02 syscall tests are failing on my environment when the root filesystem is Btrfs. While the test metadata acknowledges this as a "known-fail," the test currently results in a TFAIL, which causes regressions in automated CI/CD pipelines.
In ustat02, this is particularly problematic because the expected EFAULT return value is masked by EINVAL because the kernel's device ID check on Btrfs takes precedence over the memory address check.