* Davidlohr Bueso <d...@stgolabs.net> wrote: > @@ -1674,13 +1689,19 @@ retry_private: > } > > /* > - * Wake nr_wake waiters. For requeue_pi, if we acquired the > - * lock, we already woke the top_waiter. If not, it will be > - * woken by futex_unlock_pi(). > + * For requeue_pi, if we acquired the lock, we already woke > + * the top_waiter. If not, it will be woken by futex_unlock_pi. > + * > + * The regular (non-pi) case is much simpler: Wake the top > + * waiter (next in line) and repeat. > */ > - if (++task_count <= nr_wake && !requeue_pi) { > - wake_futex(this); > - continue; > + if (!requeue_pi) { > + if (!wake_futex(this)) { > + ret = -EINVAL; > + break; > + } > + if (++task_count <= nr_wake) > + continue; > } >
Hm, so at a first glance this change appears to go beyond the scope of adding a return value to wake_futex()? For example before the change in the !requeue_pi case we'd only call wake_futex() if ++task_count <= nr_wake, after the change we always call it. What's the intention here? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/