Hi,
Js2xxx wrote:
Brendan wrote:
You can enable IRQs again
Well, I think if so, scheduler will mess the stack up again.
So what if I mask the timer and sti and cli and then unmask the timer?
Most IRQ handlers may end up triggering a task switch for various reasons (e.g. because data that a task was blocked/waiting for arrived), so disabling the timer IRQ shouldn't help.
If the kernel is supposed to be pre-emptable; you'd want to fix the scheduler (e.g. have a special kind of lock that causes task switches to be postponed if anything triggers a task switch) so that it doesn't matter if any IRQ interrupts a syscall (even if the IRQ triggers a task switch, and even if the syscall triggers a task switch).
Js2xxx wrote:
EDIT: My syscall handler works well when there's only one thread calling the system. But it reboots when two threads call the system at the same time. Bochs says there's three canonical failure.
So how to solve this problem?
EDIT AGAIN: I think the three canonical failure is this: When the second thread calls the system. The swapgs instruction is executed again. My original gs base is 0 so rsp will be loaded a non-canonical value. Then a push instruction causes #SS. But it's CPL = 0 now, so rsp will not change and the push instruction in exception handler will causes a double fault. However, according to the text above, it reboots. So I think I should set IST to the exception handlers. But how do I solve the first canonical failure?
From this I'd assume that your scheduler is unstable, and syscall just exposes pre-existing bugs.
Cheers,
Brendan