> Hi Petr, > > -----Original Message----- > > From: Petr Vorel <pvorel@xxxxxxx> > > Sent: Wednesday, July 10, 2024 4:17 AM > > To: Gulam Mohamed <gulam.mohamed@xxxxxxxxxx> > > Cc: Li Wang <liwang@xxxxxxxxxx>; ltp@xxxxxxxxxxxxxx; Cyril Hrubis > > <chrubis@xxxxxxx>; Gulam Mohamed <gulam.mohamed@xxxxxxxxxx>; Jens > > Axboe <axboe@xxxxxxxxx>; linux-block@xxxxxxxxxxxxxxx > > 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@xxxxxxxxxx> > > > Sent: Saturday, July 6, 2024 9:13 AM > > > To: Gulam Mohamed <gulam.mohamed@xxxxxxxxxx> > > > Cc: ltp@xxxxxxxxxxxxxx > > > 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@xxxxxxxxxxxxxx<mailto:ltp@xxxxxxxxxxxxxx>> 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.
