Implementing TLS: step 1

[Daniel Eischen]

On Thu, 19 Jun 2003, Daniel Eischen wrote:

> On Thu, 19 Jun 2003, Marcel Moolenaar wrote:
> > On Thu, Jun 19, 2003 at 04:12:50PM -0700, Julian Elischer wrote:
> > > 
> > > 
> > > BTW Marcel, I think that we can get from where we are now with kse to
> > > what we need by just a little massaging of what points to what.
> > > it is possible that the register %gs could be pointed to the thread
> > > structure directly and we could derive the KSE from that. it will just
> > > make the context switches a fraction more expensive if we need to
> > > change the segment register..
> > 
> > Yes. On i386 because the indirection through %gs:0x0 allows having %gs
> > point anything we like: the KSE. On ia64 there's room for a pointer at
> > offset 8 in the TLS that we can use to point to whatever we like.  That
> > context switches involve an additional pointer fiddle to make sure we
> > always have the indirection to the KSE is something I don't worry about.
> 
> Currently, the libkse TLS pointer has to point to the KSE mailbox.
> It is necessary to be able to set a word in the KSE mailbox in 1
> instruction.  The KSE mailbox "current thread pointer" must be
> set to NULL to prevent upcalls.  Indirecting to get to the
> mailbox pointer in order to set it leaves open a race condition
> where the TLS changes out from under us before we set it.
> So if TP can't point to the KSE mailbox, then there needs to
> be other changes in the kernel and libkse.

Perhaps we can just read and clear the TP register
in order to prevent upcalls?  Once read, we can access
the KSE (through indirection if necessary), set
km_curthread to NULL, then restore the TP register.

I think that would work, except the kernel would need
MD code to detect whether upcalls were disabled or not.

Just thinking out loud...

-- 
Dan Eischen