Map PTEs for MAP_SHARED | MAP_LOCKED files on fork
authorBarret Rhoden <brho@cs.berkeley.edu>
Wed, 23 Mar 2016 19:23:05 +0000 (15:23 -0400)
committerBarret Rhoden <brho@cs.berkeley.edu>
Thu, 31 Mar 2016 20:53:42 +0000 (16:53 -0400)
commit2fa47a73cfbb47cc806bdafb97e771ac664d8d9f
tree6ded609556056d78262b853d9a8347b21d8bfb42
parenta8c190a2a0a2fd89db22c3db5edfe011bcd2e447
Map PTEs for MAP_SHARED | MAP_LOCKED files on fork

If you had a process that forked but did not exec, then the read-only parts
of the binary would not be in its address space.  Those parts would be in
the page cache, so long as the parent was still around (which had the VMR
MAP_LOCKED) (or if it left and we flushed the cache).

Then later, the child asks the kernel to perform a syscall on one of its
addresses in the read-only section, e.g. .rodata.  The kernel would then
page fault.

Right now, the kernel won't attempt to handle a PF *of its own* by talking
to the page cache.  Eventually we'll need to do this.  But it's also just
wrong for us to not have MAP_LOCKED VMRs present in a process's page table.

I <3 fork.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
kern/arch/x86/trap.c
kern/src/mm.c