On Wed, May 20, 2026, at 11:19 AM, Mark Brown wrote: > On Wed, May 20, 2026 at 11:12:51AM -0400, Chuck Lever wrote: >> On Wed, May 20, 2026, at 10:54 AM, Mark Brown wrote: > >> > It's not testing tmpfs (well, it does but that passed), as the log above >> > shows it is making a vfat filesystem on a loop device backed by a file >> > that happens to be in a tmpfs and then testing that. There's a bunch of >> > filesystems covered in this manner: > >> OK. Is vfat the only failure in LTP statx04 ? > > Yes, it's the only one showing as failing - there are four failures > correspoding to the four tests done for vfat.
03/15 adds .fileattr_get = fat_fileattr_get for both fat_file_inode_operations and vfat_dir_inode_operations. LTP opens a directory (SAFE_OPEN(TESTDIR, O_RDONLY|O_DIRECTORY)), so FS_IOC_GETFLAGS on the dir now succeeds, and statx04 proceeds where it was previously skipped. AFAICS, 03/15 did not change pre-existing kernel behavior of stx_attributes_mask on vfat. It merely converted a "skipped" LTP outcome into an "executed but failed" outcome. Fix options: * fat_getattr() could call generic_fill_statx_attr(inode, stat), which advertises KSTAT_ATTR_VFS_FLAGS (IMMUTABLE + APPEND). That clears 2 of 4 TFAILs but not COMPRESSED/NODUMP, which FAT genuinely does not back. * Set stat->attributes_mask |= KSTAT_ATTR_FS_IOC_FLAGS in fat_getattr(). Honest only to the extent that FAT now exposes some FS_*_FL bits via fileattr. This would silence the test failures, but advertises capabilities (COMPRESSED, NODUMP) FAT doesn't track. * Admit the LTP statx04 test needs to be updated. FS_IOC_GETFLAGS succeeding does not logically imply all four FS_IOC_FLAGS-mapped STATX_ATTR_* bits are supported. The test's gate is too coarse for filesystems that gained a narrowly-scoped fileattr_get (just casefold/immutable). The test's tag list pins it to filesystems that do support the full set, but vfat was tacitly excluded by the prior ENOTTY. The first option is the narrowest kernel-side change, and matches what other minimal-fileattr filesystems do. -- Chuck Lever _______________________________________________ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
