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

[Jan Stancek]

On Tue, Jul 12, 2022 at 10:33 AM Li Wang <liwang@redhat.com> wrote:
>
>
>
> 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>

Pushed.

>
>
> --
> Regards,
> Li Wang