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 F2012C54EBD for ; Mon, 9 Jan 2023 17:32:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 59E288E0003; Mon, 9 Jan 2023 12:32:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 54DE88E0001; Mon, 9 Jan 2023 12:32:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4163D8E0003; Mon, 9 Jan 2023 12:32:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 320DD8E0001 for ; Mon, 9 Jan 2023 12:32:01 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id C651C80815 for ; Mon, 9 Jan 2023 17:32:00 +0000 (UTC) X-FDA: 80335953600.03.2E1E1D0 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf24.hostedemail.com (Postfix) with ESMTP id E9CA5180019 for ; Mon, 9 Jan 2023 17:31:58 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=AuoJztK2; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf24.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=1673285519; 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=7Y8sYMiVxr5d/xH+Fb2wWeCatePzGiiVYwboZe60u9E=; b=Mx4+PkURRdYj6K8iUSVi1OvskWgtFS7nZN283GNAkmIM0iVnB5fHhTNR58NGrEdS19iOTp VXjFk2Z0NfIHxLabouC43HWWdF0B7nA3qj71nlo/u8YyZFrIHAjeBUXb2eowDiXNSCT+BV CVCNKR7Im5PfkiUdA114vKlKUg3yFvY= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=AuoJztK2; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf24.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=1673285519; a=rsa-sha256; cv=none; b=muSBl2PRisrrV+11EkUUrqvLbda0t8A40ZPn76fYan8a9XKvnzTZYyQ9TYD1BNBCh00cy9 jaGQ0Grk4jMjscat3iLPYmSlWBB6O4GZfB/CLKaYVK4xnfyF9QucOMuSUVmJff5gDmjCKT 9w2W2MOy/t2IIV8Y3KaMLPwBmyBWyr0= 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 EE697B80EB2; Mon, 9 Jan 2023 17:31:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AE2E8C433F0; Mon, 9 Jan 2023 17:31:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1673285515; bh=jxa+M5AtGc67CyBQ1nzfz1X4tuyA9GGxWUMPIh+fQAs=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=AuoJztK2bmb5F4EUQkjim73r75Fn9zbyFDjnAdeIsIPsRAn9r3O+eXwBbzHWiGUoZ I+MRymkg1DrKXlNAgMjxgxdbSr/PIUV/c5UVXa1uMwPJy6oz0Q3BnZKvfhLVSG7c2n Vg8blISSm0uULNmBuy9r9M8dJ1d3PFmA4Evs6EiYj0IrDpd67kWyq7weA9ik0clYqc NIOgB97lyYd+a+3OUdgvq9vJjfoxX4QtEgwHdu8mn3EQ7AGOdBQjLcjibM/6HNI7sO oRaSnBHqaeW4Vtiy/fyzsX58FSnic7h5gVS6whdjw4aTHRlcmimwdu2jgwjKlmN3ow OgHO6HLffxcuQ== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 5643B5C05C8; Mon, 9 Jan 2023 09:31:55 -0800 (PST) Date: Mon, 9 Jan 2023 09:31:55 -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: <20230109173155.GS4028633@paulmck-ThinkPad-P17-Gen-1> Reply-To: paulmck@kernel.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: E9CA5180019 X-Stat-Signature: 7gz3iu4imrcn6mtj1p1rtxxw7er6n5kj X-HE-Tag: 1673285518-977415 X-HE-Meta: U2FsdGVkX1/366WTTjYVFATbe/NWzYsjkszg+jZumdy2+tOpWR2+3Ro57BCVwmAVLEauYZ4ISPrKEhT6h/P/lr4NWOakWJHzNEktGp3S7xjZ7FgbNkmr84GQs6YjnYjsURkUAwotX70JA7rZ7TAW4QfgrFY96ciZaYj12plFDO2qNi7K6j8g5n+sGwpH8j6EyXqc008COiJEb9mHtE8vli3UC0jkmC7mwiU1wee2lUcZaUa8Xklac+FXbzBsETo20yVAHW5BiWz6Zq12bY7J/aLJs/D1ASFphHy1dZLhsY7iu7R1xMZAQI/IFby+Vr1NkXB1qdy13PlaoWiCr2o1J96m85GwrrhY5EoRhXpb6aufzeWKEIjEb3kPIkrDV4MP8xtKg2+bXw8FE5IIVEI0fWixNF7AK3YhAFKOaoAzMFh6XyCYvpIEiIiQqTnL7TJ30Rl6SDOIwumzVlnMSqAKIIHbpFL25t9oDLQRNgS5upuBbL4sgXQXhcuPkDuMKOc6JJk67WvmaP2lfqFvwhe7VOCE1x3uJMp1HgOjQ83eMOhQwY0LzOa+g7ipzbQOp0kObN/M0aoQiXGmUCo2/uvTDFsYp11x9PSkHzRdAY7Yrwo4jO2FW7f+PhG7Dsbbj5ki559k8haouxWRyrV2ddltpvHNHhkP1+q2rMFc+kleXcqOen7QoRe9OZworrd9fiSH+R2pEX45kd1Dj+amqwr7roDlyRiT4UlraXZL0zpbfWOJgPEIoPu8jSVwILseBLCVTZg+WtP5biVmwkIhWYg16mJ9bIpTs8DXKsenU4eZ+t9yqmD+076hfbSdva3oPNi60aIsIffpqxx4J3cZ215xKSLrTxm439rfgNYnzXy5muplOPMcpsQWyL3ByhrprqDwO9UYktc7+TwZoRGZL9oG9eCyA3ZPOVNcNjACGSqr7NF1LBknhhfOZ619D1Os6xcKRxmWdM8gVfyXgzNwl4+ ihbKKQAw l9s+VccIvQfiXSVoKliIz+NOsztHqqXDK0YJIzpHQrSi+ykAZsLTvae0eUpcYPpxU8T2tuSlG/KTdQlYKlPpQNTlk6Es/Btvu0t/4DNeEazT8PBrB0fzBC9JTmdK5bQGt/LZms+vsUqEc/o78dyLWz41gns94zcUq3rNAoh3jFOvt3VzIThcKq26A5X6BZNNziAKD5qKV1lAhKiS36S9OPz5Xohm4Pj2RC5aLu/XLa5fFR0c/01Ki7KCa8cZbl2Dz1oxqlu/H+TPwaZB8ABHNfJNG84Sd23O/79rF+YvjenfifyBGaR6hzwtSSTB5pYIrCdfWMXSDPkNfz5+opn6fCKqITbwc+5wFCc4mD0n+GL6bNvqvEZ2KSCPLUoKpkDdvI2wAeh/3XPAJe4LQHnGRpZ5iTgv79PTV9Uxk 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 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. First, please don't forget any protection and ordering that might be provided by the two locks held across this code. 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() 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 that help? Also CCing linux-mm@kvack.org in case someone with better understanding of that code has advice. Thanx, Paul