linux-kernel - Re: slub-i386-support.patch

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: <20070510233510.GQ19966@holomorphy.com>
Date:	Thu, 10 May 2007 16:35:10 -0700
From:	William Lee Irwin III <wli@...omorphy.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Christoph Lameter <clameter@....com>,
	Hugh Dickins <hugh@...itas.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andi Kleen <ak@...e.de>, linux-kernel@...r.kernel.org
Subject: Re: slub-i386-support.patch

William Lee Irwin III wrote:
>> Xen is not mandatory as it now stands.

On Thu, May 10, 2007 at 02:28:05PM -0700, Jeremy Fitzhardinge wrote:
> ?  I'm hoping to merge the Xen code in the next couple of days, so I'd
> appreciate it if we don't break the foundations just before building the
> building.

CONFIG_X86_PAE without CONFIG_PARAVIRT is the case in question here.
What's done in that case can't break Xen because it doesn't run under
Xen.


William Lee Irwin III wrote:
>>  Also, I intend to fix up Xen
>> at some point so it doesn't need this.

On Thu, May 10, 2007 at 02:28:05PM -0700, Jeremy Fitzhardinge wrote:
> As I mentioned in the previous mail, its only really necessary for a
> 32-bit guest under a 32-bit hypervisor.  While that's going to be a
> supported configuration for a long time, we expect that people will
> increasingly use 64-bit hypervisors on new machines, so this will become
> less of an issue.
> We're also looking at shadowing the 4 top-level PAE entries rather than
> using them directly, since the shadows only need to be updated when
> reloading cr3.  This would allow us to use compact pgds, so long as
> there's some other way to maintain the pgd list (ideally, something that
> can be shared with non-PAE).

ISTR you describing this method earlier. This is what I had in mind
for fixing up Xen not to need full PAGE_SIZE-sized pgd's.


On Thu, May 10, 2007 at 02:28:05PM -0700, Jeremy Fitzhardinge wrote:
> Or did I miss something?  Is pgd_list being maintained some other way
> with slub/quicklists?

No, it's identical. clameter's code makes PAGE_SIZE-sized pgd's
unconditional for CONFIG_X86_PAE, which is what bothered me.


William Lee Irwin III wrote:
>> The alternative was 64-bit generation numbers incremented at the time
>> of change_page_attr(). If generation numbers were used, it would be
>> possible to dispose of the list altogether. Given the awkwardness of
>> the list maintenance for Xen, it may be worth using them now. PAE
>> pgd's could merely double in size to maintain those for the unshared
>> kernel pmd case, and remain 32B otherwise. Full PAGE_SIZE -sized pgd's
>> for 2-level pagetables could distribute the generation number across
>> page->index and page->private, or any other fields available.

On Thu, May 10, 2007 at 02:28:05PM -0700, Jeremy Fitzhardinge wrote:
> If you use page->index for that, how does pgd_list get linked together
> for vmalloc syncing?

It doesn't need to be linked together for vmalloc_sync(). Just increment
the generation number and walk the mmlist the same as for pageattr.c


-- wli
-
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/