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 AD47CC021B2 for ; Tue, 25 Feb 2025 11:10:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 27CC06B007B; Tue, 25 Feb 2025 06:10:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 22CCD6B0082; Tue, 25 Feb 2025 06:10:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 11C716B0085; Tue, 25 Feb 2025 06:10:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id E918C6B007B for ; Tue, 25 Feb 2025 06:10:56 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 9ABB31411C1 for ; Tue, 25 Feb 2025 11:10:56 +0000 (UTC) X-FDA: 83158199712.30.EAD82EA Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf26.hostedemail.com (Postfix) with ESMTP id 94902140007 for ; Tue, 25 Feb 2025 11:10:54 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf26.hostedemail.com: domain of mark.rutland@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=mark.rutland@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740481855; 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=UhRam0JBn74B89ZVCpuJo7/ruXYreKV/tj8Ssr13oZc=; b=ETTTDgxB/1PnLbFUNr76sZK+VGq5urjlr/0o+TT8NMhd7Z1rurCL4Zh+j/EVpXgx7x50u1 LQrqxhnpQXpcCgOoKFrrwm/guVAVQcgYYOQhCXIRRb+98tlRVCgtjtn5PDzGjx9iU3mwGE oPNZ5l+YDKTzk27C2uwwC0rKE6/Pbrc= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf26.hostedemail.com: domain of mark.rutland@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=mark.rutland@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740481855; a=rsa-sha256; cv=none; b=XPMxTEg8dJcqEjRlkPBBQycP6+dIE9RAxzdh5HmG1M5XjWFWbNQVuooIaeuWPFh/4hFMHD oNhKj1+uyNCrkquF3Wt5m/63KXNbRmmc+RhNQsro2yoHA9TTfYJP5rpOYJ9mLXsREhoccA EmQM+AMtnXwTkpuUIBDEPQQhhjvsWTY= 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 D71D81516; Tue, 25 Feb 2025 03:11:09 -0800 (PST) Received: from J2N7QTR9R3 (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D357D3F673; Tue, 25 Feb 2025 03:10:51 -0800 (PST) Date: Tue, 25 Feb 2025 11:10:46 +0000 From: Mark Rutland To: Ryan Roberts Cc: Luiz Capitulino , LKML , linux-mm@kvack.org, ardb@kernel.org, "linux-arm-kernel@lists.infradead.org" , Catalin Marinas , Will Deacon Subject: Re: kernel BUG at arch/arm64/mm/mmu.c:185! Message-ID: References: <9f5600b3-6525-4045-ad1f-4408dfc9ce0f@redhat.com> <789c17e6-5ebc-4e37-93cd-19d24f148fd8@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Stat-Signature: 451671o4csr5z456in35qs8xc76yyn5j X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 94902140007 X-HE-Tag: 1740481854-87215 X-HE-Meta: U2FsdGVkX18pALzbd+rskFb24paYR4rvCanIs5aLCUtk+40WANRvptyLPGxvo+E3nS5/I16KPFy3N4gj5/INh71MWCth36slaxn4Uc4eJ9hzpiuv5YFomh0PjsFeLqqMRGF5vuDi+kU8RHFhr4JHwzdxS8jzU1jXrUz7dKho2Dhv4hUOd0d2qGzYYyA4bjP2K2ExILD/2IB+hZ556KPuQlc/sF5C3qFrW9upgZyAhMPm1eydqRM5yMf2AaBDdt/9lNTXtgoJgz9jr9DrVEfq4pC6W/4SdaqJdg0iU7M8oPG+fgjb09Ta58y0vIwsIC5mxEYNeNbixDsXgdEzBCqedHmIUzTRLGhYeWqMkzubZRt4lR8CADnbsMWJagbKhcdavK2FxlJGDv80VnKx9VZ8aMC10enqQnhZpD+RxiuGQt8w4+egxpuad5a6DJ/tn6rSrAKD3QsBV1f2OMQ05y/8VYb54qdM3Mip9pRr+QnZnWZOj0c66wtuN2tKO3xafQkRv4Zcs9PVxFGm6z6BlerkSY0gMPtQmn3dV+orAl2kWBC5AplrGOceNOv9Rj+XhbEhPq46MEMTxubHov4GP0xIflgc6r6dKCDJqWI3jefL5LJ08DekwBbaXfv5VBn7sSNUVBeqtJEzOGedRr4y9dxBkODo1yJSxbRhBRYsUdfiguw4Z8qQREWNX4zqK16vrX2RM1LBjH2Zi4IFfrp+xZrDmOoLds5ayGGLHI3EACiGgNZxsb5oEXwBYNmT1qPZnIXWk5q2qn2OWyaxdn2IcnSP+256FOeCeBCxsg/prtyGQFDQEYjgiEbCUUVxa5S3InkyMjkMuI6Vh+7cLcbnFqrqL+OhwquadZOVcTM3fp3KyPDGgcTpB5q0oOhufcW7FgfCQ9KNn/DVQ88SOGx1DxEAgot4jA0hVmVQ0qPDrY/PTfHXJ/cVkmgib6wzpnsqSkXtNCSkkduz77FSKxPUIrd pNFgNOBU 65Gp1pLlo0hPyZVbhSXvr6zxMi79n6pG1pl6Ap6soP4hOn4NS0aw29d2JDBCsGr8AlMngYWQQmsk0DCLYHwgles5XCvh/WeJhCQltIes+3/WGvlNo+CeYVz6Q/+fYmjQViLIAP7+RnUtfrdzEJ7EUpWcGUVwymQX3/kxDJWFRXIkKOX2MgADxew75llEMiFLN6qJkoDWZqkCS2Ja+Y0M8O3Dq0F5HsJaECRGG4zh2dqWKwuG1cTgqjkIomDWvVazqNAV2NHY+eW6+Vow= 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, Feb 25, 2025 at 09:47:30AM +0000, Ryan Roberts wrote: > (Adding arm folks for visibility) > > See original report here for context: > https://lore.kernel.org/all/a3d9acbe-07c2-43b6-9ba9-a7585f770e83@redhat.com/ > > TL;DR is that 6.14 doesn't boot on Ampere Altra when kaslr is enabled. > > > On 20/02/2025 20:08, Luiz Capitulino wrote: > > On 2025-02-19 09:40, Luiz Capitulino wrote: > > > >>>> Btw, I'll try to bisect again and will also try to update the system's firmware > >>>> just in case. > > > > I tried to bisect it and again, got nowhere. > > > > Git bisect says the first bad commit is 8883957b3c9de2087fb6cf9691c1188cccf1ac9c . > > But I'm able to boot that tree... > > > > OK, think I've found the dodgy commit: > > Commit 62cffa496aac ("arm64/mm: Override PARange for !LPA2 and use it consistently") > > Based on the changes it certainly looks like it could be the issue, but I > haven't spotted exactly what the problem is yet. Ard, could you take a look? > > I managed to hack multi ram bank support into kvmtool, so I can now repro the > issue in virtualization. Then was able to bisect to get to the above commit. If you're able to repro this, could you please say the configuration of memory banks you're using, and could you hack the BUG() to dump more info, e.g. something lihke the below, UNTESTED patch. Knowing the VA will tell us whether we're spilling out of the expected VA region otherwise going wildly wrong with addressing, and the values in the PTEs will tell us what's specifically triggering the warning. Also, if you're able to test with CONFIG_DEBUG_VIRTUAL, that might spot if we have a dodgy VA->PA conversion somewhere, which can Mark. ---->8---- diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c index b4df5bc5b1b8b..d04719919de33 100644 --- a/arch/arm64/mm/mmu.c +++ b/arch/arm64/mm/mmu.c @@ -171,19 +171,22 @@ static void init_pte(pte_t *ptep, unsigned long addr, unsigned long end, { do { pte_t old_pte = __ptep_get(ptep); + pte_t new_pte = pfn_pte(__phys_to_pfn(phys), prot); /* - * Required barriers to make this visible to the table walker - * are deferred to the end of alloc_init_cont_pte(). + * After the PTE entry has been populated once, we + * only allow updates to the permission attributes. */ - __set_pte_nosync(ptep, pfn_pte(__phys_to_pfn(phys), prot)); + if (!pgattr_change_is_safe(pte_val(old_pte), pte_val(new_pte))) { + panic("Unsafe PTE change @ VA:0x%016lx PA:%pa::0x%016llx -> 0x%016llx\n", + addr, &phys, pte_val(old_pte), pte_val(new_pte)); + } /* - * After the PTE entry has been populated once, we - * only allow updates to the permission attributes. + * Required barriers to make this visible to the table walker + * are deferred to the end of alloc_init_cont_pte(). */ - BUG_ON(!pgattr_change_is_safe(pte_val(old_pte), - pte_val(__ptep_get(ptep)))); + __set_pte_nosync(ptep, pfn_pte(__phys_to_pfn(phys), prot)); phys += PAGE_SIZE; } while (ptep++, addr += PAGE_SIZE, addr != end);