Opened 15 years ago

Closed 15 years ago

Last modified 15 years ago

#100 closed defect (fixed)

Exceptions should not be handled in a dedicated CPU mode

Reported by: Jakub Jermář Owned by: Vineeth Pillai
Priority: major Milestone: 0.4.1
Component: helenos/kernel/arm32 Version: mainline
Keywords: arm Cc:
Blocker for: Depends on:
See also:


So far, IRQs have ben handled in the "undefined" processor mode, while the syscalls and kernel threads execute in the "supervisor" mode. This looks like a design inconsistency, because e.g. the timer interrupt can result in a scheduler call, proliferating thus the "undefined" CPU mode to unrelated parts of the kernel. Moreover, nested interrupts have very interesting interactions which resulted in (not very correct) workarounds such as that of revision 4652.

What should be done instead is to have some sort of "preemptible" trap handler for all kinds of exceptions. The goal of this preemptible trap handler is to save the necessary state to the memory stack and switch to the CPU mode, which is used for running normal kernel code. Then the respective C handler would be called and after it returns, the interrupted state would be restored.

The normal kernel CPU mode can be either the "system" mode or the "supervisor" mode.

Change History (5)

comment:1 by Vineeth Pillai, 15 years ago

Owner: set to Vineeth Pillai
Status: newaccepted

comment:2 by Vineeth Pillai, 15 years ago

I have committed the fix in the arm branch. With the latest commit(4665), exception handling works as follows:
1)If the exception is raised while in user mode, we switch to the supervisor mode and changes the stack to kernel stack of the thread. Then we create the stack frame and calls the exc_dispatch().
2)If exception is raised while in non-user mode, then it is guaranteed that the previous mode was supervisor mode. This is because, we don't have the interrupts enabled in any other non-user mode. So we switch to the previous mode and then create the stack frame. Then we call exc_dispatch().

So the kernel code is always running in supervisor mode from this commit onwards. This makes the exception handling re-entrant.

This commit didn't take care of the ticket #93. As of now, even though the exception handler is a C function, it is purely inline assembly. The problem arises only during build with zero optimization and -g flag.

I am working on #93 now and hopes to get it fixed ASAP!

comment:3 by Jakub Jermář, 15 years ago

Resolution: fixed
Status: acceptedclosed

Fixed in revision 4666 and merged into trunk in revision 4669.

in reply to:  3 comment:4 by Jakub Jermář, 15 years ago

Replying to jermar:

Fixed in revision 4666 and merged into trunk in revision 4669.


comment:5 by Jakub Jermář, 15 years ago

Note: See TracTickets for help on using tickets.