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,
Quoted 8 lines
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
fffea00000:00 0Can 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
Quoted 10 lines · Anton Blanchard
Hi,
Quoted 5 lines
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
fffea00000:00 0Can anyone enlighten me as to what this is for and who is allocating it?
Quoted 7 lines
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,
Quoted 2 lines
For some background, we're running an emulator that uses a null pointer value of
0xffff0000and we want any accesses to that address to trap.
Weird :)
Review
Quoted 4 lines
Do you anticipate any issues with the following change?
(quoted diff) +1
-1-#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
Review
Quoted 7 lines · Chris Friesen
For some background, we're running an emulator that uses a null pointer value of
0xffff0000and we want any accesses to that address to trap.Do you anticipate any issues with the following change?
(quoted diff) +1
-1-#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.
Quoted 6 lines · Paul Mackerras
Quoted 1 line · Chris Friesen
For some background, we're running an emulator that uses a null pointer value of
0xffff0000and we want any accesses to that address to trap.Can you fix this in userspace instead by moving the stack down below
0xffff0000and then doingmunmap(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