Sharing locks between several address spaces

Sven Fülster mx at ...19...
Tue Oct 20 11:59:28 CEST 2009


Hi there,

I'm working on two applications which require communication over shared 
memory.

Therefore, I've adapted some of your datastructures (such as the slab 
allocator, semaphores and locks) so that they are safe to be shared 
between different address spaces, by adding smart pointers and taking 
care of having all shared components (like the Applicant list of the 
locks, the applicants and the locks themselves) within the shared memory.

I have now a little problem with the locks.

I have a thread in address space 1 which performs a lock operation on a 
lock in shared memory. The lock operation is (by default) mapped to the 
L4_Stop syscall (I work with the Okl4-Kernel).

Another thread in address space 2 performs a wake-operation on the same 
lock (where the thread id is deposited in the applicant), which is 
mapped to L4_ThreadSwitch which is again mapped to the 
L4_ExchangeRegisters syscall.

This operation does not wake the first thread.

In detail, the L4_ThreadWasHalted call which is performed upon 
L4_ThreadSwitch returns false, hence the thread which tried the wake 
operation remains spinning in the forever-loop (this is a nice 
opportunity for a denial-of-service-attac of a malicious client by the 
way...).

However, I've started to investigate by replacing the L4_ThreadSwitch 
syscall by L4_WaitNotify and the wake-operation by L4_Notify. The result 
was the same.

Checking the error code of the L4_Notify syscall with L4_ErrorCode 
showed that the call had been aborted due to L4_ErrInvalidThread, 
respectively L4_ErrNonExist (2).

Now I wonder if a thread is generally allowed to invoke syscalls on 
threads which don't belong to its address space (maybe I need some 
capability? What exactly is env()->pd_session()->bind_thread() for?).

I've also noticed that the thread ids I get from 
env()->cpu_session()->state() or from thread_get_my_native_id() differ 
from those the kernel debugger shows (what exactly do you do when you 
ask  Okl4::__L4_TCR_ThreadWord(Genode::UTCB_TCR_THREAD_WORD_MYSELF) for 
a thread id? Is that the global thread id?)

Perhaps you have an idea what's going wrong here (meanwhile I'd add 
L4_MutexControl to core :o) ).

With kind regards

Sven
--
Sven Fülster








More information about the users mailing list