Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Anatomy of a Program in Memory (2009)

manybutfinite.com

Post reply on HN
Print view View original

21–28 of 28 posts

Re: Anatomy of a Program in Memory (2009)

#21

Post by bogomipz »

MarkSweep wrote: post #18
finchisko wrote: post #16

After reading many articles about virtual memory and how kernel space is mapped into every process I don't understand why it is necessary. Why can't process only have mapped it's user mode space? Also it only seems to be case of unixes and windows. Not sure how exactly it's done in OSX but "Mac OS X does not map the kernel into each user address space, and therefore each user/kernel transition (in either direction) r…

On x86, I t was presumably for performance, so that the TLB does not have to be flushed when switching from user to kernel mode. x86 requires some kernel memeory to be mapped always, for example the stack for syscall and trap handlers. So by keeping everything mapped into memory, the kernel did not have to worry about which parts were needed to handle syscalls and which were not. These kernel pages were marked as “su…

>"x86 requires some kernel memeory to be mapped always, for example the stack for syscall and trap handlers."

Can you elaborate on what you mean be x86 requires that the kernel stack always be mapped into a process address space in order for system calls?

The kernel always knows where a process's kernel stack is located as there is a pointer to it in the user process's task_struct. It is only in kernel mode that the kernel switches the CPU's stack pointer to use that that processes kernel stack.

Re: Anatomy of a Program in Memory (2009)

#22

Post by monocasa »

bogomipz wrote: post #21
MarkSweep wrote: post #18

Earlier quoted context omitted.

On x86, I t was presumably for performance, so that the TLB does not have to be flushed when switching from user to kernel mode. x86 requires some kernel memeory to be mapped always, for example the stack for syscall and trap handlers. So by keeping everything mapped into memory, the kernel did not have to worry about which parts were needed to handle syscalls and which were not. These kernel pages were marked as “su…

>"x86 requires some kernel memeory to be mapped always, for example the stack for syscall and trap handlers." Can you elaborate on what you mean be x86 requires that the kernel stack always be mapped into a process address space in order for system calls? The kernel always knows where a process's kernel stack is located as there is a pointer to it in the user process's task_struct. It is only in kernel mode that the…

You can't unmap the kernel stack in Meltdown mitigation, because the syscall instruction will want to push to the kernel stack before you as the kernel has a chance to map the kernel stack.

Re: Anatomy of a Program in Memory (2009)

#23

Post by Myrmornis »

monocasa wrote: post #14
Myrmornis wrote: post #5

if the process depicted in the diagram were to start a second thread, where would that second thead’s stack go in the diagram? The two threads would share the same heap.

Another ~8MB(8MB plus guard pages) chunk of virtual memory that's free up there near the shared mappings. You're totally right though, that threads complicated the traditional "stack grows down heap grows up" view of a Unix user address space.

Thanks. So can I check I'm understanding correctly

- If a process has many threads, their stacks are all located within a single virtual address space corresponding to the user process?

- If one thread grows down and is about to overwrite the top of another thread's stack, does the OS detect this automatically and do some sort of reallocation procedure?

Re: Anatomy of a Program in Memory (2009)

#24

Post by bogomipz »

monocasa wrote: post #22
bogomipz wrote: post #21

Earlier quoted context omitted.

>"x86 requires some kernel memeory to be mapped always, for example the stack for syscall and trap handlers." Can you elaborate on what you mean be x86 requires that the kernel stack always be mapped into a process address space in order for system calls? The kernel always knows where a process's kernel stack is located as there is a pointer to it in the user process's task_struct. It is only in kernel mode that the…

You can't unmap the kernel stack in Meltdown mitigation, because the syscall instruction will want to push to the kernel stack before you as the kernel has a chance to map the kernel stack.

It sounded like the OPs comment wasn't strictly about the post-meltdown era and that they were commenting on the general case. But maybeI misinterpreted that?

Re: Anatomy of a Program in Memory (2009)

#25

Post by monocasa »

bogomipz wrote: post #24
monocasa wrote: post #22

Earlier quoted context omitted.

You can't unmap the kernel stack in Meltdown mitigation, because the syscall instruction will want to push to the kernel stack before you as the kernel has a chance to map the kernel stack.

It sounded like the OPs comment wasn't strictly about the post-meltdown era and that they were commenting on the general case. But maybeI misinterpreted that?

Oh, sure, my bad.

OK, in the context of 'why can't you cleanly have the kernel in a different address space from user processes on x86', the same reasons apply. It's a chicken/egg thing, as a syscall instruction executes and touches the kernel stack before you have a chance to change mmu mappings.

There are versions of Darwin for x86 (but no released versions of full OSX AFAIK) that separate the address spaces, but they reserve a (albeit much smaller) piece of virtual address space at the top for the kernel in all address spaces in order to facilitate the transition to the full kernel address space.

Re: Anatomy of a Program in Memory (2009)

#26

Post by monocasa »

Myrmornis wrote: post #23
monocasa wrote: post #14

Earlier quoted context omitted.

Another ~8MB(8MB plus guard pages) chunk of virtual memory that's free up there near the shared mappings. You're totally right though, that threads complicated the traditional "stack grows down heap grows up" view of a Unix user address space.

Thanks. So can I check I'm understanding correctly - If a process has many threads, their stacks are all located within a single virtual address space corresponding to the user process? - If one thread grows down and is about to overwrite the top of another thread's stack, does the OS detect this automatically and do some sort of reallocation procedure?

> If a process has many threads, their stacks are all located within a single virtual address space corresponding to the user process?

Yep!

> If one thread grows down and is about to overwrite the top of another thread's stack, does the OS detect this automatically and do some sort of reallocation procedure?

The kernel reserves a 8MB region for each stack and that's it (even the initial stack). So you wouldn't get overlapping stacks per se; the regions are preallocated. The kernel does try to detect stack overflow/underflow with guard pages, but that's just a best attempt kind of thing, and of you underflow by more than page you can just end up just corrupting memory.

And all of this is for C's sort of standard model. 'Split stacks' is a scheme closer to your second question, but there's a lot of overhead of that model, and not a lot of runtimes use it.

I've also even more rarely seen a model that allocates stack frames on the heap and links them together in a linked list.

But like I said, these schemes are very in practice.

Re: Anatomy of a Program in Memory (2009)

#27

Post by bogomipz »

monocasa wrote: post #25
bogomipz wrote: post #24

Earlier quoted context omitted.

It sounded like the OPs comment wasn't strictly about the post-meltdown era and that they were commenting on the general case. But maybeI misinterpreted that?

Oh, sure, my bad. OK, in the context of 'why can't you cleanly have the kernel in a different address space from user processes on x86', the same reasons apply. It's a chicken/egg thing, as a syscall instruction executes and touches the kernel stack before you have a chance to change mmu mappings. There are versions of Darwin for x86 (but no released versions of full OSX AFAIK) that separate the address spaces, but t…

Right that would be a pretty awful place to segfault :)

Thanks for the clarification.

Re: Anatomy of a Program in Memory (2009)

#28

Post by Myrmornis »

monocasa wrote: post #26
Myrmornis wrote: post #23

Earlier quoted context omitted.

Thanks. So can I check I'm understanding correctly - If a process has many threads, their stacks are all located within a single virtual address space corresponding to the user process? - If one thread grows down and is about to overwrite the top of another thread's stack, does the OS detect this automatically and do some sort of reallocation procedure?

> If a process has many threads, their stacks are all located within a single virtual address space corresponding to the user process? Yep! > If one thread grows down and is about to overwrite the top of another thread's stack, does the OS detect this automatically and do some sort of reallocation procedure? The kernel reserves a 8MB region for each stack and that's it (even the initial stack). So you wouldn't get ov…

Thanks for this.
Post reply on HN