[LTP] [PATCH] lib: tst_device: Scale loop device detach timeout

[LTP] [PATCH] lib: tst_device: Scale loop device detach timeout

[Sebastian Chlad]

From: Sebastian Chlad <sebastianchlad@gmail.com>

detach_loop_fd() retries LOOP_CLR_FD 40 times in 50ms steps, a fixed
2s timeout that ignores LTP_TIMEOUT_MUL. When another process still
holds the loop device at cleanup for longer than that, e.g. on a
loaded machine, the test ends with a spurious
"ioctl(/dev/loopN, LOOP_CLR_FD, 0) no ENXIO for too long" TWARN.

Scale the number of retries with tst_multiply_timeout(), which attach
already uses since d90d20046 ("lib: Use backoff polling to wait for
loop device nodes"). The default stays 2s, multiplied by 4 on kernels
with slow kconfig options and by LTP_TIMEOUT_MUL. The 50ms polling
step is kept, so the detach still finishes shortly after the device
is released.

Signed-off-by: Sebastian Chlad <sebastianchlad@gmail.com>
---
 lib/tst_device.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lib/tst_device.c b/lib/tst_device.c
index 00304711b..79e1fe0fb 100644
--- a/lib/tst_device.c
+++ b/lib/tst_device.c
@@ -251,7 +251,8 @@ uint64_t tst_get_device_size(const char *dev_path)
 
 static int detach_loop_fd(const char *dev, int *dev_fd)
 {
-	int ret, i, retval = 1;
+	int ret, retval = 1;
+	unsigned int i, retries = tst_multiply_timeout(40);
 
 	/* keep trying to clear LOOPDEV until we get ENXIO, a quick succession
 	 * of attach/detach might not give udev enough time to complete
@@ -259,7 +260,7 @@ static int detach_loop_fd(const char *dev, int *dev_fd)
 	 * Since 18048c1af783 ("loop: Fix a race between loop detach and loop open")
 	 * device is detached only after last close.
 	 */
-	for (i = 0; i < 40; i++) {
+	for (i = 0; i < retries; i++) {
 		ret = ioctl(*dev_fd, LOOP_CLR_FD, 0);
 
 		if (ret && (errno == ENXIO)) {
-- 
2.51.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH] lib: tst_device: Scale loop device detach timeout

[Cyril Hrubis]

Hi!
> detach_loop_fd() retries LOOP_CLR_FD 40 times in 50ms steps, a fixed
> 2s timeout that ignores LTP_TIMEOUT_MUL. When another process still
> holds the loop device at cleanup for longer than that, e.g. on a
> loaded machine, the test ends with a spurious
> "ioctl(/dev/loopN, LOOP_CLR_FD, 0) no ENXIO for too long" TWARN.
> 
> Scale the number of retries with tst_multiply_timeout(), which attach
> already uses since d90d20046 ("lib: Use backoff polling to wait for
> loop device nodes"). The default stays 2s, multiplied by 4 on kernels
> with slow kconfig options and by LTP_TIMEOUT_MUL. The 50ms polling
> step is kept, so the detach still finishes shortly after the device
> is released.

It would probably be better if we used the TST_RETRY_FN_EXP_BACKOFF() in
the detach loop instead so that the deatch is fast on fast device but we
do not poll unecessairly fast on slow devices.

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH] lib: tst_device: Scale loop device detach timeout

[Cyril Hrubis]

Hi!
> > Scale the number of retries with tst_multiply_timeout(), which attach
> > already uses since d90d20046 ("lib: Use backoff polling to wait for
> > loop device nodes"). The default stays 2s, multiplied by 4 on kernels
> > with slow kconfig options and by LTP_TIMEOUT_MUL. The 50ms polling
> > step is kept, so the detach still finishes shortly after the device
> > is released.
> 
> It would probably be better if we used the TST_RETRY_FN_EXP_BACKOFF() in
> the detach loop instead so that the deatch is fast on fast device but we
> do not poll unecessairly fast on slow devices.

And that macro already scales the timeout with tst_multiply_timeout().

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] lib: tst_device: Scale loop device detach timeout

[linuxtestproject.agent]

Hi Sebastian,

On Thu, 22 Oct 2026, Sebastian Chlad wrote:
> lib: tst_device: Scale loop device detach timeout

Verdict - Reviewed

---
Note:

The agent can sometimes produce false positives although often its
findings are genuine. If you find issues with the review, please
comment this email or ignore the suggestions.

Regards,
LTP AI Reviewer

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp