linux-kernel - 答复: Re: [PATCH] Initialize max_pfn_mapped as initial ident mapping size for x86

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

Date:	Mon, 5 Mar 2012 19:44:57 -0800 (PST)
From:	Zhenzhong Duan <zhenzhong.duan@...cle.com>
To:	<yinghai@...nel.org>
Cc:	<mingo@...hat.com>, <konrad.wilk@...cle.com>, <tglx@...utronix.de>,
	<torvalds@...ux-foundation.org>, <joe.jin@...cle.com>,
	<stable@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<rjw@...k.pl>, <tiwai@...e.de>, <hpa@...or.com>
Subject: 答复: Re: [PATCH] Initialize max_pfn_mapped as initial ident mapping size for x86_64


----- yinghai@...nel.org 写道：

> it is not that simple.
> 
> 
> 
> whole history:
> 
> before following patch, on x86_64, for low memory (under 4g) pgtable
> 
> will be allocated just under TOML
> 
> and even those memory is not mapped directly. because now we are using
> 
> early_ioremap to access those
> 
> page table.
> 
> 
> 
> but looks it has problem with S4 resume. so good_end is set to initial
> 
> mapped high address.
> 
> (that is 512M). So page table will just below 512M
> 
> but crash kernel is allocated below 768M. so will have no chance to
> 
> get 512M porting for crashkernel.

Aha, thanks Yinghai talking this interesting history.

Can't imagine the difference between below 512M and below max_low_pfn_mapped both from sw and hw's view, for S4 resume.
Even if we set max_pfn_mapped to 512M, we can play with a small trick to get 512M space for crashkernel. That's shareing space with initrd since when initrd space freed, 
it will check if pages occupied by crashkernel. But this need some address scope calculation.
> 
> 
> 
> Now your patch just set initial mapping limit to 1g. but according to
> 
> arch/x86/kernel/head_64.S
> 
> we only have initial mapping to 512M.

I browered arch/x86/kernel/head_64.S again, looks ident mapping is 1G mapped. See below
NEXT_PAGE(level2_ident_pgt)
        /* Since I easily can, map the first 1G.
         * Don't set NX because code runs from these pages.
         */
        PMDS(0, __PAGE_KERNEL_IDENT_LARGE_EXEC, PTRS_PER_PMD)

If you mean level2_kernel_pgt here, it's 512MB here. But it's not that accurate for relocated kernel and is truncated in cleanup_highmap to _text ---- _brk_end.
> 
> 
> 
> So you can not just simply set to 1G,  that will confuse early
> 
> memblock allocator.
> 
> 
> 
> We may update find_early_table_space() to use 1G as good_end for
> 
> x86_64 that will be less confusing.

Yes
> 
> 
> 
> also even in that case, you still need to double check if S4 resume is
> 
> broken again.
> 
> 
> 
> 
> 
> Or We can change KERNL_IMAGE_SIZE to 1G?
That need only a small change in arch/x86/kernel/head_64.S
But as you said, still need test for S4 resume or others.

> 
> 
> 
> Or we need to dig out when S4 resume is broken at first place when we
> 
> put page table near TOML.
I prefer that, maybe intel engineer can help on this.
--
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/