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

[Yang Shi <yang@os.amperecomputing.com>]

On 1/26/26 6:18 AM, Will Deacon wrote:
> 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...

Fine to me.

>
>>>> @@ -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.

Sure.

>
>> @@ -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 :)

No problem. Thanks for taking time to review the patch.

I will prepare a new revision once we figure out the potential 
contiguous bit misprogramming issue.

Thanks,
Yang

>
> Will