Message ID | 20240125164256.4147-26-alexandru.elisei@arm.com (mailing list archive) |
---|---|
State | Handled Elsewhere |
Headers | show
Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1B829135A55; Thu, 25 Jan 2024 16:45:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706201113; cv=none; b=scGs38KOmFkcmDYM72GIYIqcqq+gWQlLIXIpoF//2kKNkLeWNGoJo/CCainZBIfVr0r3p7w8EASlHTrlsEfFAjQXA2xBI+ejfA2+xPbSBiiI7IjUqWJhh7JSEpW7KjJmMXvcYeso8pY5mBT26KAJ1r7MfC34Rx/eh9Lmac3wpXg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706201113; c=relaxed/simple; bh=7GSpvoz7AckF0nurdaP1+AUs5Wt1UqGcytFWfgfXtws=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=d3g+29fziuSkccth75Nd1XFlUJVFwSBJe/e4qmW6ZY+PFq6FJLGVuoGlUWAfenUZFqhQKPjRklnAXrlDwSfrAu3BM7irzXwQIPFbSkT7notLZaveqK4GxNdSxc1AEHpObSKn0fon6bHe9f/gEFiWjS5aRUrOADjRLhtLhNvJRP0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com 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 08EF7169C; Thu, 25 Jan 2024 08:45:56 -0800 (PST) Received: from e121798.cable.virginm.net (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1C34E3F5A1; Thu, 25 Jan 2024 08:45:05 -0800 (PST) From: Alexandru Elisei <alexandru.elisei@arm.com> To: 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 Cc: pcc@google.com, steven.price@arm.com, anshuman.khandual@arm.com, vincenzo.frascino@arm.com, david@redhat.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: [PATCH RFC v3 25/35] arm64: mte: Reserve tag block for the zero page Date: Thu, 25 Jan 2024 16:42:46 +0000 Message-Id: <20240125164256.4147-26-alexandru.elisei@arm.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240125164256.4147-1-alexandru.elisei@arm.com> References: <20240125164256.4147-1-alexandru.elisei@arm.com> Precedence: bulk X-Mailing-List: linux-trace-kernel@vger.kernel.org List-Id: <linux-trace-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-trace-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-trace-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit |
Series |
Add support for arm64 MTE dynamic tag storage reuse
|
expand
|
diff --git a/arch/arm64/kernel/mte_tag_storage.c b/arch/arm64/kernel/mte_tag_storage.c index 8c347f4855e4..1c8469781870 100644 --- a/arch/arm64/kernel/mte_tag_storage.c +++ b/arch/arm64/kernel/mte_tag_storage.c @@ -363,6 +363,8 @@ static int __init mte_enable_tag_storage(void) goto out_disabled; } + reserve_tag_storage(ZERO_PAGE(0), 0, GFP_HIGHUSER); + static_branch_enable(&tag_storage_enabled_key); pr_info("MTE tag storage region management enabled");
On arm64, when a page is mapped as tagged, its tags are zeroed for two reasons: * To prevent leakage of tags to userspace. * To allow userspace to access the contents of the page with having to set the tags explicitely (bits 59:56 of an userspace pointer are zero, which correspond to tag 0b0000). The zero page receives special treatment, as the tags for the zero page are zeroed when the MTE feature is being enabled. This is done for performance reasons - the tags are zeroed once, instead of every time the page is mapped. When the tags for the zero page are zeroed, tag storage is not yet enabled. Reserve tag storage for the page immediately after tag storage management becomes enabled. Note that zeroing tags before tag storage management is enabled is safe to do because the tag storage pages are reserved at that point. Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com> --- Changes since rfc v2: * Expanded commit message (David Hildenbrand) arch/arm64/kernel/mte_tag_storage.c | 2 ++ 1 file changed, 2 insertions(+)