On Wed, Nov 29, 2017 at 4:58 PM, Omar Sandoval <osan...@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