lkml.org 
[lkml]   [2017]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: add_wait_queue() (unintentional?) behavior change in v4.13
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

\
 
 \ /
  Last update: 2017-11-30 03:38    [W:0.153 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site