linux-kernel - Re: x86_64: wrong DirectMap kB

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] [day] [month] [year] [list]

Message-ID: <alpine.LSU.2.00.1210021048110.1348@eggly.anvils>
Date:	Tue, 2 Oct 2012 11:16:12 -0700 (PDT)
From:	Hugh Dickins <hughd@...gle.com>
To:	Jan Beulich <JBeulich@...e.com>
cc:	Andi Kleen <andi@...stfloor.org>, Ingo Molnar <mingo@...nel.org>,
	x86@...nel.org, Yinghai Lu <yinghai@...nel.org>,
	Jamie Gloudon <jamie.gloudon@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: x86_64: wrong DirectMap kB

On Tue, 2 Oct 2012, Jan Beulich wrote:
> >>> On 01.10.12 at 10:37, Hugh Dickins <hughd@...gle.com> wrote:
> > I noticed yesterday that the DirectMap counts at the bottom of x86_64's
> > /proc/meminfo are wrong on v3.5 and v3.6.  For example, I happen to have
> > booted this laptop with mem=700M to run a test, but /proc/meminfo shows
> > 
> > DirectMap4k:        4096 kB
> > DirectMap2M:    18446744073709547520 kB
> 
> I cannot see such odd effect with "mem="; with I can (for any
                               without
> value up to around 1G).

Yes, only with a small "mem=" was my 2M number so low that it actually
wrapped around to look so obviously wrong - I presume once pat came to
carve a piece out of 0.

But even without "mem=" the DirectMap numbers were wrong, adding up
to less than the MemTotal: I did show numbers to make that clearer to
Jamie yesterday, but missed that all but lkml had dropped from the Cc.

> 
> > Or if I boot with the full amount of physical memory, the DirectMap
> > numbers do not add up to the full amount of physical memory, as they
> > used to do on v3.4 and before.
> 
> That one I can see how could have happened, in that said patch
> went a little too far: Dropping the "pages" increments from
> phys_p[um]d_init() is necessary only for the hotplug case (as
> otherwise duplicating accounting already done earlier), while
> at boot time we would want to do the accounting.
> 
> > Whilst I've not yet tried reverting it, I strongly suspect your
> > 20167d3421a0 "x86-64: Fix accounting in kernel_physical_mapping_init()".
> > 
> > Either it was a complete misunderstanding, totally bogus, and should
> > simply be reverted; or perhaps you really noticed something wrong in
> > your code inspection, but didn't get the fix quite right?
> 
> The latter, apparently. The patch below should fix both aspects.

Thanks, Jan, certainly this patch puts my "mem=700M" DirectMap numbers
back to exactly what I would expect; and without any "mem=", the ~8GB
total of DirectMap4k and DirectMap2M back to what it was with v3.4.

I'm wording it like that because these days I see 2048 kB of 4k instead
of 4096 kB of 4k, but that's most probably due to other differences.

Hugh

> 
> Jan
> 
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -386,7 +386,8 @@ phys_pte_init(pte_t *pte_page, unsigned 
>  		 * these mappings are more intelligent.
>  		 */
>  		if (pte_val(*pte)) {
> -			pages++;
> +			if (!after_bootmem)
> +				pages++;
>  			continue;
>  		}
>  
> @@ -451,6 +452,8 @@ phys_pmd_init(pmd_t *pmd_page, unsigned 
>  			 * attributes.
>  			 */
>  			if (page_size_mask & (1 << PG_LEVEL_2M)) {
> +				if (!after_bootmem)
> +					pages++;
>  				last_map_addr = next;
>  				continue;
>  			}
> @@ -526,6 +529,8 @@ phys_pud_init(pud_t *pud_page, unsigned 
>  			 * attributes.
>  			 */
>  			if (page_size_mask & (1 << PG_LEVEL_1G)) {
> +				if (!after_bootmem)
> +					pages++;
>  				last_map_addr = next;
>  				continue;
>  			}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/