Received: by 2002:a05:6358:5282:b0:b5:90e7:25cb with SMTP id g2csp2600870rwa; Mon, 22 Aug 2022 10:13:55 -0700 (PDT) X-Google-Smtp-Source: AA6agR5kIr4H0aYH4nA3y/jgD/kZN8Xs9JQ9shKZVW+4qEqSOKDn0KKdkF6YmYcSxnX63hFSICMg X-Received: by 2002:a05:6402:34d5:b0:446:cc39:2d38 with SMTP id w21-20020a05640234d500b00446cc392d38mr136710edc.171.1661188434760; Mon, 22 Aug 2022 10:13:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661188434; cv=none; d=google.com; s=arc-20160816; b=PM0opvEOXtithUly0eVFv/J6ohBiPkCJRLUYfBQUxEsjiN6plcVvyt9LN1CTUsF3lu Ug/5szEX0GndIbH/uW18+0IB0JRl0fydtTQzgZslVWe7EGadjjUubGh4JR0b8y0tktIF V7/3osas3pQl2OT7/li2mFUloNxuUZ0btbYcZ7FHOgpDD/Hcv8DHFAuIybhavVPC55zr MabHb+cChSXMW89gx1iZnTHHComeJrLgalLul4hcBaLwQLNa5RkwuXOyaS2PClUGZ6jf RSSrEnjlQTBWsaFSGHL/+q7ALO69rLFGJEwSAigidHaJmvRgPM/9YWDfoj1T6TzlIgFm koBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=FBSmStkotiGF5Og7ExawLkOys7P/24UjQfsLmwYIr/M=; b=xIvBHm/lBiEhxHw1syqMccDNY0fFVPtiCko+9f/spSvfO5yxG3iXTnK9pB3u4tRE2T cVa13yjU9+i4nYD0rnYsyVOe/ErD3+v/hNeopV8QPf01UoLpYitxMt2JiH8GS53JFMpM SXYee37HKJeqjPK1/fVL51XySl6W7eqiqknRHWhDvOKGzmTBFInZuBIW5vAAyDJV5+qI /tmI8I19i73UG8iTAXuNp5Ac0iTOQDh88ayh3cAVWBAPSFVJgmlweiLY93Kk9olNN4/Q GvqwQKY0k4ZIcvNv0LhK2D7/fY5B7wk1fFGwz6kNsiWZhD2lH9BwGA77TmCwjnxiKts9 wj7w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=a1uslqfz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sc34-20020a1709078a2200b00734c8b99826si9131937ejc.803.2022.08.22.10.13.27; Mon, 22 Aug 2022 10:13:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=a1uslqfz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236991AbiHVRKR (ORCPT + 99 others); Mon, 22 Aug 2022 13:10:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56940 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234096AbiHVRJw (ORCPT ); Mon, 22 Aug 2022 13:09:52 -0400 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9F80C422FC for ; Mon, 22 Aug 2022 10:09:08 -0700 (PDT) Received: by mail-ej1-x632.google.com with SMTP id ca13so11255349ejb.9 for ; Mon, 22 Aug 2022 10:09:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=FBSmStkotiGF5Og7ExawLkOys7P/24UjQfsLmwYIr/M=; b=a1uslqfzoUrzXGd0AtZpa/7qVFuOyaBocH8utbCHMh+IkSOo3bi2iA+PM0xZRNUJXv t1cspoXmBEBzEkIS9Wllb9Qh/U1c5tYnnJ4nHm80ZZthOK6BkFbBx1u7VhL2Ep9q2HGo sz1FnS+mb8UOtjAbiizHgEwMu4Gfjzk0Cl1cM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=FBSmStkotiGF5Og7ExawLkOys7P/24UjQfsLmwYIr/M=; b=Ztgs2yfOZgeYw7MoQ9unVl16Gm9bCs8SOGrhl8Pzx/D4MvXKssZ3aZTCJM1o/aly7d xCdX9d1dlxdAFxsv0t4rDtTNVIhrC5CjuRypAgDh0zEmommFHwR2wMWwJvfdVD2f0eR2 h/XOp3vKZKwCieur+Nxm4OUZ0NSN6ch6d6jbjE7MVRtWoKjagXViwuKbpCxuGUa6aziu tB48QYV8JtTNdd2mdcTzzpSVtVCK3cmsXg4xFRX89jQ1B01+6V/huQig8ckOLIkWxaXd SUX2FvN1N6MB7Z3nBq+7HJiBSUc8oveODDTH55csM4EXR56gsmMsoraz8eGpZEL4fPwv AXhA== X-Gm-Message-State: ACgBeo1varbUimvS2+1s5D+QMtaS8Edjq68jgggyHQzKsmmKJSomt8Ch tjVkGXiyj1KAdTFBhe/Yx0/LAaQlu6uWVj2l X-Received: by 2002:a17:906:9bd8:b0:73d:83d1:2222 with SMTP id de24-20020a1709069bd800b0073d83d12222mr3250852ejc.557.1661188146313; Mon, 22 Aug 2022 10:09:06 -0700 (PDT) Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com. [209.85.128.41]) by smtp.gmail.com with ESMTPSA id 2-20020a170906218200b0073306218484sm6405339eju.26.2022.08.22.10.09.05 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Aug 2022 10:09:05 -0700 (PDT) Received: by mail-wm1-f41.google.com with SMTP id l33-20020a05600c1d2100b003a645240a95so4008900wms.1 for ; Mon, 22 Aug 2022 10:09:05 -0700 (PDT) X-Received: by 2002:a05:600c:657:b0:3a5:e4e6:ee24 with SMTP id p23-20020a05600c065700b003a5e4e6ee24mr15334285wmm.68.1661188144843; Mon, 22 Aug 2022 10:09:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Linus Torvalds Date: Mon, 22 Aug 2022 10:08:48 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] wait_on_bit: add an acquire memory barrier To: Mikulas Patocka Cc: Alan Stern , Andrea Parri , Will Deacon , Peter Zijlstra , Boqun Feng , Nicholas Piggin , David Howells , Jade Alglave , Luc Maranget , "Paul E. McKenney" , Akira Yokosawa , Daniel Lustig , Joel Fernandes , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 22, 2022 at 2:39 AM Mikulas Patocka wrote: > > I'd like to ask what do you think about this patch? I really don't like it. It adds a pointless read barrier only because you didn't want to do it properly. On x86, it doesn't matter, since rmb is a no-op and only a scheduling barrier (and not noticeable in this case anyway). On other architectures, it might. But on all architectures it's just ugly. I suggested in an earlier thread that you just do it right with an explicit smp_load_acquire() and a manual bit test. So why don't we just create a "test_bit_acquire()" and be done with it? We literally created clear_bit_unlock() for the opposite reason, and your comments about the new barrier hack even point to it. Why is "clear_bit_unlock()" worthy of a real helper, but "test_bit_acquire()" is not and people who want it have to use this horrendous hack? Please stop adding random barriers already. Just do it right. I've said this before, why do you then keep doing this and asking for comments? My reply will remain the same: JUST DO IT RIGHT. Linus