Message ID | 20240202080756.1453939-2-ryan.roberts@arm.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-49412-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:9bc1:b0:106:209c:c626 with SMTP id op1csp278011dyc; Fri, 2 Feb 2024 00:08:51 -0800 (PST) X-Google-Smtp-Source: AGHT+IFvxz93C8OqOjjyGR+CIg5JEcBnT2xG6Myzb/uqFCcBwT2Xl/m52ymHaGCpT+WeXub6xXnC X-Received: by 2002:aa7:d055:0:b0:55f:8ddc:6c8b with SMTP id n21-20020aa7d055000000b0055f8ddc6c8bmr688772edo.10.1706861331761; Fri, 02 Feb 2024 00:08:51 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706861331; cv=pass; d=google.com; s=arc-20160816; b=vrSlpxP1BFh246ctHyosqos7zj2TVqMqVN6UyA4Q4ibg7SoJpCZ200HPmDhM2fvUTM 3RGWf57PrZNvSNHalUH5CAG3uAZnbt3Jwp33svUMVaJ+mUGZlO2uj/9Iv9NLEenxmKgZ +QisN447ivxGe/FaTYcFf8pO9MvNk2h3PbUOumSvjXp46Q2xnsJ7w9veiCWVfoRI1Pz4 tRivVV+MFIMPaJeWD9ateN7GdfnI7JlCL+OVd7uTKhKrM0KHeXYrlF+9z4iZwthvvL6j gEDoAP4YpyhJkON82hA9DtvdZE7Rrs+/MLptX0wrQ+t5aPFNIh6icSo+k1pUtY9GXfTa 7vgw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from; bh=dr+JmlJli2R+rlUtzp9TTxxnomA8MeE7u4eqm10nX+k=; fh=7FtWjP76BxXFIKi6miwOgA52mr8RrNJwv1jl8gj1aco=; b=DpILZ/vjo+aIDGAUoR6LWN2RFgfRQlMvtCc9Lzp6twcWjpnzMFkHmtwiqG5w8hiOBC oOeXrSJdyKUQLOXZKG2yZgu07eLA/Ysorhn74Ev6QFOg4xlzoJXViD29oJEZu+XOsFYP 6vqX2kU8f/Hw3cHeVhu2fPzuWYkE/4/od+StpyH4IzwpAhHg4NqqsFSAE6KJAs3YOAM7 SfBcdbm2/oyAKQiDmTO8aktZmA2fkepDdzQbe9GJg/G7Gmc6LbjdeeABTW3TS3xritRT GRl9JBbHsvBrjbEh1wfB7oCM0HJGVq6LT6nAT35zuqlAnzm8Nb2+g6T7blGzw6Cnt2cD F0fQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-49412-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-49412-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com X-Forwarded-Encrypted: i=1; AJvYcCXSGWNXPdtgETMGUZHb/WCa09Rvjpj5wylN5is6N+NDYSl5unPL3WrlLeBlX90suNrooSEvea5WAoLDgkdUWh6ZOMqKAg== Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id dh16-20020a0564021d3000b0055fa7f96b6bsi598756edb.313.2024.02.02.00.08.51 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Feb 2024 00:08:51 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-49412-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-49412-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-49412-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 541591F2A857 for <ouuuleilei@gmail.com>; Fri, 2 Feb 2024 08:08:51 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6069B182C3; Fri, 2 Feb 2024 08:08:24 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D613E17C6E for <linux-kernel@vger.kernel.org>; Fri, 2 Feb 2024 08:08:20 +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=1706861302; cv=none; b=eQBX1I+lOmIxRH6jHp8O4/ewl7uHM2v/HkFO9j9JCyn3pz1snHcdWFPZ6J4joLU77TA9lyAYcxTTN+36HdBJIOBTw+3dC7TkYVUHaQ87hQ3m2X2oyniP4e8ZSFHmtqnv/Z9fhlIm1koYIJ0qrD2qXAZ0SqtKMpejXK1NKdwybls= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706861302; c=relaxed/simple; bh=crs7YcgUTYuqfO1G2FpVn6hqQ5vqbIBn8D+pZnE5y4s=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=AXmWba+vhhMii0ZcRBxasEalutri35btSnONuW2iJCOymFQDcmeBA3yWxhMH1u9Gkkm9dK3slQwOwrGbkUVIZzpQLo6udQ8PMTsVEJxxFyv1u49CwEIk1H8XCQ3frExLPY4sx9tpJd6tZzy+Stq1C+uzto/KTzbpvdrdNdzcvUY= 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 85221FEC; Fri, 2 Feb 2024 00:09:02 -0800 (PST) Received: from e125769.cambridge.arm.com (e125769.cambridge.arm.com [10.1.196.26]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 99B143F5A1; Fri, 2 Feb 2024 00:08:16 -0800 (PST) From: Ryan Roberts <ryan.roberts@arm.com> To: Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Ard Biesheuvel <ardb@kernel.org>, Marc Zyngier <maz@kernel.org>, James Morse <james.morse@arm.com>, Andrey Ryabinin <ryabinin.a.a@gmail.com>, Andrew Morton <akpm@linux-foundation.org>, Matthew Wilcox <willy@infradead.org>, Mark Rutland <mark.rutland@arm.com>, David Hildenbrand <david@redhat.com>, Kefeng Wang <wangkefeng.wang@huawei.com>, John Hubbard <jhubbard@nvidia.com>, Zi Yan <ziy@nvidia.com>, Barry Song <21cnbao@gmail.com>, Alistair Popple <apopple@nvidia.com>, Yang Shi <shy828301@gmail.com>, Nicholas Piggin <npiggin@gmail.com>, Christophe Leroy <christophe.leroy@csgroup.eu>, "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>, "Naveen N. Rao" <naveen.n.rao@linux.ibm.com>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, "H. Peter Anvin" <hpa@zytor.com> Cc: Ryan Roberts <ryan.roberts@arm.com>, linux-arm-kernel@lists.infradead.org, x86@kernel.org, linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH v5 01/25] mm: Clarify the spec for set_ptes() Date: Fri, 2 Feb 2024 08:07:32 +0000 Message-Id: <20240202080756.1453939-2-ryan.roberts@arm.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20240202080756.1453939-1-ryan.roberts@arm.com> References: <20240202080756.1453939-1-ryan.roberts@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1789773827882459492 X-GMAIL-MSGID: 1789773827882459492 |
Series |
Transparent Contiguous PTEs for User Mappings
|
|
Commit Message
Ryan Roberts
Feb. 2, 2024, 8:07 a.m. UTC
set_ptes() spec implies that it can only be used to set a present pte
because it interprets the PFN field to increment it. However,
set_pte_at() has been implemented on top of set_ptes() since set_ptes()
was introduced, and set_pte_at() allows setting a pte to a not-present
state. So clarify the spec to state that when nr==1, new state of pte
may be present or not present. When nr>1, new state of all ptes must be
present.
While we are at it, tighten the spec to set requirements around the
initial state of ptes; when nr==1 it may be either present or
not-present. But when nr>1 all ptes must initially be not-present. All
set_ptes() callsites already conform to this requirement. Stating it
explicitly is useful because it allows for a simplification to the
upcoming arm64 contpte implementation.
Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
---
include/linux/pgtable.h | 4 ++++
1 file changed, 4 insertions(+)
Comments
On 02.02.24 09:07, Ryan Roberts wrote: > set_ptes() spec implies that it can only be used to set a present pte > because it interprets the PFN field to increment it. However, > set_pte_at() has been implemented on top of set_ptes() since set_ptes() > was introduced, and set_pte_at() allows setting a pte to a not-present > state. So clarify the spec to state that when nr==1, new state of pte > may be present or not present. When nr>1, new state of all ptes must be > present. > > While we are at it, tighten the spec to set requirements around the > initial state of ptes; when nr==1 it may be either present or > not-present. But when nr>1 all ptes must initially be not-present. All > set_ptes() callsites already conform to this requirement. Stating it > explicitly is useful because it allows for a simplification to the > upcoming arm64 contpte implementation. > > Signed-off-by: Ryan Roberts <ryan.roberts@arm.com> > --- > include/linux/pgtable.h | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h > index f0feae7f89fb..5e7eaf8f2b97 100644 > --- a/include/linux/pgtable.h > +++ b/include/linux/pgtable.h > @@ -229,6 +229,10 @@ static inline pte_t pte_next_pfn(pte_t pte) > * @pte: Page table entry for the first page. > * @nr: Number of pages to map. > * > + * When nr==1, initial state of pte may be present or not present, and new state > + * may be present or not present. When nr>1, initial state of all ptes must be > + * not present, and new state must be present. > + * > * May be overridden by the architecture, or the architecture can define > * set_pte() and PFN_PTE_SHIFT. > * Acked-by: David Hildenbrand <david@redhat.com>
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h index f0feae7f89fb..5e7eaf8f2b97 100644 --- a/include/linux/pgtable.h +++ b/include/linux/pgtable.h @@ -229,6 +229,10 @@ static inline pte_t pte_next_pfn(pte_t pte) * @pte: Page table entry for the first page. * @nr: Number of pages to map. * + * When nr==1, initial state of pte may be present or not present, and new state + * may be present or not present. When nr>1, initial state of all ptes must be + * not present, and new state must be present. + * * May be overridden by the architecture, or the architecture can define * set_pte() and PFN_PTE_SHIFT. *