VMALLOC_END definition?

VMALLOC_END definition?

[Heiko Carstens]

Hi,

I just stumbled across the VMALLOC_END definition: I'm not entirely sure
what the meaning of this is: is it the last _valid_ address of the
vmalloc area or is it the first address _after_ the vmalloc area?

Reading the code in mm/vmalloc.c it seems to be the last valid address,
which IMHO is the only thing that makes sense... how would one express
the first address after 0xffffffff on a 32bit architecture?
Whatever it is, it looks like half of the architectures got it wrong.

We have a lot of these:

e.g. powerpc:
#define VMALLOC_START ASM_CONST(0xD000000000000000)
#define VMALLOC_SIZE  ASM_CONST(0x80000000000)
#define VMALLOC_END   (VMALLOC_START + VMALLOC_SIZE)

but also a lot of these:

e.g. x86_64

#define VMALLOC_START    0xffffc20000000000UL
#define VMALLOC_END      0xffffe1ffffffffffUL

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: VMALLOC_END definition?

[Andy Whitcroft]

Heiko Carstens wrote:
> Hi,
> 
> I just stumbled across the VMALLOC_END definition: I'm not entirely sure
> what the meaning of this is: is it the last _valid_ address of the
> vmalloc area or is it the first address _after_ the vmalloc area?
> 
> Reading the code in mm/vmalloc.c it seems to be the last valid address,
> which IMHO is the only thing that makes sense... how would one express
> the first address after 0xffffffff on a 32bit architecture?
> Whatever it is, it looks like half of the architectures got it wrong.
> 
> We have a lot of these:
> 
> e.g. powerpc:
> #define VMALLOC_START ASM_CONST(0xD000000000000000)
> #define VMALLOC_SIZE  ASM_CONST(0x80000000000)
> #define VMALLOC_END   (VMALLOC_START + VMALLOC_SIZE)
> 
> but also a lot of these:
> 
> e.g. x86_64
> 
> #define VMALLOC_START    0xffffc20000000000UL
> #define VMALLOC_END      0xffffe1ffffffffffUL

A quick grep shows that most architectures are assuming vmalloc space is
VMALLOC_START >= addr < VMALLOC_END.  x86_64 seems to be an odd one out
with the following construct in architecture specific code:

arch/x86_64/mm/fault.c: for (address = start; address <= VMALLOC_END;
address += PGDIR_SIZE) {

However, it also has this:

arch/x86_64/mm/fault.c:               ((address >= VMALLOC_START &&
address < VMALLOC_END))) {

A couple of filesystems and sparsemem also appear to assume the
VMALLOC_START >= addr < VMALLOC_END model.  So it seems likely that the
architectures not using this model are wrong.

-apw

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: VMALLOC_END definition?

[Heiko Carstens]

On Thu, Nov 23, 2006 at 10:42:21AM +0000, Andy Whitcroft wrote:
> Heiko Carstens wrote:
> > I just stumbled across the VMALLOC_END definition: I'm not entirely sure
> > what the meaning of this is: is it the last _valid_ address of the
> > vmalloc area or is it the first address _after_ the vmalloc area?
> >
> > Reading the code in mm/vmalloc.c it seems to be the last valid address,
> > which IMHO is the only thing that makes sense... how would one express
> > the first address after 0xffffffff on a 32bit architecture?
> > Whatever it is, it looks like half of the architectures got it wrong.
>
> A quick grep shows that most architectures are assuming vmalloc space is
> VMALLOC_START >= addr < VMALLOC_END.  x86_64 seems to be an odd one out
> with the following construct in architecture specific code:
> 
> arch/x86_64/mm/fault.c: for (address = start; address <= VMALLOC_END;
> address += PGDIR_SIZE) {
> 
> However, it also has this:
> 
> arch/x86_64/mm/fault.c:               ((address >= VMALLOC_START &&
> address < VMALLOC_END))) {
> 
> A couple of filesystems and sparsemem also appear to assume the
> VMALLOC_START >= addr < VMALLOC_END model.  So it seems likely that the
> architectures not using this model are wrong.

Ah, right... I also found this one in include/asm-arm/pgtable.h

 * Note that platforms may override VMALLOC_START, but they must provide
 * VMALLOC_END.  VMALLOC_END defines the (exclusive) limit of this space,
 * which may not overlap IO space.

Thanks!

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>