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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFwhq-ZyDW2SYhYDg1ytKybwHywiH9jW3UmMu=YAgk694Q@mail.gmail.com>
Date:   Wed, 29 Nov 2017 18:37:40 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Omar Sandoval <osandov@...ndov.com>
Cc:     Ingo Molnar <mingo@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Jens Axboe <axboe@...com>
Subject: Re: add_wait_queue() (unintentional?) behavior change in v4.13

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