linux-kernel - Re: [PATCH 1 of 8] x86: page.h: unify constants

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]

Date:	Mon, 07 Jan 2008 14:13:52 -0800
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Andi Kleen <ak@...e.de>
CC:	Ingo Molnar <mingo@...e.hu>, LKML <linux-kernel@...r.kernel.org>,
	Glauber de Oliveira Costa <glommer@...il.com>,
	Jan Beulich <jbeulich@...ell.com>
Subject: Re: [PATCH 1 of 8] x86: page.h: unify constants

Andi Kleen wrote:
>> +
>> +#define LARGE_PAGE_SIZE		(_AC(1,UL) << PMD_SHIFT)
>> +#define LARGE_PAGE_MASK		(~(LARGE_PAGE_SIZE-1))
>> +
>> +#define HPAGE_SHIFT		PMD_SHIFT
>> +#define HPAGE_SIZE		(_AC(1,UL) << HPAGE_SHIFT)
>> +#define HPAGE_MASK		(~(HPAGE_SIZE - 1))
>> +#define HUGETLB_PAGE_ORDER	(HPAGE_SHIFT - PAGE_SHIFT)
>>     
>
> This will actually stop being the same soon with GB pages which
> are only supported on 64bit.
>   

I was wondering about that.  Will you always use GB pages, or will there 
be two classes of huge pages, or will it be a runtime/compiletime config?

>> +
>> +#ifdef CONFIG_X86_64
>> +#define THREAD_ORDER	1
>> +#define THREAD_SIZE  (PAGE_SIZE << THREAD_ORDER)
>> +#define CURRENT_MASK (~(THREAD_SIZE-1))
>> +
>> +#define EXCEPTION_STACK_ORDER 0
>> +#define EXCEPTION_STKSZ (PAGE_SIZE << EXCEPTION_STACK_ORDER)
>> +
>> +#define DEBUG_STACK_ORDER (EXCEPTION_STACK_ORDER + 1)
>> +#define DEBUG_STKSZ (PAGE_SIZE << DEBUG_STACK_ORDER)
>> +
>> +#define IRQSTACK_ORDER 2
>> +#define IRQSTACKSIZE (PAGE_SIZE << IRQSTACK_ORDER)
>>     
>
> This all seems hardly 64bit specific (except for THREAD_ORDER
> but you can probably handle that in Kconfig or just get rid
> of it for 32bit)
>   

They're only used by 64-bit at the moment, aren't they?  Or are you 
suggesting 32-bit could use them too?  There's no corresponding 
definitions on the 32-bit side at the moment.

>> +#define __PHYSICAL_START	CONFIG_PHYSICAL_START
>>     
>
> Also not 64bit specific
>   

It's use is 64-bit specific though, isn't it?

>> +#ifdef CONFIG_X86_PAE
>> +#define __PHYSICAL_MASK_SHIFT	36
>>     
>
> I originally added the PHYSICAL_MASK stuff to deal with masking off NX,
> but I must admit it wasn't the best idea I ever had. It would be probably
> better to just get rid of it and always mask off the high reserved flags bit
> explicitely. If you make that 0 then there should be no special
> case for PAE.
>   

Hm, OK.  I thought different 64-bit implementations might have different 
sized physical address spaces or something.


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