| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
ok kettenis@, visa@
|
|
|
|
|
|
|
| |
Remove `mtx_lock' from i386, add volatile before `mtx_owner' where it
was missing.
Inputs from kettenis@, ok visa@
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
this is largely based on src/sys/arch/alpha/alpha/mutex.c r1.14 and
src/sys/arch/sgi/sgi/mutex.c r1.15
always and explicitely record which cpu owns the lock (or NULL if
noone owns it). improve the mutex diagnostics/asserts so they operate
on the mtx_owner field rather than mtx_lock. previously the asserts
would assume the lock cpu owns the lock if any of them own the lock,
which blows up badly.
hppa hasnt got good atomic cpu opcodes, so this still relies on
ldcws to serialise access to the lock.
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.
tested by and ok kettenis@ jsing@
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Tested by juanfra@
|
|
|
|
|
|
|
|
| |
having mutexes on the stack, like dlg@ added recently to the scsi code,
doesn't work on hppa. So instead of relying on mutexes being properly
alligned just reserve 4 words and use the one that has the proper alignment.
ok miod@
|
|
|
|
| |
ok kettenis@
|
| |
|
|
|