Re: [LTP] Request for Modification of test cases

Re: [LTP] Request for Modification of test cases

[Petr Vorel]

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

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

RE: [LTP] Request for Modification of test cases

[Gulam Mohamed]

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.

Re: [LTP] Request for Modification of test cases

[Petr Vorel]

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