Kernelspace - SPI Write/Read Funktion - Mutex

"A successful call for a mutex lock by way of mutex_lock() will cause 
another thread that is also trying to lock  the same  mutex  to  block 
until  the  owner  thread  unlocks it by way of mutex_unlock(). Threads 
within the same process or  within  other  processes can share mutexes."

Ergo wird so beim zweiten Call der Kernelthread geblockt, was natürlich 
keine gute Idee ist. Ist zwar lange her, aber wenn ich mich recht 
erinnere willst du da eher mutex_trylock benutzen und dann später 
nochmal versuchen. (Daten ggfs. queuen)

David Brandt schrieb:
> Ergo wird so beim zweiten Call der Kernelthread geblockt, was natürlich
> keine gute Idee ist.

Aber genau das ist doch dass, was man hier will. Der zweite Thread 
wartet bis der erste fertig ist und gibt den Mutex freigibt.
Ein TryLock würde ja nur feststellen, dass der Mutex schon benutzt wird 
und dann müsste man selber immer wieder nachfragen.

Oder steh ich da gerade auf dem Schlauch ?

Grüße
Andreas

Hans Ulli Kroll schrieb:
> Kommt der Fehler nihct aus dem Userspace ??
> dhclient ??

Definitiv nicht. dhclient ist der aktuell laufende Prozess beim 
Auftreten des Bugs. In diesem Fall wird es wohl durch einen Systemaufruf 
von dhclient ausgelöst worden sein, ist aber immer noch ein Bug im 
Kernel-Code.