Received: by 2002:ac0:e350:0:0:0:0:0 with SMTP id g16csp2044328imn; Mon, 1 Aug 2022 09:07:13 -0700 (PDT) X-Google-Smtp-Source: AGRyM1svCYDKhey6VYfydesgGXx4mVFc/yrj56fxR0r7f8UFL9zyVuw3xWJwnnSGnMqfRiOaNyTk X-Received: by 2002:a17:907:2c78:b0:72b:64f5:11ea with SMTP id ib24-20020a1709072c7800b0072b64f511eamr13250781ejc.68.1659370033215; Mon, 01 Aug 2022 09:07:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659370033; cv=none; d=google.com; s=arc-20160816; b=ikabPqkzhLisK9qQQTc2f4K5UHMxis9/n4KcopZt3EnHJFBej2Vc3w9cIzw2U+h5pt lE56Zzhl+xqkmCoXPnUwZ22HVAmYFG0ZlAT4hRnS+Z7JBdf2d6sm46tMFOU422JsHgs+ woxPHxkfdyGOVNsp+INEzQ4ArXzgwZusIG1faXdYUNvcrdxwmhPC4dcIgLzFz6Gdroos lp/0PtxBLB6HeP+gCmWtllzGCb+8GD8ZPS9lYu4nIoDu9ypUPG9FPDryWSXuhxJ/mkm/ CZRVKOXF5VygzannTFyBFS7B0m0B7Pjb6t87HAOUmD3P5Z/2RJIZJE0O7FfDHb7rbQRu GpXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=bt7BMhE534IHwNmnOMClUV7zQIZFz/1HoPOHLnKB3nQ=; b=NksD6aHoQMCYISAjuozumaiUz1mt50pY/GXFL5BsIhMqigQKfIDw7M0d10qXunXqUT 0kNnRauDukjsFsIOVcMfY/wQjO2TFBqa9V51xsQk8brvytQnsc19ofO7bn1j8uM+WgSm mQLtSIt1mEZoKZ83GHIEZNbY8bW3xqWSn7lJTr4DPdH7NBnlSW/CrKSdDeHl9cuXYVBY cD46oDCGpo2T24AfWDuYxqdaoFKRDOLhHHEgnCi/c2XL4rIxLgsK3F5Ul5tkIidw60z3 qddy2E74hSEQxMFPemdPnrlPEK61FocEw3kTK3qt/ijMLE0KzOZVoXLzdfscKfuRsEVn Zb1g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=MzJVvG5h; 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=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id xa11-20020a170906fd8b00b00702d8b7438csi9577218ejb.326.2022.08.01.09.06.47; Mon, 01 Aug 2022 09:07:13 -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=@kernel.org header.s=k20201202 header.b=MzJVvG5h; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229780AbiHAPyw (ORCPT + 99 others); Mon, 1 Aug 2022 11:54:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54436 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233122AbiHAPye (ORCPT ); Mon, 1 Aug 2022 11:54:34 -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 847AF3DF1F; Mon, 1 Aug 2022 08:54:32 -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 3709AB81252; Mon, 1 Aug 2022 15:54:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7B4E7C433D7; Mon, 1 Aug 2022 15:54:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1659369270; bh=wETN0skpqza1G2a1AdifFLbckspm2eShjFjwhavetjw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=MzJVvG5h2GNIc1ys4vKYkGPP3l+3267DHrNX4BuxanV9KbqAyjyxn+l0CVZ4lTOEa eZvnjjtomrwFK7j8a/66B8sFrLl37v7+Brzcf4zyWVtYA92o7ziSPdzCJepzVXtbNP HaeczdgwxLGZY+jCQ6StvVPXuiK9c0L/px6lLIXWU9u8gV/rfWLkPOszS1TdvcsRrQ 9M0R5wwiADT8BGDWRzf3Ss8XuuKiNsgp3aLk8YLaDYTXGBkdGJBjIC6mkFGZjfQBru U1DO0aQ4lKcZsYzKKerYRJcWjY2t1ZR3f8nnZjEZNPSVX7Lllb/9nNTJCmwhMSRwXO skXkDeIUQOLDQ== Date: Mon, 1 Aug 2022 16:54:22 +0100 From: Will Deacon To: Mikulas Patocka Cc: Linus Torvalds , "Paul E. McKenney" , Ard Biesheuvel , Alexander Viro , Alan Stern , Andrea Parri , Peter Zijlstra , Boqun Feng , Nicholas Piggin , David Howells , Jade Alglave , Luc Maranget , Akira Yokosawa , Daniel Lustig , Joel Fernandes , Linux Kernel Mailing List , linux-arch , linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v4 1/2] introduce test_bit_acquire and use it in wait_on_bit Message-ID: <20220801155421.GB26280@willie-the-truck> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-7.7 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 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 Mon, Aug 01, 2022 at 06:42:15AM -0400, Mikulas Patocka wrote: > wait_on_bit tests the bit without any memory barriers, consequently the > code that follows wait_on_bit may be moved before testing the bit on > architectures with weak memory ordering. When the code tests for some > event using wait_on_bit and then performs a load operation, the load may > be unexpectedly moved before wait_on_bit and it may return data that > existed before the event occurred. > > Such bugs exist in fs/buffer.c:__wait_on_buffer, > drivers/md/dm-bufio.c:new_read, > drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:dvb_usb_start_feed, > drivers/bluetooth/btusb.c:btusb_mtk_hci_wmt_sync > and perhaps in other places. > > We fix this class of bugs by adding a new function test_bit_acquire that > reads the bit and provides acquire memory ordering semantics. > > Signed-off-by: Mikulas Patocka > Cc: stable@vger.kernel.org > > --- > arch/s390/include/asm/bitops.h | 10 ++++++++++ > arch/x86/include/asm/bitops.h | 7 ++++++- > include/asm-generic/bitops/instrumented-non-atomic.h | 11 +++++++++++ > include/asm-generic/bitops/non-atomic.h | 13 +++++++++++++ > include/linux/wait_bit.h | 8 ++++---- > kernel/sched/wait_bit.c | 6 +++--- > 6 files changed, 47 insertions(+), 8 deletions(-) > > Index: linux-2.6/arch/x86/include/asm/bitops.h > =================================================================== > --- linux-2.6.orig/arch/x86/include/asm/bitops.h 2022-08-01 12:27:43.000000000 +0200 > +++ linux-2.6/arch/x86/include/asm/bitops.h 2022-08-01 12:27:43.000000000 +0200 > @@ -203,8 +203,10 @@ arch_test_and_change_bit(long nr, volati > > static __always_inline bool constant_test_bit(long nr, const volatile unsigned long *addr) > { > - return ((1UL << (nr & (BITS_PER_LONG-1))) & > + bool r = ((1UL << (nr & (BITS_PER_LONG-1))) & > (addr[nr >> _BITOPS_LONG_SHIFT])) != 0; > + barrier(); > + return r; Hmm, I find it a bit weird to have a barrier() here given that 'addr' is volatile and we don't need a barrier() like this in the definition of READ_ONCE(), for example. > Index: linux-2.6/include/linux/wait_bit.h > =================================================================== > --- linux-2.6.orig/include/linux/wait_bit.h 2022-08-01 12:27:43.000000000 +0200 > +++ linux-2.6/include/linux/wait_bit.h 2022-08-01 12:27:43.000000000 +0200 > @@ -71,7 +71,7 @@ static inline int > wait_on_bit(unsigned long *word, int bit, unsigned mode) > { > might_sleep(); > - if (!test_bit(bit, word)) > + if (!test_bit_acquire(bit, word)) > return 0; > return out_of_line_wait_on_bit(word, bit, > bit_wait, Yet another approach here would be to leave test_bit as-is and add a call to smp_acquire__after_ctrl_dep() since that exists already -- I don't have strong opinions about it, but it saves you having to add another stub to x86. Will