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. 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.
