linux-kernel - Re: [v5 PATCH] arm64: mm: show direct mapping use in /proc/meminfo

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aXIxYcAsbFZn3ZNU@willie-the-truck>
Date: Thu, 22 Jan 2026 14:17:05 +0000
From: Will Deacon <will@...nel.org>
To: Anshuman Khandual <anshuman.khandual@....com>
Cc: Yang Shi <yang@...amperecomputing.com>, catalin.marinas@....com,
	ryan.roberts@....com, cl@...two.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [v5 PATCH] arm64: mm: show direct mapping use in /proc/meminfo

On Thu, Jan 22, 2026 at 10:39:25AM +0530, Anshuman Khandual wrote:
> Hello Yang,
> 
> On 07/01/26 5:59 AM, Yang Shi wrote:
> > Since commit a166563e7ec3 ("arm64: mm: support large block mapping when
> > rodata=full"), the direct mapping may be split on some machines instead
> > keeping static since boot. It makes more sense to show the direct mapping
> > use in /proc/meminfo than before.
> 
> I guess the direct mapping here refers to linear map ? IIUC it is called
> direct map on x86 and linear map on arm64 platforms. Then should not it
> be renamed as s/DirectMap/LinearMap instead ? This will align with names
> from ptdump as well.
> 
> Before the above mentioned commit, linear could get altered with memory
> hotplug and remove events as well.
> 
> > This patch will make /proc/meminfo show the direct mapping use like the
> > below (4K base page size):
> > DirectMap4K:	   94792 kB
> > DirectMap64K:	  134208 kB
> > DirectMap2M:	 1173504 kB
> > DirectMap32M:	 5636096 kB
> > DirectMap1G:	529530880 kB
> 
> If /proc/meminfo interface is getting updated via  arch_report_meminfo()
> why not add stats for all kernel virtual address space ranges including
> vmemmap, vmalloc etc aka all address range headers in ptdump as many of
> those could change during system runtime. What makes linear mapping any
> special ?

tbh, I think compatability with x86 is a good argument in this case and
so the naming and formatting proposed by this patch makes sense to me.

I'm also not sure that it's particularly interesting to see these
rolled-up numbers for the vmalloc area. You really want information
about the area, so extending /proc/vmallocinfo to give information
about the granule size for each entry might be useful but I don't think
it should be part of this patch.

Will