[LTP] [PATCH v2] futex_cmp_requeue01: fix test expectations

[Jan Stancek <jstancek@redhat.com>]

----- Original Message -----
> Hi!
> > > Unless spurious wakeup has happened between the requeue and wake
> > > operation which means that the num_requeues can be smaller because we
> > > will wake up less than requeued processes. So if we sampled spurious
> > > wakeups before the requeue operation and after the futex_wake() for
> > > requeued processes and call it delta_spurious we would get a range:
> > > 
> > > TST_RET - num_requeues >= set_wakes
> > 
> > This doesn't look correct if we consider spurious wakeups:
> > 
> > 5 processes, set_wakes = 5, set_requeue = 0, 1 spuriously wakes up,
> > remaining 4 are woken up by futex(), 0 are requeued:
> > 
> > 4 - 0 >= 5
> 
> Well I was betting on the fact that we wake up much less processes than
> we attempt to lock on the futex and that waking up processes takes
> precedence. I we can add delta_spurious to the right side that wouldn't
> change much and we end up being correct all the time, i.e.
> 
> TST_RET + delta_spurious - num_requeues >= set_wakes

I'd go with just spurious instead of delta_spurious. If there is spurious
wake up before requeue (and first sample), wouldn't that fail in same way
as example above?

TST_RET + delta_spurious - num_requeues >= set_wakes
4 + 0 - 0 >= 5

Also delta_spurious looks racy, because it's based on counter
that is increased only after user-space gets chance to run. But process
may have been already removed from futex queue on kernel side.
So 'first sample before requeue' can see inaccurate state.

So I'd tweak your check to:
  set_wakes-spurious <= TST_RET-num_requeues <= set_wakes+spurious