<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Hi Joerg,</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 30, 2020 at 3:53 PM Joerg Vehlow <<a href="mailto:lkml@jv-coder.de" target="_blank">lkml@jv-coder.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
>> No, af_alg07 requires 2 CPUs, otherwise it'll report false positives.<br>
>> The test will pass only if fchownat() hits a half-closed socket and<br>
>> returns error. But IIRC the half-closed socket will be destroyed during<br>
>> reschedule which means there's no race window to hit anymore. But it<br>
>> would be better to put the TCONF condition into the test itself.<br>
> Interesting, I wonder if this is also true for the real-time kernel with<br>
> the threads set to RT priority?<br>
It looks like the test can fail even with more than one cpu. I've seen <br>
this sporadic failure on different hardware with more than two cores, at <br>
least on intel denverton (x86_64) and renesas r-car (aarch64) systems. <br>
Both with kernel 4.19 with the fix included, on the denverton system the <br>
rt parches were included and on the r-car not. The test passes most of <br>
the time, but sometimes fails with the message Li posted.<br>
<br>
It also seems to fail sporadically on other systems as well: <br>
<a href="https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1892860" rel="noreferrer" target="_blank">https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1892860</a><br>
<br>
Additionally I tested on qemu-x86 with 4.19 with and without rt patches. <br>
The test succeeds even with only one virtualized cpu. So either Martin's <br>
assumption is wrong or it holds only for newer kernel versions?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">No, Mertin is not wrong, and you are also right. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">They are totally two different issues of af_alg07, the test on 1CPU</div><div class="gmail_default" style="font-size:small">should be fixed with TCONF. But the fail with aarch64 is more like a</div><div class="gmail_default" style="font-size:small">hardware issue, Chunyu has a drafted patch to add init delay value for</div><div class="gmail_default" style="font-size:small">such a system.</div></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Can you try this on your aarm64 platform?</div><div class="gmail_default" style="font-size:small">-----------------------------</div><div class="gmail_default" style="font-size:small">fzsync can't get a random delay range on hpe-moonshot systems, so run with<br>delay=0 during all the tests. This is probably the hardware issue such as<br>cache line design so can't get a stable state during the execution of the critical<br>section. Provide an experience delay value on hpe-moonshot to make it hit<br>the race window immediately without exceeding samples.<br><br>---<br> testcases/kernel/crypto/af_alg07.c | 1 +<br> 1 file changed, 1 insertion(+)<br><br>diff --git a/testcases/kernel/crypto/af_alg07.c b/testcases/kernel/crypto/af_alg07.c<br>index 6ad86f4f3..24f5b8088 100644<br>--- a/testcases/kernel/crypto/af_alg07.c<br>+++ b/testcases/kernel/crypto/af_alg07.c<br>@@ -47,6 +47,7 @@ static void setup(void)<br>       fd = SAFE_OPEN("tmpfile", O_RDWR | O_CREAT, 0644);<br> <br>     tst_fzsync_pair_init(&fzsync_pair);<br>+      fzsync_pair.delay_bias = 700;<br> }<br> <br> static void *thread_run(void *arg)<br>-- <br>2.19.1<br></div></div><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div>Regards,<br></div><div>Li Wang<br></div></div></div></div>