kernel: Rewrite KDEBUG_RW_LOCK_DEBUG.

Previously this just turned the rw_lock into the equivalent of a
recursive_lock, which meant that reader vs. writer assertions
were of no use.

Now, we have a per-thread static array which stores the held read
locks, allowing ASSERT_READ_LOCKED_RW_LOCK to work properly,
and allowing multiple readers to be active at a time.

This probably should still remain disabled even on nightly builds,
but at least it's much more useful as a debugging tool than it was
beforehand.

Change-Id: I386b2bc2ada8df42f4ab11a05563ef22af58e77f

kernel/locks: De-duplicate two inlined methods.

The functions declared in locks.h were and are exactly identical
to these inline blocks of code. So, rather than duplicate them,
just invoke them directly. The compiler will probably inline them
anyway.

kernel/locks: Implement lock switching for recursive_lock.

This allows switching from another recursive_lock, mutex or read-locked
rw_lock analogous to the switching possibilities already in mutex.

With this, recursive_locks can be used in more complex situations where
previously only mutexes would work.

Also add debugger command to dump a recursive_lock.

Change-Id: Ibeeae1b42c543d925dec61a3b257e1f3df7f8934
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2834
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

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 <waddlesplash@gmail.com>

kernel/locks: Tweak mutex_unlock KDEBUG semantics slightly.

Previously, both the "old" owner and the "new" lock owner set
the lock holder to the "new" lock holder. Now the old owner does
it before calling unblock(), and we check in the lock() functions
that we are indeed the new owner of the lock.

This may affect what the panic is for #15211 and its duplicates:
I have a suspicion that these threads are getting unblocked
when they have no business being unblocked, and this should
catch that condition.

kernel: Add and fix ownership checks in mutex_destroy and mutex_transfer.

* mutex_destroy() only checked wether or not there were waiters,
not if the lock itself was presently held by another thread.
Now we do, which should make #15015 panic much earlier instead
of trying to use freed memory.
* mutex_transfer_lock() and recursive_lock_transfer_lock() did
not check that the calling thread actually owned the lock.
Now it does, which should trigger asserts if anyone tries
to do this.

kernel: Add interrupts checks for switch_lock functions.

kernel/locks: Don't panic on interrupts disabled in unlock().

We don't reschedule or block in here, so checking for interrupts
is needlessly strict. Sorry for the noise, forgot to remove this
before the previous commit.

kernel: Add checks for interrupts in rwlocks.

recursive_locks, mutexes, and semaphores already have them.

kernel: Check for uninitialized locks in mutex_trylock().

We already do this in mutex_lock() and variants.

kernel: Tweak some mutex functions.

* Remove code duplication.
* Make _mutex_trylock work in non-KDEBUG kernels. This should fix
spurious failures to lock in drivers compiled for KDEBUG kernels
running under non-KDEBUG kernels.

More trivial syntax and logic cleanup.

Spotted by Clang. No functional change intended.

kernel: Reset lock holder and count on mutex_destroy().

Previously, there were a number of circumstances where these were
not getting reset properly, leading to some destroyed mutexes having
holders of the last thread which locked them, and some with "-1",
which meant that the next call to "mutex_lock" just behaved as if
the lock was still valid (!), and so the unlucky caller would deadlock
forever.

Now we properly reset these fields, which means from now on attempts to
lock or unlock destroyed mutexes will lead to "PANIC: uninitialized mutex"
on KDEBUG kernels, and (as before) an infinite deadlock on non-KDEBUG
kernels (perhaps we should store the thread_id of the locker on non-KDEBUG
kernels also?).

As the next commits will show, this already uncovered a number of bugs,
and there are of course potentially more strange deadlocks caused by this.

UserlandFS: Make 64 bit clean and enable build for x86_64.

I did not bother to fix the BeOS kernel emulation, so this part is
still left out of the x86_64 build.

kernel, drivers: Fix gcc2 build

kernel: Make sure mutex::holder is set to a valid value

kernel: Add thread_unblock() and use it where possible

kernel/lock: Do not use *_locked() functions when not needed

kernel: Protect lock internals with per-lock spinlock

64-bit fixes for kernel with KDEBUG_LEVEL = 0

Signed-off-by: Alex Smith <alex@alex-smith.me.uk>

More 64-bit compilation/safety fixes.

