Re: [LTP] Request for Modification of test cases

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[1] https://git.kernel.dk/cgit/linux-block/commit/?h=for-6.11/block&id=18048c1af7836b8e31739d9eaefebc2bf76261f7
[2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20240709&id=18048c1af7836b8e31739d9eaefebc2bf76261f7

> Regards,
> Gulam Mohamed.




[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux