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

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

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

Anton Blanchard wrote:

Hi,

quoted

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

 
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

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.

Paul Mackerras wrote:

Chris Friesen writes:

quoted

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