Merged signals-merge branch into trunk with the following changes:
* Reorganized the kernel locking related to threads and teams.
* We now discriminate correctly between process and thread signals. Signal
handlers have been moved to teams. Fixes #5679.
* Implemented real-time signal support, including signal queuing, SA_SIGINFO
support, sigqueue(), sigwaitinfo(), sigtimedwait(), waitid(), and the addition
of the real-time signal range. Closes #1935 and #2695.
* Gave SIGBUS a separate signal number. Fixes #6704.
* Implemented <time.h> clock and timer support, and fixed/completed alarm() and
[set]itimer(). Closes #5682.
* Implemented support for thread cancellation. Closes #5686.
* Moved send_signal() from <signal.h> to <OS.h>. Fixes #7554.
* Lots over smaller more or less related changes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42116 a95241bf-73f2-0310-859d-f6bbb57e9c96

Merged the signals branch into trunk, with these changes:
* The team and thread kernel structures have been renamed to Team and Thread
respectively and moved into the new BKernel namespace.
* Several (kernel add-on) sources have been converted from C to C++ since
private kernel headers are included that are no longer C compatible.

Changes after merging:
* Fixed gcc 2 build (warnings mainly in the scary firewire bus manager).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40196 a95241bf-73f2-0310-859d-f6bbb57e9c96

Added rw_lock_read_lock_with_timeout().


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37680 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Moved created subdirectory src/system/kernel/lock.cpp to new subdirectory
locks.
* Added syscalls for a new kind of mutex. A mutex consists only of an int32 and
doesn't require any kernel resources. So it's initialization cannot fail
(it consists only of setting the mutex value to 0). An uncontended lock or
unlock operation can basically consist of an atomic_*() in userland. The
syscalls (when the mutex is contended) are a bit more expensive than semaphore
operations, though.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36158 a95241bf-73f2-0310-859d-f6bbb57e9c96

UserlandFS: Make 64 bit clean and enable build for x86_64.

I did not bother to fix the BeOS kernel emulation, so this part is
still left out of the x86_64 build.

kernel, drivers: Fix gcc2 build

kernel: Make sure mutex::holder is set to a valid value

kernel: Add thread_unblock() and use it where possible

kernel/lock: Do not use *_locked() functions when not needed

kernel: Protect lock internals with per-lock spinlock

64-bit fixes for kernel with KDEBUG_LEVEL = 0

Signed-off-by: Alex Smith <alex@alex-smith.me.uk>

More 64-bit compilation/safety fixes.

Merged signals-merge branch into trunk with the following changes:
* Reorganized the kernel locking related to threads and teams.
* We now discriminate correctly between process and thread signals. Signal
handlers have been moved to teams. Fixes #5679.
* Implemented real-time signal support, including signal queuing, SA_SIGINFO
support, sigqueue(), sigwaitinfo(), sigtimedwait(), waitid(), and the addition
of the real-time signal range. Closes #1935 and #2695.
* Gave SIGBUS a separate signal number. Fixes #6704.
* Implemented <time.h> clock and timer support, and fixed/completed alarm() and
[set]itimer(). Closes #5682.
* Implemented support for thread cancellation. Closes #5686.
* Moved send_signal() from <signal.h> to <OS.h>. Fixes #7554.
* Lots over smaller more or less related changes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42116 a95241bf-73f2-0310-859d-f6bbb57e9c96

Merged the signals branch into trunk, with these changes:
* The team and thread kernel structures have been renamed to Team and Thread
respectively and moved into the new BKernel namespace.
* Several (kernel add-on) sources have been converted from C to C++ since
private kernel headers are included that are no longer C compatible.

Changes after merging:
* Fixed gcc 2 build (warnings mainly in the scary firewire bus manager).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40196 a95241bf-73f2-0310-859d-f6bbb57e9c96

Added rw_lock_read_lock_with_timeout().


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37680 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Moved created subdirectory src/system/kernel/lock.cpp to new subdirectory
locks.
* Added syscalls for a new kind of mutex. A mutex consists only of an int32 and
doesn't require any kernel resources. So it's initialization cannot fail
(it consists only of setting the mutex value to 0). An uncontended lock or
unlock operation can basically consist of an atomic_*() in userland. The
syscalls (when the mutex is contended) are a bit more expensive than semaphore
operations, though.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36158 a95241bf-73f2-0310-859d-f6bbb57e9c96