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

[Cyril Hrubis]

Hi!
> Any thoughts about my last reply?

Sorry this fallen out of my radar since I've been off previous week.

> > > > > 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

Sounds reasonable to me.

-- 
Cyril Hrubis
chrubis@suse.cz