wireguard-openbsd/sys/arch/alpha/include/mutex.h, branch jd/queueboostsWireGuard implementation for the OpenBSD kernelhttps://git.zx2c4.com/wireguard-openbsd/atom/sys/arch/alpha/include/mutex.h?h=jd%2Fqueueboosts2018-01-25T15:06:29ZMove common mutex implementations to a MI place.2018-01-25T15:06:29Zmpimpi@openbsd.org2018-01-25T15:06:29Zurn:sha1:710c2d98ef6b48aed52cf1712826535b248055bf
Archs not yet converted can to the jump by defining __USE_MI_MUTEX.
ok visa@
Define and use IPL_MPFLOOR in our common mutex implementation.2018-01-13T15:18:11Zmpimpi@openbsd.org2018-01-13T15:18:11Zurn:sha1:4965d1a4536ae31f44fece9aedf52ba3da2c14fb
ok kettenis@, visa@
Unify <machine/mutex.h> a bit further.2018-01-04T11:03:48Zmpimpi@openbsd.org2018-01-04T11:03:48Zurn:sha1:4c6d9147fe2ff541db95dc25133e4e496d9a3e8a
Remove `mtx_lock' from i386, add volatile before `mtx_owner' where it
was missing.
Inputs from kettenis@, ok visa@
Hook up mutex(9) to witness(4).2017-04-20T13:57:29Zvisavisa@openbsd.org2017-04-20T13:57:29Zurn:sha1:c4925651028d655edda3c8b85b8d1b4a0cda6fb9while trying to reproduce lockups on mp alpha i hit an2015-04-17T12:38:54Zdlgdlg@openbsd.org2015-04-17T12:38:54Zurn:sha1:2d14ba29e46207fdcc52c0a8fb6573bfd9fa81c6
MUTEX_ASSERT_UNLOCKED, but it turns out alpha mutexes arent very
friendly to diagnostics on smp systems.
alpha mutexes contained an mtx_lock member. when 0 the mutex was
unlocked, and when 1 it was locked. the MUTEX_ASSERT_UNLOCKED checked
if mtx_lock was 1 to see if the current cpu owned the mutex, but
in an mp system another cpu may have set mtx_lock to 1, which causes
the assert to fire.
this changes alpha mutexes so they record which cpu owns the lock
rather than just if the lock is held or not. the diagnostics compare
the owner to the current cpus curcpu() address so they can actually
tell if the current cpu holds the lock instead of whether any cpu
holds the lock.
instead of using custom asm to implement a cas this uses atomic_cas_ptr,
which on alpha uses gcc cas code. miod says he has far more confidence
in the gcc cas than the code that was there before.
while im here i also shuffled the code. on MULTIPROCESSOR systems
instead of duplicating code between mtx_enter and mtx_enter_try,
mtx_enter simply loops on mtx_enter_try until it succeeds.
this also provides an alternative implementation of mutexes on
!MULTIPROCESSOR systems that avoids interlocking opcodes. mutexes
wont contend on UP boxes, theyre basically wrappers around spls.
we can just do the splraise, stash the owner as a guard value for
DIAGNOSTIC and return. similarly, mtx_enter_try on UP will never
fail, so we can just call mtx_enter and return 1.
ok miod@
To prevent lock ordering problems with the kernel lock, we need to make sure2014-03-18T21:09:28Zketteniskettenis@openbsd.org2014-03-18T21:09:28Zurn:sha1:bb51cfd138ffdff4d1254927781bac190a9da13f
we block all interrupts that can grab the kernel lock. The simplest way to
achieve this is to make sure mutexes always raise the ipl to the highest
level that has interrupts that grab the kernel lock. This will allow us
to have "mpsafe" interrupt handlers at lower priority levels.
No change for non-MULTIPROCESSOR kernels.
ok miod@
In MUTEX_ASSERT_LOCKED, check we are the mutex owner if MULTIPROCESSOR.2014-01-28T22:04:07Zmiodmiod@openbsd.org2014-01-28T22:04:07Zurn:sha1:bafb89d1af8ebb43c03093e19c0a6f3ce5d6070cWork in progress work towards SMP, heavily based upon NetBSD. The MP kernel2014-01-26T17:40:09Zmiodmiod@openbsd.org2014-01-26T17:40:09Zurn:sha1:21c23d01e5ede77407e8bb39e92ce0cee988c51a
will boot multiuser, but will deadlock under load, and I can't find my
mistake yet.
Normalize sentinel. Use _MACHINE_*_H_ and _<ARCH>_*_H_ properly and consitently.2011-03-23T16:54:33Zpiroftipirofti@openbsd.org2011-03-23T16:54:33Zurn:sha1:2fa72412907ae78c4787a4a8f888c5f0486e225c
Discussed and okay drahn@. Okay deraadt@.
Alpha needs (will need) MUTEX_OLDIPL as well.2007-05-10T18:08:13Zartart@openbsd.org2007-05-10T18:08:13Zurn:sha1:81e4d8e6bdf7e19262d4134ec2c649d4b84c0ec2