Re: [LTP] Request for Modification of test cases

[Petr Vorel <pvorel@suse.cz>]

> Hi Petr,

> > -----Original Message-----
> > From: Petr Vorel <pvorel@suse.cz>
> > Sent: Wednesday, July 10, 2024 4:17 AM
> > To: Gulam Mohamed <gulam.mohamed@oracle.com>
> > Cc: Li Wang <liwang@redhat.com>; ltp@lists.linux.it; Cyril Hrubis
> > <chrubis@suse.cz>; Gulam Mohamed <gulam.mohamed@oracle.com>; Jens
> > Axboe <axboe@kernel.dk>; linux-block@vger.kernel.org
> > Subject: Re: [LTP] Request for Modification of test cases

> > Hi Gulam, all,

> > [ Cc linux-block and author and committer of the change in kernel ]

> > > Hi Li Wang,

> > > From: Li Wang <liwang@redhat.com>
> > > Sent: Saturday, July 6, 2024 9:13 AM
> > > To: Gulam Mohamed <gulam.mohamed@oracle.com>
> > > Cc: ltp@lists.linux.it
> > > Subject: Re: [LTP] Request for Modification of test cases

> > > Hi Gulam,

> > > On Sat, Jul 6, 2024 at 3:48 AM Gulam Mohamed via ltp
> > <ltp@lists.linux.it<mailto:ltp@lists.linux.it>> wrote:
> > > Hi Team,

> > >     This is regarding the change in kernel behavior about the way the loop
> > device is detached.

> > >               Current behavior
> > >               -----------------------
> > >               When the LOOP_CLR_FD ioctl command is sent to detach the loop
> > device, the earlier behavior was that the loop     device used to be detached at
> > that instance itself if there was a single opener only. If
> > >                there were multiple openers of the loop device, the behavior was to
> > defer the detach operation at the last close of the device.

> > >               New behavior
> > >               ------------------
> > >               As per the new behavior, irrespective of whether there are any
> > openers of the loop device or not, the detach operation is deferred to the last
> > close of the device. This was done to address an issue, due
> > >               to race coditions, recently we had in kernel.

> > >               With the new kernel behavior in place, some of the LTP test cases in
> > "testcases/kernel/syscalls/ioctl/" are failing as the device is closed at the end
> > of the test and the test cases are expecting for the
> > >                results which can occur after the device is detached. Some of the
> > test cases which are failing are:

> > >               1. ioctl04, ioctl05, ioctl06, ioctl07, ioctl09
> > >               2. ioctl_loop01, ioctl_loop02, ioctl_loop03,
> > > ioctl_loop04, ioctl_loop05, ioctl_loop06, ioctl_loop07

> > >               The main root cause of the most of the test failures, is the function
> > "tst_detach_device_by_fd()" where the function is expecting error ENXIO
> > which is returned only after the device is detached. But
> > >               detach, as per new behavior, happens only after the last close (i.e
> > after this function is returned), the test will fail with following error:

> > >               "ioctl(/dev/loop0, LOOP_CLR_FD, 0) no ENXIO for too long"

> > >               Similarly, some other test cases are expecting results which are
> > returned after the detach operation, but as the detach did not happen,
> > unexpected values are returned resulting in the test failure.

> > >               So, can LTP maintainers team change the impacted test cases to
> > accommodate the new behavior of kernel for the detach operation of the
> > loop device?


> > > Thanks for highlighting the issue, can you tell which kernel version
> > > (commit ?) introduced that change, then we could adjust the test against the
> > different kernels.

> > > Thanks for the help. The patch is already in queue by the block maintainers
> > for 6.11. Seems like it will be merged soon.

> > Thanks for your report. I suppose you are talking about commit
> > 18048c1af7836
> > ("loop: Fix a race between loop detach and loop open") [1], right? The
> > commit is already in the next tree [2].

> > Kind regards,
> > Petr

> Yes, this is the one I was talking about.

I tested few ioctl* tests on  6.10.0-rc7-next-20240711 and indeed at least
ioctl_loop02 fails:

tst_test.c:1652: TINFO: Timeout per run is 0h 00m 30s
tst_device.c:97: TINFO: Found free device 0 '/dev/loop0'
ioctl_loop02.c:54: TINFO: Using LOOP_SET_FD to setup loopdevice
ioctl_loop02.c:65: TPASS: /sys/block/loop0/ro = 1
ioctl_loop02.c:66: TPASS: /sys/block/loop0/loop/backing_file = '/tmp/LTP_iocEm3iz2/test.img'
ioctl_loop02.c:75: TPASS: lo_flags only has default LO_FLAGS_READ_ONLY flag
ioctl_loop02.c:81: TPASS: Can not write data in RO mode: EPERM (1)
ioctl_loop02.c:87: TPASS: LOOP_CHANGE_FD succeeded
ioctl_loop02.c:88: TPASS: /sys/block/loop0/ro = 1
ioctl_loop02.c:89: TPASS: /sys/block/loop0/loop/backing_file = '/tmp/LTP_iocEm3iz2/test1.img'
ioctl_loop02.c:95: TPASS: LOOP_CHANGE_FD failed as expected: EINVAL (22)
ioctl_loop02.c:54: TINFO: Using LOOP_CONFIGURE with read_only flag
ioctl_loop02.c:61: TBROK: ioctl(5,(0x4C0A),...) failed: EBUSY (16)

I'll try to have look on the fix.

Kind regards,
Petr

> Regards,
> Gulam Mohamed.

> > [1] https://urldefense.com/v3/__https://git.kernel.dk/cgit/linux-
> > block/commit/?h=for-
> > 6.11*block&id=18048c1af7836b8e31739d9eaefebc2bf76261f7__;Lw!!ACWV5
> > N9M2RV99hQ!KE2XvdHTkyIMJkkCr8N_14cJzjuRkBzr-YGp-
> > gohydEw7PVXY_4jdiz9xQIfT41XGZq2Albr_sIIVdRfUQ$
> > [2]
> > https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/
> > next/linux-next.git/commit/?h=next-
> > 20240709&id=18048c1af7836b8e31739d9eaefebc2bf76261f7__;!!ACWV5N9
> > M2RV99hQ!KE2XvdHTkyIMJkkCr8N_14cJzjuRkBzr-YGp-
> > gohydEw7PVXY_4jdiz9xQIfT41XGZq2Albr_sIGsll89g$

> > > Regards,
> > > Gulam Mohamed.

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp