Received: by 2002:a05:6358:5282:b0:b5:90e7:25cb with SMTP id g2csp3319804rwa; Tue, 23 Aug 2022 02:45:34 -0700 (PDT) X-Google-Smtp-Source: AA6agR5UP3e3Bnateg0hlxxBr3dc4UwNso8ZFKZc+/lzHv7VlZ7rFerB2ysRNM+oKYy03okrLfmM X-Received: by 2002:a05:6402:538a:b0:43a:298e:bc2b with SMTP id ew10-20020a056402538a00b0043a298ebc2bmr2872162edb.125.1661247933832; Tue, 23 Aug 2022 02:45:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661247933; cv=none; d=google.com; s=arc-20160816; b=sT2tK58ccA8/eKKioXBBSmQtgUWFm+n/9wDwyDeu5ew8dM6lZcy67Gb1Fws9EZzfyb O2CnOcMk6DbOgqGAKdy7n4aaH+b7rixWDb/Mz+gmiPavRVOE1wOYo8km9dG5zc5wrYZJ sBkNx+/rJH80Qjxn4+JZv54ManXexAOVXHcjSCkI2dSJHecKuf6Y+5Vu8JUf9n6TKpJn PUx09Cet3PJ+KOuZM2TlaktCXNCdz0RyCPf/BorWMF6I/VBPxuRoxs4cnnC00AMEUQvK 4++yCxW+CWMw+YoKv538o7JcFUIUYbVvyKEVNUuQbKsG77Rru0XLxa57Ru82zEcY4iyB mnlg== 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=67W9vBS5d8SUafsmXmewmJy1NGIIvBLDnPwQtJ1KcD4=; b=kPYHkkKlNeA7NMQgSYzcrgjbMsG4RrDyx9L096q5HxdpG8qWuxj7uviqD3fUV6F5Aj P51a/EWLPzWIl/k1Ihf7ZNARVRqAjRUst6ukUV9Lkttib/DMwZ1s+RmGEYdz9Y6eT4I9 1sOp4vIu7Nrjd8iQjPal3RqcTkzgpKIadYUwrWFQfm7iWSWFV/QTpmQF1cVuJZfkeNSZ Fls7mmhSOwCXuQ0fCUc3hfyufUb5DFlxCpH6jB3F9M78+aTb79L1x+uwAMTyXxP/YDSH VE0Zo3JjwJEJ9Fww5KE2UBdOKV0o5ntoLWyaIl85aDwqThdhc2sdvV0Kz3G8Xf5oFVuS ElQQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=HjnQn7h6; 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 a26-20020a170906245a00b0073d9a032af2si1235569ejb.919.2022.08.23.02.45.08; Tue, 23 Aug 2022 02:45:33 -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=HjnQn7h6; 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 S240533AbiHWILm (ORCPT + 99 others); Tue, 23 Aug 2022 04:11:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59792 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241830AbiHWIJY (ORCPT ); Tue, 23 Aug 2022 04:09:24 -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 B21FC66A65; Tue, 23 Aug 2022 01:06:09 -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 3F08EB81C18; Tue, 23 Aug 2022 08:06:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 90AD5C433C1; Tue, 23 Aug 2022 08:06:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1661241966; bh=n/610ybo0Q8VX/qdPiQAgzKGu5QXTZKOJay/mqFZBEg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HjnQn7h6U2A+TJNBzZBsROU1qnEbAQY5qs7KlUTA4zWfNjrTdFj/Rpm1oKeUgj0Au eYIhNFuAqQV8h7ZfLNzoVU80QnqSuAvG6zJNnRYhdd80iesfAmYitio2Jx9Sjt01V5 hEvbSnOAcUTUVD+6Dbe3ynYSOET82/ditMCPOCD8= 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 5.19 008/365] locking/atomic: Make test_and_*_bit() ordered on failure Date: Tue, 23 Aug 2022 09:58:29 +0200 Message-Id: <20220823080118.507275261@linuxfoundation.org> X-Mailer: git-send-email 2.37.2 In-Reply-To: <20220823080118.128342613@linuxfoundation.org> References: <20220823080118.128342613@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 @@ -39,9 +39,6 @@ arch_test_and_set_bit(unsigned int nr, v unsigned long mask = BIT_MASK(nr); p += BIT_WORD(nr); - if (READ_ONCE(*p) & mask) - return 1; - old = arch_atomic_long_fetch_or(mask, (atomic_long_t *)p); return !!(old & mask); } @@ -53,9 +50,6 @@ arch_test_and_clear_bit(unsigned int nr, unsigned long mask = BIT_MASK(nr); p += BIT_WORD(nr); - if (!(READ_ONCE(*p) & mask)) - return 0; - old = arch_atomic_long_fetch_andnot(mask, (atomic_long_t *)p); return !!(old & mask); }