what is ~1MB of memory allocated at fffea000-fffff000 on ppc64?

what is ~1MB of memory allocated at fffea000-fffff000 on ppc64?

[Chris Friesen]

Hi all,

I've got a ppc64 box running 2.6.14.  64-bit kernel, 32-bit userspace. 
It has a ~86KB chunk of memory near the top of the process address 
space, and I'm not sure who's setting it up and what the purpose is.  In 
/proc/<pid>/maps it looks like this:

fffea000-fffff000 rw-p fffea000 00:00 0

Can anyone enlighten me as to what this is for and who is allocating it?

Thanks,

Chris

Re: what is ~1MB of memory allocated at fffea000-fffff000 on ppc64?

[Anton Blanchard]

Hi,

> I've got a ppc64 box running 2.6.14.  64-bit kernel, 32-bit userspace. 
> It has a ~86KB chunk of memory near the top of the process address 
> space, and I'm not sure who's setting it up and what the purpose is.  In 
> /proc/<pid>/maps it looks like this:
> 
> fffea000-fffff000 rw-p fffea000 00:00 0
> 
> Can anyone enlighten me as to what this is for and who is allocating it?

Looks like your process stack. BTW we leave the top page
(0xfffff000 - 0xffffffff) unmapped mostly because of test cases that
expect

*(unsigned long *)-1UL

to fail.

Anton

Re: what is ~1MB of memory allocated at fffea000-fffff000 on ppc64?

[Chris Friesen]

Anton Blanchard wrote:
> Hi,
> 
> 
>>I've got a ppc64 box running 2.6.14.  64-bit kernel, 32-bit userspace. 
>>It has a ~86KB chunk of memory near the top of the process address 
>>space, and I'm not sure who's setting it up and what the purpose is.  In 
>>/proc/<pid>/maps it looks like this:
>>
>>fffea000-fffff000 rw-p fffea000 00:00 0
>>
>>Can anyone enlighten me as to what this is for and who is allocating it?
> 
> 
> Looks like your process stack. BTW we leave the top page
> (0xfffff000 - 0xffffffff) unmapped mostly because of test cases that
> expect
> 
> *(unsigned long *)-1UL
> 
> to fail.


Doh.  Of course, that's almost certainly it.

For some background, we're running an emulator that uses a null pointer 
value of 0xffff0000 and we want any accesses to that address to trap.

Do you anticipate any issues with the following change?

-#define TASK_SIZE_USER32 (0x0000000100000000UL - (1*PAGE_SIZE))
+#define TASK_SIZE_USER32 (0x00000000FFFF0000UL - (1*PAGE_SIZE))


Thanks,

Chris

Re: what is ~1MB of memory allocated at fffea000-fffff000 on ppc64?

[Anton Blanchard]

 
Hi,

> For some background, we're running an emulator that uses a null pointer 
> value of 0xffff0000 and we want any accesses to that address to trap.

Weird :)

> Do you anticipate any issues with the following change?
> 
> -#define TASK_SIZE_USER32 (0x0000000100000000UL - (1*PAGE_SIZE))
> +#define TASK_SIZE_USER32 (0x00000000FFFF0000UL - (1*PAGE_SIZE))

Should be OK, for a 64kB kernel we will put the stack top at 0xFFFF0000
anyway.

Anton

Re: what is ~1MB of memory allocated at fffea000-fffff000 on ppc64?

[Paul Mackerras]

Chris Friesen writes:

> For some background, we're running an emulator that uses a null pointer 
> value of 0xffff0000 and we want any accesses to that address to trap.
> 
> Do you anticipate any issues with the following change?
> 
> -#define TASK_SIZE_USER32 (0x0000000100000000UL - (1*PAGE_SIZE))
> +#define TASK_SIZE_USER32 (0x00000000FFFF0000UL - (1*PAGE_SIZE))

Can you fix this in userspace instead by moving the stack down below
0xffff0000 and then doing munmap(0xffff0000, 0x1000) ?

Paul.

Re: what is ~1MB of memory allocated at fffea000-fffff000 on ppc64?

[Chris Friesen]

Paul Mackerras wrote:
> Chris Friesen writes:

>>For some background, we're running an emulator that uses a null pointer 
>>value of 0xffff0000 and we want any accesses to that address to trap.

> Can you fix this in userspace instead by moving the stack down below
> 0xffff0000 and then doing munmap(0xffff0000, 0x1000) ?

It sounds like it would work.  I'm not entirely clear on how to move the 
starting point of the stack though--could you elaborate or point me to a 
reference?

Chris