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: <alpine.DEB.2.00.1106231604070.12963@kaball-desktop>
Date:	Thu, 23 Jun 2011 16:19:32 +0100
From:	Stefano Stabellini <stefano.stabellini@...citrix.com>
To:	Penttilä Mika <mika.penttila@...nos.com>
CC:	Stefano Stabellini <Stefano.Stabellini@...citrix.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] x86_64: do not assume head_64.S used 4KB pages when
 !use_pse

On Thu, 23 Jun 2011, Penttilä Mika wrote:
> > > And arch/x86/mm/init.c also has:
> > >
> > > #if defined(CONFIG_DEBUG_PAGEALLOC) || defined(CONFIG_KMEMCHECK)
> > >         /*
> > >          * For CONFIG_DEBUG_PAGEALLOC, identity mapping will use
> > small pages.
> > >          * This will simplify cpa(), which otherwise needs to support
> > splitting
> > >          * large pages into small in interrupt context, etc.
> > >          */
> > >         use_pse = use_gbpages = 0;
> > > #else
> > >         use_pse = cpu_has_pse;
> > >         use_gbpages = direct_gbpages;
> > > #endif
> > >
> > >
> > > So big pages are also not used for DEBUG_PAGEALLOC and KMEMCHECK
> > configs even if head_32.S did.
> > 
> > Right, but that is not a problem because head_32.S always uses 4KB
> > pages.
> 
> We use large pages FOR PAE kernels on x86-32 there
> 
 
Do you mean we use large pages for PAE kernels on x86_32 in
arch/x86/mm/init.c:init_memory_mapping?
That wouldn't be a problem for this patch.

The problem I am trying to solve occurs when head_64.S doesn't allocate
any pte pages because it is using 2MB pages, while init_memory_mapping
wants to use 4KB pages (for example because the user set
CONFIG_DEBUG_PAGEALLOC).

So on x86_32 is not going to be an issue because head_32.S doesn't use
2MB or 4MB pages as far as I can tell, even if the hardware supports
them.
Please correct me if I am wrong but I don't see any _PAGE_PSE in
head_32.S.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