Re: LTP: syscalls: TWARN ioctl(/dev/loop0, LOOP_SET_STATUS, test_dev.img) failed EOPNOTSUPP (95)

On Wed, Jul 9, 2025, at 15:48, Naresh Kamboju wrote:

On Tue, 8 Jul 2025 at 18:28, Naresh Kamboju [off-list ref] wrote:

quoted

Regressions were observed while testing LTP syscalls cachestat01 and
other related tests on the next-20250702 Linux kernel across several devices.

The issue appears to be related to the inability to configure /dev/loop0
via the LOOP_SET_STATUS ioctl, which returned EOPNOTSUPP
(Operation not supported). This results in a TBROK condition,
causing the test to fail.

Anders, bisected this down to this commit id,
   # first bad commit:
       [9eb22f7fedfc9eb1b7f431a5359abd4d15b0b0cd]
       fs: add ioctl to query metadata and protection info capabilities

I see the problem now in

+       if (_IOC_NR(cmd) == _IOC_NR(FS_IOC_GETLBMD_CAP))
+               return blk_get_meta_cap(bdev, cmd, argp);
+

This only compares _IOC_NR() but not _IOC_TYPE, so LOOP_SET_STATUS
is treated the same as FS_IOC_GETLBMD_CAP, since both use '2' in
the lower 8 bit.

include/uapi/linux/fs.h:#define FS_IOC_GETLBMD_CAP              _IOWR(0x15, 2, struct logical_block_metadata_cap)
include/uapi/linux/loop.h:#define LOOP_SET_STATUS               0x4C02

I checked a couple of other drivers using _IOC_NR(), and it seems
that they many of them have the same bug, e.g.:

drivers/accel/habanalabs/common/habanalabs_ioctl.c
drivers/block/ublk_drv.c
drivers/dma-buf/dma-heap.c

    Arnd