Received: by 2002:a05:6358:4e97:b0:b3:742d:4702 with SMTP id ce23csp3620739rwb; Tue, 16 Aug 2022 06:18:32 -0700 (PDT) X-Google-Smtp-Source: AA6agR51agBTtJ//9sk+NN+5vP/2/oFhyV4IkAo11bULfC93inIRar7Im28D5c07A51hI5zs6uOY X-Received: by 2002:a17:906:9c82:b0:6df:baa2:9f75 with SMTP id fj2-20020a1709069c8200b006dfbaa29f75mr13648855ejc.762.1660655912063; Tue, 16 Aug 2022 06:18:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660655912; cv=none; d=google.com; s=arc-20160816; b=TFeTyKzlcGXuXG6GwK1k8qcJHzVgIUe8Hv26Z3rIfC0BDBCAYC+DhM8PLtmY3CNxa6 FN5wZQC2OkbXOe33EUeuNY0BmfiybYz11C7JcrwEvG0xF3SPdo4Yf59rjJpDionsp23Q W+Db8QhxDDbg09jNfNM+Y4RR2XAuXhnhf/p1KNsfL5rKRvBlH0TrVDXjZm6z0+lnfcSL 9d5EIsfeWYZMMhEFmc+sokm63kZiTfRFq7GB1evizIjKxJr0wfYq2ZixXQKeqYTFZpbg JDyR7eWHypFp/XhoqXSYs4VIash8LtkTSiv9L7htTJTOCUCq2hPM7aqR4V8GIfr8Egki DoGg== 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=jYFy/Ap+uf26Gcpe/I0MSisZFVmPhCJtSmEvqbaImns=; b=SjwF+fHfau2II/t/13nP+0pwdQIXV9ojzh2+SFja1BcN3KNbh3kH2kpjYzZQGw1QpW YaWJ4q5R7VQQcuhE7P4Yy+oFj9nVcOWwLHWiZ3sIImfAJghCtQh1p3nq71eFJ3g73Vu6 v94NZcgYalMqmIRjKm3ghwY4a1IMO7izNaUlvBzKj8tmuqNsxYLpGOYHjQNe+d7LCuyY Q1+Br1xaSZajtywqtr0x6WEtsFOrluOnlmaBCo4VadiBX+STKxF8sCxb19Z6Nsjmdz3a 4HrraE/ibMTkMxzqgtnwb1+S5Mp7qi3CsbIbEC6NWOLLxoYE1yAWhtpEy2IDDgrG2NmY ixsQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@solid-run-com.20210112.gappssmtp.com header.s=20210112 header.b="TPm7sp/E"; 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 h15-20020a056402280f00b0044217256e13si11822576ede.441.2022.08.16.06.18.06; Tue, 16 Aug 2022 06:18:32 -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=@solid-run-com.20210112.gappssmtp.com header.s=20210112 header.b="TPm7sp/E"; 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 S235090AbiHPNGt (ORCPT + 99 others); Tue, 16 Aug 2022 09:06:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56574 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234759AbiHPNGc (ORCPT ); Tue, 16 Aug 2022 09:06:32 -0400 Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 09BDE60C9 for ; Tue, 16 Aug 2022 06:06:32 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id b142so5224610iof.10 for ; Tue, 16 Aug 2022 06:06:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=solid-run-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=jYFy/Ap+uf26Gcpe/I0MSisZFVmPhCJtSmEvqbaImns=; b=TPm7sp/EC7y75Bb9Hebx9wUeTQofUP3E8N5rnoRewYyUMY2eWw6qAfh2vaf06LqTso YjKjRjDFQEcsxNlFOM1iFupmE5nz6Q3XbtcBGZh25VL1dE4iLkyEx+d2OdQkCDQV4F1I Q3Gws5+w1yGxQXqr1/i3xdwfJnmv+szNLKS5kWYlfZBsfM5RmI/eB+NWZWPry33NMS3K 7KUwALiD/FTal89vHgf+W/bQjMhZ1WW4azMae9jdTw2nbZknuM1sk1Pi3+wD/VsqnjMN lZ7NcixEG9dmbkdfKcDkCLc/FtxPozmizq5rTPPr/72lRhKJj6KYyso7a0aS6JqLGCVp xn8g== 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=jYFy/Ap+uf26Gcpe/I0MSisZFVmPhCJtSmEvqbaImns=; b=GhX+2/exqQHMqenHZseXZrAyqq1cSeSSBkrUGSqDENMRYXuzwSPlesm5AC6puya5kM Ueo4ul5abNpA342XXQPDDsFSSpnvfTq/bdke3oBHs3YjeiEwdzvD8/z73tEb261VfjVl y4Vq8QHkcvYLAzf8nC4oN22LeZKjPCIAs6V0hm/7v3cbTWuLzC43EJ7926rgneDyMYEo Zbg1xvjvhD22ELuB3dC+HWEfgLJh9sLwDlL6JUF3SDL4aR89z5ruMHV7gYsSw8iPgvfA N+DA/G669D/7spGjwjGGS431EpYj2l4kyc0/1DRJFb/8+N3JaYuPpAQhYe2SHOkrDtiq qEPg== X-Gm-Message-State: ACgBeo09+ojrOZ6071DaAmdv7t99bUr6kBWQrBWFdJ4UE/wTAxfak+sa TqSVaie83p9gHL+NsC12VgMigyVFxPdWX0Z5WVKBAQ== X-Received: by 2002:a05:6638:d45:b0:343:2ae6:e39a with SMTP id d5-20020a0566380d4500b003432ae6e39amr9740158jak.139.1660655191422; Tue, 16 Aug 2022 06:06:31 -0700 (PDT) MIME-Version: 1.0 References: <20220816070311.89186-1-marcan@marcan.st> <20220816130048.GA11202@willie-the-truck> In-Reply-To: <20220816130048.GA11202@willie-the-truck> From: Jon Nettleton Date: Tue, 16 Aug 2022 15:05:54 +0200 Message-ID: Subject: Re: [PATCH] locking/atomic: Make test_and_*_bit() ordered on failure To: Will Deacon Cc: Arnd Bergmann , Hector Martin , Peter Zijlstra , Ingo Molnar , Alan Stern , Andrea Parri , Boqun Feng , Nicholas Piggin , David Howells , Jade Alglave , Luc Maranget , "Paul E. McKenney" , Akira Yokosawa , Daniel Lustig , Joel Fernandes , Mark Rutland , Jonathan Corbet , Tejun Heo , jirislaby@kernel.org, Marc Zyngier , Catalin Marinas , Oliver Neukum , Linus Torvalds , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Asahi Linux , stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham 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 Tue, Aug 16, 2022 at 3:01 PM Will Deacon wrote: > > On Tue, Aug 16, 2022 at 02:29:49PM +0200, Jon Nettleton wrote: > > On Tue, Aug 16, 2022 at 10:17 AM Arnd Bergmann wrote: > > > > > > On Tue, Aug 16, 2022 at 9:03 AM Hector Martin wrote: > > > > > > > > These operations are documented as always ordered in > > > > include/asm-generic/bitops/instrumented-atomic.h, and producer-consumer > > > > type use cases where one side needs to ensure a flag is left pending > > > > after some shared data was updated rely on this ordering, even in the > > > > failure case. > > > > > > > > This is the case with the workqueue code, which currently suffers from a > > > > reproducible ordering violation on Apple M1 platforms (which are > > > > notoriously out-of-order) that ends up causing the TTY layer to fail to > > > > deliver data to userspace properly under the right conditions. This > > > > change fixes that bug. > > > > > > > > Change the documentation to restrict the "no order on failure" story to > > > > the _lock() variant (for which it makes sense), and remove the > > > > early-exit from the generic implementation, which is what causes the > > > > missing barrier semantics in that case. Without this, the remaining > > > > atomic op is fully ordered (including on ARM64 LSE, as of recent > > > > versions of the architecture spec). > > > > > > > > Suggested-by: Linus Torvalds > > > > Cc: stable@vger.kernel.org > > > > Fixes: e986a0d6cb36 ("locking/atomics, asm-generic/bitops/atomic.h: Rewrite using atomic_*() APIs") > > > > Fixes: 61e02392d3c7 ("locking/atomic/bitops: Document and clarify ordering semantics for failed test_and_{}_bit()") > > > > Signed-off-by: Hector Martin > > > > --- > > > > Documentation/atomic_bitops.txt | 2 +- > > > > include/asm-generic/bitops/atomic.h | 6 ------ > > > > > > I double-checked all the architecture specific implementations to ensure > > > that the asm-generic one is the only one that needs the fix. > > > > > > I assume this gets merged through the locking tree or that Linus picks it up > > > directly, not through my asm-generic tree. > > > > > > Reviewed-by: Arnd Bergmann > > > > > > _______________________________________________ > > > linux-arm-kernel mailing list > > > linux-arm-kernel@lists.infradead.org > > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > > > Testing this patch on pre Armv8.1 specifically Cortex-A72 and > > Cortex-A53 cores I am seeing > > a huge performance drop with this patch applied. Perf is showing > > lock_is_held_type() as the worst offender > > Hmm, that should only exist if LOCKDEP is enabled and performance tends to > go out of the window if you have that on. Can you reproduce the same > regression with lockdep disabled? > > Will Yep I am working on it. We should note that config LOCKDEP_SUPPORT def_bool y is the default for arm64 -Jon