[LTP] [PATCH] syscalls/futex_waitv03: replace TST_THREAD_STATE_WAIT with repeated wake

[Li Wang]

On Tue, Jul 12, 2022 at 4:00 PM Jan Stancek <jstancek@redhat.com> wrote:

> On Mon, Jul 11, 2022 at 9:17 AM Li Wang <liwang@redhat.com> wrote:
> >
> >
> >
> > On Fri, Jul 8, 2022 at 12:56 AM Jan Stancek <jstancek@redhat.com> wrote:
> >>
> >> TST_THREAD_STATE_WAIT isn't reliable to tell that it's safe to call
> futex_wake().
> >> futex_wake() can be called prematurely and return 0, which leaves other
> thread
> >> timing out on futex call:
> >>   tst_test.c:1459: TINFO: Timeout per run is 0h 10m 00s
> >>   futex_waitv03.c:37: TINFO: Testing variant: syscall with old kernel
> spec
> >>   tst_buffers.c:55: TINFO: Test is using guarded buffers
> >>   futex_waitv03.c:106: TBROK: futex_waitv returned: -1: ETIMEDOUT (110)
> >>
> >> Replace it with repeated futex_wake() until it fails or wakes at least
> 1 waiter.
> >> Also extend timeout to 5 seconds to avoid false positives from systems
> with
> >> high steal time (e.g. overloaded s390x host).
> >
> >
> > Though TST_THREAD_STATE_WAIT is unreliable, I guess that would
> > still add more chances if we keep it?
> > (I mean go with repeat futex_wake() after checking 'S' state)
>
> We could keep it, though I'm not sure what benefit that has. You
> would probably make fewer calls to futex_wake(). Without it,
> the window where wake and wait calls are made in parallel
> is larger, and it also makes test simpler.
>

Yes, that helps reduce the tries of futex_wake() to make the test faster.
But not benefit a lot compared with removing.

So feel free to merge it as you wish, I think it's OK with both.

Reviewed-by: Li Wang <liwang@redhat.com>


-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20220712/77cae5e8/attachment.htm>