From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 47805C5479D for ; Mon, 9 Jan 2023 23:11:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B078E8E0002; Mon, 9 Jan 2023 18:11:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A90B28E0001; Mon, 9 Jan 2023 18:11:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 931E68E0002; Mon, 9 Jan 2023 18:11:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 7CA4C8E0001 for ; Mon, 9 Jan 2023 18:11:13 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 2C0BE413EE for ; Mon, 9 Jan 2023 23:11:13 +0000 (UTC) X-FDA: 80336808426.20.E86F34D Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf08.hostedemail.com (Postfix) with ESMTP id 72EEC16000D for ; Mon, 9 Jan 2023 23:11:10 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=DS18wD4i; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf08.hostedemail.com: domain of "SRS0=dtYy=5G=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 145.40.68.75 as permitted sender) smtp.mailfrom="SRS0=dtYy=5G=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673305870; h=from:from:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=66Q66qJ0zBOW4Ez1p/3txGTuJbBdjYHdUEx/0VkdUJk=; b=ZGJUMf9WqncWHrpH48jML5XeGXi7i3B0Ob9ptC+DGLw+UHNBiZ4cM8EGjiF7hKYeA2jfIS 6ly0XMIDDHj+ufw+iqY/xaN+kbuGgs5iLwHaEduPZojJEEu3oM7yZTGCmal/1P9WwTUj6m 10/qopUi1eRnOjyfJYPq/rjUaMS6tpg= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=DS18wD4i; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf08.hostedemail.com: domain of "SRS0=dtYy=5G=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 145.40.68.75 as permitted sender) smtp.mailfrom="SRS0=dtYy=5G=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673305870; a=rsa-sha256; cv=none; b=BAfWWnZeg9r01NtZ5bauAjQtpcEsli4IkC9SlOL1JoJTuMpZFUYnoC0VSy71WzKGCCBQWa xplbHgJ2WfXl/MjvW9+qEe51G+YYqydGJ/BjwEPXevRqqTaxhMB+Uf4RNPjizqmLuOYEtr JwR2Z7PBoO7HGAq+Ni9TGN+MugbnE9o= 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 90ADFB81098; Mon, 9 Jan 2023 23:11:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3BF32C433D2; Mon, 9 Jan 2023 23:11:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1673305867; bh=lSnHR1FUjpPZ+YmVda0l6KsEzzL0O6TsWb9SLW9UgN0=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=DS18wD4iLQbQ/4WyGDWmqkPwoeUaae0+chVJQVGppDEKnnS7xVTQ4i4HnCeQu7MMD bcQH9utIekU7oMLp+y7qXY3+KMJN18q9iqAiDHX7LCAnwZ1WGHaqNuHfkgBVLbgTle m8Z2Kl7O/1ZQ46ViLNnPp317uyRoSBkxzq7H9KBaYfIonvY7ywDvYY9ZbiSpthdCnT saI/7CQmxC/TVJGTDxHvBrseKlwBZglGE0j4EwXGs/RlhB1o8k1RzuuMCIvV3awhM0 eCDEwQXFx8VyxXwGpAPMpcIJjOSE94NOvwGvARITjQ20aKVU5vnM2cP619QwJEhcEh ndRr9DazfDxZw== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id DDF555C05C8; Mon, 9 Jan 2023 15:11:06 -0800 (PST) Date: Mon, 9 Jan 2023 15:11:06 -0800 From: "Paul E. McKenney" To: Yang Shi Cc: linux-mm@kvack.org Subject: Re: [QUESTION] Linux memory model: control dependency with bitfield Message-ID: <20230109231106.GZ4028633@paulmck-ThinkPad-P17-Gen-1> Reply-To: paulmck@kernel.org References: <20230109173155.GS4028633@paulmck-ThinkPad-P17-Gen-1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 72EEC16000D X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: xqw1fgrcxd1fyaggag4a55ngtdpatb74 X-HE-Tag: 1673305870-587648 X-HE-Meta: U2FsdGVkX1/RZxDxei83uc4shli5e+S6xTQCZtNp4TkOn+LKQ/5eRi8/KNP0peL+BqXA/Sc2bk6i4muazt5aT7gqFcV8E0lAunOkr6EQ+hEXLY4ot2nrwg5CzgIETV2utMeYCAhxe/TBRX3cMg6i1jqbVOG8ohrOfIOnzZ60LiZKclAnhvVh6TWGAZz1qiAYFwLLnWA5R8NZdpbvAnpZeTq2OydOHjgxJnqzGO1KsVoHtb65WqBi34n6fP10+8/s2mzRgNZt45cjlY/Fn8xy/iqMieuHhFZIm7ENnKUTeZLakRsaYEQsYVDLejEHcEGvkNbY3FDYIpPm9mhTm/t0GGbsDnLW0P1GpPCYn8qcdZsxlVriSXI51hryLlWv1CbG7QgJXNkp0Jt1LlF1xoLvOY2Gp8xa6wNyRCQ1Sn1s6VpE3k3g4YgIBEko6GOLGp5+V/AXJYA//6fi5DTJP9fRfsrTjMPg9C5kGZJj3XJYVxf1iwjw1fIWACSvU3YdKFy8kqAABpZXL2kk0k+diPo/OXZkKDTFeQt1eCxeZ4Wiww+JnfpACT4WodjXgoB22nXpn8W0zS7ottRGAco1EAGCqGF+pG+Ch+fBXuSgNera6tEcV7S7y9C0Hi+33eGJg//nw4M49yFfTq0M4Z1UQpB6g9uIuTeCCNb0YYMmS19NMN/I3jffTOTQPztTo5GcDM+aATpbdVdl4oQM6mNGGIn7Zbn2XbfRS5KG5sjbcA1/7bHQwpcTr1xpZaHUWz2AL8dmY+di/QdVGPGpanTR8/lHsVbjFfovWJr5XqYvdSOCjSKq9V9oAboQPgCBHIwLczgO3mXWteCePT1fqq93hoTQY8V+dkVMBB/4px4qobevhkUaZ1lJj+dcDr+UeNgQ6iJNC6KymxQYS043wOeD0mg3hg/mbHHh4ovBQg+rGrf+wIWXr2IpbO5mI89iEfJEAmY5ug+y4IKOTOPOZxCvYzM E3PdCk7j YKRM+ZYV/s1OB6uoczQyXuVTs4hTTUOR6NNYMZ4Qc7WLB1J0fqHKzuuknfz2cx2ObfPX55wo0rinmOYfkiRXyHCdFCgxrXbxHmZ80GuYB1seqO3WyeqBeeTprSlBT3OFVCWQwskOt94wBn8lWZYFsyThoOvN9l9nIt4AaVMHrretqIAKBQTV8970UfgjeJEG3/bAqaikbslceOjisMymY8dycTwFvmc0NGrGPnqkoA5uYA4BrpDlB5EqnEMSC6OW1VFcYRY8SUE768V2bXLXMgeuCysam72v+dAg10FvU8uF5jQdMRpkJusuoR6RsSuHGnMe8s/Eutbogkbu2Cy3UFRuagXjOoRr36GczewIqqVBHr0jIbJcSG6XLlVgTTXBZ9kQOGjgbrGPM25p/MIMcCfnEke923qs0smSSE0ba9AxmrJQ= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Jan 09, 2023 at 02:08:35PM -0800, Yang Shi wrote: > On Mon, Jan 9, 2023 at 9:31 AM Paul E. McKenney wrote: > > > > On Mon, Jan 09, 2023 at 09:14:19AM -0800, Yang Shi wrote: > > > Hi Paul, > > > > > > Hope this email finds you are doing well. I recently ran into a > > > problem which might be related to control dependency of the memory > > > model. Conceptually, the code does (from copy_present_pte()): > > > > > > acquire mmap_lock > > > spin_lock > > > ... > > > clear bit (a bit in page flags) > > > ... > > > VM_BUG_ON(test bit) > > > ... > > > spin_unlock > > > release mmap_lock > > > > > > > > > IIUC there is control dependency between the "clear bit" and > > > "VM_BUG_ON" since VM_BUG_ON simply tests the bit then raises the BUG. > > > They do touch the overlapping address (the page flags from the same > > > struct page), but they are bit field operations. Per the memory model > > > documentation, the order is not guaranteed for bit field operations > > > IIRC. > > > > > > And there are not any implicit barriers between clear bit and test > > > bit, so the question is whether an explicit barrier, for example, > > > smp_mb__after_atomic() is required after clear bit to guarantee it > > > works as expected? > > > > I am not familiar with this code, so I will stick with LKMM > > clarifications. > > Yeah, sure. This is why I tried to generalize the code. > > > First, please don't forget any protection and ordering that might be > > provided by the two locks held across this code. > > Yes, but for this case I just care about the code between clear bit > and VM_BUG_ON. Fair enough! > > Second, a control dependency extends from a READ_ONCE() or stronger > > (clear_bit() included) to a later store. Please note "store", not > > "load". If you need to order an earlier READ_ONCE() or clear_bit() > > So you mean: > > clear bit > ... > if (test bit) { > load_1 > store_1 > load_2 > store_2 > } > > The dependency reaches to the first store? It reaches both stores, but neither load. That means that your example might well execute as if it had instead been written as follows: load_1 load_2 if (test bit) { store_1 store_2 } Assuming that you mean the test_bit() function. If you instead mean a C-language statement that tests a bit, then the compiler can do all sorts of things to you. The compiler can also do interesting things to you if the stores are plain C-language stores instead of something like WRITE_ONCE(). > > with a later load, you will need acquire semantics (smp_load_acquire(), > > for example) or an explicit barrier such as smp_rmb(). Use of acquire > > semantics almost always gets you code that is more readable. > > Does the load acquire have to pair with a smp_store_release()? > smp_mb__after_stomic() is not needed because it is too strong and the > weaker barrier is good enough, right? It needs to pair with some type of applicable ordering, but yes, smp_store_release() is a good one. Thanx, Paul > > Does that help? > > Yeah, sure. Thanks. > > > > > Also CCing linux-mm@kvack.org in case someone with better understanding > > of that code has advice. > > > > Thanx, Paul