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 7CC4AC4167B for ; Wed, 29 Nov 2023 11:55:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E5BFC6B03CA; Wed, 29 Nov 2023 06:55:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DE50D6B03CD; Wed, 29 Nov 2023 06:55:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CAC836B03CE; Wed, 29 Nov 2023 06:55:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id B1EC46B03CA for ; Wed, 29 Nov 2023 06:55:50 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 907C1A0431 for ; Wed, 29 Nov 2023 11:55:50 +0000 (UTC) X-FDA: 81510837660.01.B2AD4F0 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf15.hostedemail.com (Postfix) with ESMTP id B2966A0007 for ; Wed, 29 Nov 2023 11:55:48 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf15.hostedemail.com: domain of alexandru.elisei@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=alexandru.elisei@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701258949; 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; bh=3HZBEdufaoAFivEtTbxTBKtmXrt0Zj5PyTeapCslDns=; b=glBdeQ5HvkDxCi1QUOsn1Vcinizw08xFYWZBJ/o8tKo+GDyn7b5J48CMW0M2Id+4hAr1a/ bJFSa3+9XGx+riiV8QXkoEWdU16PpI4eT6zm3ko8VpzRaliz3rtHuwGxI0CHbzsX8K5AIU MuVF5//ETvSiqQXb14fXZWhTtJ8QGDw= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf15.hostedemail.com: domain of alexandru.elisei@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=alexandru.elisei@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701258949; a=rsa-sha256; cv=none; b=Hc/j9hsv4CvheerNxp8ytaVam3KwSNqEYfwUV/1WmAXt1coXRYvCXw8AgdkJ5bPwjKRKnt 0eYuQ7UtpXhBv82zNeDoyhqVrEawXxAP0VB8xQA6mveI6VNk1tgVTdElc8b7O6+jFEhFnh IpwcJMB0xBLM/12UkNbJfZxoBK3QtIY= 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 AE3832F4; Wed, 29 Nov 2023 03:56:34 -0800 (PST) Received: from raptor (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 931583F5A1; Wed, 29 Nov 2023 03:55:42 -0800 (PST) Date: Wed, 29 Nov 2023 11:55:39 +0000 From: Alexandru Elisei To: David Hildenbrand Cc: catalin.marinas@arm.com, will@kernel.org, oliver.upton@linux.dev, maz@kernel.org, james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, arnd@arndb.de, akpm@linux-foundation.org, mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, bristot@redhat.com, vschneid@redhat.com, mhiramat@kernel.org, rppt@kernel.org, hughd@google.com, pcc@google.com, steven.price@arm.com, anshuman.khandual@arm.com, vincenzo.frascino@arm.com, eugenis@google.com, kcc@google.com, hyesoo.yu@samsung.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org Subject: Re: [PATCH RFC v2 19/27] mm: mprotect: Introduce PAGE_FAULT_ON_ACCESS for mprotect(PROT_MTE) Message-ID: References: <20231119165721.9849-1-alexandru.elisei@arm.com> <20231119165721.9849-20-alexandru.elisei@arm.com> <1c79ad05-cb52-4820-b2aa-bbe07ff82b19@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1c79ad05-cb52-4820-b2aa-bbe07ff82b19@redhat.com> X-Rspam-User: X-Stat-Signature: kejxp9aady3tw4intxsoy4n99fezh6ib X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: B2966A0007 X-HE-Tag: 1701258948-737406 X-HE-Meta: U2FsdGVkX1+AndlQaNfZez/e7nKTanSF+5eSd7gCpf9HHNaRRekfy4jBM2Czka6sMLJMXPfrgsYofqeIr5rlTAbL2RyAysjIbolOjcminADv3oaDKOMmyE/rj8fg3833dmPinwCu19+7SWw9YJcibuX7RwV5rhgRbLXvp5sXyEUMTAv2In0xnJq8O2+RxDGIkphABtVeFW8FXk4S9DhCLInGPBGQvUEgEmYSiOQpVfpQVAoVDhvaBRsJ5DFB9XLsTh2Uf1gRjjPnHn+6/PVS8qdxsQi26qZPDSzhhdSDYNXqGYQps4QPBuWQDC8IlCUhlck1Od1+RUc1Z0vdQZk9Z/XRTn2YBCjXPCzYGxGwn+lwPAQSDo83Q2psGCP2RL0B/C2WjIwY6TSsfWUPvzF96kOIcWl7+Ih8i61Ajsg0LHsNENuplCtdD9yYqrPUVCkQUrnGXuUro2hmX6s8pzJVOdXDsADa2xJCcM+a+u1Ae1sc5mXXZA4MNWFy6nO/jMZWO1tHuCXfNzD5fRcPudOyGAMtN8TB7UrPiW4/j8qJjcURMGs8hehs3aJ9WXljgWeZrVcpkwY6uYhoXLb0EhyzTSQHyXOn9wcr+a9YyyoC+BZ90z31CiKCwdafKO1RcQlTIZxuImbfF6s4X9lVajAYUXzQySaeVgroL5Bf+PWAiPDyTD2A8SuvP9ngfYKPOhYESQqlSTVDBmzWwIX7OOuU49vr1rz1KUhhV+bWis+ouJrO5Zuflc5w3E7k2WHNmMjvtmilXQqrXYP9QXnrtc0xl27kyJjI3kcQ/CUx4xyoyGxxWEguCDi1pSNdX3zvRPLR2WKsdSV8Qs0LaRUm5Q9K+zohyIRCoIZB4ipB6ZywcQuWSVJ62zkpFuEBuhWNaqkBpKcaUOYXZ5DEw3fAA9ldSsN59WkBuglabWVyweIOFGYpLf/UrPolOjNCGWiwiKszR4wfr+Dk8aeN/tW+Y4d VihE9l1j 0rjzN2IVDVW9CS9qv7YIyxbCDbGgAaHxEjtTS8xC+eT3K7eF3s1rJvN7wbiR/6pdCooD+hWjyAFABrSRBCQiHmf+tgl3KYnKHWS/uahl5unYiz7vqRbM6URRa/PPmbCfSlj+pEzZemyk0yt6kDJYl0tN7+g== 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: Hi, On Tue, Nov 28, 2023 at 06:55:18PM +0100, David Hildenbrand wrote: > On 19.11.23 17:57, Alexandru Elisei wrote: > > To enable tagging on a memory range, userspace can use mprotect() with the > > PROT_MTE access flag. Pages already mapped in the VMA don't have the > > associated tag storage block reserved, so mark the PTEs as > > PAGE_FAULT_ON_ACCESS to trigger a fault next time they are accessed, and > > reserve the tag storage on the fault path. > > That sounds alot like fake PROT_NONE. Would there be a way to unify hat Yes, arm64 basically defines PAGE_FAULT_ON_ACCESS as PAGE_NONE | PTE_TAG_STORAGE_NONE. > handling and simply reuse pte_protnone()? For example, could we special case > on VMA flags? > > Like, don't do NUMA hinting in these special VMAs. Then, have something > like: > > if (pte_protnone(vmf->orig_pte)) > return handle_pte_protnone(vmf); > > In there, special case on the VMA flags. Your suggestion from the follow-up reply that an arch should know if it needs to do something was spot on, arm64 can use the software bit in the translation table entry for that. So what you are proposing is this: * Rename do_numa_page->handle_pte_protnone * At some point in the do_numa_page (now renamed to handle_pte_protnone) flow, decide if pte_protnone() has been set for an arch specific reason or because of automatic NUMA balancing. * if pte_protnone() has been set by an architecture, then let the architecture handle the fault. If I understood you correctly, that's a good idea, and should be easy to implement. > > I *suspect* that handle_page_missing_tag_storage() stole (sorry :P) some Indeed, most of the code is taken as-is from do_numa_page(). > code from the prot_none handling path. At least the recovery path and > writability handling looks like it better be located shared in > handle_pte_protnone() as well. Yes, I agree. Thanks, Alex > > That might take some magic out of this patch. > > -- > Cheers, > > David / dhildenb >