From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753505AbdK3Chm (ORCPT ); Wed, 29 Nov 2017 21:37:42 -0500 Received: from mail-it0-f41.google.com ([209.85.214.41]:40630 "EHLO mail-it0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752801AbdK3Chl (ORCPT ); Wed, 29 Nov 2017 21:37:41 -0500 X-Google-Smtp-Source: AGs4zMbl4P4vSp0QPx41tOvw9R0WaboixPsCOXHonCTLmb9DJ0550ktpmQ/dzcSBdbFpB6ygRUSnIgX6q/bUZw8iO48= MIME-Version: 1.0 In-Reply-To: <20171130005828.GA15628@vader> References: <20171130005828.GA15628@vader> From: Linus Torvalds Date: Wed, 29 Nov 2017 18:37:40 -0800 X-Google-Sender-Auth: hEABWZ2f2_lK5b9aQneb2f__obc Message-ID: Subject: Re: add_wait_queue() (unintentional?) behavior change in v4.13 To: Omar Sandoval Cc: Ingo Molnar , Linux Kernel Mailing List , Jens Axboe Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 29, 2017 at 4:58 PM, Omar Sandoval 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