RE: [LTP] Request for Modification of test cases

Gulam Mohamed
2024-07-11T07:18:06Z

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.

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.