new process and page tables

[Pype.Clicker]

hmm ... i'm just about to clean up my address space management (exec/fork/exit if i was targetting a posix system), and there's a question that pops in my mind.

So far, i've used a technique such as

Code: Select all

    new_directory=kalloc(KMEM_ALIGNED,4096);
    *new_directory=pgCurrSpace()->directory;
    new_process.cr3=phys_addr_of(new_directory);
 //  start system thread "clone" in new_process

and "clone" would be sweeping the list of virtual regions to know if pages should be kept/reallocated/marked copy-on-write...

but now i'm concerned about what the cloned process should do while the cloning occurs ...
Should it be suspended ? Should it mark its own pages as "copy-on-write" before launching the "clone" thread in the new process ? and what if the clone fails ? should it roll back ? ...

anyone already faced such problems ? do you have a tiny light for me ... damn. it's 2 l8 for programming headaches ... i'd better go to bed ...

[Candy]

and "clone" would be sweeping the list of virtual regions to know if pages should be kept/reallocated/marked copy-on-write...

but now i'm concerned about what the cloned process should do while the cloning occurs ...
Should it be suspended ? Should it mark its own pages as "copy-on-write" before launching the "clone" thread in the new process ? and what if the clone fails ? should it roll back ? ...

Think I did some implementation on this, not sure... Afaik, my kernel freezes the current process while the pages are being copied, including all the threads... come to think of it, didn't do it . Anyway, you'd have to give a verbatim copy of the current state to the child process, so it must be frozen in time (the memory space) so the new child process gets exactly that state. What does posix specify to do with threads?

[mrd]

copy-on-write dictates that both the source and the new editions be marked as copy-on-write. if not, then one could modify the original copy without the other getting its own copy first.
and during the pte mirroring, you need to have the process frozen, because the state across the whole process must be as it was when the split occurs. this shouldn't take too long, you only have to modify the ptes for all unshared pages to COW and shared pages need to point to the same page.
of course, you're going to need some kind of management in place for tracking shared and cowed pages, so you can only free a shared page where there's no more references, and to recognize a COW'd page write exception from a RO page write exception.
when i say shared page, i mean pages that point to the same physical address. you'll likely have different varieties of this: mapped devices, mapped files, generic shared/global memory

warning: i haven't actually coded any of this, i'm still designing, so i may have forgotten something.

[Pype.Clicker]

aouch. there's no such thing like COW protection for system-level page (there's COW at system level for user page, but not for U=0 pages )

thanks anyway ...

[mrd]

i'm not sure what system-level page cow has to do w/ this, i suppose you're forking a system-level process? anyway, there's no reason why you can't COW system pages as well. you can write-protect supervisor pages on x86.

[BI lazy]

well ... forking a process ...

I 've done it yesterday in about 4 hours (with many many corrections of my bad bad design -> if one does such a thing the first time, this happens) and is is still not satisfying. Well, at least one thing goes well: whilst doing the fork call, a message is attached to both the forking process and its sibling containing a: the pid of the sibling and b: pid 0 - this one the sibling receives.

as for the copying of pages ... I do some preliminary mapping and copying, when I duplicate the forking process' pagedirectory. This is a mess, I admit, but a working mess at the moment. When the sibling comes to take his turn of processor time, it traps to the page handler and the pager moves the page directory entries to their correct places deleting the preliminary ones. It is a mess, I admit.

But you have to take care that the copying is done BEFORE you - as the pager - release the cpu, so that the process state at the time of fork is present in both processes. this one caused me many a headache, oh ye gods of silicium.

Could it be this place - the duplicating of the page directory and the copying of memory contents - where COW could come into play?

HtH - I'm a bit fuzzy today, so no wonder, my writing is a hell of a mess... *yawn*

[Pype.Clicker]

i'm not sure what system-level page cow has to do w/ this, i suppose you're forking a system-level process? anyway, there's no reason why you can't COW system pages as well. you can write-protect supervisor pages on x86.

Hm, looking back at the manual

4.11.3. Page Type

The page-level protection mechanism recognizes two page types:

• Read-only access (R/W flag is 0).
• Read/write access (R/W flag is 1).

When the processor is in supervisor mode and the WP flag in register CR0 is clear (its state following reset initialization), all pages are both readable and writable (write-protection is ignored).

The P6 family, Pentium, and Intel486 processors allow user-mode pages to be write-protected against supervisor-mode access. Setting the WP flag in register CR0 to 1 enables supervisormode sensitivity to user-mode, write-protected pages. This supervisor write-protect feature is useful for implementing a copy-on-write strategy used by some operating systems, such as UNIX* (...)

but further i have (in table 4-2) ...

PDE={Supervisor,Read-Only}, PTE={Supervisor Read-Only} => Supervisor Read/Write* (If the WP flag of CR0 is set, the access type is determined by the R/W flags of the page-directory and page-table entries).

i had cached in /dev/brain that PxE.R/W bit was ignored when PxE.U/S was cleared (supervisor mode), but i admit i haven't tried to catch a #PF due to a supervisor write-protected page, iirc, and certainly not with the CR0.WP flag set ...)

The relation with the 'new process' stuff is that i have some per-process state (like the list of vaddr areas, for instance) that should be cow'd when a process is forked, but that shouldn't be accessible by the user-level software ... Note that i could be nasty and set it with PTE.US=User and PTE.RW=Read-only until a page fault is caught (and hiding it from usermode through segments) and revert it to PTE.US=Supervisor after i generated the local copy of it -- but i'd prefer avoiding such horrors ...

[Pype.Clicker]

okay. i can finally confirm that once CR0.WP is set, you get a page fault in supervisor mode for both user read-only (xxxxxxx5) and supervisor read-only (xxxxxxx1) pages. COWing a system region will be achievable on pentiums :-p

---(IRL) oops... it almost burnt! i shouldn't be posting on Mega-Tokyo while i'm cooking ::)

[distantvoices]

*looking fascinated* What d'ya have had on the hearth, gosh?

I did some tyrolean roasted potato dish yesterday - one with much onions, garlic and spices and bacon - in my big iron wok.