Re: [PATCH v14 03/15] fat: Implement fileattr_get for case sensitivity

On Wed, May 20, 2026, at 10:54 AM, Mark Brown wrote:

On Wed, May 20, 2026 at 10:39:16AM -0400, Chuck Lever wrote:

quoted

On Wed, May 20, 2026, at 10:31 AM, Mark Brown wrote:

quoted

On Thu, May 07, 2026 at 04:52:56AM -0400, Chuck Lever wrote:

quoted

quoted

I'm seeing a regression in -next with the LTP statx04 test which bisects
to this commit:

quoted

quoted

tst_tmpdir.c:316: TINFO: Using /tmp/LTP_sta8hUyB4 as tmpdir (tmpfs 
filesystem)
tst_device.c:98: TINFO: Found free device 0 '/dev/loop0'
tst_test.c:2047: TINFO: LTP version: 20260130
tst_test.c:2050: TINFO: Tested kernel: 7.1.0-rc4-next-20260520 #1 SMP 
PREEMPT @1779279361 aarch64

quoted

quoted

...

quoted

quoted

tst_test.c:1985: TINFO: === Testing on vfat ===
tst_test.c:1290: TINFO: Formatting /dev/loop0 with vfat opts='' extra 
opts=''
tst_test.c:1302: TINFO: Mounting /dev/loop0 to 
/tmp/LTP_sta8hUyB4/mntpoint fstyp=vfat flags=0
statx04.c:121: TFAIL: STATX_ATTR_COMPRESSED not supported
statx04.c:121: TFAIL: STATX_ATTR_APPEND not supported
statx04.c:121: TFAIL: STATX_ATTR_IMMUTABLE not supported
statx04.c:121: TFAIL: STATX_ATTR_NODUMP not supported

quoted

At first blush, that does not seem like a plausible bisect
result. This commit shouldn't affect the behavior of tmpfs
in any way.

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:

tst_test.c:1985: TINFO: === Testing on ext2 ===
tst_test.c:1985: TINFO: === Testing on ext3 ===
tst_test.c:1985: TINFO: === Testing on ext4 ===
tst_test.c:1985: TINFO: === Testing on btrfs ===
tst_test.c:1985: TINFO: === Testing on vfat ===
tst_test.c:1985: TINFO: === Testing on tmpfs ===

OK. Is vfat the only failure in LTP statx04 ?

-- 
Chuck Lever