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 E0879C7EE29 for ; Fri, 26 May 2023 02:03:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 46717900005; Thu, 25 May 2023 22:03:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3F014900002; Thu, 25 May 2023 22:03:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2740B900005; Thu, 25 May 2023 22:03:17 -0400 (EDT) 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 10086900002 for ; Thu, 25 May 2023 22:03:17 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id C407180C55 for ; Fri, 26 May 2023 02:03:16 +0000 (UTC) X-FDA: 80830758792.18.EDB0395 Received: from mail-il1-f173.google.com (mail-il1-f173.google.com [209.85.166.173]) by imf08.hostedemail.com (Postfix) with ESMTP id EBEF6160006 for ; Fri, 26 May 2023 02:03:14 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=qWdwWqkC; spf=pass (imf08.hostedemail.com: domain of yuzhao@google.com designates 209.85.166.173 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1685066595; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=MNtWvPa28u8wZV0f4gpjr4fry1u8z+TX9d18m7U9c/Y=; b=NR/AiMXCy6pLZcpVaoy4YH2f9sZFmHPwPlNtYkgLEbVW9amQoc9vkFWwqPYkmHasSUHw60 BnPsdM6SRo3eCbCnXvQUDw92YDIznwqA8exlOm0fyuRMtg/BDMNc3GPmpRL81vI6m+BO6w 9Nzyb4m/ydNSQ+otPBdOCCoNUyvCEos= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=qWdwWqkC; spf=pass (imf08.hostedemail.com: domain of yuzhao@google.com designates 209.85.166.173 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1685066595; a=rsa-sha256; cv=none; b=05x/A3S8LhlmkLSWWpp6mQCmQ3/wWeaEghFFpjYFZPZXMMwfWOq64FBg5eQ6fsQfERugcx iNOVz5UKFFeoDC50x6UbKyFWsKLZEH0QCdyCInAUd31evEDl2vpVC9Orm/MNKgxfnThoNe h/yszkhubXxbkCNnA16UrFuQ6fFPV6Y= Received: by mail-il1-f173.google.com with SMTP id e9e14a558f8ab-33828a86ee2so75565ab.0 for ; Thu, 25 May 2023 19:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1685066594; x=1687658594; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=MNtWvPa28u8wZV0f4gpjr4fry1u8z+TX9d18m7U9c/Y=; b=qWdwWqkCCTrSBfiqEXFlPREbqH9nZcRKo8eUTletLcLKGRfEd8BVHPYe6UHX/gvwE5 miVrAiLJEcZdAICpaldRssz9r8HdxlCrAh114QYxjrmTn6IGRCfhb2Hv5J1Oeu3fy/SF 7z+tw19d0oZdlyEH3kaTpOpEgoJ0jVXi+sl+5uhTsfr+i4f0gNx2IpMn7DsXa/eDyW7+ lPNp09CxaZW14hXdDcH0MVYt5kN5tKRPhSn4XJ0KH+VLs+kG7DmmiC7igkEq+TrVl+q9 qGRSI8gpv+Tfvu4yQyCeG60+FxbGNCF6cKkFvVJwNnynFUyHvVJUccJXZLSARhxIY6Af EPKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685066594; x=1687658594; h=content-transfer-encoding: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=MNtWvPa28u8wZV0f4gpjr4fry1u8z+TX9d18m7U9c/Y=; b=EQ3W2RGUCaAEpVDPWuhLhCTB69UmkIQBKASHb9f4Gp2oIxa61Ld0g4p4LTyWn5ltmh BcEyvHwd1612fWBkbkEKW+uK0ViDHwQnch97bRhDVKpt0lt+ac/xmhZwIdp3a6dFNDUE qUyIcbT6KMWoWXwLPR0MSYc8bTY1pt3vXTvKmBg1qDfiTSGCS3t+UJg9Lk2J2P1ufxBl BbY5kukz2Ycl7fRn5dfvWi06Z2BiUCjKm/g0Ll8jW7GjAm+cm1egr5Rg1b2/qHdMUbPL cUzlfmYLCVDZjPXije+2IVqlxavUbBvOuNiFRhdykCSbXgOU+y9IK7Dq7Fp5Brip0/pp TNoQ== X-Gm-Message-State: AC+VfDwoTIDgGxuD4RivEWzr9y+42qScA1pOZfov6a2D5dxrVx5/2XUf XFXx43EAMu7aYTuwCzeqUEk5xm42FTiu9AsG5dckzw== X-Google-Smtp-Source: ACHHUZ4iI2JJ36IHzsm7dTn9A+Vj+4OycDbPHRLJ+FJ28mIjDg1G3+RBJ+IHC1KZvYl8wi08Yr+oSlfn4P76WrDoK0A= X-Received: by 2002:a05:6e02:1c2e:b0:33a:e716:a76c with SMTP id m14-20020a056e021c2e00b0033ae716a76cmr399ilh.26.1685066593951; Thu, 25 May 2023 19:03:13 -0700 (PDT) MIME-Version: 1.0 References: <20230518110727.2106156-1-ryan.roberts@arm.com> <20230518110727.2106156-5-ryan.roberts@arm.com> <692e9e7e-ee00-368b-6a31-60a895f7011c@arm.com> In-Reply-To: <692e9e7e-ee00-368b-6a31-60a895f7011c@arm.com> From: Yu Zhao Date: Thu, 25 May 2023 20:02:37 -0600 Message-ID: Subject: Re: [PATCH v2 4/5] mm: Add new ptep_deref() helper to fully encapsulate pte_t To: Ryan Roberts Cc: Andrew Morton , SeongJae Park , Christoph Hellwig , "Matthew Wilcox (Oracle)" , "Kirill A. Shutemov" , Lorenzo Stoakes , Uladzislau Rezki , Zi Yan , linux-kernel@vger.kernel.org, linux-mm@kvack.org, damon@lists.linux.dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: EBEF6160006 X-Rspam-User: X-Stat-Signature: pmircs4cn6pinu6hynnm4eunz4ogu769 X-Rspamd-Server: rspam01 X-HE-Tag: 1685066594-786321 X-HE-Meta: U2FsdGVkX1+cQhf6ZkXR3Wck2PCpdEMuy1sVuSsuoqwCqxF6i0PZIi4tEcMNlFVojWIZ+ihxftXlnr5KwFq6bfFUiDYp0zALND7ta+SEA+SkbQ3JI60y0bgT1svKfcvKsPT/i/sDip6c0ZA/oIQ5OHWstBYmsyfsuRvCHdZgu07hLIdcQ7jAiHGdcNKvodo3f6IT3HAPjeBr0e+iEccxuiLrvTAkhgJuPXYJ7rCGnMrIjBjqHowZ+qgLxdskekHpqj9DptG5G9bPzYO7XZHehsmzF68YtQoTTAMOzHENQznYKZBViTS+RV9HiUhxgujt2vdbLp7ALCsTyQWI0yKP1+AWjK1+iLt4NCmzgTvshuRHzij6SimT0zwLGVFXFGeDX9rYb7Q7n9kSTGckaAlj0cxLVYlK98RbiWUl3ZMhMgUhzR/qh3HB3nO5JXQpK1APeTygtO6rKHa+0Rv2ci0vHV4BNLZUQ9/ljSbbdeO0NNCr9s60TY1AFZVKXFAMEq+5w7friWKGBThPMetkfhGypeq+Me25nwHsX0Y7+bVc5txphc9rG0LmVVHkUwdEHUzTd6QwuFDxhLOQr6qpDXi6aKYUZTNKiMqAAnxSUfoM0YJ6PJpg/NoBYkLFaCUjXQKNkOuUECzLe4bEBL0TixW0FN+w24Iuc6ze98uNUFuyaVVZAMZ7n7V62qrf8EK4+hXPMr+pq1YkssSbXyfi4d/k7Vt+RestlVZ42RXiSXnLRnNcwYq4CnT7S47A2JZGP94L4dnncI2ctQS6FggUvq0c/8k9+D86TjinKhZKRmUwVqWyJDUlXsSqugbiRq7hKyyXXZASVsMzgK3uiYAmQavo3IJXhyU4oEdeqngO+Sc0OOwvnGkTTH0WQD1SFYjj/1h1p6HtMFro+F0p0GiXj4s+O8sM5jylVOYoKfajp5g1hoLe9H0ZfFSDE8sSi+9U3EfzXsFs9EtshPbu1rdAFFR X8epBVKX hNPAOwo6pRW+uQeiBP8Pesjo6Pv2CkYdBW72oteqwPobg5dbnjd/sKQ+wEPtSiJ6HYv2Xx4rTJqU53aiuSMP8TA4gyCgcUYrsXtgxvZekDzOFMDMqOmbM1B1z/7fclxDHvE6yZivKfy3AhmINqiDstOeN0wDjj/XqjkPdNi8N15HK+m+yuDoHqpYj9XHL6iBR1xOzUT+Jvn9CVQi8SzZizrfogPoWveA1idQ6n4Qju0EUIPoVsGSsXK7BUOudRe9TXVGfHBccB0gkcGDrDiAYgHTLUTwrE+9qrBdPjtdFoo6UgU6BUJrggE2sIPeWo3781VA0G4YU9ZB1qZIkl10r9BXolg== 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 Fri, May 19, 2023 at 3:12=E2=80=AFAM Ryan Roberts = wrote: > > On 18/05/2023 20:28, Yu Zhao wrote: > > On Thu, May 18, 2023 at 5:07=E2=80=AFAM Ryan Roberts wrote: > >> > >> There are many call sites that directly dereference a pte_t pointer. > >> This makes it very difficult to properly encapsulate a page table in t= he > >> arch code without having to allocate shadow page tables. ptep_deref() > >> aims to solve this by replacing all direct dereferences with a call to > >> this function. > >> > >> The default implementation continues to just dereference the pointer > >> (*ptep), so generated code should be exactly the same. However, it is > >> possible for the architecture to override the default with their own > >> implementation, that can (e.g.) hide certain bits from the core code, = or > >> determine young/dirty status by mixing in state from another source. > >> > >> While ptep_get() and ptep_get_lockless() already exist, these are > >> implemented as atomic accesses (e.g. READ_ONCE() in the default case). > >> So rather than using ptep_get() and risking performance regressions, > >> introduce an new variant. > > > > We should reuse ptep_get(): > > 1. I don't think READ_ONCE() can cause measurable regressions in this c= ase. > > 2. It's technically wrong without it. > > Can you clarify what you mean by technically wrong? Are you saying that t= he > current code that does direct dereferencing is buggy? Sorry for not being clear. I think we can agree that *ptep is volatile. Not being treated as such seems a bad idea to me. I don't think it'd cause any real problems -- most warnings KCSAN reported didn't either, but we fixed them anyway. So should we fix this case as well while we are at it. > I previously convinced myself that the potential for the compiler generat= ing > multiple loads was safe because the code in question is under the PTL so = there > are no concurrent stores. And we shouldn't see any tearing for the same r= eason. > > That said, if there is concensus that we can just use ptep_get() (=3D=3D > READ_ONCE()) everywhere, then I agree that would be cleaner. Does anyone = object? (No objection to NOT using it either. Just a recommendation, since it's already there.)