<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 8, 2022 at 12:56 AM Jan Stancek <<a href="mailto:jstancek@redhat.com">jstancek@redhat.com</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">TST_THREAD_STATE_WAIT isn't reliable to tell that it's safe to call futex_wake().<br>
futex_wake() can be called prematurely and return 0, which leaves other thread<br>
timing out on futex call:<br>
  tst_test.c:1459: TINFO: Timeout per run is 0h 10m 00s<br>
  futex_waitv03.c:37: TINFO: Testing variant: syscall with old kernel spec<br>
  tst_buffers.c:55: TINFO: Test is using guarded buffers<br>
  futex_waitv03.c:106: TBROK: futex_waitv returned: -1: ETIMEDOUT (110)<br>
<br>
Replace it with repeated futex_wake() until it fails or wakes at least 1 waiter.<br>
Also extend timeout to 5 seconds to avoid false positives from systems with<br>
high steal time (e.g. overloaded s390x host).<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Though TST_THREAD_STATE_WAIT is unreliable, I guess that would</div><div class="gmail_default" style="font-size:small">still add more chances if we keep it? </div><div class="gmail_default" style="font-size:small">(I mean go with repeat futex_wake() after checking 'S' state)</div></div><div><br></div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Regards,<br></div><div>Li Wang<br></div></div></div></div>