The NetBSD Project

CVS log for src/sys/kern/kern_lock.c

[BACK] Up to [cvs.NetBSD.org] / src / sys / kern

Request diff between arbitrary revisions


Default branch: MAIN
Current tag: netbsd-8-0-RC2


Revision 1.158.6.2 / (download) - annotate - [select for diffs], Sat Jan 13 21:57:11 2018 UTC (6 years, 2 months ago) by snj
Branch: netbsd-8
CVS Tags: netbsd-8-2-RELEASE, netbsd-8-1-RELEASE, netbsd-8-1-RC1, netbsd-8-0-RELEASE, netbsd-8-0-RC2, netbsd-8-0-RC1
Changes since 1.158.6.1: +5 -5 lines
Diff to previous 1.158.6.1 (colored) to branchpoint 1.158 (colored)

Pull up following revision(s) (requested by ozaki-r in ticket #495):
	lib/librumpuser/rumpfiber.c: revision 1.13
	lib/librumpuser/rumpuser_pth.c: revision 1.46
	lib/librumpuser/rumpuser_pth_dummy.c: revision 1.18
	sys/kern/kern_condvar.c: revision 1.40
	sys/kern/kern_lock.c: revision 1.161
	sys/kern/kern_mutex.c: revision 1.68
	sys/kern/kern_rwlock.c: revision 1.48
	sys/rump/include/rump/rumpuser.h: revision 1.115
	sys/rump/librump/rumpkern/locks.c: revision 1.76-1.79
Apply C99-style struct initialization to lockops_t
--
Tweak LOCKDEBUG macros (NFC)
--
Distinguish spin mutex and adaptive mutex on rump kernels for LOCKDEBUG
Formerly rump kernels treated the two types of mutexes as both adaptive for
LOCKDEBUG for some reasons.
Now we can detect violations of mutex restrictions on rump kernels such as
taking an adaptive mutex with holding a spin mutex as well as normal kernels.
--
rump: check if the mutex is surely owned by the caller in mutex_exit
Unlocking a not-owned mutex wasn't detected well (it could detect if the mutex
is not held by anyone but that's not enough). Let's check it (the check is the
same as normal kernel's mutex).
If LOCKDEBUG is enabled, give the check over LOCKDEBUG because it can provide
better debugging information.

This form allows you to request diff's between any two revisions of a file. You may select a symbolic revision name using the selection box or you may type in a numeric name using the type-in text box.




CVSweb <webmaster@jp.NetBSD.org>