kernel/locks: Remove ignore_unlock_count and fix races in lock timeout.

As far as I can tell, there is no reason to ignore unlocks, ever;
if no threads are waiting, then mutex_unlock() will act appropriately.
So all we need to do is increment the lock's count here,
as we are relinquishing our request for locking.

On the other hand, if we did not find our structure in the lock,
that means we own the lock; so to return with an error from here
without changing the count would result in a deadlock, as the lock
would then be ours, despite our error code implying otherwise.

Additionally, take care of part of the case where we have woken up
by mutex_destroy(), by setting thread to NULL and checking for it
in that case. There is still a race here, however.

May fix #16044, as it appears there is a case where ACPICA
calls this with a timeout of 0 (we should make this be
a mutex_trylock, anyway.)

Change-Id: I98215df218514c70ac1922bc3a6f10e01087e44b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2716
Reviewed-by: waddlesplash <[email protected]>

This commit is contained in:

Augustin Cavalier

2020-05-17 00:22:15 +00:00

committed by

waddlesplash

parent 785518beef

commit fd161d7bf2

2 changed files with 19 additions and 20 deletions

									
										headers/private/kernel/lock.h
									
		-2
	
												View File
												
				@@ -24,10 +24,8 @@ typedef struct mutex {

					spinlock				lock;

				#if KDEBUG

					thread_id				holder;

					uint16					_unused;

				#else

					int32					count;

					uint16					ignore_unlock_count;

				#endif

					uint8					flags;

				} mutex;