From: Richard Palethorpe <rpalethorpe@suse.de>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] fzsync: skip test when avaliable CPUs less than 2
Date: Wed, 25 Nov 2020 13:23:54 +0000 [thread overview]
Message-ID: <87blflo9hx.fsf@suse.de> (raw)
In-Reply-To: <04c4b073-6ad3-836a-7f63-7632a4e6ddb7@suse.cz>
Hello,
Martin Doucha <mdoucha@suse.cz> writes:
> On 25. 11. 20 12:22, Richard Palethorpe wrote:
>> Hello Li,
>>
>> Li Wang <liwang@redhat.com> writes:
>>
>>> It makes no sense to run parallel thread to simulate race conditions on
>>> system with CPU number less than two, especially for kvm guest, it does
>>> not have any chance to get real parallel running and probably encounter
>>> failure as below:
>>
>> Most of the tests using FuzzySync do not need true parallism. We were
>> able to reproduce a number of race conditions on a single vCPU. Infact
>> it may actually benefit some races because one thread has to pause to
>> allow the other to run, perhaps creating a huge race window.
>>
>>>
>>> === 100% reproducible on a 1cpu guest ===
>>>
>>> cmdline="af_alg07"
>>> contacts=""
>>> analysis=exit
>>> <<<test_output>>>
>>> tst_test.c:1248: TINFO: Timeout per run is 0h 05m 00s
>>> ../../../include/tst_fuzzy_sync.h:507: TINFO: Minimum sampling period ended
>>> ../../../include/tst_fuzzy_sync.h:330: TINFO: loop = 1024, delay_bias = 0
>>> ../../../include/tst_fuzzy_sync.h:318: TINFO: start_a - start_b: { avg = -137522ns, avg_dev = 854248ns, dev_ratio = 6.21 }
>>> ../../../include/tst_fuzzy_sync.h:318: TINFO: end_a - start_a : { avg = 1915ns, avg_dev = 535ns, dev_ratio = 0.28 }
>>> ../../../include/tst_fuzzy_sync.h:318: TINFO: end_b - start_b : { avg = 1885ns, avg_dev = 42ns, dev_ratio = 0.02 }
>>> ../../../include/tst_fuzzy_sync.h:318: TINFO: end_a - end_b : { avg = -137492ns, avg_dev = 854818ns, dev_ratio = 6.22 }
>>> ../../../include/tst_fuzzy_sync.h:318: TINFO: spins : { avg = 554786 , avg_dev = 7355 , dev_ratio = 0.01 }
>>> ../../../include/tst_fuzzy_sync.h:636: TINFO: Exceeded execution time, requesting exit
>>> af_alg07.c:96: TFAIL: fchownat() failed to fail, kernel may be vulnerable
>>>
>>> Signed-off-by: Li Wang <liwang@redhat.com>
>>> CC: Richard Palethorpe <rpalethorpe@suse.de>
>>> ---
>>> include/tst_fuzzy_sync.h | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/include/tst_fuzzy_sync.h b/include/tst_fuzzy_sync.h
>>> index 4141f5c64..2e864b312 100644
>>> --- a/include/tst_fuzzy_sync.h
>>> +++ b/include/tst_fuzzy_sync.h
>>> @@ -281,6 +281,9 @@ static void tst_init_stat(struct tst_fzsync_stat *s)
>>> static void tst_fzsync_pair_reset(struct tst_fzsync_pair *pair,
>>> void *(*run_b)(void *))
>>> {
>>> + if (get_nprocs() < 2)
>>> + tst_brk(TCONF, "Fuzzy Sync requires at least two CPUs available");
>>> +
>>> tst_fzsync_pair_cleanup(pair);
>>>
>>> tst_init_stat(&pair->diff_ss);
>>
>> Perhaps this test would pass with more loops and a big enough delay
>> range, but this is also wasting time on a single vCPU. I'm not sure
>> whether we should filter this test at the LTP level; it may trigger the
>> bug on some single CPU configs.
>
> No, af_alg07 requires 2 CPUs, otherwise it'll report false positives.
> The test will pass only if fchownat() hits a half-closed socket and
> returns error. But IIRC the half-closed socket will be destroyed during
> reschedule which means there's no race window to hit anymore. But it
> would be better to put the TCONF condition into the test itself.
Interesting, I wonder if this is also true for the real-time kernel with
the threads set to RT priority?
--
Thank you,
Richard.
next prev parent reply other threads:[~2020-11-25 13:23 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-25 10:16 [LTP] [PATCH] fzsync: skip test when avaliable CPUs less than 2 Li Wang
2020-11-25 11:22 ` Richard Palethorpe
2020-11-25 11:54 ` Cyril Hrubis
2020-11-25 11:57 ` Martin Doucha
2020-11-25 11:56 ` Martin Doucha
2020-11-25 12:50 ` Li Wang
2020-11-25 13:13 ` Cyril Hrubis
2020-11-25 13:23 ` Richard Palethorpe [this message]
2020-11-30 7:53 ` Joerg Vehlow
2020-11-30 8:14 ` Li Wang
2020-11-30 8:39 ` Joerg Vehlow
2020-11-30 9:03 ` Li Wang
2020-11-30 9:01 ` Richard Palethorpe
2020-11-30 14:16 ` Martin Doucha
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=87blflo9hx.fsf@suse.de \
--to=rpalethorpe@suse.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.