* [LTP] Request for Modification of test cases
@ 2024-07-05 19:47 Gulam Mohamed via ltp
2024-07-06 3:43 ` Li Wang
0 siblings, 1 reply; 6+ messages in thread
From: Gulam Mohamed via ltp @ 2024-07-05 19:47 UTC (permalink / raw)
To: ltp@lists.linux.it
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?
Regards,
Gulam Mohamed.
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [LTP] Request for Modification of test cases
2024-07-05 19:47 [LTP] Request for Modification of test cases Gulam Mohamed via ltp
@ 2024-07-06 3:43 ` Li Wang
2024-07-09 14:10 ` Gulam Mohamed via ltp
0 siblings, 1 reply; 6+ messages in thread
From: Li Wang @ 2024-07-06 3:43 UTC (permalink / raw)
To: Gulam Mohamed; +Cc: ltp@lists.linux.it
Hi Gulam,
On Sat, Jul 6, 2024 at 3:48 AM Gulam Mohamed via ltp <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.
--
Regards,
Li Wang
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [LTP] Request for Modification of test cases
2024-07-06 3:43 ` Li Wang
@ 2024-07-09 14:10 ` Gulam Mohamed via ltp
2024-07-09 22:46 ` Petr Vorel
0 siblings, 1 reply; 6+ messages in thread
From: Gulam Mohamed via ltp @ 2024-07-09 14:10 UTC (permalink / raw)
To: Li Wang; +Cc: ltp@lists.linux.it
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.
Regards,
Gulam Mohamed.
--
Regards,
Li Wang
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [LTP] Request for Modification of test cases
2024-07-09 14:10 ` Gulam Mohamed via ltp
@ 2024-07-09 22:46 ` Petr Vorel
2024-07-11 7:17 ` Gulam Mohamed via ltp
0 siblings, 1 reply; 6+ messages in thread
From: Petr Vorel @ 2024-07-09 22:46 UTC (permalink / raw)
To: Gulam Mohamed; +Cc: Jens Axboe, linux-block, Gulam Mohamed, ltp@lists.linux.it
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.
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [LTP] Request for Modification of test cases
2024-07-09 22:46 ` Petr Vorel
@ 2024-07-11 7:17 ` Gulam Mohamed via ltp
2024-07-11 13:55 ` Petr Vorel
0 siblings, 1 reply; 6+ messages in thread
From: Gulam Mohamed via ltp @ 2024-07-11 7:17 UTC (permalink / raw)
To: Petr Vorel; +Cc: Jens Axboe, linux-block@vger.kernel.org, ltp@lists.linux.it
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.
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [LTP] Request for Modification of test cases
2024-07-11 7:17 ` Gulam Mohamed via ltp
@ 2024-07-11 13:55 ` Petr Vorel
0 siblings, 0 replies; 6+ messages in thread
From: Petr Vorel @ 2024-07-11 13:55 UTC (permalink / raw)
To: Gulam Mohamed; +Cc: Jens Axboe, linux-block@vger.kernel.org, ltp@lists.linux.it
> 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.
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-07-11 13:55 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-07-05 19:47 [LTP] Request for Modification of test cases Gulam Mohamed via ltp
2024-07-06 3:43 ` Li Wang
2024-07-09 14:10 ` Gulam Mohamed via ltp
2024-07-09 22:46 ` Petr Vorel
2024-07-11 7:17 ` Gulam Mohamed via ltp
2024-07-11 13:55 ` Petr Vorel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox