Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp1163657ybh; Sat, 14 Mar 2020 19:49:52 -0700 (PDT) X-Google-Smtp-Source: ADFU+vuZuioqBTTGlIj3CTxEFab89e/cu3XOeQ5FRGOngIwv4HGpgLOzbpt+qrhCcQoA4Z21cyj+ X-Received: by 2002:a9d:64ca:: with SMTP id n10mr17616825otl.325.1584240592334; Sat, 14 Mar 2020 19:49:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584240592; cv=none; d=google.com; s=arc-20160816; b=nf/p/ZjcVMbzOYCBQpy6YgvIGKoYwSsV1/m5jmnOnDDJG1cn/SdzsuxuS43gD18lfC gay6Y7Sz8tkRWBbNV2jF00ldkkDblmbCMitLu+jMWnIKzHmlfvgHd+2e5qNUbfBMi+OT saNBiaUAlmjT5+v4ZBoyTnn7rrWr8D1IhQjWXTR+T9/IXthZxztBBuKYR7/shL7o8vkD MoUlWRwm2uDRmaHwI2M0PxH2Wl7VsQdOMMWTG6Xwrg+Zd8OUIDPBR6GT1qMAUTuT/sBE mUG0UqBCOqJ7QsPqCOtOmBfQ/cOfsRTlKWweeWrCbet+sNduz7zpoP3X7/ad3eaF4Y39 VNaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=YPgN4l93OeEWMDSYtyHK2xEec1H49aBedq26BrSDmkA=; b=ltg61HPTaOJtihTQG9g6V5s3pHg2mbp0/lG+W8fGOqn4SSb7A27xDvSZyoZYXbxmvY s13XO2hIokpZC3Ujkq7U8lsM5lf8d+JXvWfr6zk3TPn6luGOIi4pK/TgHgzxk8EgHkJM dSGV1zzejqOqJk2rwvTGQYUWACPDvK05706qnWJoOTvW9xujqxXfi5xspOxNEOaOU67E Oy3QqL6z8S0e2FSN8P94UXUcS9k3t1W2dbZOC4pAzKTX91koeVWh52pe50WQTcqTzkf6 IdOYrS6HfNp2qKGN91SJFn6+AvLAlyFFbaEFKV+CBPLq/rTEFo6gji7aE/Z+trFgpS+x P/CA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=eAS3kn7v; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u137si4094164oie.160.2020.03.14.19.49.40; Sat, 14 Mar 2020 19:49:52 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=eAS3kn7v; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727498AbgCOCtG (ORCPT + 99 others); Sat, 14 Mar 2020 22:49:06 -0400 Received: from mail-ed1-f68.google.com ([209.85.208.68]:37333 "EHLO mail-ed1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726811AbgCOCtF (ORCPT ); Sat, 14 Mar 2020 22:49:05 -0400 Received: by mail-ed1-f68.google.com with SMTP id b23so17427398edx.4 for ; Sat, 14 Mar 2020 19:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YPgN4l93OeEWMDSYtyHK2xEec1H49aBedq26BrSDmkA=; b=eAS3kn7vfdKKx02/krekDoFV619IUUiDr+1OClPUae5Ij8mqsEA+MjuC5/3521kbs7 dxE5vpUPD0EmtOE4s6uxCLkrZDRvo36YV0uzX/AMD4xWRqc6VgorbY3sI9ARwyAXHRcr 7ixd9w7pQfxwxGBFVI6FnfuMgRvvfwKxQgyx4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YPgN4l93OeEWMDSYtyHK2xEec1H49aBedq26BrSDmkA=; b=K88v4iC9+VZGh13qYPs4+gsUtXREnl9muHdXtVX4mYKQfrJYksxN11B4z7GPmnxEuq IdEZd00Zqgtzt1UREG2ZlFPmE2PNR5FtbrfbwcFSuztAnNtyiFGatVi0VViY0aJjzTpx Yt6PWcDca6txfUrj+Eglhfu1vyPn5vS/WnJG8HOhvAgio1H5SaXAUcKo0msf0rHW5K9/ 69dycFsX8Dy58O2+0+69CNRWgnnK/N75+V6FtmS3KzOK68SwtxxMDXs9o52x7qDsTDPU 0AQDHrPaosTDNNvwINSHdGnOk0BouG4o/xxtSygeDpWRqREkIj7txeDHSWd/2Nc+XFgf 7Kyg== X-Gm-Message-State: ANhLgQ0ynfglMLID2/akBfAsVQ0pDIRQkCNosqqj2PeL3vp0Vc2dJmry RjhJ716dp8vtP2VKVLxnv5xirSaplaU= X-Received: by 2002:ac2:53b8:: with SMTP id j24mr11718626lfh.79.1584200426093; Sat, 14 Mar 2020 08:40:26 -0700 (PDT) Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com. [209.85.208.170]) by smtp.gmail.com with ESMTPSA id h10sm3451859ljg.38.2020.03.14.08.40.24 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 14 Mar 2020 08:40:25 -0700 (PDT) Received: by mail-lj1-f170.google.com with SMTP id u12so13883656ljo.2 for ; Sat, 14 Mar 2020 08:40:24 -0700 (PDT) X-Received: by 2002:a05:651c:555:: with SMTP id q21mr11396356ljp.241.1584200424436; Sat, 14 Mar 2020 08:40:24 -0700 (PDT) MIME-Version: 1.0 References: <20200313174701.148376-1-bigeasy@linutronix.de> <20200313174701.148376-6-bigeasy@linutronix.de> In-Reply-To: <20200313174701.148376-6-bigeasy@linutronix.de> From: Linus Torvalds Date: Sat, 14 Mar 2020 08:40:08 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 5/9] completion: Use simple wait queues To: Sebastian Andrzej Siewior Cc: Linux Kernel Mailing List , Peter Zijlstra , Ingo Molnar , Will Deacon , "Paul E . McKenney" , Joel Fernandes , Steven Rostedt , Thomas Gleixner Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 13, 2020 at 10:47 AM Sebastian Andrzej Siewior wrote: > > Replace the wait queue in the completion with a simple wait queue (swait), This is almost certainly completely and utterly wrong. Every time somebody uses those horrible swait queues, the end result is buggy. Don't do it. And most definitely, don't do it like this, which seems to be entirely mindlessly just randomly changing things by some brute force in multiple places. The swait semantics are completely different from the normal wait-queue semantics, and generally not in good ways. There's a *REASON* why the comment at the top of starts with * BROKEN wait-queues. * * These "simple" wait-queues are broken garbage, and should never be * used. The comments below claim that they are "similar" to regular * wait-queues, but the semantics are actually completely different, and * every single user we have ever had has been buggy (or pointless). and before you do a conversion, you need to spend a _lot_ of time thinking about why that is the case. And _after_ you do the conversion, you damn well need to explain why it's safe. Not just state that it's a good idea. For example, this patch just randomly changes wait events to the swait event _exclusive_ waits. With not a single explanation of why that would be ok. I want an explanation for EVERY SINGLE CASE. Because people have done this kind of conversion before, and it's been buggy garbage before. I want to see that people actually thought about what the semantic differences were, and _documented_ that thinking process. Linus