[LTP] [PATCH 1/2] testcases/lib: Fix tst_ns_* helpers
Petr Vorel
pvorel@suse.cz
Fri Jan 17 13:44:07 CET 2025
Hi Cyril, Li,
> On Fri, Jan 17, 2025 at 8:25 PM Cyril Hrubis <chrubis@suse.cz> wrote:
> > Replaces SAFE_CLONE() with tst_clone() in the tst_ns_* helpers.
> > The reason for the replacement is that SAFE_CLONE() uses
> > TST_RETRY_FUNC() which calls tst_multiply_timeout(). The problem with
> > that is that the tst_multiply_timeout() is a test library function that
> > started to print TINFO messages recently and that we rely on parsing the
> > output from the tst_ns_* helpers.
> > The reason SAFE_CLONE() started to call TST_RETRY_FUNC() is that in the
> > case that we create new namespaces with the clone call, we may end up
> > creating them faster than kernel can clean them up which is described in:
> > commit 7d882081a5613f44a12fc6b1c44267d4df0857a4
> > Author: Petr Vorel <pvorel@suse.cz>
> > Date: Mon Mar 28 22:46:43 2022 +0200
> > lib: Retry safe_clone() on ENOSPC
> > This combined with the newly introduced changes in the test library that
> > check for kernel debugging options that may need to adjust default
> > timeouts:
> > commit 893ca0abe7e82851ff0e5d93c09b1098f2eff121
> > Author: Li Wang <liwang@redhat.com>
> > Date: Sun Dec 22 15:22:49 2024 +0800
> > lib: multiply the timeout if detect slow kconfigs
> > which adds tst_has_slow_kconfig() into the tst_multiply_timeout() causes
> > the TINFO messages to be printed.
> > The reason why we can safely replace the SAFE_CLONE() with tst_clone()
> > here is that we are not creating new namspaces in the tst_ns_* helpers,
> > but rather than that cloning a new process to be executed inside of the
> > namespace, hence we do not need to retry on ENOSPC.
> > Signed-off-by: Cyril Hrubis <chrubis@suse.cz>
> Reviewed-by: Li Wang <liwang@redhat.com>
> Nice work!
Thanks for fix and review. This one fixes the problem, thus I merged it.
I'll let you know about the other patch soon (I suspect that it does not catch
other usage, some tools needs to parse stderr ...).
Kind regards,
Petr
More information about the ltp
mailing list