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 AA5A0C54EBD for ; Mon, 9 Jan 2023 22:08:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4CE29900002; Mon, 9 Jan 2023 17:08:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 47E3D8E0001; Mon, 9 Jan 2023 17:08:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3466D900002; Mon, 9 Jan 2023 17:08:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 27FA78E0001 for ; Mon, 9 Jan 2023 17:08:50 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 035B21A1277 for ; Mon, 9 Jan 2023 22:08:49 +0000 (UTC) X-FDA: 80336651220.16.FBB5032 Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com [209.85.210.174]) by imf19.hostedemail.com (Postfix) with ESMTP id 734821A0009 for ; Mon, 9 Jan 2023 22:08:48 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=SjZ8RmXS; spf=pass (imf19.hostedemail.com: domain of shy828301@gmail.com designates 209.85.210.174 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673302128; h=from:from:sender: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=RHuNRVAbU2e9Dv7lmJOMzEak3Ea0/iEO/4bYCPvY8fc=; b=afrJwggU8RIpne9+3SeZmJjOdIUubLOz97jaCXBRLVrQiI6o8Lcn8IYSCZOJPiJ3zt++aG fEvhsowTcukqpE5bABXuJAqej2bLQE5yGyT+xIxlmVt6o7NiPuTT7Bj0tYNfNcUCJsbRAY jrotgZzUPjsPo8twzF55/5RSU/1JM/4= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=SjZ8RmXS; spf=pass (imf19.hostedemail.com: domain of shy828301@gmail.com designates 209.85.210.174 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673302128; a=rsa-sha256; cv=none; b=zqDwmPkaa2ViqiKne99g+cIJ/YgEbO3lG+DHC5gl9tfto+W+/PFe7+nSc1rZx62F3+NW4i tRn6tvpj3niuLa8OpSqZDqwWIylVHbjlDyUa3j1OV/fnvmFG+GYnE/kb1aF+wbhoJw05ut dLen/scBJ/ND7Ub2DnPIOOWv5H4e30w= Received: by mail-pf1-f174.google.com with SMTP id s3so4768676pfd.12 for ; Mon, 09 Jan 2023 14:08:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RHuNRVAbU2e9Dv7lmJOMzEak3Ea0/iEO/4bYCPvY8fc=; b=SjZ8RmXSgw3oEL5A1rXAwFcGTJOgJgb+WMOqs78QZtEXJfgzhQsPTk0LOKASZFAKkX +yWqq6uItAKkgS16iUv7q4yg9SBlt6/fpKLxZPGDoGhYdRVO5pmu/v6haEa2ZGOiG3Sk 9BI6duDuQJRbrjXy2WrqhHNtku4l9HeIuH5cE+Gff4VoXBpcjbrJ3W/QThUCok0CnjI+ 9G3mfY/sby4Wtok9d3wp56qMHHyYPApRHYyiqNl4C2fNrlm7SF8wdnCCsvSIBaCo1lcT jGfwTkL8lvVMi21tXB8ereM4yJ2OqdNXUK1R7i09w3bZxI5klkazXGTrgP9InMHP2Vi5 xf+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=RHuNRVAbU2e9Dv7lmJOMzEak3Ea0/iEO/4bYCPvY8fc=; b=slGp24QsAwmkzCMy7Z1PSBBu8+giYPbRr3NwOYXvnNznlwqrG6fCap8MU/qV1FGtvl IraMG9Ko1Zs6Oyuxx1I8Nd9O1dSiTQp9CyHrW8Rn5ZkcYh/2uq3PUVWp74bbWWYLvllD hjBYM11Q61mPFOyAWZ5UUDZp2zCIvin57AjLQNDL6VMlAAP6ZcC++IS55tHKDjLHIz++ Wp//whjsRziWN3ol1Q0io/LeqHCWyW5p0EnqfVx18RZPiEqW8n/4gPg3Vqv+xbejjxW7 m7Gug/LfgnDRD9uxkTUa00RPm0miTrEtAgc//QKcSehX9C8liqIy0k7vIYbQuNranVmw VgEQ== X-Gm-Message-State: AFqh2kqESlz3nJ+0+iY1y4Kdcv/Brlvit97QBseJ1YyGeH1wHv41XTVL b8e5ouI4gLgFfKFUm3HCGeowxaA0/Z+4qbUYL9k= X-Google-Smtp-Source: AMrXdXv6DWXA3kqVbBBhtoE63UGA6EzXp1yfteEpn7MrLvwc1WOLD6hiGa3L28HXp4hLZPF1WPdu/CEl7dclV3U+kIo= X-Received: by 2002:a62:aa0f:0:b0:581:faef:76e1 with SMTP id e15-20020a62aa0f000000b00581faef76e1mr2750111pff.85.1673302127238; Mon, 09 Jan 2023 14:08:47 -0800 (PST) MIME-Version: 1.0 References: <20230109173155.GS4028633@paulmck-ThinkPad-P17-Gen-1> In-Reply-To: <20230109173155.GS4028633@paulmck-ThinkPad-P17-Gen-1> From: Yang Shi Date: Mon, 9 Jan 2023 14:08:35 -0800 Message-ID: Subject: Re: [QUESTION] Linux memory model: control dependency with bitfield To: paulmck@kernel.org Cc: linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 734821A0009 X-Stat-Signature: a1cqgc9sswsmhr7386robnn4xy7j9zuo X-HE-Tag: 1673302128-972939 X-HE-Meta: U2FsdGVkX1/uEYcQU5l13G6AMM6nv1/hCAuKGjI5b1AIBg5qLfL1U7H5ZH0Qhz3umddZP4meSl2IQQakC1Td9iuCs6iq4Rcha07NZRxcXXGX6Yx9muUDPSICzvdpJoWLceoOca/MPRb9NLs5c5B6LbLR5O+YMorhbSMnhDu+/GzUaAxB/YVDIOhWh0mR6SxOL1m+Jl/eiZ4aXLSOCTkzLr4ArU2vWm/XXUzXEZ21dwp+Jjo3TeA19AQUilccpZVhAkAq09Cf9ddZ3D6kxDZ6CkjBtw4hPa1jEVZi2J+BueArAz5/PzWE1lJ7NfhJrsHw1+BaxlaAyBR1JQDaIhq+NgLhDF/Su5CP2HonME6a3CPAg5QjrmTi2dPYVNRj28fRXAkSiGfcssx5iMd6lf1CL88KoPUFs2rIcXCLzBe2TccaAhI49z10GK4XYkcQ0KsEveVQ+xDp8xxkgLkGKxN1i9lkg5fLJkRw3jYAu030huQmpLukt+5WSgCcrTRmLVN4pCZo44Dz6paDDMKPwrfThpFPJXjtyiLu7lTxm1aGVXsD9GA59nBw50xhcUkCCYZCvddiP/U05e3Zj9fHItlmx1pXZfuA+eiWFTT7vj+1cjQqqjygRPmn0Pb8XKI/R3mhdWPb20YHpjk711OjOoscYH6lX9a1x2tKUszb4T3j30Ajx6XtK3zGF+hlIU9uzLrc2F10bFwqlA4qz4rn0vdL17by5alOxNtBXKdBPhv9ko4cCCsPH1+6NCQWzyqe4EDuQMfEpBmkmRGT8w2hTwJCPjaZUOL1t5rr0cT7ogY5DX9ydR/YSoLN/26NQvAwW2gIGKewjDa17+bfW+tHFLyFqe9HGM5/CNWfUU6bMxAQmv7HcWvmBuMBYwDtz7zbWqLIpwVmzL9vc9+OT6wE0esQX9+q1Q431M7rPemQJ5uDgXQ2uSpJLDBIOzGbDXciD2cKS+JNDiuAcQhBiIF6ZKv HzpV1Yig 4PruwyxoRNETRrCn08LyvpDOhjOV1XAWk/BL++Jw5guEJfm8= 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 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. > > 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? > 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? > > 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