Received: by 2002:a05:6358:5282:b0:b5:90e7:25cb with SMTP id g2csp3415872rwa; Tue, 23 Aug 2022 04:31:58 -0700 (PDT) X-Google-Smtp-Source: AA6agR41togV8UzILoXpEa+OUFq7684qWU3waXuvBQuR7OuU8AfUWu6XTqzWSIDoe9CqgvsWsgtl X-Received: by 2002:a17:907:9623:b0:73d:8c1c:5da with SMTP id gb35-20020a170907962300b0073d8c1c05damr4540912ejc.7.1661254218146; Tue, 23 Aug 2022 04:30:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661254218; cv=none; d=google.com; s=arc-20160816; b=YiQJrwyiI/32tYH3EFNGHcaBtGpJ8TtERHVunWsh2tBFCffQRAygay0QiIsCi7OZ6+ cU/JOi3r1b5GBmkPqLwXeoee57kdMwlG5w5CFaRWq90Ych2buCtBCLyWszZCjwYlSl0R VIn0zAyNYdZOgDmvzKb6m8XRgcqSrMxWempdjWI1Tf8vIEPUhCeWs/FonXJguTLfugUh gV0RVZnNVHaRmKraeyTBfYek9d8vo/i4wkoD8TfmtYOrtrE6Pg/25QrYxZ0KKfb8tyNH yL1v3NQ98M3lZ4B9CWHfyzs6BCFYkCShXRA4CIs+76Fmlmo8cx9F2pVdBtL76V4/jR8r BFcA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=bo5FHdQ/qj3ZC3FPnJDClfiBHoPu3VXgoGiQ4I2FIkc=; b=sggrlSEsOYyLUkTFffv/GOITTAG4rCrcdubAEvzjD4CNjU6SPX5Zt5Qq91dwgXcz8v BVT7Q7eBpxJDDEoRMgkUncYwHip55X4y+J2jecoKUoJCqveYkSCgiXk8dJ2U0CDUsCEz AfOCeGzfs2G93xwZoyFYxxUtd8u82z70VCwEDE4+V5fnXZg0HJSNcBqWzHx4VB3RKG1E 0PjEmRCENQu5LFAMAFmziqEYqf7qXteAVr9qlk+3LHWvbhboEMgKstybaqIp9EDfi8bs hYRJQx+73ThhY2O3z1NjKpE07VfEtgpgOUmu2HR0PjNKbxbwLLPUrsAd2UYtxBRSP7Yz /nww== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=XmpshZIi; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q20-20020a170906541400b0073d6b88fdc7si6887014ejo.738.2022.08.23.04.29.50; Tue, 23 Aug 2022 04:30:18 -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=@linuxfoundation.org header.s=korg header.b=XmpshZIi; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1355951AbiHWK61 (ORCPT + 99 others); Tue, 23 Aug 2022 06:58:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54878 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1356550AbiHWKyS (ORCPT ); Tue, 23 Aug 2022 06:54:18 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 23B132DC7; Tue, 23 Aug 2022 02:13:17 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 63310B81C88; Tue, 23 Aug 2022 09:13:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B10C0C433C1; Tue, 23 Aug 2022 09:13:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1661245994; bh=+cQueMhG49MjrWyekbaH7KLGxxmn10UFrF2aTy84y2Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XmpshZIi48SWWkXsO2Oali1j4HNNlNIOKUIQiC0Bl4iuwIS255deAAj6NR3velFey C8Wrb6RJDAsM7h6T0fz1o+t+o9PvoEC55tE/QzluioQd0L+/7T7IxYvuxzbhBfzIjo siiwIcOmXautNSXFuNDO9GiYAPHqm0U/5AOsEPbY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Linus Torvalds , Hector Martin , Will Deacon , Arnd Bergmann Subject: [PATCH 4.19 256/287] locking/atomic: Make test_and_*_bit() ordered on failure Date: Tue, 23 Aug 2022 10:27:05 +0200 Message-Id: <20220823080109.872293149@linuxfoundation.org> X-Mailer: git-send-email 2.37.2 In-Reply-To: <20220823080100.268827165@linuxfoundation.org> References: <20220823080100.268827165@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, 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 From: Hector Martin commit 415d832497098030241605c52ea83d4e2cfa7879 upstream. 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 Acked-by: Will Deacon Reviewed-by: Arnd Bergmann Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- Documentation/atomic_bitops.txt | 2 +- include/asm-generic/bitops/atomic.h | 6 ------ 2 files changed, 1 insertion(+), 7 deletions(-) --- a/Documentation/atomic_bitops.txt +++ b/Documentation/atomic_bitops.txt @@ -59,7 +59,7 @@ Like with atomic_t, the rule of thumb is - RMW operations that have a return value are fully ordered. - RMW operations that are conditional are unordered on FAILURE, - otherwise the above rules apply. In the case of test_and_{}_bit() operations, + otherwise the above rules apply. In the case of test_and_set_bit_lock(), if the bit in memory is unchanged by the operation then it is deemed to have failed. --- a/include/asm-generic/bitops/atomic.h +++ b/include/asm-generic/bitops/atomic.h @@ -35,9 +35,6 @@ static inline int test_and_set_bit(unsig unsigned long mask = BIT_MASK(nr); p += BIT_WORD(nr); - if (READ_ONCE(*p) & mask) - return 1; - old = atomic_long_fetch_or(mask, (atomic_long_t *)p); return !!(old & mask); } @@ -48,9 +45,6 @@ static inline int test_and_clear_bit(uns unsigned long mask = BIT_MASK(nr); p += BIT_WORD(nr); - if (!(READ_ONCE(*p) & mask)) - return 0; - old = atomic_long_fetch_andnot(mask, (atomic_long_t *)p); return !!(old & mask); }