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 A59EAC2D0CD for ; Wed, 21 May 2025 11:45:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 30DC86B00B1; Wed, 21 May 2025 07:45:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 297AC6B00B2; Wed, 21 May 2025 07:45:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 186676B00B3; Wed, 21 May 2025 07:45:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id ECC306B00B1 for ; Wed, 21 May 2025 07:45:24 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 7D12012114F for ; Wed, 21 May 2025 11:45:24 +0000 (UTC) X-FDA: 83466734568.22.2279AB3 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf28.hostedemail.com (Postfix) with ESMTP id B1276C0009 for ; Wed, 21 May 2025 11:45:22 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=none; spf=pass (imf28.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747827922; 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=Y0kgKx6XouuiWptvr0pCruAp21uBzd0iJtEg/vmkzqw=; b=YB53OXxNLIuHEzL5G/fRfPoxmxiyst5Zs8ZMavo1+BVYUAfuvTPB8pCXotYAUIZP0ZbUlg wNJsl49ABnP9MsB61xFjPL/ehdCdMd/TXC2fhOr0qv180Zi0r0SaQM9BH/brjyO1xlt08j VSigxo20qnRAgTASlA/d6sC2dJAJ/8w= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none; spf=pass (imf28.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747827922; a=rsa-sha256; cv=none; b=Ta3QaiDJKiJUsNg7a7YwXmwRqFiVV8v7CczMTMi0QjoBBrsFlwKmPhd6XvP5ncp/QWf2L3 zWravnARYq+OYVrqQojKJJdkbCyzBEASTaJa5oFqxryzIggtVUsdI6zQSK9xejebSsFvzV aPtt909oBvKC3HLNcCLtHWE+HLJIBeg= 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 3598C1515; Wed, 21 May 2025 04:45:08 -0700 (PDT) Received: from [10.57.94.227] (unknown [10.57.94.227]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4380D3F6A8; Wed, 21 May 2025 04:45:18 -0700 (PDT) Message-ID: <7a1ae902-d97c-41ae-a3e7-5b6258ced1c5@arm.com> Date: Wed, 21 May 2025 12:45:16 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/5] mm: Add batched versions of ptep_modify_prot_start/commit Content-Language: en-GB From: Ryan Roberts To: Dev Jain , akpm@linux-foundation.org Cc: david@redhat.com, willy@infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, catalin.marinas@arm.com, will@kernel.org, Liam.Howlett@oracle.com, lorenzo.stoakes@oracle.com, vbabka@suse.cz, jannh@google.com, anshuman.khandual@arm.com, peterx@redhat.com, joey.gouly@arm.com, ioworker0@gmail.com, baohua@kernel.org, kevin.brodsky@arm.com, quic_zhenhuah@quicinc.com, christophe.leroy@csgroup.eu, yangyicong@hisilicon.com, linux-arm-kernel@lists.infradead.org, hughd@google.com, yang@os.amperecomputing.com, ziy@nvidia.com References: <20250519074824.42909-1-dev.jain@arm.com> <20250519074824.42909-3-dev.jain@arm.com> <59242559-5e90-4422-82f7-179a44eb968a@arm.com> In-Reply-To: <59242559-5e90-4422-82f7-179a44eb968a@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: awrautxneqd3sy8jbnuecdieqsyac3e6 X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: B1276C0009 X-HE-Tag: 1747827922-618062 X-HE-Meta: U2FsdGVkX18nXep4vE/nguuIPntPd6drCNmcQGHGZk0ep6h29IM/Ct/7T7A+/5M1+0v76l0y0Fe4JDy5Vl1UeSdHDAkLmxS9LKxnQjTu0d1CZahd245ZXiV0obpjtKtdz0RPn+erSqswAqm1ZqvzpMNOm7XhVvOYDtnhV9WyJEtkShGS0jck6U6YecWWWw0L328sNGqA0lRAYA2/avmYjKaaU/6ZFEoI4WHdVPK3897QtLWaYsDAyoN1A4KN8S2uL0vWaND/87eszMKNkTtBZtTenN67gXlsuQJupMfruYKlUEKHB9Hosx1gqHAFbAF2C7LyL9joJCs5ZxJnNOxTN6B0+b94g2q8SWay1buXANs2rdcFIXYtnCFTZkJU+VnuRDuMY6d1c8DZ2sRy1s3X31jR0ciUdd2JxuUE20L+6t8BWzvGJoJKaAdshp6XnRpJaCFzbMyMdpyXCAZJfczwW4D/wmZMB0Dr6smco+23b6r3urJPsABusAP0IzMpM/CACIXyj3SCbis90mUBIWJP3hUhmi9CbBJT/16PKaywZt65wLZYD29yan+MWyWr2ikzQNlXkpc6ZeupO1iNukW6bsppdYXsUOVEfOlOIyLrcoaHShEIbMx5mvZ3M5e7Nmuixvdv1qPnQdq4XswMmoORfd2L7/1jifVldGoYBlchrRROK9v2UKdjx21Rv7erlCANBkVgGjirqlF38U+K6y0ENVSF34MTA6g1pYskhZDO688QFHYa9TPtcNvvuhHwjfYmH4Ikw4s/vOZqxAq2piUyh4uA4sLud+/nNlyNq2HurkBxTMb9QXk1Mg0+23597kWJkVYNfjlzMPHF06aFIcP+tX59fmiqHqx1bbUwUrLG3PhDEutRSjYypzVKxYXdkKRFcwZMr+UMZBaDUpTgFVjg8DD68oqCcYoBgOZ+i7sEWKTTjcTp6nb9x90BMlJDxAUQgbm1uXY4afbB+u5fOlK O0l2p1Nx 0QanK7t3PwTMT0LgNe0WaMzkQB1vzmQ20KOTKB5l/PT9QNZ/VJX9XGNM72Jb3na6vFyIjXFCuXCH66IQNeEeHoW5U1iuu/CL3XXesoFv70Yvu7Y8QpoXnFSRJQVGHKFPG8UK4J+UNuGzHPwRuFkzhG5rZ8J9KKsXk8VR7dOkhZ7mnLxhYT2cpLWLe0aplWTuDh745qLu1zB9zvqFu5xMGlPn34Q== 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: List-Subscribe: List-Unsubscribe: On 21/05/2025 12:16, Ryan Roberts wrote: > On 19/05/2025 08:48, Dev Jain wrote: >> Batch ptep_modify_prot_start/commit in preparation for optimizing mprotect. >> Architecture can override these helpers; in case not, they are implemented >> as a simple loop over the corresponding single pte helpers. >> >> Signed-off-by: Dev Jain [...] > > I have some general concerns about the correctness of batching these functions. > The support was originally added by Commit 1ea0704e0da6 ("mm: add a > ptep_modify_prot transaction abstraction"), and the intent was to make it easier > to defer the pte updates for XEN on x86. > > Your default implementations of the batched versions will match the number of > ptep_modify_prot_start() calls with the same number of ptep_modify_prot_commit() > calls, even if modify_prot_commit_ptes() is called incrementally for sub-batches > of the batch used for modify_prot_start_ptes(). That's a requirement and you've > met it. But in the batched case, there are 2 differences; > > - You can now have multiple PTEs within a start-commit block at one time. I > hope none of the specialized implementations care about that (i.e. XEN). I had a look; this isn't a problem. > > - when calling ptep_modify_prot_commit(), old_pte may not be exactly what > ptep_modify_prot_start() returned for that pte. You have collected the A/D bits, > and according to your docs "PTE bits in the PTE range besides the PFN can > differ" when calling modify_prot_start_ptes() so R/W and other things could > differ here. It looks like powerpc will break if you provide old_pte which has different permissions to the "real" old_pte, see radix__ptep_modify_prot_commit(). So I think you need to at least spec modify_prot_start_ptes() to require that all bits of the PTE except the PFN, access and dirty are identical. And perhaps you can VM_WARN if found to be otherwise? And perhaps modify ptep_modify_prot_commit()'s documentation to explcitly allow old_pte's access/dirty to be "upgraded" from what was actually read in ptep_modify_prot_start()? XEN/x86 and arm64 don't care about old_pte. Thanks, Ryan > > I'm not sure if these are problems in practice; they probably are not. But have > you checked the XEN implementation (and any other specialized implementations) > are definitely compatible with your batched semantics? >