From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5ED1D33D4EC for ; Mon, 26 Jan 2026 14:18:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769437106; cv=none; b=AjzXqGGCga477SoBmmji8QR+pNm5SU+iDybNfBtLYuLalOZw2CY+dY0+S+Mv4hYDm9B3tNoyVg8QXRn+bHM09iGfCA/Wl1HWiCutDg5Pt0VtHgnpLpSvV6za+BmUXQ9jioGXbT45P6l8Wh5YD3kB7yBdfp2Yl9dt2JVZ9cwvvKQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769437106; c=relaxed/simple; bh=SzW0Gil2VZdrbEyNqGsbocnMPP9c7OdoPzfUpkSM08M=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=itrnyl0ylMx2Ho1+XA28X8mCA/wvqZuCDdQxgmMoEuea7NO1Y3/9/hN7SZ/RVVBhLQ+nRNT0yft09R79iv82bjZ+FWMjyTjik0Iud3Tey1FLL+5c8aabJ3E9qHWWayoau1zTqGRQYwgoWIDSf/al+E47Sm83a6AhIoEwRqzziX8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MhCtSowZ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MhCtSowZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9E019C116C6; Mon, 26 Jan 2026 14:18:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769437105; bh=SzW0Gil2VZdrbEyNqGsbocnMPP9c7OdoPzfUpkSM08M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=MhCtSowZKbZn7fMam57zwRRM7aPZV0bbvMRfqnLop3buhqJc+Wb71u+XhmONIN071 nU+7aeg/7kubK2dDxPOM+HWSHexxqhL0JE8YADE95iGuBw8Y6vuJL7CpkeIQxDVO/B ulAVokRwP31qSkK+hL4EN2onlhmmvyhpG3z4KNd4cq19xZXBEX3IJeU28qi8cmbEAv tWgvQd6dg9CV9jgvZRO2mf5cTtz0Z3tzfcQqR8d/bIc8S81gBALU7kuvVdbV6mhODi uJ8xQtTYfPC3b7vxc6Mf2QLUNePXtR/5dAxevjOFbax/PZ2HGfKsGUkDM2QFbVkLOP Fl8KLiQaVSTvA== Date: Mon, 26 Jan 2026 14:18:21 +0000 From: Will Deacon To: Yang Shi Cc: catalin.marinas@arm.com, ryan.roberts@arm.com, cl@gentwo.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [v5 PATCH] arm64: mm: show direct mapping use in /proc/meminfo Message-ID: References: <20260107002944.2940963-1-yang@os.amperecomputing.com> <5f1bfe55-454c-40d5-ac45-1aed651b3747@os.amperecomputing.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5f1bfe55-454c-40d5-ac45-1aed651b3747@os.amperecomputing.com> On Tue, Jan 13, 2026 at 04:36:06PM -0800, Yang Shi wrote: > On 1/13/26 6:36 AM, Will Deacon wrote: > > On Tue, Jan 06, 2026 at 04:29:44PM -0800, Yang Shi wrote: > > > +#if defined(CONFIG_ARM64_4K_PAGES) > > > + size[PTE] = "4k"; > > > + size[CONT_PTE] = "64k"; > > > + size[PMD] = "2M"; > > > + size[CONT_PMD] = "32M"; > > > + size[PUD] = "1G"; > > > +#elif defined(CONFIG_ARM64_16K_PAGES) > > > + size[PTE] = "16k"; > > > + size[CONT_PTE] = "2M"; > > > + size[PMD] = "32M"; > > > + size[CONT_PMD] = "1G"; > > > +#elif defined(CONFIG_ARM64_64K_PAGES) > > > + size[PTE] = "64k"; > > > + size[CONT_PTE] = "2M"; > > > + size[PMD] = "512M"; > > > + size[CONT_PMD] = "16G"; > > > +#endif > > > + > > > + seq_printf(m, "DirectMap%s: %8lu kB\n", > > > + size[PTE], dm_meminfo[PTE] >> 10); > > > + seq_printf(m, "DirectMap%s: %8lu kB\n", > > > + size[CONT_PTE], > > > + dm_meminfo[CONT_PTE] >> 10); > > > + seq_printf(m, "DirectMap%s: %8lu kB\n", > > > + size[PMD], dm_meminfo[PMD] >> 10); > > > + seq_printf(m, "DirectMap%s: %8lu kB\n", > > > + size[CONT_PMD], > > > + dm_meminfo[CONT_PMD] >> 10); > > > + if (pud_sect_supported()) > > > + seq_printf(m, "DirectMap%s: %8lu kB\n", > > > + size[PUD], dm_meminfo[PUD] >> 10); > > This seems a bit brittle to me. If somebody adds support for l1 block > > mappings for !4k pages in future, they will forget to update this and > > we'll end up returning kernel stack in /proc/meminfo afaict. > > I can initialize size[PUD] to "NON_SUPPORT" by default. If the case happens, > /proc/meminfo just shows "DirectMapNON_SUPPORT", then we will notice > something is missed, but no kernel stack data will be leak. Or just add the PUD sizes for all the page sizes... > > > @@ -266,6 +351,17 @@ static int init_pmd(pmd_t *pmdp, unsigned long addr, unsigned long end, > > > (flags & NO_BLOCK_MAPPINGS) == 0) { > > > pmd_set_huge(pmdp, phys, prot); > > > + /* > > > + * It is possible to have mappings allow cont mapping > > > + * but disallow block mapping. For example, > > > + * map_entry_trampoline(). > > > + * So we have to increase CONT_PMD and PMD size here > > > + * to avoid double counting. > > > + */ > > > + if (pgprot_val(prot) & PTE_CONT) > > > + dm_meminfo_add(addr, (next - addr), CONT_PMD); > > > + else > > > + dm_meminfo_add(addr, (next - addr), PMD); > > I don't understand the comment you're adding here. If somebody passes > > NO_BLOCK_MAPPINGS then that also prevents contiguous entries except at > > level 3. > > The comment may be misleading. I meant if we have the accounting code for > CONT_PMD in alloc_init_cont_pmd(), for example, I think I'd just drop the comment. The code is clear enough once you actually read what's going on. > @@ -433,6 +433,11 @@ static int alloc_init_cont_pmd(pud_t *pudp, unsigned > long addr, >                 if (ret) >                         goto out; > > +               if (pgprot_val(prot) & PTE_CONT) > +                       dm_meminfo_add(addr, (next - addr), CONT_PMD); > >                 pmdp += pmd_index(next) - pmd_index(addr); >                 phys += next - addr; >         } while (addr = next, addr != end); > > If the described case happens, we actually miscount CONT_PMD. So I need to > check whether it is CONT in init_pmd() instead. If the comment is confusing, > I can just remove it. > > > It also doesn't look you handle the error case properly when the mapping > > fails. > > I don't quite get what fail do you mean? pmd_set_huge() doesn't fail. Or you > meant hotplug fails? If so the hot unplug will decrease the counters, which > is called in the error handling path. Sorry, I got confused here and thought that we could end up with a partially-formed contiguous region but that's not the case. So you can ignore this comment :) Will