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 169E3C77B7A for ; Tue, 13 Jun 2023 08:53:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7CE728E0003; Tue, 13 Jun 2023 04:53:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 77E018E0002; Tue, 13 Jun 2023 04:53:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 694FA8E0003; Tue, 13 Jun 2023 04:53:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 5C6578E0002 for ; Tue, 13 Jun 2023 04:53:05 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 1EFBE1A0449 for ; Tue, 13 Jun 2023 08:53:05 +0000 (UTC) X-FDA: 80897109930.25.A15A1C0 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf05.hostedemail.com (Postfix) with ESMTP id 48447100007 for ; Tue, 13 Jun 2023 08:53:02 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf05.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686646383; 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; bh=XMhPEoAG1cg4aEIKU6iWxH70Dz0V2NbPuW9Y5cmd5w4=; b=UDKipsuBhw08fT1UHv/8d83tZzqP1p/Df9sxko5nXYEW/gtJLfvvmP+xPEdWOT1z7ci10Z gssfQA2TzRvLtkiak+swS/bkObS8yPyCyXyYhBOHH1bZe/WEu2JxjvsOeMGzf7AEOQJa6m OyzZ2lWJB5NIvL0IMsPYxgxj2bayB8s= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf05.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686646383; a=rsa-sha256; cv=none; b=v+Zy1oDGA75guTPnAk3O3bwr2H+6IWpQEX9qy9VHmKeNJQDIdOJabUkf59hE1QJJavGlFy tXWWsuJ+C6lUWXJt+TgelZD5Od3ie/uz/wTG5RVo4mTH7UWfe5wOFL7mhhcWkq4BqjRU5/ iq0A0ZzWoFqZEtx3FXEemhgSxVojz/A= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4BED11FB; Tue, 13 Jun 2023 01:53:47 -0700 (PDT) Received: from [10.57.74.148] (unknown [10.57.74.148]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 130BE3F71E; Tue, 13 Jun 2023 01:52:56 -0700 (PDT) Message-ID: Date: Tue, 13 Jun 2023 09:52:55 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.11.2 Subject: Re: [PATCH v3 0/3] Encapsulate PTE contents from non-arch code To: Muchun Song Cc: Andrew Morton , SeongJae Park , "Matthew Wilcox (Oracle)" , "Kirill A. Shutemov" , Mike Rapoport , Yu Zhao , Jason Gunthorpe , David Airlie , Daniel Vetter , Dimitri Sivanich , Alex Williamson , Oleksandr Tyshchenko , Alexander Viro , Christian Brauner , Mike Kravetz , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Ian Rogers , Adrian Hunter , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Naoya Horiguchi , Miaohe Lin , Pasha Tatashin , Uladzislau Rezki , Christoph Hellwig , Lorenzo Stoakes , linux-kernel@vger.kernel.org, Linux Memory Management List , damon@lists.linux.dev References: <20230612151545.3317766-1-ryan.roberts@arm.com> <3ECE40AA-536E-4A2C-82BA-FE74AA6FB689@linux.dev> From: Ryan Roberts In-Reply-To: <3ECE40AA-536E-4A2C-82BA-FE74AA6FB689@linux.dev> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 48447100007 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: j5n16wmo1xt457po89wyn6zk1wwqmw6i X-HE-Tag: 1686646382-332142 X-HE-Meta: U2FsdGVkX18sUtA7K5hLFcUNvsid5hO3NjFS5HuojDEUSoyMGZUhdXaXLq5JZyLPMtmANhGsuTEtyPOrn2/NtbhflK0ggXlihrlClq24RbTPKv/Cl0hvonzLAHYqwJA33J0B55WU4baxNW0xIuivDOeKuVIKWgz23swg75Gyta76mH8+vc1/ovPHH8dRQi+L4+P7b7cGFXO9cZzcfdREyPqlJDT6pfUW+N2hFe480VgPswGR275RDuk2aGO/LhI0UBiOYn+Au/Hz3QElcjqYDGASj0zcCTl2qkVW1nNNba+40ZXK8SAK0Lnx3f6N+z2ZdyL8BjrT98vDbaF/eZYzdfADEQHv5TKdXJAPGkIBxzI0Q/27/HooPkJABz/qfIco+rfdsOCIA+EqA/ywei+xE5KnK4MpF8z9PKxxpMr3ruAMmy/oMVzSmrEDBO9i2k9oQ4KbOjLt3KtofbXVPU9VqjjxNRmiWOsP0lm6fuUgWK27CzQ9+0nfxBfryTd9mmRdC7W7cblbNQdWFfPKoA4yKPlJriRO4CjB4oEySsWJoLOK/3bx+wOQ45u7GQTlX0EieROVCdLqhtdjX1t1vvOc2cOk7PBYR2cgf1aBAU4Ej3Ej//6oDBrJMosUb/ppZITTO+KWf86BX4TdWiT+DbtO9Q6omaV9K18hCLVcziCR6GkO+X66n2rK20gL0sHfxEjoOLI7ClKQ9hME7tIma25Yf1tcY1mj1n6rKoO0dTOX6jVagNH6TgWHJnbq0Tm69LkOJbjB6IZ7dm5Znr5NT6neE7fuU7tt9HMUXP9x5xNcdjI3T1UuwKx/uF1XVKCfuG4h102B3DgKSZ+aPbVE6tchcAHiniqps0MSLPM1zKAP0xP684pOO0tOAwikE7qQ988Zq38x0GO4e7XbejWbubteMf4PKG727QRFL3Hr/f9xRZAeKVvaXQoBWQoTFm8RB4KC1PgE4XfnUBIu9h9yDw7 WWhiZzbU 8w/Qv1+8WkfuGdKCeHEBsi4D3TMmJRDrgn7ksRRnX/uYJMgsmr4wa1y7fzSK6GRLq5jXhZ+D9sgsOYjAXijOPMamHxdNn2OXWD/vNwGLGCFD5o5bs7C08oSdfECH38qUdiHl57ydtfU4wNECmtSsRl4UUT4DrDQnS7Fhnyt+oMX+GkfRWjd+h50r0PLnVnzhSnOoyc3kfwZavrl08QmdnQDuGK5nqFS6pIynqB8eQM9HhtmRHjUcD4fYQBBP9/MTmOvje60XqRtsgkYmP3TCgLh13nycdInhdhygJIFesCuCArDCWejHZYwud8a47WtXlCzNoUboiyNwcSOwzFRe9EWlUe5NXsmmM1iNDagum422VgYA= 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 13/06/2023 03:16, Muchun Song wrote: > > >> On Jun 12, 2023, at 23:15, Ryan Roberts wrote: >> >> Hi All, >> >> (Including wider audience this time since changes touch a fair few subsystems) >> >> This is the second half of v3 of a series to improve the encapsulation of pte >> entries by disallowing non-arch code from directly dereferencing pte_t pointers. >> Based on earlier feedback, I split the series in 2; the first part, fixes for >> existing bugs, was already posted at [3] and merged into mm-stable. This second >> part contains the conversion from direct dereferences to instead use >> ptep_get()/ptep_get_lockless(). >> >> See the v1 cover letter at [1] for rationale for this work. >> >> Based on feedback at v2, I've removed the new ptep_deref() helper I originally >> added, and am now using the existing ptep_get() and ptep_get_lockless() helpers. > > When I first saw the name of ptep_get()/ptep_get_lockless(), I thought > the pte seems like to be protected by the refcount mechanism (Why I have > this though? Because Qi Zheng has proposed a approach to free pte page tables > by using the refcount mechanism [1]). And your proposed name of ptep_deref() > is intuitive for me, so I have another thought, should we rename ptep_get() > to ptep_deref()? Just a thought from me, I'd like to hear if others object. I see your point, but I think any renaming exercise should be discussed and applied in the context of a separate patch series, given that ptep_get() and ptep_get_lockless() already exist in the code base. This would be a much bigger job, since it would need to cover all the arch code too. > > Thanks. > > [1] https://lore.kernel.org/lkml/20211110105428.32458-7-zhengqi.arch@bytedance.com/