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 2DBE0C47258 for ; Tue, 23 Jan 2024 15:22:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6D1196B0075; Tue, 23 Jan 2024 10:22:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 680B56B007B; Tue, 23 Jan 2024 10:22:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5709B6B007E; Tue, 23 Jan 2024 10:22:10 -0500 (EST) 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 466506B0075 for ; Tue, 23 Jan 2024 10:22:10 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id B687B120B23 for ; Tue, 23 Jan 2024 15:22:09 +0000 (UTC) X-FDA: 81710941578.13.AA35714 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf10.hostedemail.com (Postfix) with ESMTP id 80825C0015 for ; Tue, 23 Jan 2024 15:22:07 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf10.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706023328; 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=U4rODFtGTmyWl99tccAq27uh/JRrwvUMNk83FjTeLnE=; b=k01vbbbR8LM7GOSkhuTTLmWwj4I9gz+KeCUZCUW36V7QL0+a3NhCGFJid/1o8xMEhAiPB0 VveFl8Lj/0z1P1CQBN6UouNiIOeNtuWEtG18neIsMUpBBbh4W0WMyWnhqBHuxzl4FHB38U UE8s9XfO++OuqWZDdZ/gNMZnwdzhoCc= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf10.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706023328; a=rsa-sha256; cv=none; b=eM0iCGwLq/LLw45GheXlfOJ4mnPLjyia/IsNkWcj5+SgBCuGdj44FVmdv1SvDvuj+PdpEX OBOgiYFlavzYRx9EqErl09IlAXB2sw5VnmUTo9ewjn6/4ysdJxco3N9e0PMA4up+RiRxci hgzmBsD7VDrmasL13XJxP8lWz510J0I= 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 985121FB; Tue, 23 Jan 2024 07:22:51 -0800 (PST) Received: from [10.57.77.165] (unknown [10.57.77.165]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1AB543F5A1; Tue, 23 Jan 2024 07:22:01 -0800 (PST) Message-ID: <90a9b1e5-9203-4baf-a69a-69b4f9ad73d5@arm.com> Date: Tue, 23 Jan 2024 15:22:00 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 01/11] arm/pgtable: define PFN_PTE_SHIFT on arm and arm64 Content-Language: en-GB To: Matthew Wilcox Cc: David Hildenbrand , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Russell King , Catalin Marinas , Will Deacon , Dinh Nguyen , Michael Ellerman , Nicholas Piggin , Christophe Leroy , "Aneesh Kumar K.V" , "Naveen N. Rao" , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexander Gordeev , Gerald Schaefer , Heiko Carstens , Vasily Gorbik , Christian Borntraeger , Sven Schnelle , "David S. Miller" , linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, sparclinux@vger.kernel.org References: <20240122194200.381241-1-david@redhat.com> <20240122194200.381241-2-david@redhat.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 80825C0015 X-Stat-Signature: mrneqrgyj1j3z6ujwj1awys49haufkcf X-Rspam-User: X-HE-Tag: 1706023327-845359 X-HE-Meta: U2FsdGVkX19sQrhYGkzfES13YhejKdGTxu/+qEp8+Svghur0OoUW0yDuQFo122goVqpXOfQ3UtudwgkKm0imi0//5GVd25y6iOrANSnXvZ99TFAK7nbaksQ5J7HfPrTx0zPA5wV515lqwNk6npTVitK5jwInUmhHLcVXTN/fWm5vo78hyW95omct72tW5R6nlyoltIC239ip5QNCxxJ+I2z9lUOekTfr/S91XjJtuBmlkIHEepLx/FpxzISrWmydC1euBj7q4OWKiDqJl/Bak+H+4fThtfVEPdOUavRZVmiggCWMhQRb3XVvNJfDF1GXmYzmmix5pi6+4d5BHC6OI1Xbs5+hO2P4e7oJRV98LuiutyKfv/ouNzRAiIDfxbMeMkBpHQCRx3owtGXULxo3gIyx5jHhIQHt+zgOx9l2nbfUjit9AAXazHjhaYxDQpVNINb84bBo8zOvuGnC2CzIp+K92Cfa1SqPxpQ1pLId5l/8x3/1nRBK2odfffu7qD2JiHCeOOLsuLBQNkKpukAss6FiRyzVnlYEvzhVLWUcFkG0/srjm2FhhLngZcqdrAEvarOuMVhm2/aElED2SccNYFyrTnUd7SIKhfRzuD1AXmqx0p0wOSlJcJjBE2YNfxPlgipN0ff2X+xEOBDXoT/YOP3tLB0yW0yTm4lFnCf1oY7x3eRy30GkoqIS8Ez9w32yRq5AvMPQtqHwuqgwAjV56w+ns/g7YPljKe2x4DQgqbAZrLPg5JHaOQJi5FEC7xOXfR2zagrh77Kr0BiVPor6byHYSRTTqDDkY078ixA+sgS2Q48Z4FLAlNKI+eTtex6D2OA84/m21Mivxc4UtFp9VvQPBytyHKogEij4y05iF5dNTOrur/EfKRCyy/JLKCWD4SVGDUG+gXVRDhYt3FFNZRydqlGko+Iuw+/u+B+dxraDMBp4WnhvgD2zicCyhR1iOR+6P40qU61G3Y3T4nZ EY/FJ4/5 /Evi7brCrciy1TxdXBiMML15LuWnnfZRu7TooPRaTYqVOSNiMwDsmk2cvfh8XQkjy2YqlTEkdF/aa7i0ORD3lTDTjaAtHIhi2KvfkqvvboleQdcPACZ5k+41H8c683RXp2Cg2MtNY+YvpdJOwRsiDjwV21D0zr137tBGV0QpSY+my/FdkVddapfWGPAAkCL2LzIyj 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 23/01/2024 15:01, Matthew Wilcox wrote: > On Tue, Jan 23, 2024 at 10:34:21AM +0000, Ryan Roberts wrote: >>> +#define PFN_PTE_SHIFT PAGE_SHIFT >> >> I think this is buggy. And so is the arm64 implementation of set_ptes(). It >> works fine for 48-bit output address, but for 52-bit OAs, the high bits are not >> kept contigously, so if you happen to be setting a mapping for which the >> physical memory block straddles bit 48, this won't work. > > I'd like to see the folio allocation that can straddle bit 48 ... > > agreed, it's not workable _in general_, but specifically for a memory > allocation from a power-of-two allocator, you'd have to do a 49-bit > allocation (half a petabyte) to care. Hmm good point. So its a hypothetical bug, not an actual bug. Personally I'm still inclined to "fix" it. Although its going to cost a few more instructions. Shout if you disagree.