find a bug(maybe) in JamesM's kernel development tutorials

[orafy]

I'm learning to develop os from JamesM's kernel tutorial. (http://www.jamesmolloy.co.uk/tutorial_html/)
It's really a great tutorial
I've finished all chapters.
But things break down when i add a new system call to it.
I'm adding syscall_fork(). but child task's stack always break down.
After some debuggings, i notice that there lacks something in tutorial's fork() (http://www.jamesmolloy.co.uk/tutorial_h ... sking.html)
inside its fork(),

Code: Select all

 // We could be the parent or the child here - check.
   if (current_task == parent_task)
   {
       // We are the parent, so set up the esp/ebp/eip for our child.
       u32int esp; asm volatile("mov %%esp, %0" : "=r"(esp));
       u32int ebp; asm volatile("mov %%ebp, %0" : "=r"(ebp));
       new_task->esp = esp;
       new_task->ebp = ebp;
       new_task->eip = eip;
       // All finished: Reenable interrupts.
       asm volatile("sti");

       return new_task->id;
   }

i think something is wrong with new_task->esp; new_task->ebp ,
since new_task still using parent_task's stack after such code.
they should point to somewhere inside new_stack->kernel_stack.
we need to first copy_kernel_stack from parent task to child, and fix the ebp,
then write:

Code: Select all

u32int offset =  new_task->kernel_stack - parent_task->kernel_stack;
new_task->esp = esp + offset; 
new_task->ebp = ebp + offset;

maybe need to add code and explaintions or at least mention that in
http://www.jamesmolloy.co.uk/tutorial_h ... 0Mode.html

btw, is this forum's moderator "JamesM" the author of the tutorial, you're my idol!

[thomasloven]

That shouldn't be a problem.
After fork() you have two address spaces. One for the parent task and one for the child. Those are clones from a virtual standpoint, i.e. things like kernel_stack is mapped to the same virtual address, but different physically.
That means when you access kernel_stack from one process, the request is routed to one page in physical memory, and when you access it from another process, it's routed to another physical page.

The exception to this is kernel structures, which are the same through all address spaces, and therefore are routed to the same physical pages in every case. You should make sure your stack is not inside one of those pages.

[orafy]

well, you're right in theory, but in his tutorial, it's kernel_stack = kmalloc_a(..), which is dynamically allocated on kernel heap.
And address space of kernel heap remains same in every taski n his clone_directory implementation.
i encouter such things in debugger:
kernel heap starts from 0xc0000000
parrent_task's esp = child_task's esp = 0xc0089000
the page's frame of 0xc0089000 not get copied when clone_directory, since kernel_heap remains consistant in every task.

[thomasloven]

That's what move_stack() is for.
In the tutorial the stack is moved to 0xE0000000, which is far away from anywhere mapped in kernel_directory.

[piranha]

(I just started actually learning this stuff, so correct me if I'm wrong). Thats where the stack is, but since the kernel uses usermode, it switches to the kernel stack on a syscall so that its preemptible.

In my kernel, which has a tasking system based heavily off of those tutorials, I kmalloc a new kernel stack for the child, copy the stack from the parent to the child, and then calculate the offsets and use those values as esp and ebp. While I'm just assuming that this is the right approach, it seems to work perfectly.

The exception to this is kernel structures, which are the same through all address spaces, and therefore are routed to the same physical pages in every case. You should make sure your stack is not inside one of those pages.

It always is. Well, nearly always.

-JL