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 B3567C07E97 for ; Wed, 29 Nov 2023 11:30:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4ABE46B03CB; Wed, 29 Nov 2023 06:30:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 45BCD6B03CC; Wed, 29 Nov 2023 06:30:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 34AFC6B03CD; Wed, 29 Nov 2023 06:30:31 -0500 (EST) 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 268016B03CB for ; Wed, 29 Nov 2023 06:30:31 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id EC3BC80348 for ; Wed, 29 Nov 2023 11:30:30 +0000 (UTC) X-FDA: 81510773820.09.1916CC6 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf03.hostedemail.com (Postfix) with ESMTP id 1FF8320022 for ; Wed, 29 Nov 2023 11:30:28 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf03.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=1701257429; 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=HUrKZ3dL65b1LLjsUK4CJ0B90SSgtUZ9F5W2Ycl+uMQ=; b=TIr3/uWvQAi5PJim8H29PNjYKuCHbKEB82NBFH+V2UP2wWA1blp5Zi6/sYoV47YuFrRR5c p1J7HcAbZ2fMvSbVCDgdk7fznUW12Ozd9T4pMPy5IYd+8OJM5btUSqS8WmnxkIG4NI9LX6 gVgyG/K1nIChg3FjrucMG5krHeSJ5TU= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf03.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=1701257429; a=rsa-sha256; cv=none; b=u70q2DfnPkzwN4eDHa8c2lxQtbgOlzy1DOejLOrNKGiXFtzwimO5J6RIrPrvgq3DJjDhlJ n11EHsRaSv0g8PsfcOZqbkrZvFz14KLTuD3WTtBIx8jDXQdef8Q2hoVYe/OebjDj8uFtzw e8eQHyIXWwUDGHRGCupCp+mzPuKn3g8= 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 4AEB72F4; Wed, 29 Nov 2023 03:31:15 -0800 (PST) Received: from raptor (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C0D8A3F5A1; Wed, 29 Nov 2023 03:30:22 -0800 (PST) Date: Wed, 29 Nov 2023 11:30:20 +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 18/27] arm64: mte: Reserve tag block for the zero page Message-ID: References: <20231119165721.9849-1-alexandru.elisei@arm.com> <20231119165721.9849-19-alexandru.elisei@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Stat-Signature: 8odcxzgurqynyhqmosa6mf5dqp39qohk X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 1FF8320022 X-HE-Tag: 1701257428-887995 X-HE-Meta: U2FsdGVkX1/l6InfHsRxUkh8sp0VQvPKQkXDhCoo+0SqszUpk1OfIZ7mMgtz87R3E5UDYNz3wK2JkozqgRlk+vl7BP+Bb3eCMFb4FkgOFqhXDvwaLVraOr+jd4ruFDGF6iVW1LqM2/BfxoQwihbtFOKSjGk76PkN/xheox8cskyxe4a2zSU8Ua6SeXYLvNANBvsGwakm+Zt0/AeCf6L3Z2GWo428JgYJ8nMqaleoAF6bR5XVbIbonD/leqZzexa3MFHQ1IT1bpOBbLjKLYZTTlKOjJuxcYx4/lD2HBNg+bXLqCepwQQxCryQ3WR2dikp4Zig4PJcF1DHT1tWK7FHfeno7XNDmQbltNKT7XsVS6rIhsZiOvIV+OirzSRlVSFdDFlASYrX2lMrYprwPe7CcJ26ERfTV/1oNOFYIoJzv3tpL3cWJrKACc5ROQO4uA0opK8k9yMtCNfp9BB4rdPEzrLynJmNyBCuFx2Xub/sM8hkpesO4Hq40MG0Aiq9mY35BfQF3LRLJiTTcBhi0I5dFoa+CwtYtEyZO0nxhIaK+dmw1+N30mzn/jwhET+lwW5ORUci91uKo6EINgBjAEd4tpFthxns4Ky46/jCo6S581p2wZzq0euSYG+V275H7b9x/xnVCI/7fEyqLGVBLl5mMwLEl7gvzd110DX3/LO86zUz36AYgJzNe7FWq2z0zemmOgCZXD0ie31oGvfOOUdDOnO7RYB/8vARteftILYAcHKhAiYiBHkg4pc4IzAevVos8GSCkMM/RiYOnsgTdhgJ54jahwL27MgzGCwRcntGZferKd8joX2jrozCupQrTZFtdiRwdxKkEwaBpHpmUE108PgPnga/6SC8oBdConLmR0JLjyGpEAs+nnihGVLCAfRTupJ8FB1TLloRX945HUuxhVVj2JvMiYoDAyV5Jj87sdRK6GfydkDo1bw6uUS5KHEFdBobsdTWZIKg9zv0aut dF4gt/dm 9q5v0YG8HhjbySPsiBy50hFIVAisFY1ATFV78kr/3aYB/yvj6/F67829YjVeOwn7PgokJXxOC+1rnPMPSKg0g9++6LJ50gJTS4yMjiIjQ4Xl2vMvsOAInoUgwSzAVl3o73KDfmioqCd9Q5UrfSRFEzEiSMOwyAX0c2mHI5daXsdZIfnWaN4EojFH8QRcKVsrZP5o4QTBYtFmudtPtOXUyzYNpmslR2ynJIQQP 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 Tue, Nov 28, 2023 at 06:06:54PM +0100, David Hildenbrand wrote: > On 19.11.23 17:57, Alexandru Elisei wrote: > > On arm64, the zero page receives special treatment by having the tagged > > flag set on MTE initialization, not when the page is mapped in a process > > address space. Reserve the corresponding tag block when tag storage > > management is being activated. > > Out of curiosity: why does the shared zeropage require tagged storage? What > about the huge zeropage? There are two different tags that are used for tag checking: the logical tag, the tag embedded in bits 59:56 of an address, and the physical tag corresponding to the address. This tag is stored in a separate memory location, called tag storage. When an access is performed, hardware compares the logical tag (from the address) with the physical tag (from the tag storage). If they match, the access is permitted. The physical tag is set with special instructions. Userspace pointers have bits 59:56 zero. If the pointer is in a VMA with MTE enabled, then for userspace to be able to access this address, the physical tag must also be 0b0000. To make it easier on userspace, when a page is first mapped as tagged, its tags are cleared by the kernel; this way, userspace can access the address immediately, without clearing the physical tags beforehand. Another reason for clearing the physical tags when a page is mapped as tagged would be to avoid leaking uninitialized tags to userspace. The zero page is special, because the physical tags are not zeroed every time the page is mapped in a process; instead, the zero page is marked as tagged (by setting a page flag) and the physical tags are zeroed only once, when MTE is enabled at boot. All of this means that when tag storage is enabled, which happens after MTE is enabled, the tag storage corresponding to the zero page is already in use and must be rezerved, and it can never be used for data allocations. I hope all of the above makes sense. I can also put it in the commit message :) As for the zero huge page, the MTE code in the kernel treats it like a regular page, and it zeroes the tags when it is mapped as tagged in a process. I agree that this might not be the best solution from a performance perspective, but it has worked so far. With tag storage management enabled, set_pte_at()->mte_sync_tags() will discover that the huge zero page doesn't have tag storage reserved, the table entry will be mapped as invalid to use the page fault-on-access mechanism that I introduce later in the series [1] to reserve tag storage, and after that set_pte_at() will zero the physical tags. [1] https://lore.kernel.org/all/20231119165721.9849-20-alexandru.elisei@arm.com/ Thanks, Alex > > -- > Cheers, > > David / dhildenb >