KSE/ia64 & thr_spinlock.c:1.18: problem identified

[Marcel Moolenaar]

On Thu, Nov 27, 2003 at 01:22:30AM -0500, Daniel Eischen wrote:
> On Wed, 26 Nov 2003, Marcel Moolenaar wrote:
> 
> > Ok,
> > 
> > I found what the problem is. Syscalls that got interrupted were not
> > restarted when they should be. This is the result of using the KSE
> > internal context functions, when we should be going through the
> > kernel. So, the end result is that we do in fact need a syscall to
> > switch KSE contexts. Attached a patch to add such syscall. Please
> > review (ia64 specific changes to make use of the syscall are not
> > included).
> 
> We don't need this for x86 or amd64, at least AFAICT, correct?

Correct. There's no difference between a synchronous context and
an asynchronous context. The context that the kernel creates for
syscalls either point to the interrupt instruction or immediately
after it. In all cases, the way you enter the kernel is the same.
On ia64 we use the normal call/return mechanism to enter the
kernel for syscalls. Restarting a syscall is therefore slightly
more complex. Enter kse_switchin().

> How does a context get marked so one knows that you need to use
> kse_switchin()?

I currently mark it as synchronous with valid scratch registers.
Userland contexts are synchronous, but don't have valid scratch
registers. I plan rename flags after the dust has settled to make
it more explicit.

> BTW, why do we have to go through the kernel for ia64 in this
> case?

Only the kernel can restart a syscall because the arguments can
get clobbered (and are). Also, since we're using a call/return
machanism, there's no safe way to construct a context that calls
the kernel again.

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel at xcllnt.net