From: Petr Vorel <pvorel@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] cpuset_hotplug_test.sh: Fix a race condition
Date: Thu, 16 Jul 2020 16:21:53 +0200 [thread overview]
Message-ID: <20200716142153.GA15980@dell5510> (raw)
In-Reply-To: <20200716134939.tqxswbdd2lcpcwp3@e107158-lin.cambridge.arm.com>
Hi Qais,
> > > Let me know what would be the preferred approach.
> > Just please try to send a patch using TST_RETRY_FUNC (thus you need to figure
> > out the verifier), or let us know and we either figure that or just simply use
> > your original patch.
> So I have cooked something quick but I either get
> /root/arm64-ltp/testcases/bin/cpuset_hotplug_test.sh: line 159: TST_RETRY_FUNC: command not found
I'm sorry, I have forgotten that the tests haven't been ported to the new API
yet (tst_test.sh). Thus, I'm ok to take the original patch, unless anybody
objects.
Why? Rewriting is going to be bigger task, as shell scripts has interdependencies,
thus turning cpuset_funcs.sh to use new API requires turning the other tests
which use it (it's not acceptable to load both legacy and new API in a test).
Besides new API needs to rename some functions (s/tst_resm/tst_res/, ... that's
easy task), but also works differently, so it's more work that renaming these
functions. Also tests need heavy cleanup (style is not optimal, using full path
like /bin/kill is ugly).
Although this should be done, the bigger problem is that these tests test just
cgroup v1 (and only early implementations, see notes about 2.6.29 in the code),
has other bugs than just one you spotted. There might be similar approach we
took with NUMA tests: shell tests are in maintenance mode and new tests are
written from the scratch in C.
BTW there is some support for cgroup in lib/tst_cgroup.c.
> or
> cpuset_hotplug_test 1 TBROK: Test /root/arm64-ltp/testcases/bin/cpuset_hotplug_test.sh must call tst_run!
> Depending whether I impost test.sh or tst_test.sh.
> It seems there's a dependency on the overall test construction depending on
> what file is imported. And one can import one or the other. It seems
> tst_test.sh is the legacy approach?
No, test.sh is the legacy one.
There is a docs for new API (C and shell), if you're interested.
https://github.com/linux-test-project/ltp/wiki/Test-Writing-Guidelines
> My WIP patch is attached in case there's somethign obvious to be done here that
> I missed.
> It looks like the current patch is the simplest thing to do otherwise? :-/
yes :).
Kind regards,
Petr
next prev parent reply other threads:[~2020-07-16 14:21 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-14 15:25 [LTP] [PATCH] cpuset_hotplug_test.sh: Fix a race condition Qais Yousef
2020-07-16 6:07 ` Petr Vorel
2020-07-16 9:33 ` Qais Yousef
2020-07-16 9:57 ` Petr Vorel
2020-07-16 10:12 ` Qais Yousef
2020-07-16 12:08 ` Petr Vorel
2020-07-16 13:49 ` Qais Yousef
2020-07-16 14:21 ` Petr Vorel [this message]
2020-07-16 15:30 ` Qais Yousef
2020-07-16 20:56 ` Petr Vorel
2020-07-17 11:25 ` Qais Yousef
2020-07-17 11:28 ` Petr Vorel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200716142153.GA15980@dell5510 \
--to=pvorel@suse.cz \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox