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

[Jan Stancek <jstancek@redhat.com>]

Any thoughts about my last reply?

----- Original Message -----
> 
> 
> ----- 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
> 
> 
> --
> Mailing list info: https://lists.linux.it/listinfo/ltp
> 
>