Re: add_wait_queue() (unintentional?) behavior change in v4.13

[Linus Torvalds <torvalds@linux-foundation.org>]

On Wed, Nov 29, 2017 at 4:58 PM, Omar Sandoval <osandov@osandov.com> wrote:
>
> Note the change from __add_wait_queue() to
> __add_wait_queue_entry_tail(). I'm assuming this was a typo since the
> commit message doesn't mention any functional changes. This patch
> restores the old behavior:
>   [...]
> I didn't go through and audit callers of add_wait_queue(), but from a
> quick code read this makes it so that non-exclusive waiters will not be
> woken up if they are behind enough exclusive waiters, and I bet that'll
> cause some bugs.

This sounds right to me.

Ingo?

The "add to head of wait-queue" is nasty and causes unfair waiter
behavior, but it does have that exclusive waiter reason going for it.

In the page bit-wait queues, we actually did this change
_intentionally_ a few months ago (see commits

  3510ca20ece0 Minor page waitqueue cleanups
  9c3a815f471a page waitqueue: always add new entries at the end

but there it was intentional: an exclusive waiter on the bit
wait-queues is going to acquire the bit lock, which in turn means that
they'll eventually release the bit lock and then wake up any
subsequent non-exclusive waiters, so the non-exclusive ones _will_ get
woken up eventually (and in a fair order).

Sadly, when it comes to wait-queues in general, we don't have those
kinds of guarantees. An exclusive waiter is going to use the resource,
but there's no fundamental reason to believe that non-exclusive
waiters will be woken up again (although in practice it's probably
very rare that they wouldn't).

                Linus